We are currently living in an interesting time. The digitization of all business capabilities has reached a new level and has had a huge impact on virtually every industry. Business models are being redefined and new companies have emerged to become global players. Today, companies must be more agile than ever before and the speed of change will only continue to increase.
To tackle this challenge, the only option is to become an “Adaptive Enterprise.” After digitizing business capability after business capability via strategic changes, most operations are digitized and the process will continue to extend to other operational areas. However, a very important capability is missing:
To become a truly “Adaptive Enterprise” you have to digitize your change capabilities!
Marc Lankhorst and Peter Matthijssen explain this in depth in their book, How to Become an Adaptive Enterprise. To be able to describe your business and its supporting technologies on various detail levels is an important capability to speed up strategic transformations. Enterprise Architecture provides a method and techniques to develop and describe the enterprise strategy, business, technologies, programs and how they’re connected.
Speaking the same language to align different roles, business areas, projects and operations is a constant challenge to strategic change. In practice and on the Web, we see a lot of architecture descriptions. Some use formal language, some use stencils provided by tools and some use plain matrices or textual descriptions.
Using formal notation provides the huge advantage of precision and alignment for architects, and allows them to answer:
What is the architecture description all about? Does everyone think the same when using the same words?
Does the architecture description address a functional description?
Does the architecture description address real-world assets, such as deployed servers?
Does it describe production, installation, backup systems, pre-production systems?
Does the architecture drawing describe parts of an industry architecture or our company’s architecture?
Where to start to get grip on the huge variety of architecture descriptions of different projects and programs?
First, we should be able to categorize architecture descriptions. To manage this, the TOGAF Enterprise Continuum is a very useful framework. It helps highlight which level of abstraction an architect is (currently) acting on, and outlines different levels to be used for different purposes: “The Enterprise Continuum provides methods for classifying architecture and solution artifacts […]”(TOGAF 9.1, section 39.1), and the picture below shows the general idea of classification.
Figure 1: Adaption from fig 39-1 TOGAF 9.1
Let´s start with the rectangle at the bottom. The deployed solutions describe what is actually implemented – the real-world assets. It reflects which solutions are selected and instantiated with a deployment. These deployed solutions may be the production installations, such as “SAP ERP P123” or “Salesforce P123,” and are often managed by Operations. Since the deployed solutions are instances of solutions, the solution building block continuum contains types or blueprints of solutions which are rolled out: “Solution Building Blocks (SBBs) […] may be either procured or developed” (TOGAF 9.1, 37.2.4). They are product or vendor aware, e.g. “SAP ERP” or “Windows Server” as a type of a product which can be procured and developed.
The upper orange rectangle of the Enterprise Continuum reflects the architecture building blocks (ABBs). “Architecture Building Blocks capture the architectural requirements and direct and guide the development of SBBs. They consist of, or they describe, the fundamental functionality (TOGAF 9.1, 37.2.3).” You can also call them conceptual or logical components; e.g. “Enterprise Resource Planning” or “Operating System.”
Architecture Building Blocks are functional descriptions (e.g. ERP, OS)
Solution Building Blocks are product types (e.g. SAP ERP, in-house developed software)
Deployed Solutions are deployed product instances (e.g. SAP ERP P123)
Now, you can already classify your architecture descriptions according to these three groups. If you are currently only managing the deployed solutions in a CMDB, there may be more descriptions of a different kind that help you to architect the future of your enterprise!
More on classifying architecture descriptions
Next to these three groups, the Enterprise Continuum provides a spectrum for the architecture and solution building blocks to classify the architecture description to answer, “How specific is the architecture description compared to my organization?” This information will help complete the picture of classifying architecture descriptions in the next blog.