Eight essential enterprise architecture artifacts

February 2017

Floor number 8Svyatoslav Kotusev discusses eight specific enterprise architecture (EA) artifacts that seemingly can be considered as essential for EA practices, and explains how these EA artifacts map to the generalised CSVLOD taxonomy.

Enterprise architecture (EA) practice implies developing and using specific EA documents (artifacts) to facilitate information systems planning. Popular EA books1,2 and frameworks, e.g. TOGAF3 or IAF4, provide exhaustive lists of EA artifacts to be used in EA practices. However, the approaches to EA advocated by these sources represent typical management fads that cannot be successfully implemented in organisations5,6,7,8. Therefore, the comprehensive lists of EA artifacts recommended by these books and frameworks can be considered at best only as ‘dictionaries’ providing little useful information, and, at worst, as a pure science fiction. But what EA artifacts then are used in real successful EA practices? Previously I presented the taxonomy defining six general types of EA artifacts used in real EA practices (namely considerations, standards, visions, landscapes, outlines and designs)9. Here I explain how these EA artifacts map to the generalised CSVLOD taxonomy.

Eight essential EA artifacts

As a result of my analysis of EA artifacts I identified eight specific EA artifacts which can arguably be considered as essential for EA practices since they are found in the majority of organisations with more or less mature EA practices. These eight essential EA artifacts are principles, technology reference models, guidelines, business capability models, roadmaps, landscape diagrams, solution overviews and solution designs. Importantly, these EA artifacts represent eight consistent groups of EA artifacts with very similar meaning found in different organisations regardless of their organisation-specific titles. The titles provided above are merely the most popular titles for these EA artifacts, but the same EA artifacts can be used under different titles in different organisations. Now I will describe each of these essential EA artifacts in detail.

Principles (sometimes also called maxims) describe high-level policy statements having significant impact on both business and IT, for instance, that all provided services should be available to customers via single sign-on. The list of ~10-20 principles is typically defined and then periodically reviewed collaboratively by architects and senior business leaders in order to achieve the agreement on basic rules, values, directions and aims. All business and IT decisions, as well as architectures of all IT projects, are evaluated for their compliance with established principles. Principles are the most ‘classic’ EA artifacts related to the considerations general type (business-focused rules)9. Like all EA artifacts related to considerations, principles represent the overarching context for information systems planning.

Technology reference models (TRMs) (can be called technology standards or split into infrastructure, applications and other more specific reference models) provide standardised sets of available technologies to be used in all IT projects structured according to their domains, often with their lifecycle phases color-coded. TRMs are typically developed by architects and subject-matter experts in specific technologies and then updated in a periodic manner, often yearly. Architectures of all IT projects are reviewed by architects to ensure their alignment to TRMs and thereby achieve overall technological homogeneity and consistency of the IT landscape.

Guidelines (often also called standards) define low-level IT-specific prescriptions or best practices to be followed in all IT projects grouped by their technology domains, for instance, that certain network protocols should be used for particular purposes or certain encryption standards should be used for particular types of data. Guidelines are typically developed and periodically updated by architects and subject-matter experts in specific areas. Architectures, of all IT projects, are reviewed by architects to ensure their adherence to guidelines and thereby achieve technical consistency and, in some cases, regulatory compliance as well.

Even though both TRMs and guidelines describe some implementation-level technical rules relevant to IT projects, they are complementary to each other because TRMs provide lists of technologies to be used, while guidelines define more narrow prescriptions regarding their usage. TRMs and guidelines are the most common EA artifacts related to the standards general type (IT-focused rules)9. Like all EA artifacts related to standards, TRMs and guidelines represent proven reusable means for IT project implementation.

Business capability models (BCMs) (sometimes also called business capability maps) provide structured views (‘maps’) of all organisational business capabilities on a single page, sometimes together with other supporting information like business strategy, objectives, main customers, partners, etc. BCMs are typically developed collaboratively by architects and senior business leaders and then ‘heatmapped’ to identify best investment opportunities, prioritise future IT spending and ensure the alignment between IT investments and desirable business outcomes. BCMs are often considered as ‘entry points’ into IT for business executives.

Roadmaps (which can also be called investment roadmaps, divisional roadmaps, capability roadmaps, technology roadmaps, etc.) provide structured views of planned future IT investments with their tentative timelines aligned to different capabilities or business areas, often outlining their high-level target states after several years. They usually explain how and when ‘heatmapped’ business capabilities will be uplifted. Roadmaps are typically developed collaboratively by architects and senior business leaders and help prioritise proposed IT initiatives, align future IT investments to business plans and initiate IT projects.

Even though both BCMs and roadmaps provide some descriptions of the desired future from the business perspective, they are complementary to each other because BCMs help decide where future IT investments should go, while roadmaps help decide when these IT investments should be made. BCMs and roadmaps are definitely the most common EA artifacts related to the visions general type (business-focused structures)9. Like all EA artifacts related to visions, BCMs and roadmaps represent agreed and shared long-term goals for business and IT.

Landscape diagrams (used under very diverse titles, including system interaction diagrams, relational diagrams, platform architectures, one page diagrams, integration contexts, etc.) describe high-level connections between various applications, databases, platforms, systems and sometimes business processes covering large parts of the corporate IT landscape, typically in their current states. Landscape diagrams are usually maintained by architects and updated at the completion stages of all IT projects modifying the IT landscape. They help architects optimise the IT landscape and select best implementation options for new IT projects. Landscape diagrams are seemingly the most common EA artifacts related to the Landscapes general type (IT-focused structures)9. Like all EA artifacts related to landscapes, landscape diagrams represent reference materials for general technical planning.

Solution overviews (can be called conceptual architectures, solution outlines, conceptual designs, preliminary solution architectures, solution briefs, etc.) describe specific IT projects in a brief business-oriented manner, usually including their high-level architectures, expected business value, estimated costs, risks and timelines. Solution overviews of ~15-30 pages long are typically developed for all proposed IT projects at their early stages collaboratively by their business sponsors and architects. They help senior business stakeholders estimate the overall business impact and value of proposed IT projects and make informed investment decisions regarding these projects. Solution overviews are the most common EA artifacts related to the outlines general type (business-focused changes)9. Like all EA artifacts related to outlines, solution overviews represent benefit, time and price tags for specific IT projects.

Solution designs (can be called high-level designs, solution definitions, detailed designs, full solution architectures, project-start architectures, etc.) describe specific IT projects in a highly technical manner with all the necessary details required to implement these projects. Solution designs of ~25-50 pages long are typically developed for all approved IT projects collaboratively by architects, project teams and business representatives to reflect both business and architectural requirements. They are used by projects teams during the whole duration of IT projects and help implement these projects according to the pre-agreed requirements. Solution designs are the key EA artifacts related to the designs general type (IT-focused changes)9. Like all EA artifacts related to designs, solution designs represent communication interfaces between architects and project teams.

The eight essential EA artifacts described above with their schematic representations mapped to the generalised CSVLOD taxonomy for EA artifacts9 are shown in Figure 1.

 

Figure 1. Eight essential EA artifacts (click for larger image)

Figure 1 shows the schematic representation and mapping of the eight essential EA artifacts actively used in most established EA practices. Importantly, these eight EA artifacts are merely the most typical, but far from the only possible EA artifacts. My analysis shows that reasonably mature EA practices usually use around 10-15 different EA artifacts. Therefore, the full set of EA artifacts used in successful EA practices is not limited to these eight EA artifacts. However, all real EA artifacts can still be mapped in a similar manner to one of the six general types of EA artifacts defined by the CSVLOD taxonomy9.

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 Bernard, S.A. 2012. An Introduction to Enterprise Architecture, (3rd ed.). Bloomington, IN: AuthorHouse.

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

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

4 van’t Wout, J., Waage, M., Hartman, H., Stahlecker, M., and Hofman, A. 2010. The Integrated Architecture Framework Explained: Why, What, How. Berlin: Springer.

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

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

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

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

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

 

Image: iStock/157423692

Comments (4)

Leave Comment
  • 1
    Joe Lewis-Bowen wrote on 17th Feb 2017

    This way of organizing an EA team's artifacts is simple but covers useful outputs very well. I recognized what my team's being doing here (in a slightly haphazard way, for a public sector organization), so I hope we can use this 'framework' to improve our service!

    Report Comment

  • 2
    Julian Brearley wrote on 17th Feb 2017

    How refreshing it is to read an article that actually proposes condensing the key artefacts of a methodology rather than further complicating it. In this case 'less is more' because the author appears to have managed to distil the 'essence' of the methodology without discarding key ingredients.
    It is also refreshing to read an article that is not afraid to raise and challenge the subject of 'management fads' in our profession, often the source of much lucrative CPD certification business but perhaps rather less real world complete implementation success.
    Given his ability to distil and simplify, perhaps Mr Kotusev would next like to turn his attention to the question of the scalability of our most popular project and BA methodologies. After many years I for one still sometimes struggle with scalability of complex methodologies in smaller organisations and for smaller (but nethertheless stregically important) projects.

    Report Comment

  • 3
    David Slight wrote on 6th Mar 2017

    Suggest the "essential" elements need to focus more on traceability and outcomes - where is the list of stakeholders and their influences and desires? How do these artefacts connect with each other? There is only one mention of stakeholders in Solution Overviews "help senior business stakeholders estimate the overall business impact and value" of proposed IT projects" - surely we must do much more than "help" these people - there needs to be a shared ownership of the value and outcomes. While I also applaud the reductive approach, this list still includes much that is irrelevant rather than essential.

    Report Comment

  • 4
    RICHARD HILLIER wrote on 21st Mar 2017

    Seemed to missing an Enterprise Information (or Data) Model.

    Report Comment

Post a comment