TL;DR
Application Architecture artifacts describe the baseline and target application landscape. Common Phase C artifacts include the Application Portfolio Catalog, Application Communication Diagram, and Application/Organization Matrix.
Start from stakeholder concerns
When developing application and data architecture, choose viewpoints that answer stakeholder needs.
The question is not “How many diagrams can we create?” The question is “Which views help stakeholders understand the application landscape and make decisions?”
See also: Stakeholders, Concerns, Views, and Viewpoints.
Useful application artifacts
TOGAF lists many possible catalogs, matrices, and diagrams for Application Architecture.
Three useful ones are:
| Artifact | Type | What it shows |
|---|---|---|
| Application Portfolio Catalog | Catalog | Logical and physical application components |
| Application Communication Diagram | Diagram | Application components and their interfaces |
| Application/Organization Matrix | Matrix | Which organization units use which applications |
Application Portfolio Catalog
The Application Portfolio Catalog is often the starting point for Application Architecture because it lists the applications in scope.
It provides a foundation for later matrices and diagrams.
Typical fields:
| Field | Meaning |
|---|---|
| Logical application component | Implementation-independent application functionality |
| Physical application component | Deployed application, module, service, or product instance |
| Application owner | Person or team accountable for the application |
| Supported business capability | Business capability supported by the application |
| Lifecycle status | Current, target, retired, planned, or replaced |
Example:
| Logical application component | Physical application component | Owner | Lifecycle status |
|---|---|---|---|
| Purchase Request Processing | ERP purchasing module | Procurement IT | Current |
| Supplier Management | Supplier portal | Procurement Operations | Target |
| Employee Expense Capture | Expense SaaS platform | Finance IT | Current |
Logical vs physical application components
Enterprise architects often separate logical and physical components.
| Component type | What it means | Example |
|---|---|---|
| Logical application component | Application functionality independent of a specific implementation | Purchase Request Processing |
| Physical application component | A deployable application, module, service, or product instance | Configured ERP purchasing module |
The logical component describes what application capability is needed.
The physical component describes how that capability is implemented.
Application Communication Diagram
The Application Communication Diagram shows application components and their interfaces.
It helps answer:
- which applications exchange information?
- what data is exchanged?
- which business services are supported by each application?
- where are key integration dependencies?
flowchart LR PR["Purchase Request App"] ERP["ERP Finance"] SP["Supplier Portal"] BS["Procurement Service"] PR -- "purchase request data" --> ERP SP -- "supplier status" --> ERP ERP -- "approval and payment status" --> PR PR -. "supports" .-> BS ERP -. "supports" .-> BS
Keep this model logical unless technology details are relevant to the stakeholder concern.
Detailed interface models can become hard to maintain and difficult for stakeholders to read. Show as little as possible and as much as necessary.
Application/Organization Matrix
The Application/Organization Matrix shows how applications are used across organization units.
It helps with:
- understanding application support requirements
- identifying critical applications for important business operations
- checking whether an organization unit is missing required application support
- supporting gap analysis
Example:
| Organization unit | Purchase Request App | ERP Finance | Supplier Portal |
|---|---|---|---|
| Procurement | Primary user | Uses | Primary user |
| Finance | Uses | Primary user | |
| Operations | Raises requests | Views supplier updates |
If an organization unit performs a critical business operation and depends on an application, that application may need stronger availability, resilience, and support requirements.
Models vs matrices
Matrices are useful for collecting and checking data.
Models and diagrams are usually better for stakeholder communication.
Use both when needed:
- use catalogs and matrices to capture structured facts
- use diagrams to explain relationships, dependencies, and decisions
Exam note
- Application Architecture artifacts are created in Phase C.
- The Application Portfolio Catalog lists logical and physical application components.
- Logical application components are implementation-independent.
- Physical application components are deployed or deployable application components.
- The Application Communication Diagram shows application components and interfaces.
- The Application/Organization Matrix shows which organization units use which applications.
- Diagrams are often better for stakeholder communication; matrices are useful for data collection.