Application Architecture and Integration

Application Architecture is the EA domain that defines the systems that deliver enterprise capabilities — what applications exist, what they do, how they are structured, and how they integrate. In most enterprises, the application portfolio is the single largest and most complex technology asset, and the place where strategy meets execution most directly.

Two forces dominate modern application architecture: the integration of the portfolio (how hundreds of systems work together) and its composition (how the enterprise assembles new capabilities from modular parts). Both have been transformed by the API-first movement, event-driven architecture, and the MACH/composable patterns.

This page covers application portfolio management, integration patterns, the API platform, and the move to composable architecture — the connective tissue of the modern enterprise.

The application portfolio is rarely designed; it accretes. Years of mergers, local optimisation, and vendor-driven purchases leave most large enterprises with hundreds of overlapping applications, many underused or redundant. Application portfolio management (APM) is the discipline of bringing order: inventorying applications, mapping them to capabilities, assessing value and cost, and making rationalisation decisions.

The classic APM frame is the 4 Rs — Retain, Retire, Replace, Rationalise (sometimes Rehost/Replatform). Each application is assessed against business value, technical fit, cost, and risk, then assigned a disposition. The output is a rationalisation roadmap that reduces run cost and complexity while preserving capability.

APM is not a one-off project. It is a continuous practice, ideally refreshed annually, that keeps the portfolio aligned to strategy. The capability-to-application mapping produced here is one of the most queried views in the EA repository — and the basis for impact analysis when strategy or regulation changes.

Integration is the heart of application architecture because the portfolio's value is realised through how systems work together. The pattern landscape ranges from point-to-point (simplest, least scalable) through hub-and-spoke and enterprise service bus (ESB) to API-led and event-driven. Each pattern trades flexibility against complexity.

Point-to-point integration is the default that emerges when there is no integration strategy — every system talks to every other directly, producing an N-squared tangle that becomes unmaintainable. The ESB centralised integration in the 2000s; API-led integration decentralised it again in the 2010s with managed APIs as the contract. Event-driven architecture decouples producers and consumers via events, enabling loose coupling and real-time responsiveness.

The modern best practice is a hybrid: API-led for synchronous request-response, event-driven for asynchronous, streaming, and real-time flows. The enterprise API platform and the event backbone are now peer infrastructure — and both belong in the EA reference architecture with standards, ownership, and governance.

The API platform has become the most strategically important integration asset. It exposes enterprise capabilities as versioned, secured, documented, and metered APIs — turning integration from a project-by-project activity into a product. The platform typically includes a gateway (routing, security, rate-limiting), a developer portal (discovery, documentation), and management (lifecycle, analytics, monetisation).

API-led integration organises APIs into layers: experience APIs (tailored to consuming apps), process APIs (orchestrate business processes), and system APIs (wrap back-end systems). This layering lets the enterprise change back-end systems without breaking consumers, and add new experiences without building new integrations each time.

Governance of the API platform is essential: versioning policies, deprecation rules, security standards (OAuth, mTLS), and contract testing. An ungoverned API platform fragments; a governed one compounds reuse and becomes the enterprise's integration nervous system.

Event-driven architecture (EDA) models the business as a stream of events — things that happen (order placed, payment received, shipment delivered) — and lets systems react to them independently. Where API-led is synchronous and request-response, EDA is asynchronous, loosely coupled, and naturally real-time. The backbone is an event broker or streaming platform (Kafka, Pulsar, cloud event services).

EDA shines where responsiveness and decoupling matter: fraud detection reacting to transactions, inventory adjusting to sales, customer notifications triggered by lifecycle events. Its cost is operational complexity — event schemas, ordering, idempotency, and replay all require engineering discipline.

The pragmatic pattern is event sourcing for high-value domains (where an immutable audit of events is valuable) and simpler pub-sub elsewhere. The architect's job is to choose where EDA's power justifies its complexity rather than applying it universally.

Composable architecture assembles the enterprise from packaged business capabilities (PBCs) — independently deployable, API-exposed modules that can be combined, replaced, and scaled. The MACH acronym (Microservices, API-first, Cloud-native SaaS, Headless) captures the technical style that enables composability. Originating in commerce, MACH has spread across the enterprise.

The payoff is packability: the ability to launch a new experience by composing existing PBCs rather than building or integrating monoliths. The cost is integration discipline — PBCs must have clear contracts, ownership, and lifecycle independence, or composability collapses into a distributed monolith.

Cataloguing PBCs in the EA repository — with their APIs, owners, and dependencies — is what makes composability real. Without that catalog, teams cannot discover what exists and rebuild what already exists; with it, reuse compounds and the portfolio rationalises itself over time.

AI is reshaping application architecture in two ways. First, AI capabilities (RAG, agents, copilots) are themselves applications that integrate with the portfolio via the same API platform and event backbone — they should be treated as first-class applications, not special cases. Second, AI is being embedded into existing applications, requiring architectural decisions about where intelligence lives (in the app, in a shared AI platform, in an agent).

The emerging pattern is a shared AI platform (model serving, orchestration, governance) that applications call via APIs, much as they call a database or a payment service. This keeps AI consistent, governed, and cost-efficient, and avoids every team building its own AI stack.

The architect's role is to ensure AI integration follows the same discipline as any other integration: contracts, versioning, security, and observability. An AI capability bolted onto an app without an integration contract is a future liability; one integrated through the governed platform is a reusable asset.