Contents tagged with Enterprise Architecture
-
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 25-32 (Modeling & decentralized organization)
Working for company with different business units locating in different places around the world requires me to pay visits to our offices. In the last 6 days I paid a visit to our office in London and Manchester area (which belong to different business unit). The trip has two goals: to model changes in those offices current architecture and to reach an agreement regarding our target architecture (using the same principles and blueprints)
-
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.