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.
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.
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.