An Overview of the Levels of Abstraction in Enterprise Architecture

An Overview of the Levels of Abstraction in Enterprise Architecture

Organizations today are faced with an ever-increasing speed of change. To enable faster transformation, they implement agile methods, which impact the whole enterprise. Obviously, change need to be communicated, but one cannot document all the details because otherwise they would be outdated the next week, or perhaps the very next day. Enterprise architecture (EA) is a discipline to describe the structure of an enterprise at different layers such as strategy, business, information, application and technology. ArchiMate is the world-wide standard to describe and analyze your enterprise visually in a holistic manner. It covers all the layers mentioned above, as well as at different levels of granularity (level of details, additional attributes) and /or abstraction. The last point is often challenging to define, but has broad implications for the analysis you can do and to the maintenance effort required in keeping the information updated. This blog presents an overview of these different levels of abstraction in enterprise architecture and gives indications what can be done at each level of abstraction. The explanation is given by using examples.

Introducing the Overview

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.

Summary and Recommendations

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 have labeled the levels on the right 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 while there might also be different variants of processes or systems (not explicitly modelled as own elements). Modeling architecture at this level will only allow you to create an architecture repository for design purposes. You can create different architecture views based on reusing the same building blocks to describe on different views different options, variants or reference architectures. By reusing the same elements, you ensure consistent naming, 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, to name some common examples. 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 Enterprise Studio and HoriZZon.