ArchiMate 3.0

by Phil Chudley, Principal Consultant at Dunstan Thomas Consulting

  The Open Group released the official specification of ArchiMate 3.0 in June 2016, and this new specification is supported in Enterprise Architect version 13. This article summarises the new features and changes within ArchiMate 3.0 and provides an example of how to migrate an existing ArchiMate 2.0 model to ArchiMate 3.0 model using Enterprise Architect v.13.

Summary of Changes

The following is a summary of the changes made within ArchiMate 3.0:

• Motivation Extension;
  • New element for modelling Outcomes.
  • New set of Strategy Elements, Resource, Capability, Course of Action.
• Business Layer;
  • Representation of the Contract element modified so as to be different from the Business Object Element.
  • Location element removed (although Enterprise Architect has re-located this element to the Technology Layer – Physical Extension).
• Application Layer;
  • Two new elements added, Application Process and Application Event
• Technology layer;
  • Elements called Infrastructure in ArchiMate 2.0 are now called Technology in ArchiMate 3.0.
  • Four new elements added, Technology Process, Technology Interaction, Technology Event and Technology Collaboration.
  • New set of Physical Elements, Equipment, Facility, Distribution Network and Material. These elements are known as the Physical Extension.
• Implementation and Migration Extension;
  • One new element added, Implementation Event.
• Relationships;
  • Representation of Assignment modified to have a directional arrow.
  • Bi-directional Access relationship added.
  • Plus (positive) and Minus (negative) symbols added to Influence Relationship.
  • New relationship, Serving.

Detail of Changes

The following tables provided an example of the changes for each of the sections listed in the Summary of Changes above.

Motivation Extension

Element	Definition	Notation
Outcome	An end result that has been achieved.
Resource	An asset owned or controlled by an individual or organisation.
Capability	An ability that an active structure element, such as an organisation, person, or system possesses.
Course of Action	An approach or plan for configuring some capabilities and resources of the enterprise, undertaken to achieve a goal.

Business Layer

Element	Definition	Notation
Contract	A formal or informal specification of an agreement between a provided and consumer that specifies the rights and obligations associated with a product.

Application Layer

Element	Definition	Notation
Application Process	A sequence of application behaviours that achieves a specific outcome.
Application Event	An application behaviour element that denotes a state change.

Technology Layer

Element	Definition	Notation
Technology Collaboration	An aggregate of two or more nodes that work together to perform collective technology behaviour.
Technology Process	A sequence of technology behaviours that achieves a specific outcome.
Technology Event	A technology behaviour element that denotes a state of change.
Technology Interaction	A unit of collective technology behaviour performed by (a collaboration of) two or more nodes.
Equipment	One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
Facility	A physical structure or environment.
Distribution Network	A physical network used to transport materials or energy.
Material	Tangible physical matter or physical elements.

Implementation & Migration Extension

Element	Definition	Notation
Implementation Event	A behaviour element that denotes a change of state related to an implementation or migration.

Relationships

Element	Definition	Notation
Assignment	Expresses the allocation of responsibility, performance of behaviour, or execution.
Serving	Models that an element provides its functionality to another element.
Access	Models the ability of behaviour and active structure elements to observe or act upon passive structure elements.
Influence	Models that an element affects the implementation or achievement of some motivation element.

Implications to existing ArchiMate models

If an organisation has modelled their Enterprise Architecture using Enterprise Architect and ArchiMate 2, and are now using Version 13 of Enterprise Architect, they have two courses of action:

1. Continue to model using ArchiMate 2.0. In this case no action is required either for Enterprise Architect or the model repository. An organisation would continue to model using ArchiMate 2.0 if they do not wish to make use of any of the new features in ArchiMate 3.0.
2. Migrate their existing ArchiMate 2.0 model to ArchiMate 3.0, and then continue to model using ArchiMate 3.0. An organisation would continue to model using ArchiMate 2.0 if they wish to make use of any of the new features in ArchiMate 3.0.

My own personal opinion is that an organisation should consider moving to Enterprise Architect version 13 (mainly due its new feature of “Time Aware Modelling”) and ArchiMate 3.0. One of the main reasons, is due to inherent ambiguity (due to the lack of direction indication) in the assigns relationship in ArchiMate 2.0, which has been eliminated in ArchiMate 3.0 by making the assigns relationship directional.

Migrating an ArchiMate 2.0 model to ArchiMate 3.0

Enterprise Architect version 13 provides a migration script for this purpose. The following steps are used to perform the migration:

1. Take a backup copy of the existing model repository.
2. Using the Configure | Manage Technology ribbon, ensure that both ArchiMate 2.0 and ArchiMate 3.0 MDG technologies are enabled.
3. Using the Code | Scripting ribbon, make the scripting window visible:
   
4. Select the topmost package (or view) that contains the model to migrate:
   
5. Select the script Migrate ArchiMate 2 to ArchiMate 3 in the scripting window.
6. Right-click and select Run Script from the menu.
7. The progress of the migration, together with any errors / warnings will be displayed in the system output window.
8. Review the diagrams (you may have to tidy some of the relationships).
9. Turn off the MDG ArchiMate 2.0 using the Configure | Manage Technology ribbon.

NOTE: It appears that composition relationships are NOT HIDDEN, when using nested structures in ArchiMate 3.0. I suspect this is an Enterprise Architect version 13 issue. This is likely to be fixed and should not deter migration, as these relationships can always be hidden using the Visible Relations function in Enterprise Architect. (Layout | Manage ribbon and select Show and Hide Relationships… from the menu).

Phil Chudley
Principal Consultant
Dunstan Thomas Consulting
@SparxEAGuru

You'll find lots of useful Enterprise Architect videos on our YouTube Channel.

Introduction

In the last year I have done a number of projects for a Dutch government agency as a data architect. This organisation has an architecture team with four members. There is a problem in producing architecture documents like Project Start Architectures, it takes too much time and the result has limited value for the projects.  This is mainly caused by the lack of overview on the baseline and the target architecture. There is no overview of the business processes, the application and the infrastructure.

For every project, an architect has to do a lot of research on the baseline architecture first, sometimes this activity takes weeks to get a architecture view that is input for working on the target architecture. Another problem is that every architect has his own tools and techniques for the architecture notations and documents. Although there is an architecture document template, there are large differences in the quality and presentation of these documents. However due to the differences in tools and techniques, every architect starts from scratch for every project.

To tackle these problems the team decided to synchronize their activities, techniques, notation and tools. Therefore the following questions where formulated:

·         Which notation is best to support our architecture documents and diagrams?

·         Based on the selected notation, which tool can help us to make our documents more efficiently?

·         What do we have to change in our team to encourage reuse of existing documents and diagrams?

Below I will describe how we looked for answers to these questions and what lessons we have learned.

ArchiMate

In the Netherlands, there are a lot of architecture methods available like Togaf, Zachman, Dragon1, Demo, DyA and ArchiMate.  Each method has its own characteristics. However which are important for our own organisation. The architecture team did an interactive workshop to formulate the following requirements for the architecture methodology:

·         It must be an open standard and is used in other government agencies for exchanging models.

·         Applicable for all aspects of an enterprise architecture, from business to infrastructure and data architecture.

·         It must be easy to use and easy to read for non IT professionals.

In this interactive workshop a number of extra requirements where formulated and most important we defined a multiplier define the importance for each requirement. The requirements were mapped on a number of architecture methodologies and ArchiMate was the methodology with the highest score.

ArchiMate is an open standard with a powerful notation for all the aspects of enterprise architecture. Since ArchiMate 2.0 there are even extensions for motivation like principles, requirements and stakeholders and project management for plateaus, gaps and work packages. In the figure below you see a sample ArchiMate 2.0 diagram.

Figure 1 Sample ArchiMate notation

After this methodology selection the next step was to evaluate it in a number of projects. For ArchiMate there are Visio Stencils and a number of open source tools. Every architect used the notation for a period of time and during this period we organized a number of sessions to discuss the results. We also organized an interactive session with our non IT stakeholders to evaluate the selected methodology.

In these evaluations we discovered that the ArchiMate notation is valuable for describing the architecture in our organisation. For the notation instruction material was made with example diagrams and describing when to use what ArchiMate viewpoints. However the notation is too rich for most of the situations. So the following categories were introduced:

·         Primary diagrams, should be present in every architecture document

·         Secondary diagrams, only available in complex documents for extra description

During the evaluations it became clear that the Visio stencils and open source tooling had insufficient functionality for the next phase, the implementation of the methodology.

Using Enterprise Architect

Like we did with the notation we formulated a number of requirements including a multiplier for each architect and compared a number of tools with each other. This was done with a simple spreadsheet. In the figure below a part of the spreadsheet

Figure 2: Requirement-Tool matrix

Based on the results of this matrix Enterprise Architect had the best score and we introduced the product. This introduction was done in a number of planned steps. There was a risk that the organisation returned to old habits of working in an unstructured way and introducing a architecture methodology combined with tooling has to be embedded in all the activities of the architects.

In the following sessions I will describe a number of important aspects for introducing Enterprise Architect with ArchiMate.

Repository setup

Already in an early phase of the tool introduction we discovered that the repository content can become messy when you do not think about structuring the elements. Although there is a good project browser search function structuring the project so you can browse for elements is a good aid for the users of the system.

The repository is divided in three sections:

·         Projects,  actual project documents in various stages of completion

·         Reference architecture, elements and diagrams from previous projects that are generic and probably reusable in future projects. This section is subcategorized in a structured manner comparable with the ArchiMate layers and columns

·         Archive, diagrams and elements from projects that are probably not reusable.

Figure 3: Repository setup

Document generation

Introducing an architecture methodology in combination with tooling asks a lot of effort from the involved professionals. It was therefore important to seek for a solution to reduce the production time of the architecture documents, this was the reason why we started this project in the first place.

Already in an early phase of the project document generation was investigated as part of the overall solution. Document generation proved to be a great help to achieve this goal. The standard document templates were changed to our own corporate layout and the layout of the elements was changed for a better readability. The repository setup was changed so it was possible to change ordering and exclude packages from the document generation.

Sharepoint Wiki

In the organisation Microsoft SharePoint is the application for team- and project collaboration. The architecture team used this already and has made a lot of information available in a SharePoint wiki. First approach was to transfer this information to Enterprise Architect. However making links to files and Wiki content from the Enterprise Architect packages and elements turned out to be a good solution. With the links from the screens and the generated documentation to the wiki content people can easily get access to background information.

Custodian

In the repository setup a distinct difference is made to project data and generic data of the reference architecture. Especially this reference architecture is an important aspect of introducing standardization and reusability. Therefore the reference architecture needs special governance. The team decided to introduce a custiodian role. This custodian is responsible for the reference architecture package in the repository. To keep this reference architecture up to date the custodian has the following activities:

·         Give information and instructions to team members about the setup of the reference architecture and how to use the elements and diagrams.

·         Give feedback on diagrams and notation made by team members in project documentation.

·         Select generic diagrams and elements from project documentation for transfer to the reference architecture.

This custodian role turned out to be a very good decision to help introduce the ArchiMate notation, the new methodology and the usage of the tooling in a right manner.  

Lessons Learned

In one year the organisation introduced a new architecture methodology, notation and tooling. Furthermore the production of architecture documents changed dramatically. Some aspects were successful, while others werenot. The most important lessons we learned are

·         Team involvement,  this is most important to make this a success. Every team member must see the advantages of the new methodology. Furthermore, everybody must be an ambassador and therefore should have sufficient influence on the final product.

·         Notation governance, especially in projects under time pressure, it is so tempting to make an simple diagram in Visio or PowerPoint for a few team members. The role of the custodian is in this important to keep everybody involved!

·         Communicate! A new architecture methodology, notation and tooling has a great impact, not only for the team members but for every stakeholder in the organisation. Take care of informing everybody about results, products and other notifications. We made a number of posters of architecture diagrams for important projects and that helped a lot (see figure 4)

·         ArchiMate 1 and 2, there are two versions of ArchiMate in notation and in Enterprise Architect. At first we decided that we used these notation together. This turned out to be a wrong decision. Not only was it confusing, the tooling has strange behaviour when using the versions simultaneous.

Figure 4 Project Poster

Conclusion

The introduction of ArchiMate in combination with tooling was not always easy. There are a lot of options and it was difficult to make the right choice, especially for the methodology. Introducing a new working proceedure was not simple for evberybody. The custodian role helped a lot here. Enterprise Architect in combination with ArchiMate 2.0 turned out to be a good choice. The tooling is easy to use, has sufficient search capabilities, can be adapted easily for document generation and connection with existing applications like SharePoint.