Organizations today are facing a rapidly increasing pace of change. They adopt agile methods that impact the entire enterprise to drive faster transformation. Naturally, change must be communicated, but documenting every detail is impractical, as the information could become outdated in just a week or even a day. Enterprise architecture is a discipline that outlines an organization’s structure across various levels of abstraction, including strategy, business, information, application, and technology. ArchiMate is the global standard for visually describing and analyzing an enterprise holistically. It addresses these layers at varying levels of granularity, incorporating different levels of abstraction.
ALSO READ: Get expert insights on Enterprise Architecture Strategy
Defining these levels can be challenging but is crucial for the depth of analysis and the effort required to maintain up-to-date information. This blog provides an overview of the various levels of abstraction in enterprise architecture, with examples to illustrate what can be done at each level.
The ArchiMate Core Framework offers the ability to model the active structure (e.g. applications), behavior (e.g. processes) and passive structure aspects (e.g. data objects) of an enterprise architecture. In enterprises, a lot of diagrams circulate that partially describe a domain from a certain point of view: capability maps, business processes, information flows, application landscapes, technology architectures etc. These diagrams consist of the aspects mentioned above and they often vary in their level of abstraction. You might see generalizations, types of IT solutions abstracting from single deployments, or detailed process variants to show differences between regions. In consequence, you can add three “sub-aspects” to each aspect: Solution-agnostic, Solution-specific and Deployment-specific. By doing this you can create an Overview of the Levels of Abstractions in Enterprise Architecture.
First of all, the picture shows that you can model all these levels of abstraction with ArchiMate, but it does not tell you that you should model all these levels! For example, modeling every deployed instance of a technology service is definitely out of scope of enterprise architecture. But let’s start from the top of the picture.
Looking at the behavior column, we can model (at least) three levels of abstraction as shown in the picture.
In the application layer we reflect the same circumstances by showing that we have front office application services that can support the front office processes (very abstract, but useful for high-level patterns) and that we have an application service to “Create Sales Order”. Modeling a Sales Department in the business layer (see the active column) that performs the Sales Process already describes a solution to what we want to get done. In the application layer, we might want to distinguish between application services of different solutions, which leads to one additional level of abstraction for applications.
The behavior aspect of the technology layer follows the same logic as the behavior aspect of the application layer. You can model high-level types of technology and (solution-specific) types of services to describe architecture patterns or project-specific designs, you can describe deployed or implemented services of technology solutions, and you can describe types or bundles of technology or infrastructure functionality to setup a technology reference framework.
The other two aspects (active, passive structure) follow the same logic, so we intentionally don´t describe their elements in detail in this blog, except for a few. In the active structure aspect of the application layer, it is worth mentioning that you can also use an application component to model an Enterprise Resource Planning (ERP) application. This is an option when you want to start with a generic name for the new application, relate it to other existing solutions, and add the name of the solution when it is selected. This is a practical example how an architecture model evolves over time.
In the active structure aspect of the technology layer we intentionally left out the deployed or implemented elements of system software, because that would correspond to specific licenses running on the server nodes. That is too far removed from enterprise architecture modeling and too deep into the implementation details. When designing enterprise architectures, usually only types of servers and system software (e.g. Windows 10) are modelled, not each deployed instance or license. Server instances are usually managed in CMDBs and the used system software provides a fruitful input for enterprise architecture repositories.
The passive structure aspect can describe the information architecture in your enterprise. There are different approaches to describe information architecture using concepts like the conceptual/ logical/ physical levels reflected in ArchiMate in the business object, data object, and artifact concepts. This
can be incorporated in the approach shown above. But you need to keep a possible federated approach into account here, too.
In this blog we have demonstrated that you can use ArchiMate at different levels of abstraction. It is also possible to add more granularity as you can create a hierarchical drill-down for each element. In the big-picture overview, we labeled the right levels with “Design” and “Design & Document”. This gives a rule of thumb for which purpose the levels of abstraction are usually used.
The elements indicated with “Design” can be used to model types of building blocks in an enterprise. At the same time, there might also be different variants of processes or systems (not explicitly modeled as own elements). Modeling architecture at this level will allow you to create an architecture repository for design purposes. You can create different architecture views by reusing the same building blocks to describe views of other options, variants, or reference architectures. By reusing the same elements, you ensure consistent naming and reuse of additional documentation and assessments (e.g., “current standard technology stack”), and by using ArchiMate, you use a common language for the development of your enterprise. These advantages help to standardize communication in transformation projects and make it, therefore, faster and more efficient.
The elements indicated with “Design & Document” can be used to capture the actual deployment level of an enterprise. This usually includes process variants or IT instances, for example. It allows you to do to enterprise portfolio management, trace faults in your IT infrastructure, assess the business impact of a server failure, and more. It is certain that for a large enterprise, this level of abstraction cannot be modeled and maintained by a small centralized EA team. You need to involve additional roles in the organization, and preferably automate harvesting such information with techniques like process mining and crawlers that listen to your network traffic, service bus communication, et cetera. Applying this level of abstraction to projects, you can manually model all variants or examples and capture the rest via mass imports to complete the repository information. The visual modeling (of examples) reflects the design flavor and the completion of changes to all elements reflects the documentation flavor.
Key message: This overview provides an instrument to classify levels of abstraction of enterprise architecture descriptions and gives hints for which tasks which level of abstraction is useful. Analyze and decide which level you need to describe for your purpose. Everything is possible and there is a way to connect all dots with Bizzdesign Horizzon. Contact us for more information.
Managing Consultant & Chief Technology Evangelist at Bizzdesign
Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.
Managing Consultant at Bizzdesign
Bernd has held various roles during career, including consultant, trainer, and global solutions manager. His expertise includes Business Architecture, Enterprise Architecture, Portfolio Management, and Business Intelligence, where he has guided customers in maximizing value from Bizzdesign Horizzon predominantly in finance and manufacturing sectors in DACH and EMEA region.
