ArchiMate Patterns: Making Enterprise Architecture Reusable

An organization needs to add a new type of information to its architecture repository. The real-world question is simple. The modelling behind it isn’t, because the architect has to decide which ArchiMate elements and relationships represent the concept, and how much detail is enough. For anyone who doesn’t know where to start, the framework can feel far more complicated than the problem it’s meant to describe.

Finding an answer once doesn’t end the challenge, either. When the next architect meets the same situation, they may make slightly different choices. Both models can be valid ArchiMate without being consistent with each other.

ArchiMate Patterns address both problems. A Pattern captures an agreed modelling approach for a recurring situation. Architects who feel overwhelmed by ArchiMate get a clear place to start, and everyone who follows works from the same answers. That makes EA and ArchiMate more practical to apply and more consistent across a team.

A single Pattern still solves only a single problem. The larger gain comes from Patterns designed to work together, so information captured through one is ready for all the others.

A Pattern turns one architect’s modelling decision into the organization’s default.

At their simplest, ArchiMate Patterns are reusable modelling solutions for recurring architecture situations. A Pattern can specify six things:

• Which ArchiMate elements are relevant
• Which relationships to use
• What information to capture
• How the model is structured
• When the Pattern applies
• Why the modelling approach makes sense

Each item settles a question architects would otherwise have to work out alone before modelling even starts. Taken together, they also separate a Pattern from a diagram someone copies and pastes. A Pattern captures a modelling approach, so its value comes as much from the architectural thinking behind the model as from the model itself.

An example of a Pattern for SAP S/4HANA modelling with one Application Component per Line of Business.
Fiori apps are modelled as Application Services, and SAP technical components as System Software.

A Pattern gives architects a structure designed for one situation. They work with the elements and relationships that situation needs, not the full ArchiMate language, so the model stays as simple as the question behind it.

That’s especially useful when introducing ArchiMate to new teams, since a Pattern gives them a focused way to apply it. It’s ArchiMate made easy through reuse, with the underlying standard left fully intact.

If ten architects model the same type of situation independently, there are ten chances for their decisions to diverge. A Pattern replaces those ten separate judgment calls with one common approach.

Models built from the same Pattern don’t have to look identical. What they share are the important modelling decisions, which makes the results easier to understand and maintain. The next architect starts with the agreed structure and spends their time on the information that matters.

Consistency pays off well beyond the modelling step. Once architecture information follows a predictable structure, it can be reused for analysis and reporting. It also gives governance and visualization a dependable base, and each Pattern becomes a building block for the wider architecture landscape.

Building blocks only help if they fit together, though. When each Pattern is designed independently, one might model an application one way while another expects the same application to be represented differently. A third might bring its own structure for data the first two already cover.

The result is a library of useful templates that don’t fit together. Moving from one Pattern to the next means remodelling information that already exists, which adds back the very effort Patterns were meant to remove.

A coherent set of Patterns avoids this by design. Each Pattern is defined with its relationships to the others in mind, so the elements it captures become usable inputs for the next.

• A capability captured with a Capability Pattern should be usable when working with an Application Pattern.
• An application should be able to connect to the relevant data and technology information.
• An AI system should fit into the same architecture and not become a separate modelling island.

An example of an ArchiMate Pattern for Application Portfolio Management
linking an Application Component to the Capability it realizes and the System Software that serves it.

Information is modelled once and reused wherever it’s needed. Patterns stop acting as independent templates and become connected building blocks, which makes the overall enterprise architecture much easier to maintain.

A Pattern can be written up as modelling guidance or published as a diagram in a document. Implementing it as part of an EA practice is a different step, and it needs a shared place for the information each Pattern produces.

ADOIT is built around an architecture repository, where ArchiMate elements are maintained as repository objects that can be connected and reused across models and contexts.

A Pattern defines the structure, and the repository holds the resulting information. Other Patterns can then reuse those same objects, so a Pattern doesn’t have to create a new copy of information that’s already in the repository.

The ArchiMate Patterns provided in ADOIT are being developed as exactly this kind of coherent set.

ADOIT also provides Lean Architecture Profiles based on the ArchiMate standard, which let organizations start with a focused scope and expand their architecture practice over time.

Patterns suit that approach well, and they give teams that are new to EA a manageable first step. You don’t need to model everything or use every ArchiMate element at once. Start with the recurring situations that matter most to your organization and define useful Patterns for them. Each Pattern you add later should reuse what the earlier ones captured, so the practice can grow into a connected set without the same information being modelled again.

Patterns make ArchiMate easier for architects. Many people who hold architecture knowledge aren’t architects or ArchiMate experts at all.

With ADOIT Forms, organizations can offer a simpler interface for collecting and maintaining architecture information. Stakeholders answer questions in a form without needing to understand the complete ArchiMate metamodel, and their answers become part of the ADOIT repository.

An application owner, for example, can describe an application through a Form without deciding which ArchiMate relationship represents each dependency. The Pattern supplies the structure, and ADOIT stores the result so other Patterns can reuse it.

The architect defines the structure, and the stakeholder provides the knowledge. The repository connects the two.

Opening contribution to more people raises the question of data quality and change control.

ADOIT Forms can support approval workflows for submitted information. Organizations decide which changes go straight into the repository and which need review first.

Approvals protect the quality of what Forms bring in, and the repository keeps all of it connected to the Patterns that defined its structure. Together, they turn Patterns from standalone modelling guidance into part of an ongoing EA practice.

ArchiMate gives enterprise architecture a powerful, standard language. What it can’t do is tell each organization how to model the situations it meets repeatedly. Without that guidance, architects either struggle to find a starting point or solve the same problem in different ways.

Patterns supply that missing layer of practical guidance. Designed as a connected set, they let each new modelling exercise extend the architecture already in the repository, so architects don’t have to begin with a blank canvas or remodel what a colleague already captured.

Patterns don’t replace architectural thinking. They make it reusable.