Six types of enterprise architecture artifacts

November 2016

Closeup of designers handsSvyatoslav Kotusev explains his taxonomy for defining six types of enterprise architecture artifacts.

Enterprise architecture (EA) is widely used in diverse organisations across the globe and is usually associated with popular EA frameworks (TOGAF, Zachman, FEAF, etc.). However, EA frameworks are no more than typical management fads with the long history of unsuccessful implementations1, 2 and successful EA practices do not resemble the recommendations of these EA frameworks in any real sense3, 4, 5. But if popular EA frameworks do not explain real EA practices then how can the notion of EA can be explained and conceptualised?

Previously I presented the ‘one minute’ conceptualisation of EA, which explains EA as a set of four different types of EA artifacts, namely: Principles, Visions, Standards and Models6. My further analysis of EA artifacts used in successful EA practices shows that the notion of EA can be better explained with a refined taxonomy defining six general types of EA artifacts: Considerations, Standards, Visions, Landscapes, Outlines and Designs.

Taxonomy for EA artifacts

My in-depth analysis of EA artifacts identified in the organisations successfully practicing EA shows that all EA artifacts can be grouped into six general types based on what EA artifacts describe and how EA artifacts describe.

Firstly, all EA artifacts can be classified based on the objects of their description, from more generic ones to more specific ones, into Rules, Structures and Changes. Rules describe broad global rules defining the organisation or its divisions; Structures describe high-level structures of the organisation or its parts, while Changes describe specific proposed changes to the organisation.

Secondly, all EA artifacts can be classified based on the terminology of their description into Business-focused and IT-focused. Business-focused EA artifacts are typically technology-neutral and use business language (money, customers, capabilities, business goals, competitive advantages, etc.), while IT-focused EA artifacts are usually purely technical and use IT-specific language (systems, applications, databases, platforms, networks, etc.).

The intersection of the two orthogonal classifications described above produces the taxonomy with six general types of EA artifacts: Considerations, Standards, Visions, Landscapes, Outlines and Designs.

Six general types of EA artifacts

Considerations, Standards, Visions, Landscapes, Outlines and Designs are the six general types of EA artifacts found in all mature EA practices. Despite the diversity of identified EA artifacts relevant to each type, these six general types of EA artifacts reasonably accurately describe the main common properties of all related EA artifacts. Specifically, the six general types of EA artifacts explain what these EA artifacts describe, how they are used, what their purpose is and what benefits result from their usage.

Considerations are business-focused Rules. EA artifacts related to this general type identified in organisations include principles, policies, maxims, core drivers, architecture strategies, conceptual data models, governance papers, position papers, strategy papers and whitepapers. All these EA artifacts describe global conceptual rules and considerations important for business and relevant for IT. Considerations are developed collaboratively by senior business leaders and architects and then used to influence all architectural decisions. Their purpose is to help achieve the agreement on basic principles, values, directions and aims. The proper use of Considerations leads to improved overall conceptual consistency.

Standards are IT-focused Rules. EA artifacts related to this general type identified in organisations include guidelines, standards, patterns, IT principles, data models and reference architectures as well as technology, application, infrastructure, platform and security reference models. All these EA artifacts describe global technical rules, standards, patterns and best practices relevant for IT systems. Standards are developed by architects and technical subject-matter experts and then used to influence architectures of all IT projects. Their purpose is to help achieve technical consistency, technological homogeneity and regulatory compliance. The proper use of Standards leads to reduced costs, risks and complexity.

Visions are business-focused Structures. EA artifacts related to this general type identified in organisations include business capability models, value reference models, business context diagrams, business reference architectures, business activity models, enterprise process maps, future state architectures and all sorts of roadmaps. All these EA artifacts provide high-level conceptual descriptions of the organisation from the business perspective. Visions are developed collaboratively by senior business leaders and architects and then used to guide and prioritise all IT initiatives. Their purpose is to help achieve the alignment between IT investments and business outcomes. The proper use of Visions leads to improved effectiveness of IT investments.

Landscapes are IT-focused Structures. EA artifacts related to this general type identified in organisations include platform architectures, relational diagrams, application portfolios, integration contexts, system interaction diagrams, inventories, asset registers, IT systems value maps, one page diagrams, enterprise technology models and all sorts of technology roadmaps. All these EA artifacts provide high-level technical descriptions of the organisational IT landscape. Landscapes are developed and maintained by architects and used to support technical decision-making and facilitate project planning. Their purpose is to help rationalise the IT landscape, manage the lifecycle of IT assets and plan IT projects. The proper use of Landscapes leads to increased reuse and flexibility, reduced duplication and legacy.

Outlines are business-focused Changes. EA artifacts related to this general type identified in organisations include conceptual architectures, solution overviews, conceptual designs, solution briefs, preliminary solution architectures, solution outlines, idea briefs, solution proposals, initiative summaries, investment cases, options papers and solution assessments. All these EA artifacts provide high-level descriptions of specific IT projects understandable to business leaders. Outlines are developed collaboratively by architects and business leaders and then used to evaluate, approve and fund specific IT projects. Their purpose is to help estimate the overall business value of specific IT projects. The proper use of Outlines leads to improved efficiency of IT investments.

Designs are IT-focused Changes. EA artifacts related to this general type identified in organisations include detailed designs, solution definitions, full solution architectures, high-level designs, solution specifications, integrated solution designs, physical designs, solution blueprints and technical designs. All these EA artifacts provide detailed technical descriptions of specific IT projects actionable for project teams. Designs are developed collaboratively by architects, project teams and business representatives and then used by project teams to implement IT projects. Their purpose is to help implement IT projects according to business and architectural requirements. The proper use of Designs leads to improved quality of the project delivery.

The resulting taxonomy with six general types of EA artifacts described above is shown on Figure 1.

Six General Types Of EA Artifacts

Figure 1. Taxonomy with Six General Types of EA Artifacts (click for larger image)

Despite its apparent simplicity, this taxonomy with six general types of EA artifacts provides a clear, straightforward, powerful and evidence-based conceptual explanation of the complex notion of EA.

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.

References

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

2 Gaver, S.B. 2010. 'Why Doesn't the Federal Enterprise Architecture Work?,' Technology Matters, McLean, VA.

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

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

5 Holst, M.S., and Steensen, T.W. 2011. 'The Successful Enterprise Architecture Effort,' Journal of Enterprise Architecture (7:4), pp. 16-22.

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

 

Image: iStock/503215052

Comments (5)

Leave Comment
  • 1
    Graeme Betts wrote on 1st Dec 2016

    Very easy to comprehend and makes good sense

    Report Comment

  • 2
    Michael Griffith wrote on 2nd Dec 2016

    Many thanks for this excellent article. An easy to understand high level approach to Enterpnse Architecture. Distinguishes clearly between the business structure and the supporting IT structure. Thanks for being honest about the ineffectiveness of TOGAF.

    Report Comment

  • 3
    Ganiat Kazeem wrote on 23rd Dec 2016

    An insightful and straightforward outline. Very helpful for compacting consulting delivery

    Report Comment

  • 4
    Harry Hendrickx wrote on 6th Jan 2017

    Thank you for this overview. This matrix makes sense to me. However, I have two issues with it. The first one is the separation between business and IT. The current challenges are integration. The matrix does not address this.
    Secondly I agree that TOGAF for instance can be criticized a lot. However, it is an effort to get the different elements standardized. That is exactly the problem with architects in general. If each does not convey their value in a concise and consistent way, stakeholders will keep on having difficulty to accept it. TOGAF is currently in a good process to align the different cross atlantic communities and their vocabularies. Part of this may be useful to consider and compare with the above matrix as well. Part I for instance of the Open Business Architecture Standard published by The Open Group last summer contains a vocabulary that fits well with the matrix but is more specific in what exactly for instance rules, visions or landscapes are.
    Still for consulting practice the above may be sufficient, if we seek to explain it to non-insiders I might have a challenge with it.
    Notwithstanding these comments, I appreciate the matrix and find it also insightful.

    Report Comment

  • 5
    David Slight wrote on 9th Jan 2017

    I wanted to support Harry Hendrickx comments as I agree totally. Until Architecture and Architects understand that we must talk consistently in terms of value and outcomes, then the decline into obscurity continues.

    Report Comment

Post a comment