Application Architecture

9.2.1Definition

Application architecture describes how an organization's individual applications relate to each other — which systems exist, what each is responsible for, and how they integrate — as distinct from the internal architecture pattern (7.10) of any single one of them. It's the map of the entire application landscape rather than the blueprint of one building within it.

9.2.2Why It Exists

Individual applications built in isolation, however well-architected internally, tend to duplicate capability and integrate poorly across an enterprise with dozens or hundreds of systems. Application architecture exists to maintain a coherent, deliberate map of that landscape — avoiding redundant systems, defining clear integration points, and identifying where a new capability should live before it's built.

9.2.3Core Concerns

• System inventory — a maintained catalog of what applications exist and what each owns.
• Integration patterns — how applications communicate (APIs, 5.4; events, 5.6) rather than each building bespoke, undocumented connections to every other system.
• Redundancy identification — spotting where two systems have grown to serve overlapping purposes, usually unintentionally.

9.2.4Common Mistakes

• No maintained application inventory, leaving the organization without a clear picture of what systems exist or who owns them.
• Point-to-point integrations built ad hoc between every pair of systems, creating a tangled, undocumented web that becomes progressively harder to change safely.
• New capabilities built as entirely new systems by default, when an existing application's scope should reasonably have been extended instead.

9.2.5Best Practices

• Maintain a living inventory of applications, their owners, and their responsibilities.
• Standardize integration patterns (APIs, events) rather than allowing bespoke point-to-point connections to accumulate.
• Review the application landscape periodically for redundancy and consolidation opportunities.