As I look into linking the business layer with other perspectives in enterprise architecture, the following question came to me: “How do I link business rules with business processes, business objects and even with data objects?”

Inspired by this article from Antonio Plais on business rules,  I have looked in depth into ArchiMate Enterprise Architecture Modeling Language (ArchiMate 3.0 specification). I illustrate what I have learned by relating elements from three different layers from Enterprise Architecture, namely, Business Layer, Motivation Layer and Application Layer. The following diagram shows an overall view of element types in these layers using Sparx Systems’ Enterprise Architect:

business-layer-overall.png

Business Layer

Let’s start by defining the business processes and the related business objects. The relationship from a Business Process to a Business Object are:

  • access: a type of dependency relationship that indicates that a process acts upon (e.g. read, update, delete) an object.
  • association: an unspecified relationship between any two elements.

The following diagram shows the Business Layer with the Business Process ‘Create Recipe’ that creates the ‘Recipe’ business object using the access relationship.

business-layer.png

Motivation Layer

The Motivation layer in ArchiMate represents the reasons that guide the solution. Adding motivational concepts from this layer, I use a Requirement element to represent business requirements.

The possible relationships from a business process, business object or data object to a requirement are:

  • realisation: a structural relationship that indicates that one element plays a critical role in the operation of another element.
  • influence: a type of dependency relationship that indicates that a element affects the other element (e.g. positively, negatively).
  • association: an unspecified relationship between any two elements.

On the other hand, the relationship possible from a requirement to a business process, business object or data object is association.

From these options, I selected realisation due to its stronger meaning to demonstrate that one element realises the other, in this case, a business process realises a requirement. The others relationships were not selected because association is generic and influence is the weakest type of dependency. The ArchiMate specification mentions: “For weaker types of contribution to the realization of an element, the influence relationship should be used” (section 5.1.4. Realisation relationship). In addition, the influence was created to link motivational elements, specific to Archimate, which are not in UML. Thus, the realisation seems the best suit for this case.

The following diagram shows the business process ‘Create Recipe’ and the business object ‘Recipe’ realising the requirement ‘Possibility to update portions’.

business-layer-cs.png

According to ArchiMate, a business rule is a specialisation of a requirement. There is no specific element to represent business rules in ArchiMate. But, we could use the same element as from requirement. However, in a context where there are already business rules, a businessRule element can be used to make an specialisation of the requirement element.

business-layer-brule-cs.png

Application Layer

Going to the application layer, the relationship between data object (application layer) and business object  (business layer) is realisation.

Considering a business rule as a specialisation of a requirement, the relationship of a data object to the business rule is a realisation, following the same reasoning for relationships towards requirements.

The data object ‘Recipe’ realises the business object ‘Recipe’ and the business rule ‘Update portion of ingredients’. The user can increase, decrease portions and reset to original portion.

business-layer-brule-busobj-cs.png