Categories
erwin Expert Blog Enterprise Architecture

Using Enterprise Architecture Models, Views & Diagrams

Models and views are fundamental to managing and communicating enterprise architecture (EA).

Enterprise Architecture Models

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.

Having a consistent underlying model allows an organization to have an authentic representation of its information – an advantage not afforded by the ad-hoc, spreadsheet and presentation tool approach to enterprise architecture (a.k.a, the “Office Tools approach”).

Enterprise architecture models represent the structure of an organization and how the technologies and other assets that power the organization are interconnected. An enterprise architecture model is the foundational representation of this information. The blueprint.

Therefore, an understanding of enterprise architecture views and diagrams has to start here. That is because views and diagrams are ultimately just different ways of communicating the information in a model.

By filtering the information present in the model, views and diagrams can help involve less technical stakeholders and provide the organization more generally with a new perspective, more comprehensive insight and greater opportunities for process and technological improvements.

Enterprise Architecture Views

A view is a work product that can be used to communicate, analyze and manage EA models. 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.

Using different views allows an organization to represent a model from different perspectives – or viewpoints. These alternative viewpoints on a model allows organizations to focus on specific concerns regarding the model. They can also suppress irrelevant information and detail to provide a simplified, more easily digestible 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.

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 a 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 is as they use the same design standards.

Enterprise architecture review