Contents tagged with General Software Development
-
The Enterprise Architect (EA) diary - Day 34-36 (Information Architecture)
Although enterprise architecture consider to be based on four domains (Business, Information, Applications and technology) for me the business and information domains are more important to become successful enterprise architect. There aren’t any doubts about the need to understand what is driving the business and what and how the business is reaching (and planning to reach) it strategy. Business architecture is crucial to make sure that IT is really supporting and planned to increase IT’s business support. Information architecture, which is critical for EA success is usually hide as sub domain of application architecture or doesn’t get the right attitude and resources.
-
The Enterprise Architect (EA) diary - day 22 (from business processes to implemented applications)
After spending time on keeping our repository up to date (add new ETRM application and related data flows as well as changing databases to DB clusters), collecting more data for the root cause analysis and spending time for writing proposal to creating new software infrastructure team ( that will help us to clean the table from a pile of problems that just keep on growing due to BAU control over IT dev team resources). I spend time to adapt our EA tool to support a diagram flow from high level business processes to implementation of new applications that will better support the business process. http://www.theeagroup.net/ea/Default.aspx?tabid=1&newsType=ArticleView&articleId=195
-
The Enterprise Architect (EA) diary - day 15-20 (IT architecture)
We’re working on IT architecture or more accurate to-be architecture for very long time. After we spend time to model and understand what IT has to offer as well as what the business is doing (and need) to reach company’s goals and objectives, we started to work on the to-be architecture in two phases.
-
Plan your budget and reduce risks by aligning enterprise products road maps to the vendor road maps.
Vendors tend to publish roadmaps for their products. Those roadmaps include when the product schedule to be replaced with new version, when the product regular support will be replaced with extended support and when the vendor won’t support certain product version.
-
Real Example of Enterprise Architecture Values
This time I'm sharing a list of EA values of mature EA practice. This customer is a leading company in the utilities industry with aggressive business strategy of merge and acquisition. as a result they have continues challenge of merging IT units together.
-
Case study of not successful EA practice
After posting three case studies of successful enterprise architecture practices and discussing common EA pitfalls I decided that it’s the time to present a case study of en enterprise architecture practice that didn’t manage end up successfully.
-
10 EA pitfalls that a real EA implementation might experience
-
Doing EA just for the sake of EA:
Enterprise architecture is a mean to reach a goal.
If you don’t know what is your goal and how you'll
use enterprise architecture to reach this goal, you
fall into the most common and painful pitfall. There
should be at least one goal; like to reduce IT
cost, better planning and executing of IT, dealing
with compliance requirements or even migrating
legacy applications to new platform. If you cant
provide clear goals and explain how EA is serving
you, you're doing enterprise architecture for the
sake of enterprise architecture. Regretfully doing
EA for the sake of EA will bring your initiative to
complete failure.
-
Weak political skills of EA lead:
I once wanted to write an article about "The
election of new enterprise architecture" :-), I
might do it in the future. Doing enterprise
architecture is usually involved in many changes
that enterprises need to go through. Changes from
any types are not easy to digest by employees. In
order to introduce and implement a change one need
to be a real political animal to survive in the
jungle and make the jungle a better place. If the
enterprise architecture team leader is missing
political skills, the project is also doomed to be
failed.
-
No measuring and selling of EA: as
any thing else that we are doing in life we need to
make sure that other people understand the
importance and contribution of enterprise
architecture to the enterprise. It's not enough that
we as a team are very happy and the CIO is happy as
well. We need the entire enterprise to understand
what is our contribution. To sell our enterprise
architecture work we need to put some efforts in
collecting data and measuring what is the enterprise
architecture contribution. For example if we were
after IT cost reduction as a goal, we want to show
how much money on time scale we managed to save to
the enterprise and how much money we'll save in the
future.
-
Lack of short term outcomes : long
enterprise architecture projects without any
deliverables tend to fail as well. The scenario is
pretty known. We got a charter to start EA work and
we were told that we have a year to do our work and
show what we've done. But funny enough, the same guy
that told us to work for a year will loose his
patience if he won't show any deliverables after
three months. So if the scenario is known why not to
prevent it. Simply plan for deliverables every three
months and reduce pressure from you.
-
Not enough involvement in SDLC:
creating to-be architecture together with
principles, standards and blueprints is huge step
forward, but without making sure that what you set
will be done in reality (to some degree) you simply
will lost it all (or it will be equivalant to the
chiness great leap forward). In order to make sure
that you will affect IT landscape you need to be
fully involve in running projects. When I say
involvement I don't mean formal reviews as part of
the SDLC. What needed here is actual participant in
SDLC. You should be with the working teams to know
when EA principles clashing with project needs and
timelines to be able to influence. Finding that a
project is not compliance at all to enterprise
architecture when formal code review is done, is too
late. If the project approved by clients it will be
deployed no matter if it compliance to EA or
not.
-
Missing focus on Information:
there are two main types of focus while doing EA
project. It can be business focus or
Application/Technology focus. Few EA initiative that
I know are focus on information. Whether you like it
or not information is the bridge between business
and IT. Business can't perform business processes
without information (as input/output to each
processes task) and IT helps to manage Information
and manage processes. Most of the basic problems
that I found in enterprises have roots in
Information management. If Information isn't manage
correctly I bet that you'll find problems in
business processes as well as in application domain.
Focusing on information will not make your EA
success or failure, but it will certainly helps you
to achieve success.
-
Buried under business processes:
people tend to think that modeling all enterprise
processes is a good practice. It might be right, but
they forget about much more difficult task, which
is keeping business processes up to date. I found
out that using
business capabilities
mapping (just what, not how) I have enough data to
do my work. Usually I found myself modeling high
level business processes, but I never end up with
detailed modeling of all business processes.
-
Missing PMO / Finance control:
getting CEO/CIO or any executive support is nice but
not enough. If you want your enterprise architecture
to be successful you got to have teeth that can
bite. If you don't have teeth you'll find yourself
spending a lot of time to get the same thing that
you can get much more easily with teeth. The most
powerful set of teeth that I know is your ability to
control financial or PMO duties. So if you don’t
have any PMO/Financial control, try to get them
ASAP.
-
Wrong location in hierarchy:
never underestimate your group location in the
enterprise hierarchy. People might say that it
doesn't make any different, but there is a huge
different if your team directly under the CEO/CIO or
the team reports to director which reports to a VP
that reports to a VP and the VP reports to the CIO.
Again support is not enough , your location in the
hierarchy does matter.
-
Spending time on frameworks:
well, I make my living from creating frameworks for
enterprises, but I believe that it's a waste of
time. Don't waste months to create a framework based
on TOGAF, Zachman, FEAF or any other framework. Find
a pain-point and use your common sense (or
consultant experience) to resolve the pain-point
using enterprise architecture. Don't worry you'll
build your EA framework one way or another, just
following my approach you'll get success and credit
that are needed as well.
-
Doing EA just for the sake of EA:
Enterprise architecture is a mean to reach a goal.
If you don’t know what is your goal and how you'll
use enterprise architecture to reach this goal, you
fall into the most common and painful pitfall. There
should be at least one goal; like to reduce IT
cost, better planning and executing of IT, dealing
with compliance requirements or even migrating
legacy applications to new platform. If you cant
provide clear goals and explain how EA is serving
you, you're doing enterprise architecture for the
sake of enterprise architecture. Regretfully doing
EA for the sake of EA will bring your initiative to
complete failure.
-
What needed to be monitored to get better Governance
Collecting, modeling, validating and analyzing data from different domains to create to-be architecture in a form of principles, standards and blueprints are not enough to create successful enterprise architecture. The real challenge of enterprise architecture is the ability to make it happened in projects. If you can't find signs of enterprise architecture outcomes in running projects, all the work that you've done worth nothing. In this post I'll try to describe what are the main task that I'm doing to create successful enterprise architecture governance processes.
-
Communicate highly complex information to a broad audience
One of the common tasks that enterprise architects are dealing with on a daily basis is the need to explain complex IT issues to different audience, including non IT audience and CxO level. I can find many discussions around this requirement but I can hardly find any best practices or advices. In this post I'll try to share my experience and knowledge and I'll be happy to hear other experience as well.
-
Related EA posts of mine
How to retire (respectfully) legacy systems
Information Architecture - The bridge between
Business and IT
Business Capabilities and Business Strategy
Consolidation of CRM solutions
Creating IT strategy (with a little help from
enterprise architecture)
Enterprise Architecture Meta-model, size doesn't
matter
Enterprise architecture work Case studies
Using Enterprise Architecture for forecast and
implementation of Merges and Acquisition(M&A)
Using Enterprise Architecture to reduce IT costs ( a
cookbook for IT cost reduction)
Business Capabilities (a practical guide)
Using enterprise architecture for creating long term
IT planning (roadmaps)
What can be done with enterprise architecture
Principles as enterprise architecture outcome blueprint - an enterprise architecture outcome
How to build practical enterprise architecture
team
Modeling application dependencies Can enterprise architects be young?
Using Hungarian Cube to demonstrate enterprise
architecture
Enterprise architecture frameworks are dead, long
live real-life practice !
IT('s) Simple!
How to do inormation architecture (in 20 days)
What really makes you Enterprise Architect
Information Architecture (What need to be collected
and modeled)
Information Architecture (What is information
architecture)
Enterprise Architecture in SAP world
Sorting SA diagrams by EA domain
Reference model for EA definitions and views
What I expect from a vendor EA framework
Business concept
Worktures
It's not SOA it's IT 2.0
10 standards (including standard de facto) that
Enterprise Architect should know
Proven way to run your Enterprise Architecture
practice
The triangle of complexity and the square of success
for EA projects
What is a service (part II)
How to publish your EA work
SOA implementation types, from the Chinese city to
the European city What is a Service
The utopia of one dictionary for the enterprise
How your IT chassis will look like - Part 1
Are your IT vehicles based on one chassis?
Enterprise architecture modeling example
Enterprise architecture is just another systematic
approach
SOA, It’s not about the IT It’s about the
Business.
Business capabilities or business processes
The Data-Centric Enterprise: A Blueprint for EA -
Listen to the audio and watch the - slides! (Running
time: 59 minutes)
Does enterprise architecture serve only for long term
strategic plans?
Introducing NAAF.
Using enterprise architecture framework to map
services and set their granularity
The “Natty” method for monitoring and encouraging
systems compliance with the - enterprise
architecture
What are Enterprise architecture patterns and how we
should define them?
Enterprise architecture 10 common myths