Diagramming the Big Idea


How can we present an EA vision that really communicates the big messages about enterprise transformation?

I've been at the leading edge of enterprise architecture for 30 years, and there is one topic that has remained at the top of the EA best-seller list throughout this time: does enterprise architecture really provide genuine value?

The short answer is "yes it does", but there are a couple of things that conspire to make this less evident.

The first point is that true architectural change is always transformational. When we switch architectures we are changing things that are fundamental and foundational. This is not the same as carrying out minor upgrades, or tweaking components within the architectural landscape. So when stakeholders find it hard to recognize value from EA it is often because the changes are minor, and not genuinely architectural in nature!

The second point is that when architects present an EA vision they often fail to show an architectural perspective. EA visions certainly play back concerns and convince stakeholders that their concerns will be addressed. But they rarely emphasize the part that architectural transformation plays in achieving this! And many EA visions don’t show how the current architecture is constraining and inadequate, or demonstrate how the target architecture is enabling and transforming.

Which begs the question: how can we present an EA vision that really communicates the big messages about digital transformation? Here are some practical tips that leading EA teams use to diagram the big idea!

Be clear about the nature of the change

Don’t pass off minor tweaks to an existing architecture as a major change. And don’t underplay the enormity of authentic architectural transformation. Diagram 1 shows four types of change that EA gets involved in. The most frequent type of change is to maintain or fix the current architecture, followed by minor improvements. Typically, these changes result in reduced costs or the elimination of a problem. After that there are changes which enhance the existing architecture; these changes usually add something that wasn’t present in the architecture, and this is where architectural change starts to produce value, rather than merely reduce costs. Finally, we reach tangible or measurable transformation – where one enterprise pattern is replaced by another that supports new capabilities. The magnitude of architectural change is far greater for transformational change. Being clear about the nature of the change is making sure that you don’t oversell the degree of change, but also making sure you don’t undersell genuinely major changes.


Show the problems you are addressing and the capabilities you are enabling

Too often architecture visions focus on the end result – which may not be delivered for several years. If you fail to explicitly show the problems you are addressing, you are missing a big opportunity to market your value. So keep reminding your stakeholders of the big hole that they are currently in and how they can’t get out of the hole without your ideas and vision. The simple way to do this is to have two diagrams for the architecture vision: one that shows the problems and constraints imposed by the current architecture, and one that highlights the benefits, possibilities, options and value that are enabled by the target architecture. The transition should be shown clearly and simply. Diagram 2 gives an example, with two diagrams showing the current and target enterprise patterns. Below the current enterprise pattern is a summary of the problems, constraints, issues and costs imposed by this pattern. Under the target enterprise pattern the summary focuses on the benefits, opportunities, options and value enabled by delivery of the new architecture.


Make sure that you highlight dependence on the enterprise architecture

It is easy to show a vision that overlooks the obvious points. Instead you need to emphasize exactly why the Current Architecture is inadequate and how it constrains the operations or strategy of the enterprise. Don’t waste this chance to highlight the unsuitable nature of the architecture. In our example, the enterprise wants to be more customer centric, but the current architecture has many diverse staff systems that vary across the many business divisions; each of these current systems is account-centric, pushing customer accounts, product processes and customer details to the bottom layer of the architecture. In contrast, the future architecture positions a relationship management system as the top layer of the enterprise pattern – making the customer the focal entry point. The new architecture will enable the customer centricity the enterprise wants, but the diagram also demonstrates that this can only be done through many changes to the layering and design of the architecture components.

Make sure that the vision really does address all of the many stakeholder viewpoints

A really good high-level enterprise pattern is a big picture amalgamation of the many detailed building blocks and components that comprise the architecture. A good enterprise pattern takes some time to produce, but from it you can drill down to any detailed element in the architecture. This makes it an effective way to summarize all stakeholder positions. By having two enterprise patterns – one for the Current Architecture and one for the Target Architecture (as shown in the second Diagram) – it is possible to show all stakeholder concerns and how they have been resolved. For example, our current diagram shows why it is impossible to get customer-centricity, and the diagram talks equally well to senior executives, business managers, account teams, and IT.

At the outset I said that EA teams often compromise their role and fail to explicitly show the value they are delivering. This problem can be resolved through an EA Vision that really communicates the degree of change and how EA morphs the organization from one enterprise pattern to another.