Natty Gur

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)

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

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.

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.

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.

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.

1. 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. 
   
2. 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.
    
3. 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.
    
4. 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. 
   
5. 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. 
   
6. 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.
    
7. 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.
   
8. 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. 
   
9. 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.
   
10. 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.
    

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.