Skip to content
Software Architecture Guide

Application Landscape Evolution Drivers

Explanation

Section titled “Explanation”

An application landscape is the set of applications a company runs. Drivers are the reasons that landscape changes.

Where drivers come from. A driver arises from a gap between a workload’s current state and the state the business wants. It is a specific, actionable reason for change. Typical high-level goals behind cloud-driven change are adopting AI, agility, innovation, cost reduction and resilience.

Standardization and consolidation. Companies often run duplicate or similar applications. Harmonization merges them. It uses capability mapping, which groups applications by function or value-added. Standardization reduces versions and variants. It phases out legacy systems in a targeted way. It also defines a target stack per area, with justified exceptions.

Cost. Landscape optimization aims to cut cost. Quick wins often sit in licenses, operations and support.

How drivers become evolution patterns. The driver guides which migration strategy fits.

  • Retire: decommission redundant, obsolete or low-value applications. This shrinks the landscape. It also removes cost and the security risk of unsupported components.
  • Replace (repurchase): switch to SaaS or AI solutions. The aims are simpler operations, freed development resources and lower maintenance, infrastructure and licensing cost.
  • Refactor: rework the application. Business demand for scale, faster releases and lower cost drives it.
  • Retain: keep the application in place, for example for compliance, data residency, risk or dependencies.

Portfolio view. The TIME model, as described by LeanIX, rates applications on technical and functional fit. It supports rationalizing the portfolio: Tolerate, Invest, Migrate, Eliminate. Strategy choices should be tied to documented goals and reviewed regularly, because business priorities change.

Example

Section titled “Example”

A company runs three order-entry tools after mergers. Cost reduction and standardization are the drivers. The team maps each tool to the capability it supports and picks one target tool. It retires the other two. It replaces a custom reporting tool with a SaaS product. One tool that holds regulated data stays in place. It stays for data residency reasons. The team reviews these choices each year against the company’s goals.

Trade-offs

Section titled “Trade-offs”

Drivers can conflict. Rehosting is fast and low-risk, but it carries technical debt forward. Problematic workloads should be modernized instead. Refactoring serves scale, speed and cost goals, yet it is the most complex strategy. That complexity clashes with speed and risk goals in large migrations. Security and compliance needs, such as data residency, can also block moving an application to the cloud. Make the priorities explicit and review them as goals change.

A driver guides the choice of strategy.

Diagram source 
flowchart LR
  D[Business driver: gap between current and desired state] --> S{Migration strategy}
  S -->|redundant or low value| R[Retire]
  S -->|cut custom maintenance| P[Replace with SaaS]
  S -->|scale, speed, cost| F[Refactor]
  S -->|compliance, dependencies| T[Retain]

Checks

Section titled “Checks”
  • Each planned landscape change is tied to a documented business goal or driver.
  • The chosen strategy per application (retire, replace, rehost, refactor, retain) is stated with its reason.
  • A target stack per area is defined, with justified exceptions.
  • Rehosted workloads with known problems have a modernization plan.
  • Strategy decisions are reviewed on a regular cycle against current goals.
Section titled “Related”

Sources

Section titled “Sources”