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.
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.
A work package is defined as a series of actions designed to accomplish a unique goal within a specified time.
Figure 75: Work Package Notation
Example
The model below illustrates a model of a work package that models a program to rationalize the application portfolio. This program consists of two projects that are executed sequentially, each of them also modeled as a work package. First, a project is carried out to integrate the back-office systems (except for the CRM systems) into a single back-office system. Next, a project is carried out to integrate the CRM systems.
Example 58: Work Package
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.
A deliverable is defined as a precisely-defined outcome of a work package.
Figure 76: Deliverable Notation
Example
In PRINCE2, the deliverables (products) of a project are leading. The overall result of a project is described in a “project product description”; the hierarchical decomposition of this product in sub-products is shown in a Product Breakdown Structure, an example of which is shown in the model below.
Example 59: Deliverable
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.
A plateau is defined as a relatively stable state of the architecture that exists during a limited period of time.
Figure 77: Plateau Notation
Example
The model below illustrates the use of the plateau concept to model the migration from Baseline to Target Architecture, defining a number of intermediate (possibly alternative) Transition Architectures.
Example 60: Plateau
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.
A gap is defined as an outcome of a gap analysis between two plateaus.
Figure 78: Gap Notation
Example
The model below illustrates the gap between the Baseline and Target infrastructure, showing which of the elements of the infrastructure are added to or removed from the Baseline.
Example 61: Gap
Table 34 gives an overview of the implementation and migration concepts, with their definitions.
Table 34: Implementation and Migration Concepts
|
Concept |
Definition |
Notation |
|
Work Package |
A series of actions designed to accomplish a unique goal within a specified time. |
|
|
Deliverable |
A precisely-defined outcome of a work package. |
|
|
Plateau |
A relatively stable state of the architecture that exists during a limited period of time. |
|
|
Gap |
An outcome of a gap analysis between two plateaus. |
|
The Implementation and Migration extension re-uses the standard ArchiMate relationships.
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
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.
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
|
Project Viewpoint |
||
|
Stakeholders |
(operational) managers, enterprise and ICT architects, employees, shareholders |
|
|
Concerns |
Architecture vision and policies, motivation |
|
|
Purpose |
Deciding, informing |
|
|
Abstraction Level |
Overview |
|
|
Layers/Extensions |
Implementation and Migration extension |
|
|
Aspects |
Passive structure, behavior, active structure |
|
Concepts and Relationships
Example
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
|
Migration Viewpoint |
||
|
Stakeholders |
Enterprise architects, process architects, application architects, infrastructure architects and domain architects, employees, shareholders |
|
|
Concerns |
History of models |
|
|
Purpose |
Designing, deciding, informing |
|
|
Abstraction Level |
Overview |
|
|
Layers/Extensions |
Implementation and Migration extension |
|
|
Aspects |
Not applicable. |
|
Example
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
|
Architecture Implementation and Migration Viewpoint |
||
|
Stakeholders |
(operational) managers, enterprise and ICT architects, employees, shareholders |
|
|
Concerns |
Architecture vision and policies, motivation |
|
|
Purpose |
Deciding, informing |
|
|
Abstraction Level |
Overview |
|
|
Layers/Extensions |
Business layer, application layer, technology layer, implementation & migration extension |
|
|
Aspects |
Passive structure, behavior, active structure |
|
Concepts and Relationships
Example
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C13L.
