10 EA pitfalls that a real EA implementation might experience
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.