Enterprise Architect Program for organization

The intended audience of this article are Enterprise Architects who are just starting with the role or are still going through the early phases and trying to establish EA practice in their organization.


From kick start to acceptance

1. First seek to understand. 
1. Don't do EA for EA's sake. Really seek to understand what clients want. Do they need and EA program to solve something critical to business. 
2. That might mean much more than having meetings and workshops. Use your experience as a seasoned professional to understand the enterprise, business strategy, actual stakeholders, pain points of the business, the key stake holders etc. Form a very clear idea of what needs to be addressed. Both in long term (no more than 3 years) and in short term (no less that 6 months). 
3. Put down the "problem statement" in as simple a way as possible and no simpler. Get the key stakeholders to write it down and / or be a part of the process where it is articulated and circulated. It will make it much easier for you to get them to endorse the problem - and lend their support to EA program should they choose to have one to solve the problem.  
4. Limit the scope of the "problem statement" by clearly calling out what will be delivered, and what will not be delivered. 
2. Once you have got the "problem" nailed down - please take that statement with a pinch of salt, for the "problem" statement is never really nailed down and any EA will be naive to not have periodic reaffirmation of the problem statement from the key stake holders - start by working backwards
1. What information do you need to solve the problem? When do you need it by? Who will provide it? Who controls the information? Are the providers and controllers of information bought in to the success of EA program? Does the EA program work against the vested interest of any of these key enablers? 
2. How do all these information link with each other. Which information is input to which decision which in turn leads to which information. This interrelation of inputs leading to the answer to a specific question is a framework. 
3. Pick a framework The different generalized framework are Zachman, TOGAF etc. The generalized framework - if you choose to pick one - is only the starting point. 
3. Don't succumb to the pressure of having to start with a solution. A solution - enterprise specific and unique to each enterprise - will emerge in due course of time if you start with a framework and let it evolve. 
1. EA solutions will be expected to fit the enterprise and it is not enough for them to be good for a project. 
2. It is better to have a solution that is good fit for the enterprise and might not fit all the projects like a glove. 
3. The trick is to come up with a framework that works for the enterprise and has extension points where the individual projects can put in their specific extensions, should they need to. 
4. Fetch data to feed into the framework - and hope it will lead to an answer. 
1. If you have worked hands on with technology till now, this is perhaps the most difficult mental blocker / challenge that you will have to face. For the first time in your career perhaps - the success of your job does not depend on your being able to find the right technology / api / tool / software. There is no right answer. At least there is no way to prove immediately that the answer that you get to, is right. 
2. Once you have defined the "problem", scoped it, closed on a "framework" , it is all about getting the correct, sufficient and relevant information to the framework. The solution might come from the management, from the production line, from the domain etc. 
3. So, plan that out. List down what you need (information, statistics, report ...), from where do you need (stakeholders, production line, chief executives, ...), how do you want to collect (interviews, workshops, online surveys ...). Determine the resources required to collect this - human, tools, archiving etc. Identify dependencies, key milestones. Put down in a plan. 
4. Go. Execute the plan.   
5. In an ideal world EAs output might have been 100% correct. In practical world - with moving business scenarios, transient business priorities, inherent issues around correctness of data - expect errors and educate key stakeholders to expect errors as well. 
1. It is another mental blocker / challenge that folks from software technology background will face. Those who are used to see their solutions compile, execute, see the solution solve the problem and be able prove that a problem is solved - will find themselves grappling with the concept that what they are striving for is "roughly right" and non demonstrable solution. 
2. In fact it is a sure set recipe for failure in all but the smallest of enterprises for an EA to strive for a demonstrable solution. The output is intended to set a broad direction. It can never be correct until there are implementations which actually take that broad direction forward. 
6. Know where to stop 
1. Whatever you do as an EA has to be reusable. 
2. Whatever you deliver as an EA has to be applicable to multiple projects (at least) if not the whole of the organization. 
3. Whenever you are assigned / picked up something that is not reusable / not applicable to multiple projects, stop. Don't do it. Hand it over to project teams. Let them have some fun as well. 
7. Know what to avoid 
1. Avoid taking decisions. I don't mean to be funny. I seriously mean it. The matters that EA practices "solve" are matters of business, projects, finance etc. There are people whose jobs are on the line to execute a solution e.g. CEO, Project Manager, CFO etc. Your role is advisory. You advise people on "enterprise problems" with multiple suggestions, one recommendation and raw data should they choose to delve into it. But that's where you should draw the line. 
2. Do not get into the technology wars - Java vs. .Net - Agile vs. Waterfall - are simply not for you to fight. Put a framework in place. Get an agreement on the framework from the key stakeholders. Get data - push it through the framework - arrive at a suggestion and hand it over. 
3. Just to prove the point made above, lets take an imaginary scenario: You might have arrived at a suggestion in favor of .Net (in a Java vs .Net decision making progress) and handed it over to the Delivery Manager - and he ultimately might go and choose Java because resources are easily available all of a sudden as some java based software house might have gone bust. It is not a technology based decision. It is an incident in the market that nobody foresaw. Let the Dellivery Manager - whose job is in line to deliver the software product in time and within budget - take the decision that is best for his deliverable. Let him prove to CEO that it is best for the business in long run. Don't be caught standing in the way of business success because it violates some EA finding. 
8. Know when and how to say "No"  
1. Any scope by definition has a tendency to explode if unchecked. However, while the scope of the work of a developer can increase only so much, the scope of EA program can take colossal proportions unless very actively and routinely controlled. 
2. Most of the activities assigned to EA will be multi-year efforts if not more. However, the business appetite to fund a program could start straining as soon as the business hits a bad quarter. It is vitally important to put an iterative approach (half yearly cycle) to achieve a continuous measurable velocity towards any task. 
3. "Out of scope for the current iteration", "Not approved for the current iteration", "Will add that into the to-discuss list for future iteration" are ways of saying no that should not ruffle too many feathers in the corporate world. Practice these phrases as you would practice any other tool in your kitty. 
9. Get down from the "ivory tower" and make friends. 
1. Given that output of EA activities tend to restrictive and prescriptive to the organization, it is likely for EAs to be seen as working in an "ivory tower". This is wrong on two accounts. Firstly it means that it is more difficult to evangelize EA activities and sell the outputs. Secondly it means that the EAs have not got enough information specific to the organization and hence the output is less likely to be tailored for the specific organization.  
2. Get down to the working floor and welcome / invite / allow / reward the bright chaps to contribute in the EA activities. This will make your job easier and win you that many more friends - both factors crucial for success of EA program.  

Work in progress ...

Suggested post read

Tools for EA

If you want to get in touch, you can look me up at Linkedin or Google + .