Enterprise architecture debt arises when architectural choices or accumulated misalignments constrain an organization’s ability to meet its goals or adapt. The consequences can span business processes, information, applications, and infrastructure.
How debt accumulates
A team may keep an older interface to meet a deadline. As more teams rely on it, future changes can require additional coordination, testing or rework. The initial decision may have been sensible under the constraints at the time. Its long-term effect depends on how the architecture evolves and whether the organization revisits the decision.
What does it cost to carry?
Principal is the effort or cost of addressing a debt item. Interest is the additional burden of carrying it, such as recurring manual checks or the extra effort required for future changes. Estimate both for a stated period or for a change scenario, and document uncertainty.
From observation to decision
Identify
Start with an observable issue, a stakeholder concern, or an EA smell. Check whether the observation reflects the architecture, the model, or the available evidence.
Characterize
Record the architectural objective, the element or decision that contributed to the debt, and the elements affected by it. Document where the impact appears and who experiences it. Read the published EA debt taxonomy.
Assess and manage
Describe the consequences and the effort to address them. Decide whether to accept, monitor, or address the debt. Assign an owner and a review point. Read the discovery and assessment study.
Related research
The terminology work develops a common vocabulary for EA debt. Work System Theory adds a way to reason about how people, processes, information, and technology shape its effects. Read the terminology paper or explore the Work System Theory article.
Investigate a smell · Find more publications · Try the debt register example.