Skip to content
Software Architecture Guide

Application Architecture Artifacts

Explanation

Section titled “Explanation”

Application architecture artifacts describe which applications an organization runs and how they relate. They are a set of views, not one document. Each view answers a different question.

The catalog. The application portfolio catalog lists all applications in the enterprise. Once the organization agrees on this list, it can define a standard set of applications and govern it.

Interfaces and interactions. The interface catalog scopes and documents the interfaces between applications. The application interaction matrix shows which applications communicate with each other. It complements the catalogs. The application communication diagram shows components and their interfaces. It stays logical and shows intermediary technology only where that matters architecturally.

Link to deployment. The application/technology matrix maps applications to technology platforms. It connects the application view to the deployment view.

Change over time. The application migration diagram is a time-oriented view. It shows the path from the baseline applications to the target applications, including temporary ones.

Use in rationalization. Rationalization means deciding which applications to keep or remove. It needs an inventory that records, for each application, the business capabilities it supports and its user groups. One possible decision is to retire a redundant application. Its data and users then move to an existing one.

Level of detail. A catalog entry is coarse. The arc42 building block view decomposes a single system into building blocks. It prefers relevance over completeness. It is therefore finer-grained than a catalog entry.

Example

Section titled “Example”

A company keeps a catalog with three entries: web shop, billing and old invoicing. An interaction matrix shows that the web shop talks to billing and that old invoicing also talks to billing. The inventory records that old invoicing and billing support the same business capability. The team decides to retire old invoicing and move its data and users to billing. A migration diagram then shows old invoicing as a baseline application that disappears in the target state.

Trade-offs

Section titled “Trade-offs”

Several views give a fuller picture, but each one is a separate artifact that someone must keep current. The facts here do not say how to maintain them or who owns them. A catalog entry is coarse by nature. Details of one application’s internals belong in finer-grained views such as the building block view.

Checks

Section titled “Checks”
  • The documentation includes a list of all enterprise applications that is agreed and used to define a standard application set.
  • Interfaces between applications are documented, and communication views stay logical.
  • Applications are mapped to technology platforms.
  • A migration view shows baseline and target applications, including temporary ones.
  • The application inventory records the business capabilities and user groups of each application.
Section titled “Related”

Sources

Section titled “Sources”