11                  Implementation and Migration Extension

11.1             Implementation and Migration Extension Metamodel

Figure 74 shows the metamodel of implementation and migration concepts.

Figure 74: Implementation and Migration Extension Metamodel

Conceptually, a work package is similar to a business process, in that it consists of a set of causally related tasks, aimed at producing a well-defined result. However, a work package is a unique, “one-off” process. Still, a work package can be described in a way very similar to the description of a process.

11.2             Implementation and Migration Concepts

11.2.1           Work Package

The central behavioral concept is a work package. A work package has a clearly defined beginning and end date, and a well-defined set of goals or results. The work package concept can be used to model projects, but also, e.g., sub-projects or tasks within a project, programs, or project portfolios.

Figure 75: Work Package Notation

Example

Example 58: Work Package

11.2.2           Deliverable

Work packages produce deliverables. These may be results of any kind; e.g., reports, papers, services, software, physical products, etc., or intangible results such as organizational change. A deliverable may also be the implementation of (a part of) an architecture.

Figure 76: Deliverable Notation

Example

Example 59: Deliverable

11.2.3           Plateau

An important premise in TOGAF is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the ADM, a Baseline Architecture and Target Architecture are created, describing the current situation and the desired future situation. In Phase E (Opportunities and Solutions), so-called Transition Architectures are defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage.

In order to support this, we introduce the plateau concept.

Figure 77: Plateau Notation

Example

Example 60: Plateau

11.2.4           Gap

A gap is an important outcome of a gap analysis in Phases B, C, and D of the TOGAF ADM, and forms an important input for the subsequent implementation and migration planning. The gap concept is linked to two plateaus (e.g., Baseline and Target Architecture, or two subsequent Transition Architectures), and represents the differences between these plateaus.

Figure 78: Gap Notation

Example

Example 61: Gap

11.2.5           Summary of Implementation and Migration Concepts

Table 34 gives an overview of the implementation and migration concepts, with their definitions.

Table 34: Implementation and Migration Concepts

11.3             Relationships

The Implementation and Migration extension re-uses the standard ArchiMate relationships.

11.4             Cross-Aspect Dependencies

Figure 79 shows how the implementation and migration concepts can be related to the ArchiMate core concepts.

Figure 79: Relationships between Implementation & Migration Extension and the ArchiMate Core Concepts

A business role may be assigned to a work package.

A plateau is linked to an architecture that is valid for a certain time span. To indicate which parts of the architecture belong to a certain plateau, a plateau may aggregate any of the concepts of the ArchiMate core.

A gap is associated with the core concepts that are unique to one of the plateaus linked by the gap; i.e., the core concepts that make up the difference between these plateaus.

A deliverable may realize, among others, the implementation of an architecture or a part of an architecture. Therefore, any of the concepts of the ArchiMate core may be linked to a deliverable by means of a realization relationship.

Like most of the core concepts, a location may be assigned to a work package or deliverable.

Weaker relationships may also be defined. For example, the association relationship may be used to show that parts of the architecture are affected in some way by certain work packages.

Strictly speaking, the relationships between the implementation and migration concepts and the motivation concepts are indirect relationships; e.g., a deliverable realizes a requirement or goal through the realization of an ArchiMate core element (e.g., an application component, business process, or service). However, it is still useful to make these relationships explicit, to show directly that a deliverable is needed to realize certain requirements and goals.

Also, goals and requirements can be associated with a certain plateau; e.g., certain requirements may only be applicable to the Target Architecture, while others may apply to a certain Transition Architecture. This can be modeled by means of the aggregation relationship.

Figure 80 summarizes the relationships between the concepts of the Implementation and Migration extension and the concepts of the Motivation extension.

Figure 80: Relationships between Plateau, Deliverable, and Motivation Concepts

11.5             Viewpoints

The following standard viewpoints for modeling implementation and migration aspects are distinguished:

•           The project viewpoint is primarily used to model the management of architecture change.

•           The migration viewpoint is used to model the transition from an existing architecture to a target architecture.

•           The implementation and migration viewpoint is used to model the relationships between the programs and projects and the parts of the architecture that they implement.

All viewpoints are described separately below. For each viewpoint the comprised concepts and relationships, the guidelines for the viewpoint use, and the goal and target group and of the viewpoint are indicated. Furthermore, each viewpoint description contains example models. For more details on the goal and use of viewpoints, refer to [2], Chapter 8.

11.5.1           Project Viewpoint

A project viewpoint is primarily used to model the management of architecture change. The “architecture” of the migration process from an old situation (current state enterprise architecture) to a new desired situation (target state enterprise architecture) has significant consequences on the medium and long-term growth strategy and the subsequent decision-making process. Some of the issues that should be taken into account by the models designed in this viewpoint are:

•           Developing fully-fledged organization-wide enterprise architecture is a task that may require several years.

•           All systems and services must remain operational regardless all the presumable modifications and changes of the enterprise architecture during the change process.

•           The change process may have to deal with immature technology standards (e.g., messaging, security, data, etc.).

•           The change has serious consequences for the personnel, the culture, the way of working, and the organization.

Furthermore, there are several other governance aspects that might constrain the transformation process, such as internal and external co-operation, project portfolio management, project management (deliverables, goals, etc.), plateau planning, financial and legal aspects, etc.

Table 35: Description of the Project Viewpoint

Concepts and Relationships

Example

11.5.2           Migration Viewpoint

The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture. Since the plateau and gap concepts have been quite extensively presented in Section 11.2, here the migration viewpoint is only briefly described and positioned by means of the table below.

Table 36: Description of the Migration Viewpoint

Concepts and Relationships

Example

11.5.3           Implementation and Migration Viewpoint

The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected. In addition, the way the elements are affected may be indicated by annotating the relationships.

Furthermore, this viewpoint can be used in combination with the programs and projects viewpoint to support portfolio management:

•           The programs and projects viewpoint is suited to relate business goals to programs and projects. For example, this makes it possible to analyze at a high level whether all business goals are covered sufficiently by the current portfolio(s).

•           The implementation and migration viewpoint is suited to relate business goals (and requirements) via programs and projects to (parts of) the architecture. For example, this makes it possible to analyze potential overlap between project activities or to analyze the consistency between project dependencies and dependencies among plateaus or architecture elements.

Table 37: Description of the Architecture Implementation and Migration Viewpoint

Concepts and Relationships

Example