Application Landscape

Most organisations of any size cannot answer basic questions about their own estate: how many systems there are, who owns each, what would break if one were switched off, and which are unsupported.

The landscape is the artefact that answers them, and its usefulness depends entirely on the attributes recorded rather than on the diagram.

The attributes that earn their keep: business owner and technical owner — separately, because they differ and both are needed; capabilities supported, which is what links it to the business layer; integrations, which is what makes impact analysis possible; lifecycle status — invest, maintain, retire, replace; technology currency, including whether components are still supported; cost; and users, since a system with three users and a large licence is a decision waiting to be made.

Two disciplines determine whether it stays true. Automate what can be automated — discovery from cloud accounts, dependency data from network flow logs and service catalogues — because a manually maintained inventory is stale within a quarter. And attach it to a process that keeps it current, such as requiring registration before a system can be deployed or granted network access.

An inventory nobody is required to update is a snapshot, not a landscape.