The process view of enterprise architecture practice

The practice of enterprise architecture (EA) implies following certain processes for translating abstract business strategies into concrete information systems supporting the execution of these strategies. The most widely known process models of an EA practice include the early Enterprise Architecture Planning (EAP) ‘wedding cake’ model¹; and the modern TOGAF Architecture Development Method (ADM). Both of these popular models, as well as many other similar less widely known models^{2, 3,} describe an EA practice as a single sequential step-wise process, where architects document the current state, define the desired future state, analyse the gaps between them, develop the transition plan and then the resulting plan is implemented.

While some authors might claim that ‘TOGAF Architecture Development Model (ADM) is a proven approach to architectural success’^{4 (page 6)}, all the actual evidence from organisations clearly suggests exactly the opposite: following any mechanistic step-by-step processes is proven to fail. Since the 70s, numerous rigid step-wise architecture-based planning methodologies have been promoted by consultancies (e.g. BSP, Method / 1 and Information Engineering) all of which proved ineffective and fell into disuse⁵.

More recently, EAP-based Federal Enterprise Architecture (FEA) program has reportedly wasted $1bn without delivering much value⁶ (see also Enterprise Architecture Frameworks: The Fad of the Century). Unsurprisingly, my analysis shows that successful EA practices today never follow the steps of TOGAF ADM, EAP or any other similar step-wise models^{7, 8} (see also The Critical Scrutiny of TOGAF), even in the organisations included in the ‘official’ list of TOGAF users provided by The Open Group. Moreover, these observations are not particularly new. For instance, Haki et al.⁹ (page 1) earlier reported that ‘our experience indicates that very few companies follow the steps prescribed by [such step-wise process models]’.

But, if the most widely known process models barely resemble successful EA practices, then how can an EA practice be conceptualised and explained from the process perspective? Previously, I presented the CSVLOD model which conceptualises the notion of enterprise architecture as a set of six general types of EA artifacts (see Six Types of Enterprise Architecture Artifacts and Enterprise Architecture on a Single Page): considerations (e.g. principles and policies); standards (e.g. technology reference models and guidelines); visions (e.g. business capability models and roadmaps); landscapes (e.g. landscape diagrams and inventories); outlines (e.g. solution overviews and options assessments) and designs (e.g. various solution designs).

My further analysis of established EA practices shows that an EA practice can be generally conceptualised as a set of three distinct but interrelated processes with different goals, participants and outcomes revolving around these six general types of EA artifacts: strategic planning, initiative delivery and technology optimisation (importantly, this article focuses on internal EA practices carried out inside organisations, rather than on one-offs performed by external EA consultants).

Strategic planning

The strategic planning process revolves around considerations and visions EA artifacts. The goal of this process is to articulate the long-term future course of action for IT by means of answering the following question: ‘How is the business environment changing and what should we do to react on these changes?’ Organisations often run a single instance of the strategic planning process covering the whole business.

Strategic planning is a continuous and largely unstructured process, which is tightly integrated with regular strategic management activities, e.g. environmental analysis, identification of competitive advantages and goals formulation. From the temporal perspective, this process is often aligned to the annual business planning cycle, important business dates, periods and events, e.g. ends of the financial year, board meetings or updates of a business strategy.

Strategic planning is carried out collaboratively by senior business leaders and architects, who organise numerous meetings, workshops and presentations in order to decide what to do in the future, develop shared global plans for both business and IT and document these plans in considerations and visions. For example, as part of strategic planning business executives and architects may formulate a set of principles and policies regulating how IT should work, create business capability models to ‘heatmap’ strategic capabilities and develop more detailed IT investment roadmaps. The overall meaning of this process can be best summarised as strategy-to-portfolio, i.e. converting an abstract business strategy into more specific suggestions regarding the desired IT investment portfolio.

Initiative delivery

The initiative delivery process revolves around outlines and designs EA artifacts. The goal of this process is to deliver optimal IT solutions for specific needs by means of answering the following question: ‘What is the best way to address the requested need and all the associated requirements?’ Organisations run multiple instances of the initiative delivery process simultaneously, i.e. one instance for each active IT initiative, project or program (most IT initiatives actually represent business initiatives with IT components).

Initiative delivery is a sequential process consisting of two inherent steps: initiation and implementation. This process is closely integrated with regular project and program management activities, e.g. scoping, estimating, scheduling, budgeting and monitoring. From the temporal perspective, this process is linked to the established initiative delivery phases and gates, e.g. scope, evaluate, plan, build, test and deploy.

For you

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

The first step of initiative delivery (i.e. initiation) is carried out collaboratively by business leaders and architects, who organise discussions and presentations in order to analyse possible solution implementation options, select the most preferable ones, document these options in outlines and make formal investment decisions. For example, as part of the initiation step, business managers and architects may develop initial options assessments to evaluate the available options from the business point of view, then create more elaborate solution overviews with respective business cases for the preferred options and finally approve the corresponding IT investments.

The second step of initiative delivery (i.e. implementation) is carried out together by architects and project teams, who collaborate on a daily basis to develop more detailed designs based on the previously approved outlines and then implement these designs. For example, as part of the implementation step, architects and IT specialists may create preliminary solution designs to confirm the expected project timelines and costs, then produce more technical implementation-ready solution designs and finally build tangible IT systems according to these designs.

The overall meaning of the initiative delivery process can be best summarised as need-to-solution, i.e. converting a specific need into a concrete IT solution addressing this need in the most optimal manner.

Technology optimisation

The technology optimisation process revolves around standards and landscapes EA artifacts. The goal of this process is to improve the overall quality of the organisational IT landscape by means of answering the following question: ‘What is wrong with the current IT landscape and what should we do to improve it?’ Organisations often run a single instance of the technology optimisation process embracing the entire IT landscape.

Technology optimisation is a continuous and unstructured process, which may be not integrated with any regular processes or activities and performed largely in a standalone manner. From the temporal perspective, this process may be carried out independently without any systematic schedule, often on an as-necessary basis or even opportunistically, e.g. in the absence of other higher-priority activities.

Technology optimisation involves mostly architects, though with some participation of senior IT leaders and technical subject-matter experts, and consists of numerous informal discussions within the IT department intended to analyse the IT landscape and its possible evolution and then reflect corresponding information in standards and landscapes.

For example, as part of technology optimisation architects may capture the structure of the existing IT landscape in a set of landscape diagrams and inventories, mark some IT assets as strategic or redundant, create a technology reference model to indicate which technologies should be used in the future and formulate more detailed guidelines to specify how exactly these technologies should be used. The overall meaning of this process can be best summarised as structure-to-rationalisation, i.e. understanding the current structure of the IT landscape and formulating the rationalisation strategy to guide its future evolution.

Enterprise architecture practice as a set of three processes 

The three processes provide a very abstract aggregate view of all the essential activities happening within established EA practices. Each of these processes represents an articulate and consistent ‘story’ in the context of an EA practice with its own unique goals, meaning, involved actors and supporting EA artifacts. However, these three processes are also closely interrelated with each other and together produce a synergistic decision-making system constituting an EA practice as a whole, or a ‘clockwork mechanism’ of an EA practice.

Specifically, the strategic planning process takes fundamental factors of the external business environment (e.g. shifting customer preferences, new business opportunities and competitor actions) as an input and converts them into high-level strategic plans for IT reflected in considerations and visions, which in turn launch new IT initiatives (i.e. spawn new instances of the initiative delivery process) and also provide strategic directions and requirements guiding the technology optimisation process.

The initiative delivery process takes as its input specific business needs incoming either from the strategic planning process (i.e. planned business needs) or directly from the external business environment (i.e. urgent business needs that have not been anticipated in advance) and converts them into new working IT solutions. Finally, the technology optimisation process takes the current structure of the organisational IT landscape as an input and converts it into technical rationalisation suggestions reflected in standards and landscapes, which in their turn inform the initiative delivery process, e.g. suggest which IT assets, technologies and implementation approaches should be used in new IT solutions.

Besides the direct and obvious relationships described above, somewhat less strong, reverse relationships between the three processes also exist. For instance, the technology optimisation process informs the strategic planning process regarding strategic IT capabilities and constraints that can facilitate or inhibit the execution of certain business strategies.

Similarly, IT initiatives cancelled as part of the initiative delivery process (e.g. due to their technical infeasibility or lack of compelling business cases) feed back into the strategic planning process and may cause the change of a global strategic direction, while modifications of the IT landscape resulting from the initiative delivery process, as well as new best practices learnt as part of this process, inform the technology optimisation process and may cause the update of respective EA artifacts. The process view of an EA practice with the three processes described above, their key actors, relevant EA artifacts and mutual interrelationships is shown in Figure 1.

Figure 1. The process view of enterprise architecture practice (click for larger image)

As Figure 1 suggests, an EA practice cannot be viewed as a single step-by-step process, where architects create numerous EA artifacts to describe all the layers of architecture from business to infrastructure, but rather as a complex set of diverse and interacting processes happening simultaneously, where different planning decisions are made collectively by relevant actors at appropriate organisational levels. In other words, successful EA practices do not resemble mechanistic step-wise processes (e.g. TOGAF ADM), but rather constitute organic communication and decision-making networks permeating entire organisations and involving various actors from senior business executives to project teams.

Importantly, an EA practice is an inherently complex phenomenon that cannot be described or explained in any ‘simple’ way. Moreover, an EA practice arguably represents one of the most sophisticated organisational practices where only certain high-level patterns can be articulated in a generic form (see Figure 1), while most lower-level details underlying these patterns (e.g. concrete EA artifacts, procedures and actors) are always highly organisation-specific. It is also critical to understand that an EA practice is never a work of architects alone since most processes in an EA practice deal with decisions EA artifacts and require active participation of other actors, most importantly business leaders and project teams, to add real value.