Using ArchiMate with other Standards
An introduction to combing ArchiMate with other standards – UML, BPMN, BMM & BMC
Watch the ArchiMate Video
Right then. Since we’re encouraging you to combine all these tools and see what works for your organization, let’s have a look at how they get along. Specifically, let’s see how ArchiMate can be combined with other standards to achieve a better design for your architecture.
First of all, a word about ArchiMate. As you may know, it is currently the de facto standard modeling language for developing enterprise architecture worldwide. This level of success means it also has its share of detractors, people who are quick to point out that it has too few/too many concepts to properly reflect the world that surrounds us; or that the definitions in the framework are too detailed; or that it struggles to model certain specific areas etc.
Which is to say it’s not perfect – what is, though? If you instead tune your expectations to be more in line with reality, well, you might come to realize that 1) it sure is a lot better than when it first came out, 2) it’s an Open Group standard, continually improved by the most successful practitioners in the world and 3) it features good built-in connectivity to other standards. So, you see, the global increase in popularity is no happenstance.
Now let’s get back to that third point. It needs to be clearly stated that ArchiMate is a modeling language that enterprise architects can use to design architectures pertaining to the enterprise level of abstraction, as well as the level directly below that – domain architectures. The key word here is enterprise.
ArchiMate has breadth – along with a certain level of granularity, sure, but it scores most of its points for being high level enough that it can model an enterprise-wide architecture. This means there are areas where it lacks the concepts to paint a proper picture of reality, which is exactly what this entire piece is centered around – recognizing that ArchiMate has certain blind spots, but acts as a great “blanket” language for enterprise modeling.
Thus, it sits neatly on top of the other standards you’re using, covering everything from one end of the organization to the other, while also combining satisfactorily with them. That’s because right from its developmental stages, it was meant to be used in conjunction with other languages in order to address areas outside its scope. In fact, it borrowed certain concepts here, adopted and modified some other concepts there, so the synergies are all too present. Bottom line, the ability to use ArchiMate in conjunction with other languages is there by design and it’s a virtue, if anything, not a drawback.
|Business Actor, Role||Actor|
|Requirement + Service||Use Case|
|Business Object, Data Object||Class|
|Node, Device, System Software||Node, Device, Execution Environment|
|Application Interface + Service||Interface|
|Aggregation, Composition, Specialization||Aggregation, Composition, Generalization|
The Unified Modeling Language is the most widely used developmental modeling language in the field of software engineering and it’s used to provide a standard way of visualizing the design of a system. From its definition you may immediately get a feel that it has a considerably narrower scope than ArchiMate, and that’s true. UML mainly covers application architecture, system requirements, as well as software and infrastructure design.
Therefore, the two standards somewhat overlap at the solution architecture tier of granularity, but all in all, they have different scopes. That means there are some great benefits to be had by combining them. For instance, say you need a viewpoint that is abstract enough it doesn’t put off your CEO, but still contains enough technical information to satisfy an IT manager. Using ArchiMate to model the higher level concepts, which may be relevant enterprise-wide, and then switching over to UML in order to accurately depict the details within specific application components is a very effective way to achieve that.
Ultimately, this allows you to build an architecture where formerly separate domains are now connected – enabling you to perform insightful analyses into the relationships between your enterprise’s IT systems, business processes, products, as well as its products and services. What’s more, it facilitates and encourages interaction between the organization’s departments since all the elements that make it up are clearly laid out.
You can find a table detailing the approximate correspondence between UML and ArchiMate. It’s not a perfect mapping as that’s hardly possible considering their different scope but it is very useful, nonetheless.
|Business Actor, Role, Application Component||Participant/Pool, Lane|
|Junction||Inclusive and Parallel Gateways|
|Or-junction||Exclusive and event-based gateways|
Basic mapping between the concepts in BPMN and ArchiMate
The Business Process Model and Notation (BPMN), quite plainly, is a graphical representation for specifying business processes in a business process model, based on a flowcharting technique. Its main purpose is to provide a standard notation that is easy to understand by all business stakeholders in order to bridge the disconnect that is so often encountered between business process design and implementation – and it’s very good at that. It features a great level of granularity, allowing the modeller to descend further into a sub-process and specify the minutest individual task, if required. Organizations who use BPMN will generally have a keen interest in developing their process architecture.
However, BPMN is constrained to support only the concepts of modeling that relate to business processes. It doesn’t acknowledge or account for things such as: organizational models and resources, functional breakdowns, data and information models, strategy etc. We can, therefore, say that both ArchiMate and BPMN can be used for modeling business processes, but while the former is best employed for high-level processes and how they relate to the enterprise context, the latter’s fine grained elements make it the clear choice for decomposing processes into smaller components. Which of the two you use simply depends on the specific audience that will see it.
|Goal||Vision, Desired Result (Goal, Objective)|
|Course of Action||Mission, Course of Action (Strategy, Tactic)|
|Principle, Requirement||Directive (Business Policy, Business Rule)|
Mapping between BMM and ArchiMate
The next standard we want to talk about is the Business Motivation Model, which is a standard used for successfully developing, communicating and managing business plans. Apart from helping you understand how to change the business in order to reach the desired business goals, clearly mapping out the motivation of the organization is also a great way to make sure everyone understands the overall vision, strategy and tactics that are to be used in getting there. Its main elements are Influencers, Assessments, Ends and Means, which are further broken down into more detailed concepts.
Of course, as is the case with the previous standards, ArchiMate can be used to model motivation on an enterprise-wide level, but if you need to delve deeper into the matter and provide a more detailed description of business motivation, then you need a tool like the BMM. You may not be aware of this, but ArchiMate’s strategy and motivation elements have actually been influenced by the BMM. As a result, it’s possible to create a fairly decent mapping between the two standards.
|Business Actor, Business Role||Customer Segments|
|Business Service, Value, Product, Goal||Value Proposition|
|Business Collaboration, Business Interaction||Customer Relationships|
Mapping between BMC and ArchiMate
Finally, the last framework we’re going to look at is the Business Model Canvas, which is a strategic management and lean start up template for developing new or documenting existing business models, and an all-round great tool for describing an organization’s value proposition, finances, infrastructure and customers. So how do the BMC and ArchiMate cross paths?
Often times, initiatives within a company fail because they start from within one department, they don’t take into consideration enterprise-wide reality of the organization and they push for changes that have little buy-in from the other actors involved. It seems preferable, then, to ensure that at the start of such an endeavour, before any resources are expended, the company has sound business model in place. This isn’t surprising, a strong foundation makes for a great future in any scenario imaginable, in and outside of business.
Afterwards, however – and this is key – it should turn it into an enterprise architecture to make sure it’s well adapted to the market. That transformation is, in effect, where we leave the BMC’s concepts behind in favour of ArchiMate’s.
For a very long time, ArchiMate was faulted for not having a motivation extension. Eventually, one was added and the model became more useful because it more closely served the reality of business. Further down the road, in ArchiMate 3.0, additional layers were added, the extensions stopped being called extensions in order to emphasize their core nature, and the language started accounting for physical world artifacts. So, who knows what the future holds?
We might even see an actual, proper integration between ArchiMate and some of the other standards, or they might all continue to be developed independently. What’s certain is that until such a time, there is great value to be had from combining ArchiMate with the different standards available to us, as we hope to have made it clear above.
Book a Demonstration
Let us show you what iServer can do for you with a free, personalised demonstration of iServer's capabilities.Book your Demo