Using the TOGAF Enterprise Continuum to Classify Architecture Descriptions
Mar 7, 2018
Previously, I wrote about the need to digitize change capabilities and how enterprise architecture can support and provide value to your organization. I also discussed how to categorize architecture descriptions along different levels of abstraction. But there is one dimension I didn’t dive into: How generic or specific is the architecture description compared to your organization?
Over the past decade, reference architectures have been developed and many have been published. They are a very useful start describing an enterprise, and the architectures are more or less specific to our enterprise. I don’t want to lose myself in academic discussions about what should be classified as what, so I will focus on the big points of the idea behind.
The spectrum shown in the picture above starts at the left with the most generic type of architectures, the Foundation Architectures. Generic technology or infrastructure architectures often fall under this category, such as the Technical Reference Model (TRM), to which the TOGAF 9.1 specification refers. Here, we often find architecture descriptions of technologies or technological platforms.
Moving to the right, the Common Architectures can be built upon the Foundation Architectures. Usually, these are more specific to an organization’s architecture, but still, these kinds of architectures could potentially be applied in all industries. I would like to raise the example of an Enterprise Resource Planning (ERP) reference architecture, or an ERP system, that can be used in different industries.
If an architecture is more specific, but still potentially reusable in several organizations of the same industry, these kinds of architectures can be classified as Industry Architectures, e.g. ERP Automotive reference architecture. Another example is an ERP system that is developed to be used in the energy and water industry where companies in some countries face a lot of changing regulatory changes.
Organization-Specific Architectures are those architectures you describe for your organization, mainly to support programs or projects. So they are therefore the most specific architecture descriptions for your enterprise.
TOGAF calls the architecture descriptions “artifacts,” which are “an architectural work product that describes an aspect of the architecture” and can be expressed in tables, matrixes or diagrams (TOGAF 9.1, 2.5). There is more information available in the TOGAF specification on how this category spectrum interrelates to each other, but let me focus on the most practical part.
In practice, I often see organization-specific architectures (our architecture descriptions) and industry-specific architectures. If you can´t find a reference architecture for your industry, you might want to give it another try to find a more generic architecture – common or foundation architectures. These reference models exist in various architecture domains; e.g. for capabilities, business processes (e.g. ITIL), functions, applications, technologies or risk and security.
Now, you can classify architecture descriptions according to functional/solution descriptions and according to their specificity. The following example will help apply this categorization in practice.
To make it practical, you can use technology classification taxonomies provided by companies that offer services about technology information. One such company is Flexera BDNA Technopedia, which provides information about technology lifecycles and more. This serves as a good starting point to classify technologies and is an alternative to the older TOGAF TRM. Also, if you miss some classifications, please remember what TOGAF says to “tailor the reference model to your need.”
The following table shows examples across the enterprise continuum:
Now, you have the means by which to classify your architecture descriptions. To achieve the value propositions of EA on the path to become an adaptive enterprise, you can take a closer look at the architecture and solution building blocks, which prevents you from getting lost in managing all the deployed instances as an EA architect.
In the next blogs in this series, I will outline how you can use ArchiMate to describe these architectures in a world-wide standard notation. This will help you standardize your communication regarding architecture descriptions to support strategic changes!
To get a brief explanation about ArchiMate and how it is positioned next to BPMN, UML and other notations, please read Combining ArchiMate 3.0 With Other Standards.