Opinion Piece, Enterprise Architecture

Over the last 6 months I have been involved in a fair amount of architectural / strategy review work. This has generally happened because of my transition to working for Dell, and having the opportunity to share learning with others, and also because my new role offers me the freedom to support health systems / organisations with their strategy as a value add for Dell.

One common theme that I keep seeing time and time again is the overuse of Enterprise Architecture to fulfil some unknown need to define the entire enterprise. To be clear, this is not the purpose of EA, and overuse of EA to fulfil individual needs should be challenged at all costs.

Here's why;

The definition of Enterprise Architecture is as follows;

"a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies."

Key elements of the above are the realization that EA is a thorough toolset to support change. This means that leveraging EA framework(s) should always be for the purposes of supporting change and any analysis required to deliver said change at scale. EA is not a supplementary tool for a CMDB, the purpose isn't to provide in-depth diagrams of the entire organisation, and it certainly isn't a tool to help boards understand their organisation. This is a high cost approach to managing an organisation which I would argue is better placed in the realms of service rather than architecture.

I think a lot of EA functions consider themselves gatekeepers to an organisations digital enterprise. This feels pretty old school to me and I think has already been challenged across the EA community as a reason why EA functions often fail and are seen as an inhibitor to change. A good EA function supplements, supports and enhances delivery - it is not a capability that says 'no' at every given opportunity or postures against organisational change.

Now, that being said, EA can be really handy when used effectively to communicate problems in an objective way. Using appropriate diagrams, viewpoints, maps, catalogues etc. are a great way of keeping information stored in a way to support developing more translatable outputs for senior audiences. Remember, the purpose of an EA is to support Enterprise Change, and therefore the outputs developed must always translate to the audience who are receiving them.

Just Enough EA.

I have been criticized by some of my teams (EA purists) in the past for using terms such as 'Minimum Viable Architecture' or 'Just Enough EA' because I have always tested the purpose of what my architectural teams are doing when leveraging EA practices.

Key questions for all artefacts I ask myself and my colleagues are;

1, Who is the audience and will they understand the output?

2, Is the output sufficient to provide enough information to progress the change we are trying to achieve?

3, Is there too much information in the output which will lose the audience and could we achieve the same goal with less?

4, Will the output be approved by the audience / board that is receiving it or does it ask more questions than is answers?

What EAs must always remember is the documents used most (whether we like it or not) are word documents, and powerpoint presentations. So if you are generating diagrams that are not easily consumable in these formats, I'd suggest you stop and test the purpose of why you are creating the diagrams in the first place. There are of course exceptions such as component diagrams which are used as reference for engineering which I have happily printed and placed on the wall in the past.

So - what is just enough EA. Well, to me - it is the outputs needed to move through the Architectural Development Method (ADM) - See TOGAF | www.opengroup.org, with enough knowledge and support to get to delivery. Because delivery is the ultimate goal of any change programme - analysis paralysis is the worst of all worlds and results in procrastination.

The EA Process

I always refer to the ADM when leveraging EA programmes and designing strategy, but I am not a stickler to the methodology and I am certainly not a stickler to the outputs. What I do like about the ADM is the expectation that you consider all facets of an organisations views at each juncture during the lifecycle and that all parts of the ADM are optional.

This means I often produce rich-pictures, rather than capability models, I generate powerpoint diagrams instead of visio / archimate diagrams. And I always try and test the models with the audience that will be consuming them. At the level I work at this generally is enough EA to present the messages I need to the audiences that need to consume them. But my engineering days are long behind me now and I fully understand why different levels of depth are needed when solutioning but would challenge the need to be too in-depth at an enterprise / strategy level.

Key take aways

1, Stop doing architecture 'for architectures sake', revisit the purpose and justification of what you are doing and why you are doing it?

2, Are you actually supporting business change and delivery with your outputs / deliverables or are you actually hampering change? If it is the latter then stop, review your purpose and streamline the documents so that you are supporting change - and providing resources to support a 'yes' rather than 'no' culture.

3, Always test your outputs and ensure they will translate to the audience that is consuming them. Do not create diagrams that ask more questions than they solve.

4, Do not be scared to venture out of traditional EA formats and leverage other approaches such as strategy maps, rich-pictures, wardley maps, story boards, personas etc.