Enterprise Architecture

Some thoughts from the workbench

In recent times I increasingly hear of folks bemoaning the fact that Enterprise Architecture (EA) doesn't deliver and is too complicated and that we need a new paradigm. I think that once again as we have with other ICT governance methodologies we are blaming the tools for our own failings.

What EA is good at

Lets start with a simple discussion of what EA is good at - its not complicated -

1. EA is a structured way of looking at a organisation and reflecting back to it what its needs are in Information Management. This reflection is structured into Viewpoints that can be taken to various stakeholders in the organisation and validated. The visualization from viewpoints such as capability, process and organization allow the organisation to critically examine itself, thus we come to know the current state.
2. From this EA, Subject Matter Experts and responsible officers of the organisation can work together on what would be a more desirable Future State. This process also allows for an understanding of the delta between the two states and how the journey might be undertaken
3. This agreed Future State is then used as governance tool to help the organisation on the way to the Future State, which will hopefully lie in the "broad sunlit uplands"

Obviously there needs to be a iterative cycle of management and realignment to how the organization and the world around it changes to make the process useful.

Now whilst many smarter folks will bewail the simplicity of this description I believe it is fit for purpose and defensible, so let us move on.

What EA is not good at

Enterprise Architecture requires a creative view of complex problems sets and a wide review of options to look for a future state - this makes it an excellent tool for look at issues at a high level and finding good guidance. However this approach will lead to endless analysis and confusion if pushed to low into the process.

Once we have the big architectural concepts in place and the general motifs and standards of the desired future state then we need to set a point where we let the designers of the mechanics of a system just get on with it - inside the boundaries and governance of the architecture Future State. We also need to mindful that some times designers will hit walls and limits that may require changes to the architecture or waivers in some fields.

The reasoning for this is exactly the same as in physical architecture - if everything is designed for perfection against the Future State ( A Sydney Opera House) then we are going to end up with a massive amount of bespoke development and specialised engineering.

Yet our task is to build a Information Management space for our organisation that is useful, rational and expedient. ( A well performing warehouse)  If there is a area where great competitive advantage may accrue from being radical and wonderfully elegant then that is a risk that should be managed and taken on with gusto. However in the general case we need to remember our requirements to be useful, rational and expedient.

EA teams need to stay up in governance and control and provided Information Managers are developing systems that are flying in the right direction leave them alone to get on with it.

Please note we haven't needed to talk about Information and Communication Technology (ICT) at all here - ICT is an enabler only - ICT allows for more and faster.

• If a system is well architected then ICT can enable more and faster IM goodness
• If a system is badly architected then a good dose ICT will ensure that you quickly dig a hole from which you cannot get out.

The power of Enterprise Architecture

EA offers a very powerful tool set to help us understand an organisation and its information needs and then build a consensus about how to move towards a better Future State in a structured, considered and measurable manner. I commend it to any medium to large organisation with significant Information Management challenges.