From the Editor: Graham Berrisford from Avancier Ltd has provided us with a series of articles related to modelling of business systems. This is part 2. Have a read and let us know what you think in the comments section below.

System modelling premises

How do you reduce ambiguity, ensure consistency and coherence in architectural specifications? UML and ArchiMate are modelling languages designed to help architects describe the operational (run-time) structure and behaviour of information-intensive business systems. The UML standard may be hard to read, but does declare its system theory premises in a way that ArchiMate doesn’t. To begin with, UML set outs two fundamental premises.

• All behaviour is event-driven, or discrete.
• All behaviour is performed by active structural elements (called active objects in UML; actors, components and nodes in ArchiMate).

It’s possible to express and elaborate UML’s premises using ArchiMate terminology.

1. Encapsulation: All systems and actors or components therein are encapsulatable behind an I/O interface.
2. Behaviour: All regular behaviours in a business system are triggered by discrete events, and run over time.
3. Structure: All behaviours in a system are performed by actors or components that occupy space and must be addressable.
4. Data: A data object contains a data structure or item that is meaningful or valuable to its creators and users.
5. Abstraction: All system descriptions abstract from operational systems that exist or are envisaged.
6. Typification: Architects usually model types rather than instances.

Countless business systems have been designed, built and operated on the basis of these premises. They provide a platform for the discussion of principles and issues explored below. 

1. Encapsulation

Premise: All systems and actors or components therein are encapsulatable behind an I/O interface.

The motivations for creating a business system lie in its effects on entities and events in its environment. To describe a business system involves defining the system-environment interface. System designers start by identifying external entities, and include them in system models.

Principle 1a: Systems are bounded within an environment

A social, business or software system is encapsulated logically rather than physically. This table illustrates how the external view of a system is the I/O boundary that external entities can see. The internal view reveals processes performed by actors or components inside the boundary.

In one sense, the system plus related external entities combine to make a larger system. But defining the system boundary is vital; it tells us what is designed by the system designer, and what is not.

Principle 1b: Systems are nested and overlapping

Systems are nested. The external/internal division can be drawn at whatever level of system granularity you choose. So what is external to one system is internal to another. Every actor and component within a system may be regarded a system in its own right. Every actor and component (also role and function) can be encapsulated and defined by the services it offers.

ArchiMate could be clearer that systems are not only nested but also overlapping. An actor or component inside one system may perform processes in other systems.

Principle 1c: There are component-bound and stand-alone interfaces

The interface of a hardware device is that part which encloses its body in a three-dimensional space. But thinking in terms of tangible hardware systems is misleading, because the parts of human and computer activity systems are distributed in space. The interface to a human or computer activity system is logical, and can be separated from it.

It may appear that a user interface is a part of a word processor application. Yet that same interface might give access to other components (on-line help, a graphical object library, or error reporting). And the user interface of MS Outlook is decoupled from the MS Exchange application.

A principle of service-oriented architecture (SOA) is to separate interfaces from components that do the work. So, components and interfaces can be loosely-coupled and related in N-to-N associations. 1 interface can be realised by N components; and 1 component can implement some or all of N interfaces.

ArchiMate offers different box symbols for interfaces and components. So architects can define an interface whose services are realised by two or more internal roles or components. And define a role or component that realises services in two or more interfaces. Unfortunately, there are three issues with ArchiMate’s take on component-interface relationships:

• ArchiMate says components “are composed of” interfaces, and one interface is a part of one and only one component. This denies the possibility of loosely-coupling and N-to-N associations between components and interfaces.
• Where a component has the same address as its interface, then the component is the point of access. In that case there is no need to draw separate boxes on a diagram.
• ArchiMate’s definition of an interface is biased towards provided interfaces rather than required interfaces. A provided interface specifies services that a system or component (acting as server) exposes and can serve to clients. A required interface specifies services that a system or component (acting as client) depends on and delegates to servers.

Principle 1d: Business interfaces are not platform communication channels

A social, business or software system is encapsulated logically rather than physically. An actor-to-actor or business-to-business interface may be defined in a service level agreement document that lists invokable business services. Since actors and components are distributed, they must exchange discrete communication events to invoke behaviours and respond to invocations, and there must be a physical communication channel along which the communication events can be passed. There is confusion in ArchiMate examples between the concept of a logical business-to-business interface (declaring what services may be invoked), and the physical infrastructure channels via which services may be invoked. This will be discussed towards the end of this series.

The following articles will explore premises 2 to 5, and unscramble ambiguities in how people use the terms.

2. Behaviour: All regular behaviours in a business system are triggered by discrete events, and run over time.
3. Structure: All behaviours in a system are performed by actors or components that occupy space and must be addressable.
4. Data: A data object contains a data structure or item that is meaningful or valuable to its creators and users.
5. Abstraction: All system descriptions abstract from operational systems that exist or are envisaged.
6. Typification: Architects usually model types rather than instances.

Previous article in this series | Next article in this series

Copyright Avancier Ltd 2016