Eight essential enterprise architecture artifacts

Enterprise architecture (EA) practice implies developing and using specific EA documents (artifacts) to facilitate information systems planning. Popular EA books, and frameworks, e.g. TOGAF or IAF, 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 organisations. 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). 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). 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). 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.

For you

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

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). 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). 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). 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). 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 artifacts are shown in Figure 1.

Figure 1. Eight essential EA artifacts

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 taxonomy.

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.