Skip to main content

Foundationadvanced

Enterprise Architecture Fundamentals

Overview​

Enterprise architecture is the practice of making decisions that cross systems, teams and years — the ones no isolated team can make well, because the reach exceeds their field of view.

The problem it addresses is real: with nobody looking at the whole, each team optimizes locally, and the aggregate is worse than the sum of the parts.

The traditional way of practicing it — committees, documents, approvals — frequently produces more friction than value. Understanding why is a prerequisite for doing it differently.

Why This Matters​

The symptom of its absence is recognizable in any organization with more than a dozen systems:

the same data in six systems, each with its own version
four integrations doing the same thing in different ways
nobody knows what breaks if that system goes down
two initiatives building the same capability, unaware of each other
technology chosen by preference, with a multiplied operational cost

None of those is a team's fault. Each one made the reasonable choice within what it could see.

The cost appears diffusely — more integrations to maintain, more reconciliation, more time to understand what exists — and so it is rarely attributed to its cause.

Core Concepts​

Local optimization produces a bad aggregate​

Each team, optimizing its own result, produces decisions that summed cost dearly:

team A chooses database X, which it knows      → one technology to operate
team B chooses database Y, which it knows      → two
team C chooses database Z, which it knows      → three, and nobody masters any

No choice was wrong in isolation. The aggregate is an organization with three storage technologies, three bodies of operational knowledge, and three times the on-call cost.

Enterprise architecture's work is making that aggregate cost visible at the moment of the local decision — not necessarily prohibiting the choice.

The four layers​

The vocabulary that organizes the conversation:

business     capabilities, processes, actors
application  systems, and what each one does
data         information, ownership, flow
technology   infrastructure, platforms, technical standards

See business architecture, application, data and technology.

The layers' usefulness is allowing a conversation to happen at the right level. An investment discussion happens at the business layer; an integration one, at the application layer.

And the data layer is where the widest-reaching decisions live — information ownership and flow cross everything. See data ownership.

Why the reputation is bad​

Being direct, because the list is well known:

Distance from the code. Architects who do not build produce decisions that do not consider real constraints.

Documents nobody reads. Artifacts produced for a process, not for a reader.

Approving the inevitable. Committees that assess what has already been built.

An eternal target state. A three-year target revised annually, never reached.

Standards with no operationalization. Written rules that depend on somebody checking.

Authority by position. Influence that comes from the org chart, not from usefulness.

Each of those has an antidote, and they are this section's content.

The antidote is usefulness, not authority​

An enterprise architect who can only block has one tool and no influence. They get bypassed, and the work happens without them.

What generates real influence:

information nobody else has     the overview, the duplication, the aggregate cost
a paved road                    making the right choice the easiest one
early participation             being in the conversation before the decision
distributed credit              the team decides, architecture enables
hands in the work               building together, not only reviewing

The first line is the main asset: nobody outside that function has a view of the whole, and that information is genuinely useful to the teams.

The discipline is continuous, not a project​

The pattern that fails: hiring a consultancy, producing a set of artifacts, and filing them away.

Six months later, the model no longer describes reality, and nobody consults it.

What survives is what is used: a capability map consulted in the budget discussion, a system catalog fed by the pipeline, a technology radar reviewed quarterly.

An artifact with no use dies. See architecture documentation.

It is not the opposite of autonomy​

A common false opposition: either the teams decide, or there is enterprise architecture.

The design that works combines both: decisions go down as far as possible, and enterprise architecture handles what genuinely crosses — with constraints and criteria, not with case-by-case approvals. See architecture levels.

Common Mistakes​

Practicing it through authority. Blocking is the only tool, and it gets bypassed.

Producing artifacts with no reader.

Centralizing local decisions.

Treating it as a project with a start and an end.

Distance from the real work. Decisions that ignore implementation constraints.

Confusing it with control. The discipline exists to enable better decisions, not to make them in the teams' place.

Real-World Example​

A retail company with 90 systems hired a consultancy to establish enterprise architecture. The result, in eight months: a capability model, an application inventory, a three-year target state and a set of 40 standards.

Eighteen months later, none of that was used. The inventory was out of date, the target state had been superseded by two acquisitions, and the standards were cited only to block proposals.

The enterprise architecture function was seen by the teams as an obstacle.

The reformulation started from a different question: what information do the teams not have and would like to have?

The answers guided the work:

"I do not know who owns this data." A data ownership catalog was built, derived from the system inventory and maintained by the teams themselves.

"I do not know whether somebody already solved this problem." A register of architectural decisions per system, searchable, with what was decided and why.

"I do not know what breaks if I change this." A dependency map, derived from distributed tracing. See distributed tracing.

"I do not know how much this costs." Cost per capability, derived from resource tagging. See cost architecture.

None of those is an approval. All of them are information only the function with a view of the whole can produce.

The 40-item standards became 6 principles, and the rest became a paved road in the platform. See enterprise principles.

The three-year target state became a twelve-month direction, with an explicit transition architecture. See transition architecture.

The later assessment points out: the consultancy's work was not technically wrong. It was produced as a deliverable, and not as a continuous service to the teams — and so it died on delivery.

Practical Exercise​

Ask three teams in your organization: what information about the overview would you like to have and do not?

The answers define what the enterprise architecture function should be producing.

Interview Questions​

  • What problem does the discipline solve that no team solves alone?
  • Why is its reputation bad, and what corrects each cause?
  • Why does usefulness generate more influence than authority?

Further Reading​

  • Ross, Jeanne et al. Enterprise Architecture as Strategy. HBS Press, 2006.
  • Bente, Stefan et al. Collaborative Enterprise Architecture. Morgan Kaufmann, 2012.
  • Hohpe, Gregor. The Software Architect Elevator. O'Reilly, 2020.
Finished reading this document?Your progress is saved in this browser only.