The relationship between enterprise architecture artefacts

March 2017

Man pushing big jigsaw pieceSvyatoslav Kotusev, an independent researcher, discusses the, sometimes, complex relationships between the different types of enterprise architecture artefacts.

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 artefacts, 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 artefacts with different stakeholders, lifecycles, usage and complex interrelationships.

Stakeholders, lifecycles and usage of EA artefacts

Previously I reported that the notion of EA can be explained by the CSVLOD model, which articulates six general types of EA artefacts 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 organization 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 artefacts 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 artefacts 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 artefacts 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 artefacts 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 artefacts, 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 artefacts 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 artefacts

The relationship between the six general types of EA artefacts of the CSVLOD model12,13 described above are shown in Figure 1.

Figure 1. Relationship Between EA Artefacts (click for larger image)

Figure 1 explains the internal structure of EA as a complex set of different interrelated EA artefacts. 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 artefacts 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.


1 TOGAF. 2011. 'TOGAF Version 9.1,' G116, The Open Group.

2 FEAF. 1999. 'Federal Enterprise Architecture Framework, Version 1.1,' Chief Information Officer Council, Springfield, VA.

3 Bernard, S.A. 2012. An Introduction to Enterprise Architecture, (3rd ed.). Bloomington, IN: AuthorHouse.

4 Spewak, S.H., and Hill, S.C. 1992. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology. New York, NY: Wiley.

5 Lange, M., Mendling, J., and Recker, J. 2016. 'An Empirical Analysis of the Factors and Measures of Enterprise Architecture Management Success,' European Journal of Information Systems (25:5), pp. 411-431.

6 Schekkerman, J. 2005. The Economic Benefits of Enterprise Architecture: How to Quantify and Manage the Economic Value of Enterprise Architecture. Victoria, BC: Trafford Publishing.

7 Kotusev, S. 2016. 'Enterprise Architecture Frameworks: The Fad of the Century.' Retrieved 3 August, 2016

8 Tucci, L. 2011. 'Two IT Gurus Face Off on Value of Enterprise Architecture Frameworks.' Retrieved 25 October, 2015

9 Kotusev, S. 2016. 'Enterprise Architecture Is Not TOGAF.' Retrieved 21 January, 2016

10 Kotusev, S. 2016. 'One Minute Enterprise Architecture.' Retrieved 30 June, 2016

11 Kotusev, S. 2016. 'The Critical Scrutiny of TOGAF.' Retrieved 15 April, 2016

12 Kotusev, S. 2016. 'Six Types of Enterprise Architecture Artifacts.' Retrieved 26 November, 2016

13 Kotusev, S. 2017. 'Eight Essential Enterprise Architecture Artifacts.' Retrieved 4 February, 2017

Image: iStock/536659322

Comments (5)

Leave Comment
  • 1
    John Sherwood wrote on 5th Apr 2017

    What an excellent and insightful article. I will add a comment that as described here the enterprise is seen as a complex dynamic system of systems with components and sub-systems interacting in real time - nothing is static.

    Those familiar with systems theory will know that such complex systems exhibit the property of emergence. Emergent properties are unexpected and often unwanted system behaviours that arise because of component interactions that were not foreseen at the design stage. All the components and subsystems are behaving are planned and designed - none are malfunctioning according to their specification, but the interactions produce overall system behaviours (in this case enterprise behaviours) that can be nasty surprises.

    This is not the fault of the designers - it is a property of the complexity that architecture seeks to simplify. The key to recognising the potential for emergence in Figure 1 are all those relationships labeled 'guides' or 'influences'. Yes, but how much and in what ways?

    Just sayin' - there are no silver bullets for this problem.

    Report Comment

  • 2
    Graziela wrote on 6th Apr 2017

    Very good article. With the adoption of Agile delivery, one could claim that Designs also needs to evolve, especially for the duration of the project. It is of course important to keep focus on what the original initiative was aiming to deliver (which is a problem some Agile purists don't see to understand), however having a fix detailed design at the level showed on the picture implies that the design will not evolve as the solution is being built (waterfall). Or one could claim that a new entity is needed (maybe "Delivery") and new relationships to the other areas defined. Delivery would "Change" or "Refine" Design, and so on. Just a though...

    Report Comment

  • 3
    Daniel Meyer wrote on 6th Apr 2017

    I thought that was a really insightful article, most of which I see reflected in my work; the key difference I see is in the Design.
    When a project is finished, I still see value in the design as it can be pushed back into the Landscape to form the basis of the next Design. It also has some ongoing value from a training, support and maintenance perspective.

    Report Comment

  • 4
    Eric Singleton wrote on 3rd May 2017

    All the articles by the author have provided useful insights. It is therefore unfortunate that the author has misunderstood the scope of EA. What has been discussed is an effective approach to IT Architecture for the identification and prioritisation of IT initiatives and for implementing IT projects (see fig 1. And definition of principles, visions, standards and model in ref [10]).
    Effective EA must address the whole of the enterprise including, for example, business process and operating procedure design, organisational design and customer journey/experience design.
    To be effective architects we need to appreciate that there is no such thing as an IT project; we are shaping business change projects of which enabling IT is a critical component, but not the primary focus.

    Report Comment

  • 5
    David Slight wrote on 12th Jun 2017

    Completely agree with Eric; this is just IT speak, not Enterprise language. I would also add that any strategic model or models have to encompass the execution of changes suggested. Without OCM, it is just IT Architecture!

    Report Comment

Post a comment