ArchiMate® Standard and Other Modeling Notations – A Conversation with Marc Lankhorst

By The Open Group

This blog, the second in a series with Marc Lankhorst, Managing Consultant for BiZZdesign, looks at how standards can be used together to help organizations better facilitate the transformations and changes they need to make.

One of the key issues while delivering Enterprise Architecture (EA) is to address the concerns of different kind of stakeholders. How do you position the ArchiMate® standard, a standard of The Open Group, in relation to this? Do you consider that ArchiMate modeling language should be applied to address all stakeholders concerns?

One notation cannot work for all audiences. ArchiMate notation provides detailed diagrams for experts, but for business users you need different views. The language therefore separates visualization from the underlying models, so you can construct views for different stakeholders.

“One notation to rule them all” is not feasible; different views can generated based on the same model, so sections of the model can be shared and presented using different conventions and notations. The value is in the underlying model, which can be presented with different visualization techniques. These can be graphical diagrams, of course, but also a list of things (a catalogue), a matrix, or a sketch, animation or infographic. On top of these visualizations, you can add color views, heat maps, etc. to address the concerns of different stakeholders via analyses like capability based planning, risk assessments, impact of change, cost analysis, prioritization of change initiatives, and many more.

Could you provide more details on relation on how the ArchiMate modeling language could be related with implementation oriented modeling notations like UML or BPMN? How traceability and integration can be addressed?  And how a full implementation can be achieved considering that usually practitioners have different kinds of tool suites?

The ArchiMate modeling language has been designed with the idea to bridge with other modeling notations like UML or BPMN. For that reason, several concepts in the language have been ‘borrowed’ from other languages, creating a bit of overlap where these languages meet. For example, the ArchiMate application component concept corresponds with UML’s component, so you can easily move from the architecture level to more detailed design. More examples on this are given in my blog post: A similar approach can be made for BPMN when designing detailed business processes (see more on that) or for entity-relationship diagrams for modelers who create detailed data models.

Sometimes this works bottom-up as well. If there is no architecture description available, you have to reverse-engineer different models and integrate them at a higher level to create your enterprise architecture. You can also harvest information on your infrastructure from your CMDB and integrate that at a higher level.

Business architecture is another discipline that can use ArchiMate. That typically starts with the strategy and motivation and the business model of the organization, perhaps expressed in a technique like the Business Model Canvas (BMC). From there you identify capabilities, value streams and the resources you need to realize them (e.g. people, information, systems, physical and other assets). That is then a starting point for the core of your enterprise architecture in terms of processes, applications, infrastructure and the like, which in turn relates to detailed designs as described before. So there are different ways to do this integration.

The ArchiMate modeling language has been designed to provide a high level set of architecture descriptions addressing different layers and aspects. One of those aspects is motivation and strategy, do you consider that the language on its own can be used to address concerns for this specific audience or that it is better to integrate it with other notations like BMM?

Some of the ArchiMate Motivation concepts have been borrowed from the Business Motivation Model, in the same way as for UML or BPMN, so that is an easy bridge. You can also map from ArchiMate models to strategy level models like the Balanced Scorecard and Business Model Canvas. For example, BMC Key Activities are close to ArchiMate Capabilities, Key Resources map to ArchiMate Resources, and other concepts map quite easily as well. For more on these mappings, see my blog post:

Data can be added to support metrics and KPIs. That is done using the ArchiMate Profile mechanism as described in the standard, where a profile is a coherent set of attributes for some specific purpose.

This is a very powerful way to connect the business and strategic views with operations and technical platforms and make decisions like prioritization on investments in technology without losing the strategic intent.

One of the challenges while implementing EA is to connect EA frameworks such as the TOGAF® standard, a standard of The Open Group, with other management practices like project management, project and program portfolio assessments, risk assessments, etc. Do you have experience on how ArchiMate Implementation and Migration layer could be used along with practices like project management to deliver the architectures and implement them?

The core concept here is the Plateau concept – intermediate architecture and transition architectures that allow you to do the planning and consider different options and scenarios for the planning. Then this should be connected with long-term roadmaps held by Project and Program portfolio management.

Various views can be delivered depicting these roadmaps, and the architecture behind them can be used to analyze dependencies, for example to see what the effect might be of postponing a project. In the architecture model, you can trace who needs the results of that project, and perhaps you detect that some application cannot go live since it needs this project result. That kind of information is often not available in your typical program and project management environments and adds a lot of value.

In Agile approaches, the concept of an architectural runway is another relevant topic that can be supported with this approach. This helps coordinate across multiple agile teams, providing them with the architecture context for their work so they can deliver faster, while keeping track of the high-level systemic view.

At a technical level, you can integrate your architecture tools with project management environments like Jira.  User stories, features, epics and other agile concepts can easily be mapped to corresponding ArchiMate concepts, as I described in my blog post on that. As I mentioned before, you can use this integration for example to assess what would happen to the overall result if a team decides to postpone some feature to the next sprint.

Additional information such as project costs, risks and benefits can be linked to your model using the profile mechanism described before, and you can use that for all kinds of cross-cutting analyses.

The current business and technology trends demands a lot of integration and awareness for the customer journey identification and how to improve it and provide a real digital customer experience. How can the ArchiMate standard be applied to fulfill this need?

Customer Journey maps can also be expressed in ArchiMate concepts, as you can see here: As an alternative visualization of an ArchiMate model for use in for example a marketing context, this works out quite well in my experience.

Within the ArchiMate Forum, we are also addressing the need for new concepts such as Value Stream ( This is also useful for people in Marketing and operations.

When talking about digital, we should also mention cloud. From the outset, the ArchiMate language has been service-oriented and this notion of service, which abstracts from the inner workings, is also ideal to express cloud solutions.

Data management and governance and also data privacy considerations are key concerns that need to be addressed. How can the ArchiMate standard be applied in this approach? Can this approach be used also to represent data security and risks considerations?

Detailed data models are better and easier represented using a more detailed notation like UML, but for a higher-level view or data governance issues like GDPR, you can analyze which data is used where, who it is shared with, and how it is secured. Modeling data flows and information interchange, and adding privacy and security attributes to your data with the profile mechanism mentioned before, provides you with a good basis for analysis. You can then show how data is used and stored, and whether this is in accordance with applicable security and privacy requirements.

SUMMARY: The ArchiMate modeling language has been designed to be used with other standards and notations. It is not a stand-alone language. A key consideration in its design is how to integrate with other notations and practices based on specific needs. Important also to have in mind the separation of the model from its visualizations for different stakeholders.

The first blog in this series can be found here.

Find out more about Marc on LinkedIn here.    @theopengroup


  1. After struggling with ArchiMate I still believe that the best tools are a clean a3 paper sheet and clean whiteboard. It allow me to bring stakeholders to the journey when we can walk step by step draw and wipe out fragments of diagram rather than dump on them a set of diagrams and spent days explain notations and a big io front Architecture. It is imho agile vs waterfall. Mind maps btw are more effective

Comments are closed.