At the core there are two ways to start with Enterprise Architecture. Let’s start with a very quick distinction between these two and then we will explains the pro’s and con’s and provide some more depth as wellTop Down
This approach means you start describing the architecture enterprise top down. So what does this mean? Well it means that:
• You focus on the strategic planning value of EA
• You essentially describe the strategies down to business & application & information & technology (hence the term top down)Bottom Up
This approach means you start at the bottom which usually means:
• You focus on operational value of EA
• You start with your technology stack and link your way upwards (hence the term bottom up).
Now there are also hybrid models in between, sometimes referred to a Middle-Out. An example would be that you start with you applications and describe those downwards to the technology layer and upwards towards the business layer and strategic layer.
Now the question you might be asking yourself is which one is better. I am afraid the answer is ‘it depends’. It depends on what problem you are trying to solve. Secondly it also depends on the structure and maturity of the organization. Let me give you some examples:
• A top down approach will essentially provide traceability from strategic drivers down to technology required to enable the strategy. There are two key assumptions here we should validate to confirm this is a feasible approach:
1. Understanding the strategic drivers and what the technology needs behind those drivers are requires senior business management support. They need to be supportive of this. Does that support exist at the C-level?
2. The business strategies need to be clear enough that you can connect these downwards. Does the business strategy have enough depth & meat to it (fully recognizing that part of the EA is to add some depth and meat but there has to be some business direction described already)? Is there enough business strategy to build off?
• A bottom up approach will provide an impact analysis insight as primary value. E.g. what happens when this technology platform goes down? The key assumption we need to valid for this approach would include:
1. Does the rest of the organization consider this linkage a problem? This kind of impact analysis is much more operationally focused and do those groups have a need for this? A ‘built and they will come’ doesn’t work!
2. When doing a bottom up approach maintaining the content & data is key. If the data is not always up to date the outcome can’t be trusted and the entire repository is not usable for this purpose anymore. So the question would be: how can we keep this data up to date?
Now to also tie this back to enterprise architecture tools. For the top down approach, to ensure strategic alignment, it is important that the ea tool can produce business friendly outputs. Especially diagrams showing business models and capabilities maps MUST be business friendly and not too technical. On the bottom up approach, used for more operational impact analysis, the enterprise architecture tool must have the ability to generate matrices and catalogs or even specialized impact analysis reports. Also it must be easy in the tool to update data.
Now I did hint towards a third option of Middle Out
but will keep this for my next post, next week.
Founder WhiteCloud Software, creator of EAComposer
keywords: enterprise architecture, enterprise architecture tools