IT Modernisation Architecture: Planning Legacy System Transformation with Sparx EA

The short version: modernisation programs rarely fail on the technology — they fail because nobody mapped the current state first. Sparx EA gives a program team the governed foundation it needs before a single system is touched: a complete current-state application landscape, a dependency map that shows what breaks when something is retired, a risk profile that quantifies legacy debt, and a target architecture and sequenced roadmap that survive contact with reality.

IT modernisation is one of the highest-volume, highest-stakes enterprise architecture engagements in both the public and private sectors. The promise is easy to sell — replace ageing mainframes, unsupported platforms, and monolithic applications with cloud-native, API-first services that are faster, cheaper, and more capable. The execution is where it comes apart. Programs run over budget and over schedule for a predictable set of reasons: unknown system dependencies, a current state nobody documented, integration complexity that was never estimated, and the application that was supposed to be a quick win turning out to be entangled with fifteen others.

This piece walks through how architects use Sparx EA to attack those failure modes directly: building the current-state foundation, mapping dependencies, profiling legacy risk, designing the target, applying modernisation patterns, and sequencing the migration so executives can see where the program actually stands.

The legacy landscape, and why modernisation is so hard

Mature enterprises — government departments, banks, health systems, manufacturers, insurers — carry decades of accumulated IT investment. A few characteristics show up again and again, and each one raises the cost of getting modernisation wrong.

• Monolithic applications. Large, tightly coupled systems that bundle business logic, data access, and presentation into one deployable unit. Changing one part means testing the whole; scaling one part means scaling everything. Think COBOL mainframe applications running core banking or benefits administration, Oracle Forms estates, or an SAP ECC install customized beyond recognition over twenty years.
• Unsupported platforms. Software running on platforms that have reached end of support — Windows Server 2003, unpatched Oracle versions, middleware from vendors that have ceased trading. These carry unmitigated security exposure and cannot run in PCI-DSS or FedRAMP-compliant environments.
• Proprietary data stores. Custom formats, flat-file systems, or obsolete products (dBase, FoxPro, CA-IDMS) that modern tools cannot read without bespoke adapters.
• Undocumented integrations. Point-to-point links built by developers who have long since left, quietly connecting systems that look unrelated but share critical data flows. These are exactly the dependencies that cause failures when a system is switched off.
• Vendor lock-in. Stacks controlled by a single vendor, creating lock-in at the licensing, support, and skills levels at once.

The first risk in modernisation, then, is not technical — it is informational. Teams cannot inventory the estate accurately, cannot enumerate the dependencies, and cannot scope the migration because the current state simply is not written down anywhere.

Building the current-state application landscape

The foundational deliverable of any modernisation program is an accurate current-state landscape. In Sparx EA, that is built at the application layer using ArchiMate notation.

Application Components represent every discrete application in the estate. The inventory is populated from several sources: the CMDB in an ITSM tool such as ServiceNow or Jira Service Management, vendor contract registers, infrastructure monitoring (AppDynamics, Dynatrace), and application-team interviews. Each component carries tagged values that make legacy risk visible and queryable:

• Application Name and Vendor
• Version / Release — is this version still supported?
• End of Vendor Support Date — when do security patches stop?
• Hosting Model — On-Premises / Colocation / IaaS / SaaS / PaaS
• Primary Language/Platform — COBOL/IBM z/OS, C++/Solaris, .NET Framework 4.5, Java 8, and so on
• Annual Cost — licensing plus infrastructure plus support
• Business Criticality — Critical / High / Medium / Low
• Modernisation Status — Current / Legacy / End of Life / In Migration / Decommissioned
• Target Disposition — Retire / Replace / Re-platform / Re-architect / Retain

Application Interfaces capture integration endpoints: REST APIs, SOAP web services, message-queue connections, file-based interfaces (FTP, SFTP, AS2), database-level integrations, and legacy middleware (MQSeries, IBM DataPower, TIBCO). Data Flow relationships then connect those interfaces, labeled with what is exchanged and over which technology. Those flows expose the hidden dependency web — the application that looks isolated on the org chart turns out to be architecturally wired into six others.

Dependency mapping: the core risk-management activity

The most valuable product of the current-state exercise is the dependency map. In Sparx EA, ArchiMate Usage relationships (Component A uses the services of Component B) and Access relationships (Component A reads or writes Data Object B) build a complete dependency graph.

That graph answers the questions that quietly derail programs when they cannot be answered:

• “If we decommission the mainframe policy administration system, what else breaks?” — answered by tracing Usage relationships from that component to every dependent one.
• “Which systems read directly from the legacy Oracle database?” — answered by tracing Access relationships from that Data Object.
• “What is the blast radius if the Windows Server 2003 application goes offline?” — answered by tracing data flows to every downstream consumer.

Visualized as an application-layer diagram, the graph makes the impact scope of a target decommission visible before the decision is made, not after. Tagged values on the Usage relationships record the dependency type — Hard (the consumer cannot function without it), Soft (it degrades but survives), or Temporal (time-based, e.g. a nightly batch). Hard dependencies must be resolved before decommissioning; soft ones can be managed with fallback procedures.

Risk profiling: quantifying legacy debt

Because the risk data lives in tagged values, it can be profiled — a structured assessment of how much risk each legacy system carries. A risk heat map built from the repository plots:

• X-axis: time to end of support (years remaining)
• Y-axis: business criticality (Critical / High / Medium / Low)
• Bubble size: annual cost (total cost of ownership)
• Bubble color: modernisation status (red = End of Life, amber = Legacy, green = Current)

Systems in the upper-left quadrant — high criticality, imminent end of support, high cost — are the highest-priority candidates. That single view replaces a vague case (“we should modernize because modernisation is good”) with a defensible one: “these five systems run critical business functions, lose vendor support in 18 months, and cost $4M a year to operate, which is why they go first.”

Target architecture: modern patterns in Sparx EA

With the current state documented, the target architecture defines what the modernized estate will look like. Sparx EA holds the target as a separate version — a parallel package or a scenario — so as-is and target can be compared side by side.

Cloud-first reference architecture. The target typically adopts cloud-native patterns, modeled as a set of reference-architecture building blocks: an API Gateway (Application Component), a microservices runtime such as Kubernetes or ECS (Technology Node), an event bus like Kafka or EventBridge (Application Component), managed database services (Technology Node), an identity provider (Application Component), and a CI/CD pipeline (Technology Node). These become the approved building blocks for new design — architects choose from the library rather than making unconstrained choices each time.

Strangler Fig pattern. For large monoliths that cannot be rewritten in one program, the Strangler Fig is the preferred architecture pattern: new functionality is built as modern services that gradually “strangle” the monolith, replacing its capabilities while it keeps running. In Sparx EA it is modeled as a transition architecture — the monolith stays as an Application Component, new microservices are added alongside it, and an API Gateway routes each request to the right service by business capability. Work Packages capture each capability extraction and the order in which functionality migrates off the monolith.

Big bang vs incremental. The choice between an all-at-once replacement and an incremental migration is recorded as an architecture decision record with its rationale and constraints. Most programs favor incremental — big-bang carries the highest execution risk — but for a simple, low-criticality system a clean replacement is often the pragmatic call.

The migration roadmap

The transformation roadmap lives in the Implementation and Migration layer as Work Packages arranged into waves. Dependency relationships between them make the sequencing logic explicit and auditable. A typical structure runs across four phases.

Each Work Package links to the Application Components being deployed or retired, the integrations being replaced, the business processes being enabled, and the risk elements being resolved — end-of-support dates addressed, cost savings realized — so the roadmap stays traceable back to the reasons each item exists.

Executive visibility without opening the tool

Most executive sponsors will never open Sparx EA, and they should not have to. Because every status field — modernisation status, dependency type, cost, criticality — is structured data in the repository, it can be surfaced to a BI dashboard or a portal that sponsors and steering committees actually use. Sparx EA reads from a standard SQL database when hosted on Pro Cloud Server, so a tool like Power BI can read the same model the architects maintain. The dashboards that matter on a modernisation program are usually four:

• Modernisation heat map — a live view of the portfolio colored by status (Current / Legacy / End of Life / In Migration / Decommissioned).
• Cost-savings tracker — actual decommissions against plan, with realized savings accumulated.
• Dependency resolution — how many hard dependencies remain for each target decommission.
• Phase completion — Work Package progress by phase and wave.

The point is not the reporting tool; it is that the architecture model is the single source the reporting draws from. When “what is blocking the mainframe decommission?” resolves to a specific set of incomplete dependency Work Packages — rather than a slide someone updated by hand last month — the program runs on evidence instead of optimism. (If you are weighing how a live data layer over the repository changes that picture, our application portfolio management work covers the same ground for the standing portfolio.)

FAQ

Where this fits

IT modernisation needs architecture, not just project management. Most programs start by building the current-state landscape and risk profile — the scored, evidence-based starting point our Paralysis to a Plan engagement is built to produce — before committing to a single transformation decision. From there, the target architecture, the migration roadmap, and the reporting layer follow. For organizations running a multi-year program, we also help build the internal EA capability to govern the modernized estate once the program ends, so the model keeps paying dividends long after the last system is retired.