Modelling Business Rules using the ArchiMate language (LinkedIn original)

A few days ago, a question was posted on the ArchiMate group on LinkedIn: How to model or to represent business rules in ArchiMate models?

A number of answers were given, trying to approach the question from a number of perspectives. As a decision modelling practioneer, I decided to present here a more complete answer than it is possible to be done in the discussion thread. Any comments or questions about the proposed solution are welcome.

First of all, we need to acknowledge that business rules can appear on different architecture domains, so there may be a number of "right" ways to model then in ArchiMate. Let's see how to model some business rules and decisions incarnations.

A Business Rule from Motivation to Core

Gladys Lam provides a good insight on business rules and business requirements on this article. In there, she drawns a clear separation line between rules and requirements, and provides a number of well-crafted examples to explain the differences between them. In her words, "Business rules are lists of statements that tell you whether you may or may not do something, or give you the criteria and conditions for making a decision", and "a business requirement is what you need to do to enable the implementation of and compliance with a business rule". Clear crystal, no?

However, ArchiMate does not provide a native element in the Motivation Extention to express business rules like these ones (taken from the Gladys' article):

  • A Customer must have a valid Email Address
  • An Email Address must be considered Valid if an email sent to Email Address does not return 'undeliverable' within 60 minutes

On page 115, the ArchiMate 3.0 standard clearly suggests that business rules can be modelled as a specialization of a Business Requirement. Following this guidance, the rules above would be modelled as follow:

(update note: in real life I specialize a Business Rule from a Principle, so that it's clear that a Business Rule IS NOT a consequence of a Requirement, but the other way round, indeed!)

I'd strongly suggest that a new element (specialized from the Principle element) is created, but in this exercise I'll restrain to the plain usage of standard elements with a stereotype annotation.

From Business Rule to Business Requirement

Following Gladys' example, these business rules must be realized somehow in the architecture by some business requirements:

As per the ArchiMate standard, you can use these requirements to link the business rules to the core elements in the architecture that realize them:

A Business Rule as a Decision

Eventually, you may also model a business decision that enforces the business rule in the process, as shown below:

The decision model will, eventually, be detailed using e.g. the new OMG standard DMN-Decision Model and Notation, or the old (and still good) TDM notation.

Going down the road

In this post I won't go deeper and show how to model the Application end Technology Layers (where we'll eventually find a BRMS-Business Rule Management Systems or a BDMS-Business Decision Management Systems to actually run the decision model), but I'm sure you've got the idea on how business rules and business decisions can be modeled using the ArchiMate language.

If you have any doubts, or wish to share your experiences in modeling business rules using the ArchiMate language, please leave a comment.