The discipline of enterprise architecture (EA) is closely associated with numerous tools including various frameworks, approaches, techniques and modelling notations intended to help architects plan organisations and their information systems. However, for a very long time we have been observing a rather curious situation which can be characterised as absurd, paradoxical or even schizophrenic.
In particular, one set of tools is declared as fundamental to the EA discipline, consistently promoted as a global EA standard and widely taught in various EA courses, but in reality such tools are largely, if not totally, useless for all practical purposes. At the same time, other sets of tools constitute the actual body of established EA best practices that work in organisations, but these tools are barely discussed and lacking sensible descriptions for newbie architects and students to learn from.
The Zachman Framework - A ‘fake’ tool
The Zachman Framework, published in 19871, is arguably the most famous model related to EA. This framework is well known to all architects and, as many people firmly believe, even created the entire EA discipline. For instance, Simon et al.2 expressed this view rather poetically: ‘The discipline of enterprise architecture (EA) has evolved enormously since John Zachman ignited its flame in 1987’. The Zachman Framework allegedly provides the necessary foundation for EA and is considered by many to be very influential. Currently it has almost 4,000 citations in Google Scholar and entire 750-page-long books have been written wholly dedicated to it.
The reality around the Zachman Framework is, however, not that bright. First, contrary to widespread opinion, from a historical perspective the Zachman Framework did not introduce any novel ideas. Specifically, multiple world-famous comprehensive architecture planning approaches existed long before the Zachman Framework, including BSP, Method/1 and Information Engineering. The PRISM framework and some other architectural taxonomies were also published before the Zachman Framework. Finally, the framework did not even coin the term ‘enterprise architecture’, but used the older term ‘information systems architecture’.
Second, the original justification behind the Zachman Framework was entirely speculative: ‘Equivalency [between the architectural representations in manufacturing and construction industries] would strengthen the argument that an analogous set of architectural representations is likely to be produced during the process of building any complex engineering product, including an information system’1 (page 281). However, all people acquainted with the practical realities know that organisations and their information systems have a very significant social component and cannot be designed and built like other engineering products.
Third, the value of the Zachman Framework was promoted with purely fictional promises: ‘Early numbers indicate that conservatively, taking enterprise architecture-based approaches [...] produces implementations 10 times cheaper and 6 times faster’3 (page 3). Every manager acquainted with the complexities of organisational problems knows that order-of-magnitude productivity improvements cannot be achieved from any single managerial innovation.
Finally, and most importantly, it was never clearly explained how exactly the Zachman Framework should be used. Despite having thousands of citations, the framework has zero documented examples of its practical application. The most common EA artifacts that proved useful in practice5 simply cannot be mapped to the cells of the framework in any real sense. Unsurprisingly, evidence from organisations suggests that the framework was found useful only for ‘selling’ EA efforts to management, but then was ‘pinned on walls in many rooms without far-reaching consequences’6 (page 15).
Unsurprisingly, the value of the Zachman Framework is always explained by enlightened gurus using sophisticated, intentionally elusive and obscure language, e.g. the framework provides ‘a fundamental basis’, ‘a universal classification scheme’, ‘a non-discussable eternal structure’, ‘a periodic table’, ‘enterprise physics’ or even ‘an ontology’ for EA. From the practical perspective, such explanations imply no consequences whatsoever, bring no real value and, essentially, mean only that the framework is useless for down-to-earth EA practitioners working in organisations. After more than 30 years since the ‘breakthrough that created EA’, the Zachman Framework has nothing to demonstrate, the ‘king is naked’.
Similarly to the Zachman Framework, other well-known and aggressively promoted EA tools including, among others, TOGAF, FEAF and ArchiMate represent mostly fake tools (though with some caveats). They are also characterised by the very same set of attributes: continuous marketing hype, intentional vagueness, empty promises, elusive explanations and the lack of real-life practical examples. These tools are largely useless and provide little or no practical value, and only create considerable informational noise and distort the discourse in the EA discipline.
The Business Capability Model - A ‘real’ tool
Unlike the entirely ‘metaphysical’ Zachman Framework with inexplicable practical value, the usage and benefits of the Business Capability Model (or map, BCM) can be explained very clearly. The BCM shows the hierarchy of all business capabilities of an organisation on a single page providing a simple but overarching view of the business and facilitating the strategic dialogue between business and IT. In particular, via using the BCM, business executives can decide which capabilities should become the primary focus of future IT investments in order to execute their business strategy, whereas enterprise architects can determine which IT systems may be installed to enhance the required capabilities. Put it bluntly, business leaders can point to specific capabilities and say: ‘we need to improve these capabilities’, while architects can reply: ‘then we can launch the following IT initiatives to do that’.
The achieved agreements between business and IT on the set of business capabilities to be uplifted with IT are color-coded, or ‘heat-mapped’, in the BCM and then used as the basis for prioritising and initiating corresponding IT projects. Thereby, the BCM helps convert an abstract business strategy and goals into a rather specific IT investment portfolio, improves strategic business and IT alignment, and increases the long-term effectiveness of IT investments. Unlike the Zachman Framework, the BCM is a real EA tool with a widely acknowledged, immediate and intuitively understandable practical value. It is ubiquitously used and arguably represents one of the most essential tools in the toolkit of genuine EA best practices available to enterprise architects5.
The origins of the BCM in its current form are unclear. For instance, the BCM is not even mentioned in any existing ‘definitive’ EA frameworks. While the Zachman Framework was generously bestowed to us in 1987 as a profound eye-opening revelation, instantly shocking all IT planners in the world, the concept of BCM was seemingly developed some time ago inconspicuously by unknown, ‘nameless’ architects in organisations with no pomposity, proved useful and then rapidly spread across the industry without any deliberate promotion, eventually becoming one of the most recognisable EA artifacts. Nobody proposed the BCM; nobody ‘ignited its flame’.
Similarly to the BCM, many other useful EA artifacts and associated techniques are barely discussed in the available EA sources and never promoted. These practices include, among others, creating solution overviews and business cases for IT initiatives, managing the lifecycle of deployed technologies via color-coding technology reference models (TRMs), and estimating the technical debt for architectural deviations. The CSVLOD model I introduced earlier4, 5 may also become a useful evidence-based tool for thinking about EA and understanding proven industry best practices. All these approaches, techniques and models represent real EA tools that help architects deliver tangible business value.
What does it mean?
The situation illustrated above, based on the two opposite distinctive examples, indicates the existence of a dramatic gap between what is actively promoted and what really works in an EA practice. The excessive focus on fake tools, e.g. popular EA frameworks, essentially blocks the healthy development of the entire EA discipline, while the slow progress in this direction is often attributed by crafty EA gurus to the fact that ‘unlike mathematics, EA is only 25 years old’. This argument is deceptive, but still partly true: with the endless irresponsible promotion of fake tools it may, indeed, take centuries for the EA discipline to develop into something systematic.
In the current uneasy situation in the EA discipline, I argue that the following actions are necessary and should be taken sooner rather than later to advance the EA profession and theory forward:
- Instead of trying to align their practices to unrealistic EA frameworks, architects should trust their own judgment, and focus on developing practices that work well for their organisations and then share these best practices with the broader EA community.
- Instead of comparing existing EA frameworks and modeling notations, EA academics should ‘wake up’ from their slumber, acknowledge their evident faddish nature and focus on studying and codifying genuine EA best practices that proved effective in organisations
- Current EA frameworks and standards, as well as the gurus who promoted them, should be forgotten due to their obvious disconnection from reality and replaced with more adequate, evidence-based descriptions of established EA best practices existing in industry.
The analysis of fake and real EA tools provided above is briefly summarised in Figure 1.
Figure 1. ‘Fake’ and ‘Real’ enterprise architecture tools (click for larger image)
