Using Enterprise Architecture Models & Views

by Zak Cole       • September 29, 2015

Models and views are fundamental to managing and communicating enterprise architecture (EA). A model represents the data for an organization that describes the architectural concepts. It is based upon the underlying meta-model provided by an enterprise architecture framework.

Most frameworks include a default set of views. The ArchiMate® specification from the Open Group provides a set of views along with their underlying notation so that you can recognize a concept from its visualization.

A view is a work product that can be used to communicate, analyze and manage EA models. A view is a representation of a model from the perspective of a viewpoint. This viewpoint on a model focuses on specific concerns regarding the model that suppresses details to provide a simplified model.

For example, a financial portfolio viewpoint focuses on financial portfolio concerns and a financial portfolio viewpoint model contains those elements that are related to financial concerns from a more general model.

Views allow you to manage the abstraction of a model so that it is relevant to different stakeholders. A business stakeholder may have a high level goal oriented viewpoint and a software developer may have a detailed technical viewpoint of a model.

Enterprise Architecture Views

Views are represented in different ways according to stakeholder needs. In this article, we are focusing on diagrams, which are a common way for most enterprise architecture frameworks to represent views.

In later articles, we will cover other types of views such as pivot tables, charts, Kanban boards and roadmaps that are all different perspectives on the underlying model.

Metamodel and views
Figure 1: Multiple views for a single model

Figure 1 shows some sample views of a subset of the meta-model. Here we are showing application components and assignments to locations.

You can see that there are many different views of the architecture depending on stakeholders needs.

Enterprise Architecture Diagrams

Diagrams provide a view of the underlying repository concepts and their associations. The open Group ArchiMate® 2.1 specification contains a core set of views, an implementation and migration extension and motivation views.

These are the example views provided by the Open Group. However, ArchiMate® is not limited to just this collection of views. You may also create your own views (meta-diagrams) to suit your own purposes.

Enterprise Architecture Layered View
Figure 2: Example layered view

Figure 2 is an example ‘layered’ view from ArchiMate®. The layered view is useful as it contains nearly all of the meta-types and meta-associations in the ArchiMate® meta-model. You can see on this view that we are focusing in the center on the ‘Upgrade Claims Handling’ work package. We’re also showing the connected associations that this work package has to other concepts.

The other concepts include the driver (Customer satisfaction), goal (Revise claim handling process), application component (Call center application), deliverable (Upgraded website for claims handling), requirement (All claims shall be submitted online) business service (Faster claims handling) and role (Claim reviewer). Each of these associations are different and are represented in a different graphical manner.

The layered view is also useful for showing the layers between the different domains of the architecture.

ArchiMate layered view showing layers
Figure 3: ArchiMate layered view showing layers

In Figure 3, the layers are depicted with different colors. Yellow icons represent the business layer, blue icons for the application layer and green icons for the technology layer.

Representational Consistency

Many of these viewpoints can be created by hand or in drawing tool, however, a major benefit of having a model and ideally a repository-based tool is that your views are consistent. That is, they are represented directly based upon the associations in the repository.

No matter what type of view, the information should always be representationally consistent with the model. However, for the sake of visibility, it is a good idea to sometimes hide associations and detail in views to match stakeholder needs.

Metamodel and views
Figure 4: ArchiMate viewpoints mapped to a model

In Figure 4, we can see that we have two very different viewpoints for the same underlying meta-model.

The ArchiMate® Stakeholder Viewpoint shows the drivers and assessments. You can see that some of the same concepts are represented in the ArchiMate® Motivation Viewpoint which is showing the overall motivational strategy for our business.

All associations that are shown exist in the repository. When a diagram is created, you should expect your tool to show the associations that exist between two concepts automatically.

Custom Views

Architecture frameworks such as ArchiMate® and ToGAF® provide a set of views. In the case of ArchiMate®, the views are example views and ones which a user of the framework may find useful.

Most of the enterprise architecture frameworks are designed to support custom views. That is, a set of views that helps a stakeholder comprehend the architecture.

Summary

Views provide a representational consistent view of the underlying model. Views can contain as much detail or as little detail necessary to communicate the model to the appropriate stakeholder.

Diagrams are the most popular form of views and ArchiMate® provides a standard notation for the communication of views. The benefit of this being that each stakeholder has the same understanding of any concept. This is much like any builder will be able to understand any set of building plans no matter who the author as they use the same design standards.


Back to erwin Expert Blog