Enterprise architecture team might be the successful CIO
right hand (especially in today economic situation) or a group of people that
you can’t really understand what they are doing. A successful enterprise architecture
group will help you to reduce IT costs, optimize IT operation, make better IT
planning and keep the enterprise compliance with laws and regulations. The
problem is that in order to build a successful enterprise architecture group,
there is huge learning curve that CIOs need to go through. If you wish to
reduce your learning curve significantly, keep reading.
There are 5 main Steps that you have to understand and
follow. Because each step influences the others, I tried to order them by dependencies:
1) Have a clear understanding what EA means for your enterprise.
The term ‘Enterprise architecture’ has many definitions
running on a scale that moves from a purely business oriented definition to a
technological one. The first thing that you should do is to define your enterprise
architecture. Is it applications integration architecture from an enterprise
point of view? Is it business process re-engineering that will increase business
operation? Is it an attempt to align IT to business? Or is it a process of
understanding all of the enterprise domain building blocks (Business,
Information, Application, Technologies) and their relations to be able to
better run IT?
Every definition is legitimate and right, but each one of
them will take the enterprise architecture in a different path. Without a clear
definition of your enterprise architecture you will spend a lot of time to find
the definition on the move, causing changes in each one of the following steps
and increasing significantly your learning curve.
2) Define what are the results you expect your EA team to
Having the definition is not enough. Next step is to define
the results that you want your EA team to produce for you. Those results should
be explicit and followed by the deliverables expected from the team.
As I’ve argued above, the results and deliverables are the outcome
of your enterprise architecture definitions. Results and deliverables of
business oriented definitions will look different from technology oriented
definition of enterprise architecture.
Results and deliverables should be explicit. If your EA
definition is “a process of understanding all of the enterprise domain building
blocks and their relations to be able to better run IT”, the result should be:
IT long term planning showing better
alignment to business, BCP planning, Merge and Acquisition planning.
Decrease IT costs.
Increase IT availability
Increase compliance with laws and regulations.
The deliverables should be a list of reports, excel sheets,
visual views (Diagrams), dashboards or any specific outcomes you expect to see
from your EA team
3) Build the right team with the right people
Having EA definition, results and deliverables is the base
to start looking for the right personas for your team. Should you look for
technology guys, with specific knowledge in certain technologies or vast
knowledge of different technologies and trends? Should they be people with
business (industry) knowledge? Should they come from IT or from business teams?
Should they have modeling knowledge? In any specific standard (BPMN, EPC,
IDEFX, ERD, etc’)? Should they be more soft skill oriented people, with the
ability to reach common agreement or a combination of other soft skill characteristics?
Building a team before having enterprise architecture
definition and clear understanding of results and deliverables ends up with a group
of people who might be incompetent with regards to the task you want them to carry
out. Needless to say, after creating an EA group it won’t be easy to change the
Due to the fact that most CIOs simply don’t have time to
deal with the first two steps, a common approach is to hire one of the team
members or a consultant to go through the first two steps.
4) Invest time to build the team unique value
This is the most crucial step and the one that most
enterprise architecture teams are lacking. It’s not enough to take a group of
talented people, call them enterprise architects and close the deal. Let’s face
it- you (and others) listen and accept what the DBA, system analyst, software
architect, program manager, etc’ has to say in a discussion because they have
proven expertise in certain domains. The same principle has to be implemented
for enterprise architects. The problem is that if you take a group of people
with an existing knowledge of the enterprise, they won’t have any unique
knowledge to offer! In order to help them to have this unique value, some
investment will need to be made.
Again, the content depends on the context that we discussed
in steps one and two. If your enterprise architecture definition is based on
the ability of the enterprise architect to bring a holistic view of the
enterprise by introducing a knowledge of all the enterprise domains (business,
information, application and technology), then investing the time for collecting
and modeling all the needed data on those domains and their relations will make
the difference. (The same collecting and modeling of data can be applied if you
just focus on the enterprise technologies or applications).
This exercise helps enterprise architects to acquire
information and knowledge that are unique to them, especially when any other
roles are just focused on their own domain.
Having unique knowledge that is needed and appreciated by
CIO and other roles in the enterprise will make or break your enterprise
5) Demonstrate your EA team value in a short term project
When you have gone through all of the previous steps it’s
time to show what value enterprise architecture can bring to your enterprise.
Give the enterprise architecture team an assignment with a clear success / fail
indication that will be done within two to three months and will demonstrate
that your enterprise architecture team unique knowledge can contribute to the
enterprise in a way other roles couldn’t.
One of the hottest topics now is cost reduction, so pick an
area where you feel that your unique enterprise architects knowledge will help
them to gain success in a place where others didn’t and ask them for a result
within two to three months.
This short term project is important to the enterprise
architecture team from two perspectives- it helps them to gain self confidence
and understand what they are doing and how it helps the enterprise; it also helps
other roles in the enterprise to understand and value enterprise architecture
contribution to the enterprise.
One of the most common problems that enterprise architects
are facing is vagueness regarding what they need to do and how the CIO expects
them to do it. Sometimes as an enterprise architect you can feel like a child
that was asked by his father to bring some candy from the grocery store and
every time that he’s coming back home with new sweets his father’s sending him
back to the store because he doesn’t like what the child just brought him.
Having your enterprise architects in a similar position is harmful! Be as clear
as you can when explaining what you want and what are the outcomes that you
expect to see.