Do we need Archimate?

A recent, provocative, post on linkedin, posed some issues about the Archimate standard.

One of my first doubts, using introducing Archimate in our Architecture Capability, was: “why was it created as a separate graphical language and not as an UML profile?”. This doubt is still in my mind, in my previous post about this topic, I have inserted some links about this argument. The “UML profile” solution appears as natural, because a lot of classifiers from UML are available – with the same semantic and graphical notation – also in Archimate.

What are the consequences of a “separate” graphical model?

(+) dedicated modeling tools

(-) multiple skills/tools/repositories

(-) requirements for model integration

On the other side, I think that we should remember that Archimate and UML have different “meanings”:

  • Archimate is for architecture,
  • UML is for engineering.

Also if you look at building design, you will find an “Architectural” project, showing you the shape, internal space allocation, external appearance, of the building, and several specialized views (structural project, electrical plant, elevators, etc.); perhaps the potential buyer of the house is not interested in how many cables or switches are necessary to operate the elevator – and could not understand this view – but is interested in the size and number of windows of the living room.

Despite this, I believe that “Archimate as UML profile” could bear the same expressiveness, the same semantic content, and a seamless integration of architectural and technical layers.

a building under construction

Personally, I am evaluating the introduction of Archimate, and starting to represent (maybe with better results) our architecture with this language. But, in the mean time, and waiting for the similar OMG work, I am starting do develop an UML profile with the same content of Archimate. At this point, we are working on the Business Layer. The modeling tool that we use, by Sparx Systems, allows for an easy integration on different models using UML, BPMN or Archimate, so it does not force the user to a specific adoption profile. But, in the meantime, the UML-profile approach is allowing us to obtain stakeholder-oriented documentation with a better quality, and an easier transition from the previous graphical representation standards.

At the same time, the introduction of Archimate shows its usefulness in a more formalized and rigorous architectural design practice, relaying on a number of elements that fits well with the various organizational patterns that exists in our Company.

The results – at this point – are promising, I will share them later, and introduce some of them in the second edition on my book about BPMN.

Bottom line: I believe that we need archimate, as a component of our architecture capability. Maybe, representing it as an UML profile could help its adoption.

More on information modeling: from business to disk

Every business deals with a finite number of entities, concepts, things, as you may prefer to name them.

Every modeling standard and project framework deals with this, approaching this description from several different viewpoints.

The existence of different descriptions, at different abstraction levels, for the same thing, and the logical links between these different modeling contexts, is one key output of an Enterprise Architecture capability.

Let’s look at the following picture, showing a common concept, “Vendor”, at different architecture layers.

Data objects in Archimate and BPMN

The picture shows modeling elements from two widely adopted standards: BPMN and Archimate.

Context / Behaviour

A Vendor is usually a stakeholder, and an external party, for our business, As such, it may be represented with a Partner Role element, according to BPMN. This is mainly a reference role, a bookmark, also if we may wish to attach some documentation or classification elements. This element will have a place in BPMN process modeling, as a Participant in a collaboration.

Archimate modeling language includes two elements that can be used as a collaboration participant: Business Role and Business Actor. The Actor is an element modeling something which may or may not have a defined identity (in BPMN Partner Role doesn’t have an identity, while Partner Entity does), but have an independent capability to perform actively some tasks. A Role, on the contrary, is more a formal description of the duties, responsibilities, capabilities, interfaces used and provided, related to a business organizational unit or single person.

So, if we want to emphasize “what the partner does”, we can model it with a Role, but if we have more interest on “what kind of partner is”, we will prefer an Actor. Usually, and Enterprise Architect is interested in the “internal” architecture of his business and, in my opinion, will find the Actor element better suited for this task.

Business Object

This is a typical element of Archimate, representing a wide range of possible items. I usually see the Business Object (a passive element in the Business Architecture Layer) as an element of the business dictionary. In every Company, when you start an interview with people with different roles, you will recognize a number of common “words”. They represent the products, the market, the external parties, the production facilities. They are the better candidates to be represented with a Business Object (behind this analysis, we may like to perform a more detailed ontological analysis on the concepts and relationships, but this is another chapter). At the Business Layer, a Business Object is not an “information item”, but is a collection of information, rules, connection with processes and internal organizational units, that will remain unchanged if we replace the information system with another one, without changing the business architectural layer.

In BPMN there isn’t a corresponding element, but we often use the Data Object to show which activities interacts with some parts of a Business Object. In general, I prefer to limit the “technical data structure pollution” in BPMN diagrams, this means trying to be as abstract as possible with respect to the actual data structure. The BPMN standard encourages this, providing a number of Item Aware Elements, that may reference any kind of physical, logical or informational element.

So, for instance, a process where one of the deliverable is the Vendor Master data, or a new Vendor Dossier, will see the “Vendor” Data Object.

Application and Database

Coherently with the approach followed for Data Objects, I usually use Data Stores to model “logical” database representations, detached from the actual database storing their data. Following the example in this article, we will have a “Purchasing” Data Store, including everything that is connected to the purchasing cycle: items, prices, vendors, orders, deliveries, etc. Someone may observe that a “Vendor” is also relevant in the “Accounting” Data Store, as part of the Accounts Payable, but I don’t agree. We deal with a Vendor because it is a provider of services and goods, not because we have an account opened with his name in our books.

Archimate, on the opposite, makes a clear distinction between the Application/Data layer – where the Data Object will have a strong “structure/database table” meaning, and the Device elements, which is used to represent the actual “hardware” hosting the Database.

Bottom Line

By using a limited number of partially-overlapping modeling standards (in our choice: TOGAF, Archimate, BPMN and UML), we can obtain a powerful and detailed representation of our Business Architecture according to different perspectives and viewpoints. Business Concepts modeling is a key part of the Enterprise Architecture capability, allowing us to catch what is maybe the core knowledge base of our business. Extending upwards (Business interactions and processes) and downwards this modeling layers will give us the ability to track the impact of any change in our business scenario on all the levels of the Architecture.

Business information modeling with Archimate

Archimate uses the “Business Object” element to model a passive entity representing a concept or a business entity manipulated by behavioral business elements.

Creating a catalog of “Business Objects” is useful when you need to analyze links among application, data, process areas.
Consider concepts like “Purchase Order” or “Supplier”: they may appear as data input or output, part of the data architecture, stakeholders, roles in process diagrams.
It’s also important to model the information associated with each Business Objects. For instance, a “Purchase Order” may carry information about the kind and quantity/quality of goods or services, contractual information, cost accounting details, internal organization references (requester, buyer, authorizer). These information can be modeled in two ways:
  • using the “Meaning” element in Archimate;
  • using an aggregation.
I don’t like the second, because, while a Purchase Order has a defined identity and unity, the details of goods, outside the Purchase Order context, is ambiguous, because the same information can be related to a Purchase Request, a Delivery, a stock adjustments, etc.
In my Company, Caltagirone Group, I adopted the first notation, obtaining this kind of diagrams:
Archimate PO Business Object

Continue reading →