How to build practical enterprise architecture team
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) 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) 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) 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.
Summary
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.