In our 6 blog series about "How to succeed at Enterprise Architecture", we will be talking today about the common challenges an Enterprise Architect faces when creating his IT landscape, and how to solve these IT challenges.
It is all too easy for EA programs to collapse. In fact, more than 66% of Enterprise Architecture initiatives fail. But failure is not inevitable. Avoid these common EA stumbling blocks to make sure your EA program is successful and contributes value to your organization:
Too much planning, too little doing
Avoid spending too much time planning and modelling in too much detail. Sometimes Enterprise Architects are accused of living in an “Ivory Tower” and being completely removed from the realities of the real world and what is important to the business. Make sure your architecture is aligned to the realities of your organization’s IT, business and budget.
Trying to model everything
Do not try to model everything and for every eventuality. You cannot anticipate all the disruptive events that will influence your business. Ten years ago, who would have predicted the invention of the iPad and the influence it has had on how we consume media and on corporate IT? By simplifying your EA models and focusing on your capabilities, you remain flexible enough to react to unexpected events and trends.
When it comes to creating your EA inventory, you need to ask yourself, which problem you are going to solve, and starting from there you can identify the data you will need to obtain and maintain. For example, if you want to identify which applications to invest in or divest according to their technical and functional suitability, you will need to collect information on the application and rate their technical and functional fit. Do not collect data without a good reason, as the more detail you have in your EA inventory, the harder it will be to assure its quality. There is always a trade-off: if you want a deep and detailed model you must compromise on how up-to-date your data is and how much effort you have to invest to maintain it.
Think carefully about your use cases – which reports do you really need? Start with the one or two important use cases and collect the necessary information for them. This could be application rationalization; or you can always consider adding more use cases later on, as your EA practice becomes better established.
When creating your Business Capability Maps, go for breadth rather than depth. An analysis of LeanIX workspaces shows that companies typically use 7-10 capabilities on the highest level, and 70% have only one or two levels of business capabilities. Following a lightweight approach has the clear advantage of reducing complexity and focusing on what is really needed.
Solving problems on the wrong level
Neither getting too caught up in complex technical detail nor spending all your time on high level strategic models is useful. Focus on doing “just enough” EA “just in time” (Gartner) to achieve early results that are supported by the management. Do not try to make Enterprise Architecture be everything to everyone: focus on a small group of clear objectives, measure and track success. This will help you to really live EA!
You need to keep the right perspective. It is possible to be too far removed from the realities of your organization. One example of an EA having too broad an overview with a disregard for business details was the application rationalization project of a global logistics company in order to save costs. Among the measures identified by the EA team was the replacement of a parcel tracking application by a web-based system. They had already finalized the planning and allocated the budget, when the Italian country head pointed out, that the handhelds used by the logistics drivers in his region were incapable of running a web browser.
No tool or the wrong tool for the job
It definitely makes sense to introduce an EA tool early on – workarounds that are not purpose-built like Excel or Visio create more work in the long run, as they soon reach their limitations. Missing quality assurance mechanisms create problems over time and lead to significant expenditure for trouble shooting. Data capture and maintenance in spreadsheets is very error-prone as well as time consuming and needs a lot of resources. Distributed files across the organization make achieving a big picture of the interdependencies within the architecture impossible and lead to inconsistent and thus unreliable data sources.
Find an EA tool that is easy to keep up-to-date, fosters communication and collaboration across the whole organization, makes it simple to share information and extract meaningful reports. Because of the distributed access, workflows will be optimized and stakeholders will be able to drive their own analyses. Your data quality will go up thanks to quality assurance mechanisms and will give your organization a much better basis for decision making.
If you enjoyed this post, share it with your friends and colleagues!