Many architectures contain a diagram (often expressed in the Archimate language) of the current state and one or more diagrams of the future state(s). Stakeholders who study diagrams will discover how the architecture develops in time, as the titles of the diagrams look like “Current state year nnnn” or “Future state year nnnn+2”. So time is of importance, but not modelled explicitly. The question for this practice is: “What is a practical way to model time explicitly in Archimate” (by using a formal concept (a “first class citizen”) for the time periods).
Time is considered to be of importance for the Archimate-core, but also for the extensions. Therefore the following modelling-pattern contains concept from the core and from both extensions. As a result for instance analyses could be done automatically.
Note: Although a diagram is used to explain the pattern, diagrams are not the best way to model relations between workpackages, elements and periods. If your tooling supports tables to maintain those relations your modelling life gets a bit better.
- Figure 5 59: Modelling Pattern
For modelling enterprise-architectures periods of a year are often used. Depending on the purpose of the model a longer or shorter period (for instance a quarter) may be more fitted . The Plateau concept is used to model the periods, trigger relations express the sequence of the periods. It may be helpful to use periods that match periods applied in portfoliomanagement. You should use the same Periods in all models of which you want to compare results of analyses
Core-elements are associated with the periods in which they have been and/or will be operational. Workpackages are associated with the period(s) in which the work is executed. Note: Regrettably a Period/Timespan concept is not known in Archimate. The choice for the Plateau concept seems the best option for now, as Plateaus can be ordered by triggerrelations. Of course a Period is not a Plateau in the real sense, it is just a timespan, a part of a calendar. So Periods are a result of modelling, whereas Plateaus are a result of designing.
A Workpackage realizes one or more Deliverable(s). A deliverable is delivered in the associated Period. A Deliverable realizes exactly ONE Core-element and one or more Requirements. The Core-element is enriched with realized requirements in the Period in which the Deliverable is delivered. Note: When a Deliverable in reality realizes Requirements for several Core-elements, then the Deliverable needs to be split up for modelling purposes.
The pattern described allows all kinds of analyses and reports. Some examples are provided in the Example section of this document.
Usage of this good practice requires the usage of application-interfaces as a substitute or addition to flow relations.
Working on a model that will be used for formal analyses, solely based on the model-contents, asks for patterns all modellers agree on and a high level of discipline.
Relationships with other good practices
Viewpoints with Motivation concepts and Implementation & Migration concepts
Frequently given answers
- Yes, restricting the use of the Archimate language by using a pattern reduces the creativity in the way how you express yourself. On the other hand, all that creativity can now be used on what you want to express.
- Indeed, you may replace the time-modelling pattern with a realization relation from the core-element to the requirement, as soon as the deliverable has been delivered. Use of the time-modelling pattern is then restricted to not-yet-implemented requirements. Of course the model no longer knows in which period the requirement was implemented on the core-element.
- Figure 5 60: Direct Relation
- Of course you can still use the Plateau concept the way it is meant to. You then apply the (stronger) aggregation or realization relations to prevent interference with periods for which the pattern prescribes (weak) associations. You may even associate a Plateau with one or more Periods, indicating when the Plateau is operational:
- Figure 5 61: Modelling Pattern
- Figure 5 62: Modelling Time example
Requirements realized by Workpackage in which Period
- Figure 5 63: Realized workpackages example
Core element satisfies Requirement(s) starting in Period
- Figure 5 64: Core element satisfies Requirementexample
- Figure 5 65: Colored view
When you use colors (or labels) to indicate the periods involved, the periods can be omitted from the diagram, without losing information. Note : This diagram has been produced with the “BizzDesign Architect” tooling, but it can also be made “by hand” of course.