Skip to content

Application Landscape

Purpose

A connected view of the application estate showing how applications relate to one another. Where the capability map answers what the business does, the landscape answers what depends on what, which is the question that determines whether a migration wave is safe. The on-screen subtitle reads: "Circular interface map showing application-to-application relationships. Hover to highlight connections. Grouped by selected attribute."

Where to find it

Assess → Application Landscape

What you see

Cards

Total Applications, Connected, Isolated and Total Interfaces.

Chart

Application Relationship Landscape: the circular interface map. Hover over an application to highlight its connections.

Filters

  • Environment: All, plus the environment values present in the application data, for example Development, Production, Staging, Testing and UAT.
  • Business Unit
  • Criticality: All, High, Low or Medium.
  • Lifecycle Phase: All, Active, End of Life, Phase In, Phase Out or Plan.
  • Group By: Business Unit, Criticality, Environment, TIME Classification, Lifecycle Phase or Disposition (7Rs).

The screen also has a Reset button.

The screen has no grid and no forms. It has no wave or move-group overlay.

With no application relationships, the screen reads "No application relationships found. Import relationship data via Discover > CMDB."

Overview

Applications are rarely independent. One calls another. Those dependencies are what make migration waves difficult, because moving one half of a tightly coupled pair produces an outage that neither application's owner predicted.

The landscape view renders the connections between applications so that coupling is visible before it becomes a wave-planning problem. The relationships it draws come from application inference and from relationships recorded directly.

When to use this

  • Before finalising move groups, to check that tightly connected applications are not being split across move groups.
  • When assessing migration complexity, since a densely connected application is materially harder to move than an isolated one.
  • After accepting inferred dependencies on Suggested App-to-App, to see the new application-to-application relationships.

Key features

Why dependencies belong in the assessment, not the cutover

A rationalisation decision made about an application in isolation is a decision made without the constraint that will actually govern it. Two things change once dependency context sits alongside the assessment.

  • Applications that depend on one another cannot always be given independent dispositions, because retiring one may remove something another still relies on.
  • Applications that must move together are identified during assessment rather than during the cutover weekend, which is when the cost of finding out is highest.

Assess has four views, and each one can recommend the wrong thing on its own. See Why the four views are read together on the Application Portfolio page.

How to

Find applications that must move together

  1. Ensure application relationships exist. Run application inference, and work the Candidate Applications, Device Suggestions and Suggested App-to-App queues, before expecting a meaningful picture. You can also add relationships by hand on Discover → CMDB (the Relationship card), or load them in bulk with a CSV Import job whose Ci Class is Relationship. See Asset Relationships.
  2. Open the landscape. Go to Assess → Application Landscape.
  3. Narrow the view. If you need to, choose an Environment, Business Unit, Criticality or Lifecycle Phase.
  4. Identify the clusters. Choose a Group By attribute, then hover over an application to highlight its connections. Applications with dense interconnection need to move together, or be moved with a deliberate plan for the traffic that will cross between sites during the transition.
  5. Take the clusters into move group planning. A move group that splits a cluster is a move group that will produce cross-site latency or an outage.

Important fields

Field Description
Connected Card: a count of applications.
Isolated Card: a count of applications.
Total Interfaces Card: a count of interfaces.

Tips & best practices

An empty landscape usually means missing evidence, not an uncoupled estate

Very few real estates have genuinely independent applications. A sparse landscape is far more likely to mean inference has not run, its suggestions have not been accepted, or flow coverage is thin. Check the unknown-host findings before concluding the estate is simple.

Common mistakes

Planning waves from the capability map instead of the landscape

Grouping a wave by capability feels tidy and produces exactly the split-dependency problem this view exists to prevent.