Software Architecture: Enterprise Architecture

This is the final part of the Software Architecture Series. Where Part 3 zoomed in on a single solution, Part 4 zooms back out to the level of the entire organization. Enterprise Architecture (EA) is the discipline that keeps a company's portfolio of solutions, data, and technology coherent across business units, geographies, and decades.

As a reminder, here are the four parts of the series:

• Part 1: Architecture Paradigms: Common architecture paradigms such as monolithic, microservices, and event-driven architectures.
• Part 2: Architecture Conventions and Principles: Best practices, principles like SOLID, and architectural patterns such as CQRS and the Repository Pattern.
• Part 3: Solution Architecture: Designing a solution that meets business needs and scales with the organization.
• Part 4: Enterprise Architecture: The broader perspective of system integrations, scalability, and the role of enterprise architecture in large organizations.

EA tends to be associated with frameworks like TOGAF, capability maps, and steering committees. The reality is that whether or not a formal EA function exists, every large organization has an enterprise architecture; the only question is whether it has been designed deliberately or has accumulated by accident.

Table of Contents

• The Four Domains of Enterprise Architecture
  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Technology Architecture
• Running Enterprise Architecture
  • Governance
  • Capability Mapping
• Conclusion
• Appendix: TOGAF ADM Phases

The Four Domains of Enterprise Architecture

TOGAF and similar frameworks divide enterprise architecture into four interlocking domains: Business, Data, Application, and Technology. Each domain has its own concerns, artifacts, and stakeholders, but the value of EA comes from keeping the four aligned. Decisions made in isolation - a new microservice here, a new product line there, a new BI tool somewhere else - tend to drift the organization unless someone is explicitly tracking how they fit together.

Business Architecture

Business architecture describes what the organization does and why. Its core artifacts are the operating model, value streams, business capabilities, organizational structure, and the strategic objectives that drive change. A business architect's job is to make these explicit so that downstream technical decisions can be tied to outcomes the business actually cares about.

Principles:

• Lead with capabilities, not org charts; capabilities outlast reorganizations.
• Express strategy as measurable outcomes (revenue, cost, risk, time-to-market) rather than aspirational statements.
• Reuse standard reference models (BIAN for banking, TM Forum for telco) where they fit; do not invent vocabulary unnecessarily.

Data Architecture

Data architecture defines how data is structured, owned, governed, and moved across the enterprise. It covers conceptual, logical, and physical data models; master and reference data; data lineage; and increasingly, data product ownership in domain-oriented patterns such as data mesh.

Principles:

• Define ownership before tooling; without an accountable owner, data quality decays no matter how good the platform is.
• Treat shared data (customer, product, employee) as enterprise assets, not application byproducts.
• Make data contracts explicit at domain boundaries, including freshness and quality SLAs.

Application Architecture

Application architecture catalogues the business applications in use, the capabilities they support, and the contracts between them. The goal is to know what each system does, who depends on it, and where rationalization or replacement opportunities exist.

Half of an enterprise architect's job is keeping a current map of what already exists. The other half is preventing two well-meaning teams from solving the same problem twice. - summary of EA practice

Principles:

• Track applications by the capability they support, not by the technology stack they happen to use.
• Use simple lifecycle categorisation (invest / sustain / tolerate / eliminate) to drive portfolio decisions.
• Avoid the "shadow IT" trap; uncatalogued applications still consume risk and budget.

Technology Architecture

Technology architecture deals with the underlying platforms, infrastructure, and standards that the application and data layers run on. This is where decisions about cloud strategy, networking, identity, observability, and developer platforms are made enterprise-wide rather than per project.

Principles:

• Codify "paved roads"; opinionated defaults that make the right choice the easy choice reduce variance more reliably than top-down mandates.
• Tier technology standards (mandatory, recommended, allowed, deprecated) so teams know exactly where they can deviate.
• Allocate explicit budget to retiring deprecated technology; without funded sunsetting, the standards drift.

Running Enterprise Architecture

Documenting domains is half the job. The other half is keeping the architecture current and influential as the organization changes. That happens through governance and capability mapping, the operational practices that turn EA from a documentation exercise into a decision-making function.

Governance

EA governance ensures that significant decisions are reviewed against the architecture's principles, standards, and target state. Mature EA functions run lightweight, decision-focused governance rather than heavy committee processes. The maturity of governance often correlates more with EA's perceived value than the quality of any individual diagram.

Principles:

• Govern decisions, not documents; the goal is to influence outcomes, not to bless artifacts.
• Make exceptions explicit and time-bound; the value of standards comes from how exceptions are managed.
• Place architects close to the work (embedded reviews, paved roads, office hours) rather than gating from the outside.

Capability Mapping

A capability map is a stable view of what the organization can do, organised hierarchically and independent of how those capabilities are currently delivered. It is the connective tissue between business strategy and technology investment, because it lets leaders ask "where do we have gaps, duplicates, or weak capabilities?" without first wading through systems and team structures.

Principles:

• Build the capability map at the right level of abstraction for the audience: L1/L2 for executives, L3 and below for architects and product teams.
• Score each capability against business importance and current effectiveness to prioritise investment.
• Refresh the capability map only when the business model changes, not when systems change; capabilities are stable, implementations are not.

Conclusion

Enterprise architecture is the practice of keeping an entire organization's business capabilities, data, applications, and underlying technology aligned over time. The four domains give EA its structure; governance and capability mapping give it operational traction. Done well, EA reduces duplication, accelerates strategic delivery, and makes the cost of complexity visible before it compounds.

This concludes the four-part Software Architecture Series. Across paradigms, conventions and principles, solution architecture, and now enterprise architecture, the consistent thread is that good architecture is mostly about making constraints, decisions, and trade-offs explicit so they can be managed deliberately rather than accidentally.

Appendix: TOGAF ADM Phases