Application Architecture

Definition

Application architecture at the enterprise level is not the internal design of any one application. It is the map of which applications exist, which capability each supports, what data each owns, and how they integrate.

What the view is good for

• Duplication. Three applications maintaining customer records; two calculating tax; four sending email. Invisible from inside any one of them and obvious on the map.
• Ownership gaps. Applications with no owning team, which are the ones that fail unpatched.
• Integration sprawl. Counting point-to-point integrations is a useful proxy for coupling: if the number grows with the product of applications rather than their sum, the estate has an integration topology problem rather than an application problem.
• Data mastership. Which application is authoritative for each entity. Where the answer is "several" or "unclear", reconciliation problems and disputed reports follow.
• Gaps. Capabilities with no supporting application, usually being handled by a spreadsheet somebody maintains personally.

The properties worth recording per application

Keep it short, or it will not be maintained:

• Capability supported.
• Owning team.
• Data entities mastered.
• Lifecycle stage — invest, maintain, contain, retire.
• Business criticality.
• Integration points.

Anything beyond that is usually documentation for its own sake.

The lifecycle classification that drives decisions

• Invest — differentiating and actively developed.
• Maintain — necessary, stable, minimal change.
• Contain — no new investment; no new integrations; migrate consumers away.
• Retire — with a date and a plan.

Making the classification explicit is what stops "contain" applications quietly acquiring new dependencies, which is how a system scheduled for retirement in 2019 is still load-bearing.

Failure scenarios

• A catalogue with 400 attributes per application, unmaintainable and therefore unmaintained.
• No lifecycle classification, so everything is implicitly "maintain" forever.
• Data mastership unrecorded, so nobody can resolve conflicting numbers.
• The map produced for an audit and never used for a decision.
• Applications with no owner, discovered during a security incident.

Interview question

"You inherit an estate of 300 applications. What do you record about each, and what decision does it support?"