Skip to content
Software Architecture Guide

Warning Signs of Poor Enterprise Architecture

Explanation

Section titled “Explanation”

Enterprise architecture (see “Enterprise Architecture”) describes how an organization’s business and IT fit together. When it is weak or missing, the effects show up in daily work. The signs below work as a checklist.

Duplicated capabilities. Different teams build the same business capability again and again, in slightly different forms. A business capability is something the organization can do, such as verifying a customer’s identity. One enterprise can end up with six implementations of one capability and almost no reuse. The engineering effort is duplicated too.

Disconnected systems and inconsistent solutions. Without an enterprise architecture practice, systems drift apart. Solutions become inconsistent with each other.

Fragile connections. Many point-to-point interfaces (direct links between two systems) make a landscape fragile. Each added interface makes the whole harder to maintain.

Kludges. A kludge is a quick workaround. It fixes today’s problem but leaves a fragile system behind.

Redundant systems after mergers. When two companies merge, their overlapping systems must share information or be consolidated. This exposes the missing shared architecture.

Root causes

  • Reuse often takes more effort than building new. Teams then build their own, so duplication becomes the default.
  • Organizations reward local optimization, where each unit improves only its own area. This leads to fragmentation.
  • No authoritative, up-to-date inventory of capabilities exists. Without one, nobody can find what already exists or see gaps. A capability map (see “Business Capability Map”) aims to fill this need.

Why it matters. Frameworks such as TOGAF (see “TOGAF”) promise a better return on investment, less future redundant spending, and faster, cheaper procurement. Spotting these symptoms early helps make the case for such a practice.

Example

Section titled “Example”

A bank has three business units. Each built its own customer identity check. They behave slightly differently. A new product team needs one, finds no list of existing ones, and builds a fourth. Meanwhile the units link their systems with many direct interfaces and patch gaps with quick scripts. Every change now risks breaking something. A shared capability inventory would have shown the existing checks.

Trade-offs

Section titled “Trade-offs”

The facts here cover only a subset of symptoms: duplication, fragility, and mergers. Other signs, such as slow regulatory response or manual data transfer, are not covered. A symptom also does not prove one single cause. Treat the list as a prompt for investigation, not a verdict.

How common root causes lead to duplication and fragile systems.

Diagram source 
flowchart LR
  A[Local optimization rewarded] --> B[Teams build their own]
  C[No shared capability inventory] --> B
  D[Reuse harder than building new] --> B
  B --> E[Duplicated capabilities]
  E --> F[Inconsistent solutions]
  E --> G[Fragile interfaces and workarounds]

Checks

Section titled “Checks”
  • The document or an inventory lists existing business capabilities, so teams can find and reuse them instead of rebuilding.
  • The number of point-to-point interfaces between systems is known and kept under control.
  • Known workarounds (kludges) are recorded as risks rather than left implicit.
  • Redundant systems, for example after a merger, have a plan to share information or consolidate.
Section titled “Related”

Sources

Section titled “Sources”