Premise 1: Encapsulation behind an interface

How to align ArchiMate with UML and TOGAF

“The method proposed by systems theory is to model complex entities (multiple interacting components) by abstracting from certain details of structure and component.” (Laszlo and Krippner).

This is one in a series of papers that present premises and principles for using business system modelling languages and frameworks in a way that is compatible with system theory.

Principles

Introduction. 1

Principle 1a: Systems are bounded within an environment 1

Principle 1b: Systems are nested and overlapping. 2

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

Principle 1d: Business interfaces are not platform communication channels. 2

Introduction

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. The classic approach to system design is to start by defining the required input and outputs. 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.

Environment		External entities and events
System	External view	Events/Services <exposed in> Interfaces
System	Internal view	Processes <performed by> Actors and Components

Taking a service-oriented view of systems, an interface is a collection of services accessible by clients. It identifies services, may provide access to them, and hides what performs them. A service is a discrete stimulus-response behavior, specified in a service contract that encapsulates process(es) needed to realise the service. “For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant.” ArchiMate.

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. And the interface to a human or computer activity system is logical, can be separated from it.

It may appear that a user interface is a part of a word an application. Yet the user interface of a word processor 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. And 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.

A social, business or software system is encapsulated logically rather than physically. An actor-to-actor or business-to-business interfaces 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 table puts business function where it seems to belong, but highlights the question of where business interface belongs.

View	Behaviours		Structures
View	Logical types	Instances in time	Instances in space	Logical types
External	Business services	Service occurrences	Business interfaces?	Service level agreements
Internal	Business processes	Process performances	Organisation unit actors Human actors	Business functions Roles

Since ArchiMate suggests an interface is an access point to services, it is placed as an instance above. But business architecture diagrams showing business interfaces called “telephone” or “web” are highly questionable. These are generic infrastructure devices or communication paths. These are not (as ArchiMate insists an interface should be) bound to one and only business role or actor.

B2B and B2C communications depend on shared communication infrastructure, for example:

· Face to face speech - mouth to ear over the physical medium of sound waves.

· Telephone speech – mouth the ear over the deep communication stack of a Telco network.

· Snail mail – writing to reading using paper over the communication stack of a postal service.

· Email – writing to reading using keyboard and screen over SMTP/IMAP over TCP over IP over Ethernet over physical IT media.

We do view business, applications and infrastructure domains as client-server layers. And in an “open” (rather than closed) client-server architecture you can skip layers. So in playing a business role, a human actor might directly invoke an infrastructure service. But generic infrastructure devices and communication paths are not business-specific system interfaces.

So what is a business-specific interface? Some kind of service level agreement defines (logically) what services a business requires or provides. This logical interface might then be realised in an application interface via which clients can invoke individual service occurrences. Or in telephone answering system that exposes domain-specific services (press 1 for this, 2 for that) to customers. Often it is realised in formal requests for work and in less formal inter-human communication.

Here are some concepts entangled in the idea of an interface, which ought to be disentangled.

· Service level agreement: a contract or other form of interface definition that declares what services clients can invoke, but is not run-time access mechanism.

· Controls: mechanisms (including user interfaces) that give clients tools to invoke domain-specific services directly.

· Directory: a “direct broker” or introduction agent that declares services and provides their addresses to clients.

· Façade: an “indirect broker” component that accepts events and service requests and passes them to server components.

· Communication stack: platform technologies used in the communication paths between actors or components.