Understanding Reference Models and Their Representation with ArchiMate

In a previous Marc Lankhorst blog the value of reference architectures was highlighted; this article delves deeper, focusing on the "product" we are familiar with – reference models – using ArchiMate as the modeling language.

What is a reference model?

First, we step back and look at reference architectures, which are described as standardized architectures that provide a reference framework for a specific domain, industry, or field.

A reference model offers a very clear, often visual, view of an area of interest – reusable artifacts that can be adapted to fit an organization.

Examples of reference model types include:

Business Reference Model (BRM)

Technical Reference Model (TRM)

Information Reference Model (IRM)

Many industry reference models are publicly available, but the real benefit comes from tailoring these models into organization‑specific reference models that facilitate discussion, promote reuse, and provide traceability for other architectural domains.

How do I represent this with ArchiMate?

Reference models often exist as PowerPoint slides, Visio diagrams, or even filled‑in Excel cells – great for communication and one‑off messaging.

In enterprise architecture, reference models are rarely used in isolation; they need to be linked to other areas, which requires a standard such as ArchiMate to bind reference model elements.

A recurring question is – "Which concept should I use to represent a particular ‘block’ on a reference model?" This discussion can take days or weeks, yet it defeats the purpose of a reference model if consensus on representation is not reached and consistently applied.

Business Reference Model

It essentially describes the "business on the page" by breaking down parent "areas" into children, grandchildren, etc., and should convey the organization’s roles, providing strong clues about function.

For those familiar with ArchiMate, the described "behavior" is essentially business‑oriented, akin to business functions.

Microsoft Industry Reference Architecture for Banking

Technical Reference Model

Similar to the business reference model, the TRM describes the "infrastructure on the page" but from a functional perspective – it should not focus on low‑level server, processor, or hardware details.

Considering these points, the focus shifts to infrastructure services and functions (i.e., behavior).

The Cloud Ecosystem Reference Model

Information Reference Model

In the previous two examples we noticed the use of the "behavior" concept – this is common for many reference models. Typically, the "structure" concept aligns more closely with implementation.

The IRM describes common "information" available within an organization (e.g., TM Forum SID). From a logical standpoint, using the behavior concept is inappropriate, so we view it as a "passive structure" column describing objects.

Experienced ArchiMate users may decide whether to use Business Objects or Data Objects to represent IRM elements; often high‑level "information" is best modeled as business objects.

The Information Framework (SID)

Conclusion

Thus, we have some recommendations for using ArchiMate with reference models.

You can use various ArchiMate concepts to represent elements in the model; the most important point is to reach a consensus on the standard, stick to it, maintain consistency in use, and share the results.

The final note emphasizes presenting to non‑technical stakeholders – remember that architects can create reference models with standardized ArchiMate notation (enabling effective relationships for impact analysis, etc.), but there is no reason not to output them in different views, such as "notification"‑type perspectives.