Implementation and Migration Layer
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.
Implementation and Migration Metamodel gives an overview of the implementation and migration elements and their relationships.
|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 Derivation of Relationships. The realization relationship from Work Package to Deliverable (marked with an asterisk in the figure) is deprecated and may be removed in a future version of the standard. It is recommended to use an access relationship instead.|
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 typically not a continuously ongoing activity, but has a start and an end. These may be modeled as attributes. It produces a well-defined set of results, typically modeled as goals, outcomes, or deliverables. The work package element can be used to model sub-projects or tasks within a project, complete projects, programs, or project portfolios. In an Agile context, a work package can be used to model the work performed in an Agile iteration (e.g., sprint) or higher level increment.
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.
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 .
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 a 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”.
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, Baseline and Target Architecture descriptions 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 and expressing the step-by-step approach to migration.
In order to support this, the plateau element is defined.
A gap represents a statement of difference between two plateaus.
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 , 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.
Implementation and Migration Elements gives an overview of the implementation and migration elements, with their definitions.
Represents a series of actions identified and designed to achieve specific results within specified time and resource constraints.
Represents a precisely defined result of a work package.
Represents a state change related to implementation or migration.
Represents a relatively stable state of the architecture that exists during a limited period of time.
Represents a statement of difference between two plateaus.
Relationships of Implementation and Migration Elements with Core Elements shows how the implementation and migration elements can be related to the ArchiMate core elements.
A business internal active structure element may be assigned to a work package. This is used to model, for instance, a Project Manager business role that is responsible for the 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 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.
Relationships of Implementation and Migration Elements with Motivation Elements summarizes the relationships between implementation and migration elements and motivation elements. Goals, outcomes, and requirements can be aggregated or composed in plateaus. Requirements can be realized by deliverables. Since outcomes and goals can be realized by requirements, they can of course be realized indirectly by deliverables as well.