If you reply to these questions with a straight “yes”, or you haven’t yet heard of the term Enterprise Architecture before, this is a real pity. In my opinion, every executive manager should know that the Enterprise Architecture discipline serves an important purpose in the overall management of a company and its IT. If the term EA already arouses positive emotions in you then you are in a lucky position and I hope you continue to make good use of the EA team in your company.
One of the typical problems prevalent in large and complex IT landscapes is the increasing technical debt which is the sum of quick and dirty solutions from the past that were never corrected and are becoming more and more painful. This debt calls for clean-up investments that have no immediate business value. However, due to strong cost and innovation pressure, everyone rather wants to jump ahead and build new stuff on top of antiquated IT architectures – thus further increasing the debt level. This ends up in growing dissatisfaction amongst all stakeholders because this debt not only costs a lot but also decreases flexibility.
I’ve seen many large IT debt reduction programs fail. Important reasons were always that the program goals were unrealistically ambitious and the program owners wanted to introduce all the necessary changes in one big step. After the stop of such a failed program, helplessness often prevails.
In such cases the EA discipline can help. An Enterprise Architecture structures your entire IT into smaller, manageable elements (domains) that are well aligned with the business. Furthermore, one major component of a good EA is a roadmap for the evolvement of a legacy IT into one that is future-proof. Such an EA roadmap helps to steer the evolvement by small and digestible steps.
I am very much convinced that proper Enterprise Architecture thinking is an indispensable tool for every organization to get a grasp on problems prevalent in today’s large and complex IT landscapes. But unfortunately many companies do not have EA departments with the right skills, or their EA skills are just too disconnected from the projects. Furthermore, the used EA frameworks and the resulting EA descriptions are often too complex and inflexible.
If you don’t know where to start using the EA discipline as a strategy tool, you should first initiate a project that establishes a simple EA framework and models the current and future IT landscape in a way everyone understands.
If you start your EA endeavor you should consider the following 6 hints carefully:
- Start with a very simple framework. Like your IT, your EA should be flexible. The focus should be on the content, not on the framework. The framework should just outline the major elements of what EA consists of, e.g. models of the future business processes, the future IT landscape and related architecture processes. It should be a map that shows where you stand with the elaboration of the different prioritized components. We at Acrea have developed such a simple map that is an essence of other more comprehensive and complex frameworks (like for example TOGAF).
- Model for reuse: Do not fall into the Microsoft Office trap. Use a proper modeling tool to avoid redundancies and ensure consistency.
- Make sure executive managers easily understand the models: As models quickly become complex, make sure you can easily print out views on the model that every top level executive can understand. Show one of the print-outs to the CEO and tell him that this is the future business or IT landscape. If he gets enthusiastic of what he sees you are on the right track.
- Involve the stakeholders: IT executive managers and business representatives must be involved in your EA efforts. Don’t make this an architecture ivory tower exercise. If the business owners and the IT executives find excuses to not attend the EA project meetings and workshops you should stop the exercise right away.
- Progress quickly and iteratively: In order to get to a good first model version of the existing and future landscapes, spend no more than 3 months on it. Develop new versions every week during the project and review it with few key stakeholders in 2-3h workshops.
- Evolve the description continuously: Once the EA models are “finished”, make sure people work with the models and the models get updated if something in the landscape changes.
However, be aware that defining an EA model of the target business and IT landscape is only the very first step towards a future-proof and highly flexible IT. You have to identify and initiate the right projects to make your EA vision happen and you have to excel at managing these projects.
EA is not a magic tool that can solve all your problems. But in my opinion EA - if done right and in a lean way - can deliver many business benefits.