Introduction by Iver Band
Enterprise Architect, Cambia Health Solutions
Chair, The Open Group ArchiMate Forum
Welcome to the first 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!
How to be Understood as an Architect
By Mieke Mahakena, Martin Brommer, and Marcel Becker, Capgemini Netherlands
Architects have a reputation for making complex and unreadable diagrams, which are only understood by a couple of inside architects. Although some of those architects may still be around, most architects today ensure that their visualizations are easy to understand. The ArchiMate modeling language is one of the modeling languages that can support architects in creating straightforward and understandable diagrams. Use of the ArchiMate notation helps architects understand each other’s architectures.
What can we do to use the ArchiMate language more effectively?
Tips for effective use of the ArchiMate language
Tip 1: Consider your audience when talking
Speaking a language is about selecting the correct words and placing them in a preferred sequence in order to convey the right message. Using views based on specific viewpoints helps the architect to speak the correct architecture language by creating architecture diagrams that fit the intended stakeholders. Views provide the relevant story on an overall architecture with the desired level of detail. In practice an architect or architecture community within an organization will define and build up a set of reusable viewpoints for the organization. As we use views, we need to make sure the stakeholders understand the ArchiMate language specifics. A legend should be added to views to explain how symbols, connections, and colors should be read.
Tip 2: Only tell the story to meet your objectives
Most probably, you have experienced someone elaborating without getting to the point. Especially if you do not have the time, it can feel uncomfortable. Likewise, your ArchiMate models should only contain what is needed for the scope and objectives of your architecture. Adding more details will take more time and therefore more budget. Take this into account when defining the scope and views for your architecture.
Tip 3: Discuss architecture and not the language
We all have experienced many situations where discussions about the use of methods, languages, and tools could last for days (at minimum). As architecture is often on the critical path to reaching the results, those discussions are a waste of time. It will certainly be helpful to agree on some standards and guidelines on the use of the ArchiMate language. Nevertheless, the ArchiMate language, like architecture itself, is a means to an end: supporting the implementation of your strategy in business operations in a coherent way. So instead of talking about the ‘right’ application of the language, start talking about the architecture.
Tip 4: Use the ArchiMate language only for architecture
Architects use architecture models and views for designing new architectures, analyzing the impact of architecture decisions, facilitating decision-making, and for informing a variety of stakeholders. If ArchiMate models are used for other objectives, this can lead to undesirable extension and application of the underlying (meta-)models. For instance, if ArchiMate models are used for operations like periodic charging of maintenance costs of deployed systems, this can lead to undesired impact on an architecture (meta-)model. Be aware that other application of the models can interfere with the scope and objective of your architecture.
Tip 5: Seek alignment with other modeling languages
Besides the ArchiMate language, other modeling languages for IT projects can be used within the same organization as well. BPMN and UML are common examples. BPMN (Business Process Model & Notation) has become an international standard for modeling business processes, whereas UML (Unified Modeling Language) can be considered a general-purpose modeling language for software engineering. It is important and a good practice to strive for an optimal connection of business analysts and software developers to the architecture. Different roles, each with their own language, should collaborate to align their models. They should determine how models can fit together and where gaps or overlap can be prevented.
Tip 6: Open your architecture documentation
In many organizations, architecture documentation is only accessible to the architects themselves and a small group of insiders. The consequence is that architecture is seen by others as something vague, shady, and distant. It is better to open your architecture documentation and make it accessible in a comprehensible way for everyone interested in the subject. Many tools support the creation of HTML files which can be published on an intranet.
By exposing your documentation, you enable dialog and help stakeholders to become more familiar with architecture products. You will also help them to recognize the impact of your work.
Final Words
To make the ArchiMate language easy to use and understand in your organization, use it as often as possible provided it adds value to your initiatives.
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
