Enterprise architecture on a single page

Enterprise architecture (EA) as a discipline is chronically suffering from an acute lack of realism. This problem is caused, on the one hand, by the abundant supply of fake ‘best practices’ and, on the other hand, by the lack of any alternative realistic reference models for EA.

The first half of this problem is well-known EA frameworks aggressively promoted by commercially motivated consultancies and gurus, e.g. TOGAF, Zachman and FEAF. From the historical perspective all these EA frameworks can be considered only as the ‘next’ management fad related to information systems planning, and yet another attempt to sell the flawed ideas of the 50-years-old business systems planning (BSP) methodology that can hardly be successfully implemented in practice.

Even if considered merely as ‘checklists’ for an EA practice, as some EA gurus now recommend, the practical usefulness of EA frameworks is still highly questionable simply because most of their checklist points are never really ‘checked’ anywhere, while some essential elements of successful EA practices are missing in their checklists. For example, who really ‘checked’ TOGAF Enterprise Continuum in their organisation? And which framework includes ubiquitously used business capability models in its checklist?, Such checklists may only confuse people, rather than help them. And they are certainly unable to provide any real practical guidance for architects, especially for newbies with no previous EA experience.

Overall, the situation with EA frameworks looks absurd: frameworks appeared out of nowhere and have little or no connection with empirical reality, but for some reason are still widely discussed and respected by many people.

The second half of this problem is that for the last 20 years of active speculations around EA, with some rare exceptions, nobody seriously tried to produce any sensible alternatives to EA frameworks - something that can be used as a more realistic guidance or reference model for an EA practice instead of useless trinkets offered by numerous ‘snake oil salesmen’. This is especially strange, taking into account the fact that consistent EA best practices have existed in industry for a rather long time, well known to most experienced architects and institutionalised in many companies. As a result, all EA-related discussions sooner or later degrade to EA frameworks simply because no other models are available to provide constructive common points of reference. Even worse, many people have to start ‘using’ EA frameworks only because there is essentially nothing else they can start from.

In order to address this longstanding lack of reasonable reference models for EA, I thought it would be a nice idea to provide a one-page comprehensive explanatory view of EA, as a collection of specific artifacts used for planning, reflecting actual EA best practices that proved effective in real-world organisations. Such a view can be used as a convenient catalogue of EA artifacts. It can be used as a sense-making instrument or as a tool for thinking around EA. It can be freely distributed and used as a common reference point to start from. It can be printed, used as a poster and pinned on the wall. I called the resulting view of EA artifacts simply as ‘Enterprise Architecture on a Page’, and created a modest website for it: http://eaonapage.com.

Enterprise Architecture on a Page

As part of my research, I analysed all EA artifacts used in 27 diverse organisations with reasonably mature and more or less successful EA practices (various business strategy documents, business cases and project management plans were not considered as EA artifacts). As a result, I identified 24 consistent types of EA artifacts used in these organisations more or less commonly (however, some artifacts were unique and very organisation-specific).

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Based on the relative frequency of their usage, I loosely classified all these types of EA artifacts into three broad groups: essential (used in the majority of studied EA practices), common (used in about 50-25 per cent of studied EA practices) and uncommon (used in about 25-10 per cent of studied EA practices). This classification may roughly represent the relative usefulness and importance of particular EA artifacts for an EA practice. Then, I grouped these 24 narrow types of EA artifacts into six general types: Considerations, Standards, Visions, Landscapes, Outlines and Designs (CSVLOD), according to the analytical taxonomy I presented and discussed previously.

For each of these 24 identified EA artifacts I developed a simple schematic graphical representation reflecting its typical format, high-level structure, and critical informational contents.

Finally, I placed all these EA artifacts on a single page around the overarching CSVLOD taxonomy explaining their usage and other core properties in the context of an EA practice. The full version of the resulting ‘Enterprise Architecture on a Page’. A simplified schematic view of Enterprise Architecture on a Page is shown in Figure 1.

Figure 1. Enterprise Architecture on a Page (Schematic View Only)

‘Enterprise Architecture on a Page’ has been discussed with a number of experienced enterprise architects who generally approved it, found it useful and provided their improvement suggestions many of which I incorporated into the resulting model. This simple, one-page view of EA provides clear, evidence-based and concise answers to the following essential questions regarding an EA practice (surprisingly, but realistic answers to all these questions are incredibly hard to find anywhere else):

• What EA artifacts are useful?
• What information do they provide?
• What do they look like?
• For what purpose are they developed?
• How exactly are they used?
• What benefits do they bring?

‘Enterprise Architecture on a Page’ can be helpful in many ways to various people involved in EA-related activities:

• It offers an evidence-based reference model of EA artifacts to organisations starting their EA journeys.
• It provides a convenient framework for thinking about EA and EA artifacts to practicing architects.
• It explains the general ideas and mechanisms of an EA practice to newbie architects.
• It can be used as an intuitive visual model of EA for teaching EA courses to students in universities.

‘Enterprise Architecture on a Page’ is purely descriptive in nature and does not give any detailed prescriptions regarding the usage of EA artifacts. Instead, it merely shows what EA artifacts are typically used in organisations, explains how they are used and, thereby, provides some ‘food for thought’ for architects and organisations starting their EA practices.

Certainly, ‘Enterprise Architecture on a Page’ cannot be considered as a global statistical snapshot of all EA artifacts used in all organisations around the world, or even as an exhaustive list of all imaginable EA artifacts that might be helpful in organisations (many companies “invent” and use their own peculiar EA artifacts). However, it is based on empirical data from multiple diverse organisations, discussed with enterprise architects from different countries and therefore might be considered as reasonably representative and accurate. Despite its imperfectness, it is still incomparably more realistic than the fantastic recommendations of popular EA frameworks. The full version of ‘Enterprise Architecture on a Page’ is freely available to download at http://eaonapage.com