Enterprise architecture (EA) is a description of an organisation from the integrated business and IT perspective intended to facilitate information systems planning. Popular EA frameworks1,2, books3,4 and even academic articles5 suggest that EA provides comprehensive descriptions of the current and future states of an organisation as well as a transition roadmap between them. Essentially, the mainstream EA literature typically describes EA as a thick ‘book’ full of various diagrams with four distinct ‘chapters’: business architecture, data architecture, application architecture and technology architecture. A relatively well-known EA guru Jaap Schekkerman even argues that EA is a ‘complete expression of the enterprise’6. Accordingly, mainstream approaches to EA, e.g. TOGAF ADM, suggest that EA, as a comprehensive book, is developed step-by-step, chapter by chapter and then used as an instrument for planning.
However, all these approaches are based on the false belief widely promoted by John Zachman that organisations can be planned in detail like buildings or any other engineering objects. These approaches represent typical management fads and cannot be successfully implemented7,8, while successful EA practices do not resemble these approaches in any real sense9,10,11. Unsurprisingly, my analysis shows that the EA documentation in successful EA practices neither can be represented as two separate descriptions of the current and future states, nor can be easily split into distinct chapters (e.g. business, data, applications, etc.). Instead, individual EA artifacts, which often describe multiple domains simultaneously, can describe various points in time and can even be essentially timeless. Moreover, EA, in general, cannot be described as a comprehensive ‘book’, which is developed and then used, but rather as a set of diverse EA artifacts with different stakeholders, lifecycles, usage and complex interrelationships.
Stakeholders, lifecycles and usage of EA artifacts
Previously I reported that the notion of EA can be explained by the CSVLOD model, which articulates six general types of EA artifacts used in all mature EA practices: Considerations, standards, visions, landscapes, outlines and designs12,13. Considerations (principles, policies, maxims, etc.) are global conceptual rules and fundamental considerations important for business and relevant for IT. Standards (technology reference models, guidelines, reference architectures, etc.) are global technical rules, standards, patterns and best practices relevant for IT systems. Visions (business capability models, roadmaps, future state architectures, etc.) are high-level conceptual descriptions of an organisation from the business perspective. Landscapes (landscape diagrams, inventories, platform architectures, etc.) are high-level technical descriptions of the organisational IT landscape. Outlines (solution overviews, conceptual architectures, options papers, etc.) are high-level descriptions of specific IT initiatives understandable to business leaders. Designs (solution designs, solution architectures, project-start architectures, etc.) are detailed technical descriptions of specific IT projects actionable for project teams.
Considerations represent the overarching organisational context for information systems planning. Their purpose is to help achieve the agreement on basic principles, values, directions and aims. Considerations are permanent EA artifacts which live and evolve together with an organisation. They are developed once, updated according to the ongoing changes in the business environment and used to influence all architectural decisions. For example, a set of ~10-20 architecture principles are established once by senior business leaders and architects and then periodically reviewed and updated, often on a yearly basis. These principles drive all EA-related decisions and thereby influence the development of visions, selection of standards and evolution of landscapes, as well as architectures of all IT initiatives described in outlines and designs.
Standards represent proven reusable means for IT systems implementation. Their purpose is to help achieve technical consistency, technological homogeneity and regulatory compliance. Standards are permanent EA artifacts which live and evolve together with an organisation. They are developed on an as-necessary basis, updated according to the ongoing technology progress and used to influence architectures of all IT initiatives. For example, technology reference models are developed gradually by architects and periodically updated when new technologies emerge on the market. Technology reference models provide technology selection guidelines to all outlines and designs developed for specific IT initiatives and thereby shape resulting landscapes.
Visions represent shared views of an organisation and its future agreed by business and IT. Their purpose is to help achieve the alignment between IT investments and long-term business outcomes. Visions are permanent EA artifacts which live and evolve together with an organisation. They are developed once, updated according to the ongoing changes in the business strategy and used to guide IT investments, prioritise IT initiatives and initiate IT projects. For example, business capability models are developed once by senior business leaders and architects and then periodically ‘re-heatmapped’ based on the changing business priorities. Heatmapped business capabilities initiate outlines for new IT initiatives and guide the selection of standards, evolution of landscapes and development of designs.
Landscapes represent a knowledge base of reference materials on the IT landscape. Their purpose is to help understand, analyse and modify the structure of the IT landscape. Landscapes are permanent EA artifacts which live and evolve together with an organisation. They are developed on an as-necessary basis, maintained current to reflect the evolution of the IT landscape and used to rationalise the IT landscape, manage the lifecycle of IT assets and plan new IT initiatives. For example, landscape diagrams are developed gradually for different areas by architects and periodically updated when new IT systems are introduced or existing IT systems are decommissioned. Landscape diagrams provide the descriptions of the existing IT environment for planning all outlines and designs of new IT solutions.
Outlines represent benefit, time and price tags for proposed IT initiatives. Their purpose is to help estimate the overall business impact and value of proposed IT initiatives. Outlines are temporary EA artifacts, which are short-lived, single-purposed and disposable. They are developed at the early stages of IT initiatives, used to evaluate, approve and fund specific IT initiatives, but then archived after investment decisions are made. For example, solution overviews are developed by architects and business leaders for all new IT initiatives to stipulate key requirements, discuss available implementation options and support investment decisions. After the IT initiatives are approved, solution overviews lose their value, but provide the initial basis for developing more detailed technical designs for these IT initiatives.
Designs represent communication interfaces between architects and project teams. Their purpose is to help implement approved IT projects according to business and architectural requirements. Designs are temporary EA artifacts which are short-lived, single-purposed and disposable. They are developed at the later stages of IT initiatives, used to implement IT projects, but then archived after the corresponding projects are implemented. For example, solution designs are developed by architects, project teams and business representatives for all new IT projects to stipulate detailed requirements and describe required IT solutions. After the IT projects are implemented, solution designs lose their value and get stored in organisational document repositories.
The relationship between EA artifacts
The relationship between the six general types of EA artifacts of the CSVLOD model12,13 described above are shown in Figure 1.
Figure 1. Relationship Between EA Artifacts
Figure 1 explains the internal structure of EA as a complex set of different interrelated EA artifacts. As evident from Figure 1, EA can hardly be conceptualised as a single ‘book’ providing a ‘complete expression of the enterprise’, but rather as a complex ecosystem of different interacting elements. EA is not ‘developed and then used’, but consists of different types of EA artifacts with different lifecycles, some permanent and some temporary, which co-evolve together in organisations.
The views in this article are the views of the author and are his own personal views that should not be associated with any other individuals or organisations.
