The ArchiMate application layer

The application layer is the part of an ArchiMate model that describes software. It shows the applications an organisation runs, what they do, what they offer to people and to other systems, and the data they handle. It sits between the business layer above it, where people and their work are described, and the technology layer below it, where servers and networks are described. ArchiMate 3.2 gives the application layer nine element types.

Like every core layer, it sorts its elements into three aspects. Active structure is what does the work. Behaviour is the work itself. Passive structure is the data the work reads and writes. The figure above shows the nine types in those three columns. The layers and aspects article explains the grid behind this.

This article uses one example all the way through: a small clinic. Patients book visits on a web page. A receptionist books visits for patients who phone. When a new patient books for the first time, the clinic also opens a medical record for them. Here is the clinic's application layer, with every one of the nine types in it.

ZoomSwipe to see the whole diagram →Open full size

The next three sections take the figure apart one aspect at a time. The section after them adds the business layer above and the technology layer below.

Active structure elements are the things that act. In the application layer they are pieces of software and the points where people or other systems can reach them. The notation column describes the icon ArchiMate 3.2 gives each type. It is drawn in the top-right corner of a rectangle, or on its own as a small symbol.

How big is a component? Big enough that people name it in a meeting, and something you could replace with a different product. "Booking system" passes that test. "The date picker" does not, because it is a part of the booking system's code. For a closer look inside one system, use a UML component diagram.

An interface is part of a component, so it is usually drawn with composition from the component: a line with a filled diamond on the component's end. One component can have several interfaces. The booking system has a web page for patients and a screen for the receptionist, and both reach the same service.

A collaboration is the least used of the three. Draw one only when two components really do something together that neither does alone. It joins its members with aggregation (a hollow diamond), because each component also exists outside the collaboration.

Behaviour elements are the work itself. Each one is performed by an active structure element, joined to it by assignment: a line with a dot on the performer and an arrowhead on the behaviour. The application layer has five behaviour types.

Function or process? This is the question beginners ask most. A function answers "what does it do?". A process answers "in what order?". If you can number the steps and name the result at the end, it is a process. If it is a group of related abilities that run whenever they are needed, it is a function. Calendar management has no first step. Confirm booking does. A function can serve a process, which means the process uses it: Confirm booking uses Calendar management to check that the slot is free.

Service or the behaviour behind it? A service is the outside view. The function or process is the inside view, and it realizes the service, which means it is what makes the service real. Patients see Appointment booking. They never see Confirm booking, and they do not need to. An interface is assigned to the service it offers: the Online booking page is where patients use Appointment booking.

Events start things. An event takes no time. It triggers behaviour, drawn as a solid line with a filled arrowhead, and a process can also trigger an event when it finishes. Booking request received triggers Confirm booking.

The application layer has one passive structure type: the data object, which is data structured for automated processing. It is drawn as a rectangle with a band across the top, the same shape as a business object but in the application colour. In the clinic there are two: Appointment data and Patient data.

Behaviour reaches data through the access relationship, a dotted line. The line always runs from the behaviour to the data. Its arrowhead shows which way the data moves: an arrowhead at the data object means write, an arrowhead at the behaviour means read, arrowheads at both ends mean read and write, and no arrowhead means the direction is not stated. In the clinic figure, Confirm booking writes Appointment data and Register new patient writes Patient data.

Keep data objects at the level of business meaning: "Appointment data", not "the appointments table". If you need fields, keys and types, that belongs in a database schema or a UML class diagram, not in an ArchiMate view.

The application layer is rarely drawn alone. In most views its job is to show which software supports which business work, and what that software runs on. Two relationships do most of this. Serving means "is used by": a solid line with an open arrowhead pointing at the user. Realization means "makes real": a dashed line with a hollow triangle pointing at the more abstract element.

ZoomSwipe to see the whole diagram →Open full size

All of these pairs are allowed by the relationship table in Appendix B of the ArchiMate 3.2 specification. Notice that Booking system does not connect to Book a visit directly. The service sits between them, and that is on purpose: the business reader cares about what the software offers, not about which system it is.

You will sometimes see a component drawn serving a business process directly. That is a derived relationship, a shortcut through the service. It is legal, but it hides the service, so use it only in a view where the service does not matter.

1. Drawing a service as a component. If you cannot point at it running, it is not a component. "Appointment booking" is what the system offers; "Booking system" is the system.
2. Starting the access line at the data. Access always runs from the behaviour to the data object. The arrowhead says read or write; the direction of the line itself never changes.
3. Reversing realization between data and business. Appointment data realizes Appointment, not the other way round. The more concrete element realizes the more abstract one.
4. Skipping the service. A line from Booking system straight to Book a visit tells the reader that something helps, but not what. Draw the service and let it carry the name the business uses.
5. Using an application process for work a person does. If the receptionist does the step, it is a business process. An application process is behaviour the software does on its own.

Three short questions about the clinic. Try each one before you open the answer.

1. The clinic wants to send a text message reminder one day before each visit. At the right time the booking system notices a reminder is due, and then it sends the message. Which application layer elements would you add?

2. Is the Reception screen an application component or an application interface?

3. The booking software supports the business process Book a visit. Do you draw serving or realization between the application layer and that process?

Source: the official ArchiMate 3.2 Specification from The Open Group. The allowed relationships are in its Appendix B.