Blog

ArchiMate vs Other Notations - 1# - Why you might need ArchiMate?

ArchiMate vs Other Notations - 1# - Why you might need ArchiMate?

Welcome to a new mini-series of articles on ArchiMate compared to other notations. This article is an introduction to a topic. We would like to answer a question you see in the title of this chapter: Why you might need ArchiMate?

Let us face the truth: we have got plenty of modelling techniques and notations over there. There is a pretty high chance that you, dear reader, stumbled upon notations like UML or BPMN. If you had something to do with Computer Science, then you could also raise a hand and suggest ERD. In fact, every domain has many modelling techniques. In business process modelling alone there are more than 10 different techniques!

All three have established themselves in current technology world very well. BPMN sits on business processes modelling throne. A lot of companies use UML for professional design of IT solutions. Whenever you need to setup a relational database ERD is a handy tool.

So why we need another player?

All those tools have their own territory (or, in other words, domain). BPMN when you want to describe business world, UML and ERD when you enter the technical world. What when you need to connect those worlds? What if they are always interconnected but we had no means to show that?

You can call BPMN, UML and ERD a domain-specific language. ArchiMate is an enterprise architecture modelling language. Enterprise Architecture covers more than one domain. It interconnects various areas of expertise like business, IT and its infrastructure. In TOGAF, one of the Enterprise Architecture frameworks, there are 8 different areas that combined create whole organization. Due to this fact, we can say that ArchiMate is one level above domain-specific languages. Picture below shows us how we could place ArchiMate in context of other techniques:

ArchiMate in context of other techniques

Nature of concepts

Such placement tells us two things. First, we should choose the modelling notation based on the nature of concepts we want to depict. For modelling business concepts only, it is wiser to select business process modelling notation. You could present greater level of details using dedicated notation.

Example: If you want to show the flow of business processes you would stick to BPMN, if it is the tool of trade in your organization.

Yet sometimes you need to show how applications or infrastructure supports business processes. For that ArchiMate is a good choice to show those dependencies.

In a same way when you need to depict an application design or technical solution you rather lean towards UML. It allows you to show methods, interfaces or class diagrams. It helps create the implementation view of given problem solution. But if you need to show how the solution supports business and how it is deployed you could use more generic notation. ArchiMate allows you to do so. And this is exactly why we want another player.

Details or overview?

The second thing we learn from placement triangle is that we need to decide whether we are interested in details or in the overview. Domain-specific languages are great to show implementation details. Thanks to that we could have a clear guidance how to put solutions in life. But rarely we develop solutions for the sole purpose of development.

Every solution is placed in some context and has its own purpose. Enterprise Architecture is all about explaining and designing this context. ArchiMate was developed to have a common language for many different areas of an enterprises. Yet, to achieve that it had to cut off unnecessary details. If you want to explore Enterprise Architecture topic, you could refer to our article 'Enterprise Architecture 101: Everything You Need to Know'.

ArchiMate helps us draw a bigger picture. Thanks to broad vocabulary and layers mechanism we could present high-level models. They cover inter-domain concepts, not possible to present using domain-specific notations. Thanks to that we could put focus on relationships instead of implementation details.

So, which notation should you use?

Or rather: which approach: domain-specific or enterprise-wide should we take? Answer is simple: both! ArchiMate was designed to co-exist with domain-specific languages like UML and BPMN. In fact, many concepts from those notations were taken as is into ArchiMate. Thanks to that you could connect your overview and detailed models. That helps building professional architecture repository. This possibility is also stated in ArchiMate specification.

It is the biggest advantage indeed: you could enhance your models by adding ArchiMate. You do not have to replace them! If you are working in business context you would find it helpful to use both BPMN and ArchiMate. First one gives you full flexibility on details of process flow. The latter helps you to place that in the context of your organization. Those of you working on IT solutions could embrace ArchiMate to connect IT and business. It is often helpful to show how we support business with IT and infrastructure.

Let's summarize what are the main take-aways from this article:

  • We have plenty of modelling techniques. ArchiMate is one of them
  • ArchiMate is an enterprise architecture modelling language
  • ArchiMate is wider in scope than notations like UML or BPMN, which are domain-specific notations. It is less detailed than those, though.
  • ArchiMate gives you possibility to draw a big picture that connects various areas of your enterprise
  • You could use ArchiMate in addition to, not instead of your current models

This article is a first one in ArchiMate vs Other Notations series. In other articles we will compare ArchiMate to other notations. You would find there both theory and some case studies.

ArchiMate vs Other Notations - #2 - UML: Software modelling

ArchiMate vs Other Notations - 3# - UML - business processes

ArchiMate vs Other Notations - 4# - UML - infrastructure modelling

ArchiMate vs Other Notations - 5# - BPMN - overview

ArchiMate vs Other Notations - 6# - UML/ERD - database modelling

 


Piotr Szpilkowski - trainer at Architecture Center LtdAuthor: Piotr Szpilkowski - Change Leader / Agile Coach, Trainer at Architecture Center Ltd

https://www.linkedin.com/in/szpilkowski/

Quality-oriented leader equipped with both technical and soft skills. Eager to create teams, organize things and make them happen. Experienced in managing various IT projects scattered all around the world. ArchiMate and SAFe trainer.