The implementation and migration elements support the implementation and migration of architectures. This includes modeling implementation programs and projects to support program, portfolio, and project management. It also includes support for migration planning.
Figure 106 gives an overview of the implementation and migration elements and their relationships.
Figure 106: Implementation and Migration Metamodel
Note: This figure does not show all permitted relationships; every element in the language can have composition, aggregation, and specialization relationships with elements of the same type. Furthermore, there are indirect relationships that can be derived, as explained in Section 5.7.
A work package represents a series of actions identified and designed to achieve specific results within specified time and resource constraints.
The central behavioral element is a work package. A work package is a behavior element that has a clearly defined start and end date, and realizes a well-defined set of goals or deliverables. The work package element can be used to model sub-projects or tasks within a project, complete projects, programs, or project portfolios.
Figure 107: Work Package Notation
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.
A deliverable represents a precisely-defined result of a 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.
Figure 108: Deliverable Notation
Often, deliverables are contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders as is, for example, prescribed by the TOGAF framework [4].
An implementation event represents a state change related to implementation or migration.
Work packages may be triggered or interrupted by an implementation event. Also, work packages may raise events that trigger other behavior. Unlike a work package, an event is instantaneous: it does not have duration.
An implementation event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model project schedules and milestones; e.g., an event that triggers a work package, an event that denotes its completion (with a triggering relationship from the work package to the event), or an event that denotes a lifecycle change of a deliverable (via an access relationship to that deliverable).
Implementation events access deliverables to fulfill project objectives. For example, in a project to deliver a completely new application along with the technology needed to host it, an implementation event “release to production” could access the deliverables “final build”, “staging environment”, and “production environment”.
An implementation event may trigger or be triggered (raised) by a work package or a plateau. An implementation event may access a deliverable and may be composed of other implementation events.
An implementation event may be associated with any core element; e.g., to indicate a lifecycle state change. The name of an implementation event should preferably be a verb in the perfect tense; e.g., “project initiation phase completed”.
Figure 109: Implementation Event Notation
A plateau represents a relatively stable state of the architecture that exists during a limited period of time.
An important premise in the TOGAF framework 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, the plateau element is defined.
Figure 110: Plateau Notation
The gap element is associated with two plateaus (e.g., Baseline and Target Architectures, or two consecutive Transition Architectures) and represents the differences between these plateaus.
In the TOGAF framework [4], a gap is an important outcome of a gap analysis in Phases B, C, and D of the ADM process, and forms an important input for the subsequent implementation and migration planning.
Figure 111: Gap Notation
The “Next Generation Services Program” work package is composed of three other work packages. An implementation event “Program Approved” triggers the first work package, “Architecture And Planning”, which triggers the work package “Application Services Layer Development”, which triggers the work package “Business Services Development”, which triggers the implementation event “Program Completed”. The “Program Approved” implementation event also provides a deliverable “Program Brief”, as input for the first work package. Work package “Architecture And Planning” realizes three deliverables: “Business Plan”, “Architecture”, and “Roadmap” (which is accessed by the “Application Services Layer Development” work package), which collectively realize the plateau “Strategic Plan Complete”. This plateau follows the initial plateau “Baseline”, filling the gap “Knowledge Of How To Address Customer Needs”. Similarly, the other work packages realize other deliverables that realize the subsequent plateaus.
Example 35: Implementation and Migration Elements
Table 10 gives an overview of the implementation and migration elements, with their definitions.
Table 10: Implementation and Migration Elements
|
Element |
Definition |
Notation |
|
Work package |
Represents a series of actions identified and designed to achieve specific results within specified time and resource constraints. |
|
|
Deliverable |
Represents a precisely-defined result of a work package. |
|
|
Implementation event |
Represents a state change related to implementation or migration. |
|
|
Plateau |
Represents a relatively stable state of the architecture that exists during a limited period of time. |
|
|
Gap |
Represents a statement of difference between two plateaus. |
|
The implementation and migration elements use the standard ArchiMate relationships.
Figure 112 shows how the implementation and migration elements can be related to the ArchiMate core elements.
Figure 112: Relationships of Implementation and Migration Elements with Core Elements
A business internal active structure element 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 or compose any of the concepts of the ArchiMate core language. Realization from a plateau to part of the architecture is also permitted. For example, a capability may be realized by a plateau, signifying that a certain capability increment is valid only during the time span of that plateau.
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 language may be linked to a deliverable by means of a realization relationship.
Like most of the core language concepts, a composite element may aggregate 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 elements and the motivation elements 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, motivation elements can be related to a certain plateau; e.g., certain requirements may only be applicable to the Target Architecture, while others may apply to a certain Transition Architecture. Similarly, plateaus can be used for capability-based planning. This can be modeled by means of the aggregation or composition relationships.
Figure 113 summarizes the relationships between implementation and migration elements and motivation elements. Goals, outcomes, capabilities, and requirements can be aggregated or composed in plateaus. Requirements and capabilities can be realized by deliverables. Since outcomes and goals are realized by capabilities and requirements, they can of course be realized indirectly by deliverables as well.
Figure 113: Relationships of Implementation and Migration Elements with Motivation Elements
Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Library as document C197.
