Skip to Content

How to build practical enterprise architecture team

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 deliver

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)    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 group members.

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)    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 architecture team.

5)    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  architecturecontribution 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.

You must be Logged on to comment or reply to a post.
  • Good to see you back blogging here, Natty and your post is a nice counter-point to What is your title? which, though light-hearted, explores the world of titles/roles and touches on the EA.  Just a quick reminder that the use of “technology guys” perpetuates a model that is gender-biased, as one of our mentors was quick to point out in Vijay’s post.  Would be excellent to hear more about the EA teams of organizations.  I remember Cheryl Mascaro of Intel, sharing a look at her organization’s structure as regards this emerging team and role.  Cheryl spoke of Business Architecture teams at various TechEds and Sapphire events.
  • A common pitfall in an EA team is having no diversity withn the team in terms of skillset and background. You have a great gang of people (now that means both guys and gals…don’t rap me more :), i am sick today..have pity) who all have similar backgrounds. If eveyone is from say a technology background, they won’t have a deep enough understanding of data or business for example, and consequently have very biased decisions.