Application and Integration Architecture

Introduction and Context

Enterprise IT architecture concerns more than selecting technologies. It determines how business capabilities are represented in software, how applications exchange information, how change is governed, and how technology investments support organisational strategy. Application architecture describes the structure, responsibilities, interactions, and lifecycle of software applications. Integration architecture describes the mechanisms and principles through which applications, data, platforms, users, and external partners cooperate.

Modern enterprises rarely operate a single coherent application landscape. They typically combine packaged enterprise systems, custom applications, cloud services, mobile channels, data platforms, partner interfaces, and decades of accumulated legacy technology. The resulting portfolio may contain duplicate capabilities, inconsistent data, obsolete interfaces, excessive dependencies, and high operating costs. Application and integration architecture provides the disciplines required to understand this complexity and reshape it deliberately.

The central design challenge is balance. Highly centralised integration can simplify governance but create bottlenecks and single points of failure. Highly decentralised integration can improve autonomy but produce inconsistency and uncontrolled dependencies. Similarly, microservices may improve independent deployment, but they introduce distributed-system complexity. A sound architecture therefore begins with business capabilities and quality attributes rather than with fashionable technologies.

Learning Objectives

By the end of this chapter, the reader should be able to:

• evaluate an application portfolio using strategic, technical, financial, and risk criteria;
• distinguish applications, services, APIs, events, and integration platforms;
• apply modularity, domain-driven design, and bounded contexts to application architecture;
• compare point-to-point, hub-and-spoke, API-led, event-driven, service-oriented, and microservice integration styles;
• analyse interoperability, coupling, cohesion, consistency, and failure behaviour;
• develop realistic approaches to legacy modernisation;
• make defensible build-versus-buy decisions; and
• address security, governance, ethics, compliance, and operational concerns in integration design.

1. Application Architecture as a Business Design Discipline

An application is a deployable software system that supports one or more business capabilities. Examples include order management, customer relationship management, payroll, fraud detection, and inventory planning. An application architecture specifies the application’s components, responsibilities, interfaces, data ownership, dependencies, deployment structure, and quality attributes.

A useful distinction is:

• Business capability: what the organisation must be able to do, such as “settle claims.”
• Business process: how work flows through activities, roles, decisions, and applications.
• Application: software that automates or enables capabilities and processes.
• Component or module: a cohesive part of an application with a defined responsibility.
• Service: a software capability exposed through a stable contract.
• API: a technical interface through which software requests operations or data.
• Event: a record that something important happened, such as “Payment Accepted.”

These concepts should not be treated as synonyms. An API normally represents a request-response interaction, whereas an event communicates a fact without requiring the producer to know every consumer. A service may be exposed through an API, publish events, or do both.

Quality Attributes

Functional requirements state what a system does. Quality attributes state how well it must do it. Important attributes for application and integration architecture include:

Architectural decisions involve trade-offs. For example, synchronous integration may provide immediate confirmation but increase temporal coupling: the consumer and provider must both be available at the same time. Asynchronous messaging can improve resilience but introduces eventual consistency and more complex error handling.

2. Evaluating the Application Portfolio

Application portfolio management is the systematic assessment of applications to determine their business value, technical condition, cost, risk, and future role. It prevents investment decisions from being based solely on anecdote or the loudest stakeholder.

A Portfolio Assessment Model

A practical assessment considers five dimensions:

1. Business value: contribution to revenue, customer outcomes, operational efficiency, or strategic differentiation.
2. Technical health: maintainability, architecture quality, documentation, performance, security, and vendor support.
3. Financial position: licensing, infrastructure, support, enhancement, migration, and opportunity costs.
4. Risk and compliance: exposure arising from security weaknesses, unsupported components, concentration risk, or regulatory non-compliance.
5. Strategic fit: alignment with target capabilities, cloud strategy, data strategy, and future operating models.

A simple prioritisation score can support discussion, but it should not replace professional judgement. For example:

Here, P is a prioritisation score; B, T, F, R, and S are normalised scores for business value, technical health, financial position, risk, and strategic fit; and the w terms are organisational weights whose sum is 1. The score is applicable only when the dimensions have been defined consistently, commonly on a 0–100 scale. Risk may be scored so that a higher number means greater urgency, or inversely so that a higher number means better condition; the convention must be documented.

Portfolio decisions commonly fall into these categories:

Dependency and Lifecycle Analysis

A portfolio review should map upstream and downstream dependencies, interfaces, data stores, batch schedules, identity mechanisms, and operational ownership. A technically obsolete application may be difficult to retire because many other systems depend on undocumented file transfers. Conversely, a heavily used application may be a good modernisation candidate if its interfaces can be isolated.

Lifecycle analysis should include contract end dates, vendor support, programming-language skills, operating-system versions, security vulnerabilities, data retention obligations, and the cost of keeping obsolete infrastructure available. The analysis should distinguish direct costs from hidden costs such as manual reconciliation, delayed releases, duplicate data entry, and inability to respond rapidly to regulatory changes.

3. Modularity and Domain-Driven Design

Modularity divides a system into units with clear responsibilities and controlled dependencies. A good module has high cohesion—its elements strongly belong together—and low coupling—its relationships with other modules are limited, explicit, and stable.

Domain-Driven Design

Domain-driven design (DDD) places business concepts and rules at the centre of software design. It is particularly useful in complex environments where terminology, policies, and workflows differ between organisational areas.

Important DDD concepts include:

• Domain: the business area under consideration.
• Subdomain: a meaningful part of the domain, such as underwriting within insurance.
• Core domain: the area that provides distinctive competitive value.
• Supporting subdomain: important but not strategically differentiating capability.
• Generic subdomain: capability that can often be purchased or adopted as a standard service.
• Bounded context: a boundary within which a model and its terminology have consistent meaning.
• Ubiquitous language: shared terminology used by domain experts and developers.
• Aggregate: a consistency boundary containing related objects and rules.
• Anti-corruption layer: an adapter that prevents an external or legacy model from contaminating the internal domain model.

A customer in marketing, billing, fraud management, and logistics may not be the same conceptual entity. Treating all uses as one globally shared “Customer” object often creates excessive coupling and conflicting ownership. Bounded contexts allow each area to maintain a model appropriate to its responsibilities, with explicit translation between contexts.

The objective is not to create as many services as possible. It is to align boundaries with business responsibility, change patterns, data ownership, and transactional consistency. A boundary that separates parts of one rapidly changing transaction may be harmful; a boundary that isolates independently governed capabilities may be beneficial.

4. Integration Styles and Interaction Patterns

Point-to-Point Integration

In point-to-point integration, each application connects directly to another. It is initially simple and may be suitable for a small number of stable integrations. However, the number of potential connections grows rapidly as participants increase. With n applications, the maximum number of undirected pairwise connections is:

This is a combinatorial upper bound, not a prediction of actual interfaces. It assumes every pair may require one direct connection and ignores direction, protocol multiplicity, and shared platforms. For 10 applications, the maximum is 10 × 9 ÷ 2 = 45 connections. The example illustrates why uncontrolled point-to-point growth becomes difficult to govern.

Hub-and-Spoke and Enterprise Service Bus

A hub-and-spoke model places a broker or integration hub between systems. It can centralise routing, transformation, monitoring, and policy enforcement. An enterprise service bus (ESB) is a common implementation of this idea. Its strengths include mediation and central governance; weaknesses include central bottlenecks, complex shared configuration, and the risk that business logic becomes hidden inside the integration layer.

API-Led Integration

API-led architecture exposes reusable capabilities through APIs, often organised into system, process, and experience layers. APIs should have explicit contracts, ownership, versioning rules, authentication, rate limits, error semantics, and lifecycle policies. An API gateway can provide routing, authentication, throttling, and observability, but it should not become an ungoverned repository for business logic.

A well-designed API is more than an endpoint. It specifies resources or operations, data schemas, preconditions, postconditions, error behaviour, idempotency, security controls, and compatibility expectations. Idempotency is important when retries are possible: repeating the same request should not create an unintended duplicate effect. For example, a payment request may use a client-supplied idempotency key.

Event-Driven Integration

In event-driven architecture, a producer publishes an event and consumers react to it. A broker or event platform may retain events, route them to subscribers, and support replay. Events promote temporal decoupling and enable multiple consumers to respond independently.

However, events create obligations. Producers must define event meaning and schema evolution. Consumers must tolerate duplicates, out-of-order delivery, and delayed delivery where applicable. Systems need dead-letter handling, replay procedures, monitoring, and reconciliation. An event should normally describe a fact that has occurred rather than issue an opaque command disguised as a fact.

Synchronous and Asynchronous Communication

Synchronous calls are appropriate when the requester requires an immediate response and the dependency is sufficiently reliable. Asynchronous messaging is appropriate when work can be deferred, load should be smoothed, or producer and consumer availability should be decoupled. Hybrid designs are common: an order API accepts a request synchronously, while fulfilment, notification, and analytics proceed through events.

5. Services, Microservices, and Distributed Systems

Service-oriented architecture structures capabilities as services with explicit contracts. Microservices are a more fine-grained architectural approach in which independently deployable services are commonly aligned with bounded contexts or business capabilities. The distinction is not simply service size. Microservices usually imply independent deployment, decentralised data ownership, automated delivery, operational autonomy, and strong automation.

Microservices can provide:

• independent release of selected capabilities;
• scaling according to local demand;
• fault isolation when boundaries are well designed;
• team autonomy; and
• technology choice appropriate to a capability.

They also introduce:

• network latency and partial failure;
• distributed tracing and operational complexity;
• data consistency and transaction coordination problems;
• more deployment pipelines and runtime components;
• versioning and compatibility obligations; and
• increased requirements for platform engineering and skills.

A distributed transaction spanning many services should not automatically be solved with a two-phase commit protocol. In many business processes, a saga is more practical: a sequence of local transactions coordinated by events or an orchestrator, with compensating actions when later steps fail. Compensation is a business action, not necessarily a perfect reversal. A shipped item, for instance, cannot always be “unshipped” merely by writing a compensating database record.

The decision to adopt microservices should therefore be based on independent change, scaling, team boundaries, fault isolation, and domain complexity. Decomposing a stable, small application into numerous services may increase total cost without improving outcomes.

6. Interoperability and Coupling

Interoperability has at least three dimensions:

• Technical interoperability: systems can connect using compatible protocols and transport mechanisms.
• Syntactic interoperability: systems exchange data in mutually understood structures and formats.
• Semantic interoperability: systems interpret the exchanged information consistently.

A JSON message may be syntactically valid while semantically ambiguous. “Amount: 100” is incomplete without currency, precision, tax meaning, and whether it is gross or net. Canonical data models can reduce duplication, but an excessively universal model often becomes difficult to evolve. A better approach is frequently a small set of governed shared concepts plus explicit translation between bounded contexts.

Coupling can be analysed across several dimensions:

• Content coupling: one component depends on another’s internal data or implementation.
• Common coupling: components share mutable global data.
• Control coupling: one component controls another through flags or hidden instructions.
• Data coupling: components exchange only required data through an explicit contract.
• Temporal coupling: components must be available at the same time.
• Deployment coupling: components must be released together.
• Semantic coupling: components depend on shared interpretation of business concepts.

The architectural goal is not zero coupling. Useful systems must coordinate. The goal is intentional, visible, stable coupling at appropriate boundaries.

7. Legacy Modernisation

Legacy modernisation should begin with business outcomes and constraints, not with a wholesale technology replacement. Common strategies include:

1. Retain: continue operating with targeted risk controls.
2. Rehost: move the system to a new infrastructure environment with minimal code change.
3. Replatform: adopt a managed runtime or platform while preserving most application behaviour.
4. Refactor: change internal structure without changing externally visible behaviour.
5. Rearchitect: substantially alter the architecture to improve scalability, resilience, or modifiability.
6. Rebuild: create a replacement system, usually when the existing design is unsuitable.
7. Replace: adopt a package or external service.
8. Retire: remove the capability when it is no longer required.

The strangler pattern gradually places new functionality around a legacy core and routes selected capabilities to modern components. It reduces the risk of a “big bang” replacement but requires careful data ownership, routing, reconciliation, and eventual retirement planning. An anti-corruption layer can translate legacy codes, formats, and workflows into a modern domain model.

Common modernisation risks include reproducing legacy constraints in a new platform, underestimating data quality, losing undocumented business rules, and operating two systems indefinitely. Migration plans should define exit criteria, parallel-run duration, reconciliation controls, rollback conditions, and decommissioning responsibilities.

8. Build-versus-Buy Decisions

Build-versus-buy is a strategic decision about capability ownership, not merely a comparison of purchase price and development effort. Evaluation should consider:

• strategic differentiation and intellectual property;
• functional fit and process adaptability;
• total cost of ownership;
• implementation and integration effort;
• vendor viability and concentration risk;
• data portability and exit options;
• security, privacy, and regulatory compliance;
• upgrade model and release control; and
• internal skills and long-term operating capability.

A simplified total-cost model is:

Where C_acq is acquisition cost, C_impl implementation cost, C_int integration and migration cost, C_run operating cost over the evaluation period, C_change enhancement and organisational-change cost, and C_exit exit or replacement cost. All terms must use the same currency, time horizon, and treatment of taxes and discounting. This model is a planning approximation; a rigorous investment case may discount future cash flows and include risk-adjusted scenarios.

Buy is often appropriate for generic capabilities such as payroll or standard expense management. Build may be justified for a core capability that differentiates the organisation and cannot be adequately represented by a product. Hybrid strategies—buying a platform and building extensions around stable APIs—are common, but extensions should not undermine upgradeability.

9. Security, Governance, and Responsible Integration

Every interface expands the attack surface. Controls should include strong identity, least-privilege authorisation, encryption in transit and at rest, secret management, input validation, schema validation, replay protection where necessary, rate limiting, and comprehensive audit trails. API keys alone are insufficient for high-risk operations unless supported by appropriate identity and authorisation controls.

Governance should define:

• approved integration patterns and technology standards;
• API and event ownership;
• naming, schema, versioning, and deprecation rules;
• data classification and retention requirements;
• service-level objectives and support responsibilities;
• observability and incident-management expectations; and
• architecture decision records and exception processes.

Privacy must be designed into integration flows. Data minimisation, purpose limitation, access control, retention, and deletion obligations should be considered before replicating personal data into event streams, caches, logs, or analytics platforms. Sensitive data should not be placed casually in diagnostic logs or immutable event stores.

AI-enabled applications introduce additional integration concerns. AI services may require model versioning, prompt and data governance, provenance, human oversight, bias monitoring, and protection against prompt injection or sensitive-data leakage. An AI service should be treated as an evolving dependency whose output may be probabilistic; contracts must specify confidence, fallback, review, and audit expectations where decisions affect people.

10. Applied Case: Modernising a Regional Insurance Enterprise

The following is an illustrative case.

Background

A regional insurer operates separate policy administration, claims, billing, broker, and customer-portal systems. The policy system is a twenty-year-old mainframe application. Claims data is exchanged with partners through nightly files. The customer portal directly queries several internal databases, and each business unit maintains its own customer identifiers.

Problem

Customers receive inconsistent policy information, claims status updates are delayed, and regulatory reporting requires manual reconciliation. The mainframe is reliable but difficult to change. The organisation considers replacing it entirely with a cloud-native microservices platform.

Analysis

Portfolio assessment identifies policy administration as high business value and high technical constraint. Billing and claims contain valuable domain logic but have different change rates and data ownership. The portal’s direct database access creates high coupling and exposes internal schemas. The proposed total replacement has high migration risk because rules are distributed across code, batch jobs, and operational procedures.

Domain workshops identify bounded contexts for policy, claims, billing, customer interaction, and partner exchange. “Customer” is not made into one universal database object; instead, a controlled identity relationship links context-specific representations. Policy and claims teams define separate models and explicit translation rules.

Approach and Solution

The insurer adopts a staged modernisation plan:

1. An API façade is placed around selected mainframe capabilities.
2. The portal is changed to use APIs rather than direct database access.
3. Policy events such as Policy Issued and Policy Cancelled are published after controlled state changes.
4. A modern claims-workflow service is introduced for new digital claims, while the mainframe remains the system of record for selected policy functions.
5. An anti-corruption layer translates legacy codes and date formats.
6. Reconciliation reports compare legacy and modern records during the transition.
7. Partner file exchanges are gradually replaced with authenticated APIs and event subscriptions.
8. Retirement milestones are defined for each displaced batch job and database interface.

Outcome

Portal changes no longer require access to internal database schemas. Claims notifications become near-real-time, while financial settlement remains controlled by billing. The insurer avoids an unsafe big-bang migration and obtains evidence about operational behaviour before further decomposition.

Learning Points

The case illustrates that modernisation is a portfolio and domain problem as much as a technology problem. APIs can reduce exposure, events can decouple notification, and bounded contexts can clarify ownership. Nevertheless, the legacy system remains a risk until interfaces, data, operational procedures, and retirement criteria are addressed together.

11. Contemporary Developments and Best Practices

Current enterprise architecture increasingly combines API management, event streaming, cloud platforms, platform engineering, containers, and automated delivery. Service meshes may provide traffic management, identity, and telemetry, but they do not correct poor business boundaries. Internal developer platforms can standardise deployment and observability, but they must not conceal governance responsibilities.

Best practices include:

• start with capabilities, value streams, and quality attributes;
• make ownership explicit for every API, event, schema, and data set;
• prefer contract-first design and automated compatibility testing;
• use versioning and deprecation policies rather than indefinite backward compatibility;
• design for retries, duplicates, timeouts, partial failure, and recovery;
• maintain end-to-end observability across synchronous and asynchronous flows;
• keep business rules in appropriate domain components rather than accidental middleware;
• use evolutionary modernisation with measurable exit criteria;
• test interoperability semantically, not only syntactically;
• assess total cost, exit risk, and organisational capability in sourcing decisions; and
• review ethical, privacy, security, and regulatory implications throughout the lifecycle.

Chapter Summary

Application and integration architecture connects business capabilities to executable software and controlled interactions. Portfolio evaluation should consider value, technical health, cost, risk, and strategic fit rather than isolated technology preferences. Modularity depends on high cohesion, controlled coupling, clear ownership, and stable contracts. Domain-driven design provides bounded contexts, ubiquitous language, aggregates, and anti-corruption layers for managing complex business domains.

Point-to-point, hub-and-spoke, API-led, event-driven, service-oriented, and microservice architectures each offer benefits and costs. APIs support explicit request-response contracts; events support temporal decoupling but require careful handling of duplicates, ordering, replay, and schema evolution. Microservices are justified by independent change, scaling, team autonomy, or fault isolation—not by fashion.

Legacy modernisation should be staged and outcome-focused. Rehost, replatform, refactor, rearchitect, rebuild, replace, retain, and retire are distinct strategies. Build-versus-buy decisions should include strategic differentiation, total cost of ownership, vendor risk, interoperability, data portability, and exit cost. Security, privacy, observability, governance, and responsible use of AI must be designed into the integration architecture rather than added after implementation.

Key Terms

Application architecture: Structure, responsibilities, interactions, and quality attributes of software applications.

Application portfolio: Collection of applications managed as an investment and risk portfolio.

API: Defined interface through which software exposes operations or data.

Event: A record that a significant fact has occurred.

Service: A software capability offered through a defined contract.

Modularity: Division of a system into cohesive units with controlled dependencies.

Cohesion: Degree to which elements within a module belong together.

Coupling: Degree of dependency between modules or systems.

Bounded context: Boundary within which a domain model and terminology have consistent meaning.

Ubiquitous language: Shared domain vocabulary used by technical and business participants.

Aggregate: Domain consistency boundary containing related objects and rules.

Anti-corruption layer: Translation boundary protecting one domain model from another.

Interoperability: Ability of systems to exchange and use information effectively.

Eventual consistency: State in which replicas become consistent after propagation delay.

Microservice: Independently deployable service commonly aligned with a business capability or bounded context.

Strangler pattern: Incremental replacement of legacy functionality by surrounding and redirecting it to new components.

Total cost of ownership: Acquisition, implementation, operation, change, integration, and exit costs over a defined period.

Idempotency: Property whereby repeating an operation does not create unintended additional effect.

Review Questions

Short Answer Questions

1. Distinguish an API from an event.
2. What is a bounded context, and why is it useful?
3. State two advantages and two risks of microservices.
4. Name four common legacy-modernisation strategies.
5. Why is semantic interoperability more demanding than syntactic interoperability?

Long Answer Questions

1. Explain a comprehensive framework for evaluating an enterprise application portfolio.
2. Compare point-to-point, hub-and-spoke, API-led, and event-driven integration.
3. Discuss how coupling, cohesion, data ownership, and deployment independence influence service boundaries.
4. Explain how domain-driven design can guide application decomposition in a complex enterprise.
5. Analyse the factors that should be included in a build-versus-buy decision.

Analytical / Application Questions

1. An organisation has 12 applications and is planning direct integrations between every pair. Calculate the maximum number of undirected pairwise connections and explain why this may be architecturally undesirable.
2. A legacy claims system is reliable but difficult to change, while a new digital channel requires near-real-time status updates. Propose a staged modernisation architecture and identify its principal risks.
3. A proposed microservice design places policy creation, billing, notifications, and reporting in separate services, all sharing one database. Critically evaluate the design and recommend improvements based on domain boundaries, data ownership, and operational coupling.

Multiple Choice Questions with Answers

Question 1

Which characteristic best distinguishes an event from a typical API request?

A. An event communicates that something has happened

B. An event always requires a synchronous response

C. An event must directly access the consumer database

D. An event eliminates the need for schema governance

Correct Answer: A. An event communicates that something has happened

Question 2

For 10 applications, what is the maximum number of undirected pairwise connections if every application could connect directly to every other application?

A. 20

B. 45

C. 90

D. 100

Correct Answer: B. 45

Question 3

What is the primary purpose of an anti-corruption layer?

A. To increase database storage capacity

B. To prevent one domain model from contaminating another

C. To eliminate all asynchronous communication

D. To replace identity and access management

Correct Answer: B. To prevent one domain model from contaminating another

Question 4

Which situation most strongly supports using asynchronous integration?

A. The requester must receive an immediate authoritative answer

B. The producer and consumer should not need to be available simultaneously

C. The interaction requires a single local database transaction

D. The interface has no defined data contract

Correct Answer: B. The producer and consumer should not need to be available simultaneously

Question 5

Which factor is least appropriate as the sole basis for a build-versus-buy decision?

A. Strategic differentiation

B. Vendor exit risk

C. Purchase price alone

D. Integration and operating cost

Correct Answer: C. Purchase price alone

Question 6

What is a principal risk of excessive point-to-point integration?

A. It guarantees semantic consistency

B. It removes all dependency management

C. The number of interfaces and dependencies becomes difficult to govern

D. It prevents any system from communicating

Correct Answer: C. The number of interfaces and dependencies becomes difficult to govern

Question 7

Which statement about microservices is most accurate?

A. They are justified solely because they use containers

B. They always reduce total cost and operational complexity

C. They can support independent deployment but introduce distributed-system complexity

D. They require every service to share one database

Correct Answer: C. They can support independent deployment but introduce distributed-system complexity

Question 8

In the illustrative insurance case, why was an API façade placed around selected mainframe capabilities?

A. To expose internal database schemas directly to customers

B. To reduce direct coupling while enabling incremental modernisation

C. To eliminate the need for data reconciliation

D. To force an immediate replacement of the mainframe

Correct Answer: B. To reduce direct coupling while enabling incremental modernisation

Question 9

Which dimension of interoperability concerns whether exchanged information has the same meaning to both systems?

A. Technical interoperability

B. Syntactic interoperability

C. Semantic interoperability

D. Physical interoperability

Correct Answer: C. Semantic interoperability

Question 10

Which item should be included in a total-cost-of-ownership assessment?

A. Only the initial licence fee

B. Only the development team’s salary

C. Acquisition, operation, change, integration, and exit costs

D. Only the number of software features

Correct Answer: C. Acquisition, operation, change, integration, and exit costs