Language: The Basis of Successful Strategic Transformations
Feb 27, 2018
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:
Does everyone think the same when using the same words?
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.
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.”
In short:
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!
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.
You can also take a look at our other useful blogs and papers about TOGAF, ArchiMate and how to become an adaptive enterprise: https://go.bizzdesign.com/The-Adaptive-Enterprise
ALSO CHECK: Cyber Security 5 Steps to Stay Safe in a Dangerous World
