Introduction by Iver Band
Enterprise Architect, Cambia Health Solutions
Chair, The Open Group ArchiMate® Forum
Welcome to the second in a series of blog posts on The Present and Future of the ArchiMate® Language. With the release of the ArchiMate 3.0 Specification last year, we now have a complete enterprise description language that has been adopted by architects worldwide in a wide range of organizations. It is now time for The Open Group ArchiMate Forum to reach out to users and better understand how the language is being used and how it should evolve. Therefore, the following post, like all others in this series, reflects the views of its authors, and will benefit from comments and discussion. You may refine, expand upon, or even disagree with elements of the post. Regardless, you will be shaping the future of the ArchiMate language.
So please, enjoy and engage!
Maintaining and Enhancing the Usability of the ArchiMate Language
By Mieke Mahakena, Martin Brommer, and Marcel Becker, Capgemini Netherlands
In January of this year, ArchiMate Forum members discussed via email the future of the language. With that thread as a starting point, we developed the following recommendations for the ease of use and understanding.
ArchiMate usage: stick to architecture
The ArchiMate language has been extended from Version 1.0 to Version 3.0. Some of those extensions deviate away from architecture, for instance towards project management and strategy development.
Different opinions were put forward in the Forum discussions about future expansion of the language. Some would like to see the ArchiMate language extended for use by strategists and business executives, as well as operational, project, and program managers. Others say it should be kept simple and usable instead of expanding to serve functions ranging from business development to operational management. Instead, it should interface well with other modeling languages better suited for these purposes.
In our opinion, the ArchiMate language should address only what is necessary to model architecture and leave the other areas to appropriate modeling languages, such as BPMN™ for business process models and UML® for software models. Each profession has its own optimal terminology, languages, and tools. The ArchiMate language should not challenge languages designed for disciplines beyond architecture. It is better to ensure traceability between different model types to maintain consistency. If there is a desire for a modeling language for other areas, do not just add them to the ArchiMate language but make a related new language.
Form a community for creating and sharing models
Many reference architectures are available supporting the development of organization-specific architectures. It would be a huge advantage if those reference architectures would be available as ArchiMate models that can be imported into ArchiMate certified tools. This would not only speed up architecture development, but would also improve standardization and integration of building blocks and models. We challenge the architecture community to create and share their architecture models; ArchiMate users should take up this challenge using the ArchiMate Model Exchange File Format.
Distinguish between logical and physical architecture
In architectural design, we differentiate between logical components and physical components. Structuring the architecture in logical components first will normally lead to more optimal and future-proof solutions. Designing physical components directly can lead to more technology-bound components and yield solutions that are more difficult to adapt. Within the TOGAF® framework, an Open Group standard, this distinction between components is supported by Architecture Building Blocks versus Solution Building Blocks. A standard approach within the ArchiMate Specification for modeling and relating these logical components with corresponding physical components will increase the degree to which solutions can adapt to future needs.
Enable functional filtering
Views in the ArchiMate language limit the elements used to what is relevant for a particular role. But organizations have multiple variations of each defined role: the individual readers. The standard views in the language do not enable you to limit to the interest of an individual reader. There should be the possibility, supported by tools, to filter the objects based on the interest of the role instance; i.e., through keywords. If, for example, a specification contains the elements of multiple functions, it should be possible to select only the function of interest and all touched objects based on a filter. This could improve stakeholder readability, especially among stakeholders with specialized interests. It would also ease the evaluation of dependencies; i.e., what functions will be impacted if an element is changed.
Align the TOGAF and ArchiMate content metamodels
The TOGAF and ArchiMate standards use different terminology in their content metamodels. These two important standards should be fully consistent and share common terminology. Some concepts included in the TOGAF metamodel are not included in the ArchiMate metamodel yet, although they can be considered within the scope of the architecture language. Examples of such concepts are Assumption and Logical Application Component. Adding such concepts to the ArchiMate Specification would improve the alignment between the two content metamodels.
Final Words
Contributing to the ArchiMate community and sharing your experience and best practices will help the ArchiMate language evolve. If we all participate, the ArchiMate language can be widely adopted and have a beautiful future.
Authors
Marcel Becker is Certified Architect at Capgemini Netherlands Financial Services GBU. He fulfills the role of architect especially at financial institutions in a variety of areas. Marcel is TOGAF®Certified, ArchiMate® Certified and facilitates TOGAF and ArchiMate courses for Capgemini Academy.
Martin Brommer is Architect at Capgemini Netherlands Cloud Infrastructure Services CE. Martin has a broad experience in different roles in Telecom, Rail, and Utilities. As an architect, Martin has worked mainly at Energy companies. Martin is TOGAF®Certified and ArchiMate® Certified.
Mieke Mahakena is a certified senior architect at Capgemini Netherlands Application Services. She is an experienced architect in the Dutch public sector who applies the ArchiMate language frequently in her daily work. Mieke is TOGAF® 9 Certified and ArchiMate® 2 Certified. She facilitates TOGAF and ArchiMate courses for Capgemini Academy.
Content of this blog are views of the authors and not attributed directly to The Open Group. Thank you to our contributors!
ArchiMate® is an Open Group standard.
TOGAF® is an Open Group standard.
@theopengroup
Thanks for a thorough and thoughtful post with many good points!
Regarding “ArchiMate usage: stick to architecture”, I agree that ArchiMate is, and should remain, a language for enterprise and solution architecture covering business, data, application, technology and security architecture. On the other hand, in order for architects to succeed, they must build shared understanding across the many disciplines involved in enterprise assessment and transformation. Often an organization’s motivations, strategy and business processes, for example, are not documented with sufficient precision to plan business transformation. Architects can use the motivation aspect of the language, as well as the strategy and business layers, to clarify these subjects, and then use the entire language to develop, relate, and plan implementation of the baseline, transition, and target architectures that meet the organization’s need. If application technology components need to be developed or modified, they can be modeled using ArchiMate, and those components can be precisely linked to UML diagrams that define them in detail. Physical components such as factories and equipment can also be modeled and linked to design models. The same can be said of logical and physical databases, which can be modeled, respectively, with data objects and artifacts, and linked to Entity-Relationship diagrams to show their structure. A number of commercial tools support the linking of objects across languages.
Therefore, I think it is important that the ArchiMate language continue to support all of the concepts required to support enterprise transformation.
Regarding distinguishing between conceptual, logical, and physical models, the ArchiMate language supports that. The motivation aspect, as well as the strategy, business, and implementation and migration layers, are conceptual, since they represent concepts in the language of the business. These three parts of the language are designed to communicate in ways that may or may not be formally verifiable. The application layer is logical, since it represents formally verifiable structures, behaviors and relationships. The technology layer is a mix of logical concepts, such as nodes and technology services, but also contains clearly physical components such as devices and artifacts. The physical layer, is, well, physical. To make the distinction more explicit, modelers can use stereotypes as well as specialized or annotated versions of standard ArchiMate symbols.
I agree that this would be clearer and more modeler-friendly if we could fully align the TOGAF and ArchiMate content metamodels.
It is great to this discussion about the evolution of Archimate!
I think the authors bring good points but wanted to refine/augment the opinions expressed.
1. Regarding the language focus — I agree that Archimate should focus on Enterprise Architecture and defer to other languages like BPMN and UML when appropriate. That said, I think the new Motivation aspect is very powerful. Our team has adopted the motivation aspect to help model stakeholders and there concerns. When developing target enterprise and solution architectures we have found that a clear understanding of drivers, goals, assessment and value leads to better solutions.
That said, the motivation aspect, strategy layer and the business layer could be simplified and clarified. How are capabilities, requirements and business services/functions are related? Which ones can realize goals and drivers in the motivation layer? How does course of action link to goals and drivers and requirements?
2. I agree with the blog authors that logical and physical is not so clear in the language. While Iver states that Business and Application are logical while Technology is logical/physical, I don’t think that is completely true. Togaf distinguishes between logical and physical application components and so should Archimate. I can talk about a logical applicaton component called “Billing System” and then I can talk about a physical component called “Oracle Financials.”
3. Align the meta-models! To be precise, adopt the more modern Archimate model in Togal but augment Archimate’s model with some of the good things in the Togaf model!