Enterprise architecture practice on a single page

Initially, early architecture-based information systems planning approaches of the 1970s - 1980s, like BSP, Method/1 and Information Engineering, provided detailed guidelines for producing comprehensive architectures connecting business and IT. Then, early EA frameworks of the 1990s-2000s, most notably the Zachman Framework and FEAF, offered their advice regarding the development of enterprise architecture for bridging the gap between business and IT. Currently, TOGAF is positioned as the leading EA framework or even as a global de facto industry standard for an EA practice¹.

Methodologies and frameworks did not fulfil their promise

However, early architecture-based planning methodologies all proved impractical long ago, disappeared without a trace and today almost no one remembers that they ever existed. Early EA frameworks are not completely forgotten yet, but their practical uselessness is seemingly already widely acknowledged within the EA community and the interest towards these frameworks is rapidly fading away. Even TOGAF, which is still actively promoted by The Open Group, is already considered as not particularly useful arguably by the larger part of the EA community.

With the exception of commercially motivated TOGAF trainers and rare faithful zealots firmly convinced of its fundamental value, most practicing architects readily admit that TOGAF at best offers only a haphazard ‘dictionary’ for enterprise architecture, where some useful EA artifacts or separate inspirational ideas can occasionally be found. It is now perfectly clear that all these EA methodologies and frameworks actually represented only passing fashions of no real substance: Enterprise architecture frameworks: the fad of the century².

Now, after all the waves of hype around architecture have gone and the dust has settled, what veritable knowledge on an EA practice is left to us? Ironically, but the decades of motivating promises, excessive promotion and irresponsible marketing did not produce any systematic evidence-based descriptions of an EA practice and did not engender a sound understanding of how successful EA practices actually work.

Instead, best practices came from industry

Nevertheless, during my own research of EA practices in organisations I realised that despite the evident chaos observed in the EA literature, a set of remarkably consistent best practices around enterprise architecture has emerged in industry. Moreover, these best practices are rather widely known and intuitively understood by the vast majority of experienced EA practitioners - though they are not codified or systematically documented in any sources and proliferate only verbally from architects to architects, predominantly through collaboration.

For instance, none of the mainstream comprehensive texts on enterprise architecture (e.g. the TOGAF manual and popular books of EA ‘thought leaders’ ^{3, 4, 5}) provides a reasonably accurate description of established EA best practices familiar to most architects working in industry even from the purely factual perspective (e.g. what EA artifacts are created, how, when and why), let alone adequately explains the general meaning of successful EA practices. As a result, at the present moment, for outsiders, an EA practice still remains largely an inexplicable ‘black magic’ full of weird buzzwords, inconsistent models and frameworks.

Clarifying enterprise architecture

In order to shed some light on genuine EA best practices that work in organisations and provide a handy reference model of enterprise architecture, previously I developed Enterprise architecture on a page as a convenient one-page view of popular EA artifacts that proved useful with their essential properties, e.g. informational contents, presentation formats, typical use cases, lifecycles and purposes (see Enterprise architecture on a single page).

In this article, I will introduce another helpful deliverable called Enterprise architecture practice on a page. While Enterprise architecture on a page focuses solely on EA artifacts as visible, tangible and static elements of an EA practice, Enterprise architecture practice on a page focuses on EA-related processes as somewhat less visible, immaterial and dynamic elements of an EA practice. These two one-page deliverables complement each other and taken together provide a holistic view of both EA artifacts and processes that leverage these artifacts.

Enterprise architecture artifacts and processes

Earlier based on my analysis of multiple reasonably mature and successful EA practices I presented the process view of an EA practice articulating three distinct but interrelated processes: strategic planning, initiative delivery and technology optimisation in The process view of enterprise architecture practice.

For you

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

Strategic planning converts a business strategy into a desired IT investment portfolio, initiative delivery turns each investment into a working IT solution, while technology optimisation rationalises the existing IT landscape. These three processes together provide a high-level picture explaining how an EA practice generally works.

Each of these processes is based on specific types of EA artifacts from the CSVLOD model (see Six types of enterprise architecture artifacts and The relationship between enterprise architecture artifacts): strategic planning on considerations and visions, initiative delivery on outlines and designs, while technology optimisation on standards and landscapes (see Enterprise architecture on a page (PDF) for typical examples of respective EA artifacts).

Enterprise architecture practice on a page

By means of extending the process view of an EA practice and supplementing it with additional relevant information regarding the three processes (e.g. goals of each process, key questions discussed as part of each process, other non-EA-specific documents and techniques that might be relevant to each process), I produced a comprehensive diagram explaining various aspects of an EA practice and its constituting processes on a single page (importantly, this diagram focuses on internal EA practices carried out inside organisations, rather than on one-shot engagements performed by external EA consultants): Enterprise architecture practice on a page (PDF). A simplified schematic view of enterprise architecture practice on a page is shown in figure 1.

Figure 1: Enterprise Architecture Practice on a Page (BCS)

Enterprise architecture practice 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 have incorporated into the resulting model (though, certainly not all of them fully agreed with all aspects of the model). This simple, one-page view of an EA practice provides clear, evidence-based and concise answers to the following essential questions:

• What processes constitute an EA practice and who participates in them?
• What questions are discussed as part of these processes?
• What EA artifacts are developed and used during these processes?
• What other documents and techniques are relevant to these processes?
• What is the goal and meaning of each of these processes?
• How do these processes fit into the organisational context?
• How do these processes relate to each other, to the external business environment and to the organisational IT landscape?

Generic versus organisation-specific

Importantly, low-level details of each of the three processes in successful EA practices are always organisation-specific. For this reason, it is arguably impossible to develop more detailed one-size-fits-all prescriptive models for the processes of an EA practice. For example, specific actors, deliverables, communication patterns and decision-making responsibilities relevant to the strategic planning process will naturally differ rather significantly from organisation to organisation.

Likewise, every company has its own business case preparation approach, investment approval procedure, project delivery methodology and lifecycle, that all have to be properly integrated with the initiative delivery process through respective architectural reviews, assessments and approval gates. Therefore, Enterprise architecture practice on a page offers only a generic conceptual framework for an EA practice relevant, arguably, to all organisations, but leaves out numerous details that may vary across organisations and cannot be specified in any generalisable form.

Dialogue as the core of enterprise architecture practice

Besides other things, Enterprise architecture practice on a page explicitly emphasises one critically important fact regarding an EA practice which is too often neglected: dialogue between various stakeholders is the core of an EA practice and constitutes the very essence of most EA-related activities.

Successful EA practices represent flexible communication networks, where different planning decisions are made with the involvement of the right stakeholders at appropriate levels of the organisational hierarchy; but never mechanistic step-by-step analysis-synthesis processes similar to the ones prescribed by numerous faddish EA methodologies (e.g. TOGAF, FEAF and EAP) and their direct historical predecessors (e.g. Information Engineering, Method/1 and BSP)^{1, 2}.

Enterprise architecture practice 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 an EA practice to organisations starting their EA journeys
• It provides a convenient framework for thinking about an EA practice to architects and architecture managers
• It explains the general ideas and mechanisms of an EA practice to newbie architects
• It can be used as an intuitive visual model of an EA practice for teaching EA courses to students in universities.

The full version of Enterprise architecture practice on a page is freely available to download.