An Overview of the Levels of Abstraction in Enterprise Architecture

The Role of Abstraction in Enterprise Architecture

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: Business  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. 
 

Introducing the overvieww

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.

Describe what the business does

Looking at the behavior column, we can model (at least) three levels of abstraction as shown in the picture.

• Front Office Process: Having a rectangle in a diagram stating “Front Office Process” takes a very high level of abstraction to describe specific parts of behavior in your enterprise and probably some department can be named that is fulfilling these types of processes. These boxes, or these elements can be used to describe high-level patterns or classifications within your enterprise. For instance, specific requirements may apply to all Front Office Processes because they have direct contact with customers.
• Sales Process: The “Sales Process” could be a subtype of “Front Office Process” and it is less abstract. It can be related to other process types to describe a pattern or standard. For example, all international branches of your enterprise have to perform the same approval of contracts in their sales processes, which may differ in other aspects based on local regulations and market conditions.
• Sales US/UK: It is possible that your sales processes vary between the US and the UK, for example because you need to deal with sales tax in a different way. There may even be multiple versions of the US sales process because taxable goods and services differ between states and some states don’t even have a sales tax. So you have different process versions implemented in different regions that are of the same type “Sales Process”. Process managers will immediately recognize this difference of process variants.
   

Describe what the applications and technology do

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.

• Create Sales Order SAP SD: This service describes a type of solution-specific application behavior, unlike the “Create Sales Order ” application service. When not naming the solution, it would have been solution-agnostic.
• Create Sales Order SAP SD (P01/2): These service descriptions are solution-specific and additionally reflect instances deployed or implemented in the enterprise. If you want to capture different KPIs for these instance-level services, e.g. business value or performance, you can use this low level of abstraction.
• Enterprise Resource Planning: We can use application functions to describe a type or bundle of functionalities at a very high level of abstraction. It might serve to create an application framework according to which you can organize your application solutions or design your application architecture in a solution-agnostic way. Of course, you can add something like a “Financial Planning Function” to describe more details (lower level of granularity).

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.

Additional notes

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.

Key Takeaways on Abstraction in Enterprise Architecture

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.