Sparx EA gives modernisation program teams the governed architecture they need to plan legacy system transformation with confidence: a complete current-state application landscape, dependency mapping, risk profiling, target architecture, and an EA GraphLink-powered migration dashboard that keeps executives informed without requiring them to open the EA tool.
IT modernisation is one of the highest-volume, highest-stakes EA consulting engagements in both public and private sectors. The promise is compelling: replace ageing mainframe systems, unsupported platforms, and monolithic applications with cloud-native, API-first, microservices architectures that are faster, cheaper, and more capable. The reality is that modernisation programs fail: chronically, expensively, and painfully: for a consistent set of reasons: unknown system dependencies, insufficient documentation of the current state, underestimation of integration complexity, and the catastrophic surprise of an application that was supposed to be straightforward turning out to be deeply entangled with fifteen other systems. Sparx EA addresses these failure modes directly. This article explains how enterprise architects can use Sparx EA to build the current-state foundation for a modernisation program, design the target architecture, apply modernisation patterns, and give executives live program visibility through EA GraphLink.
Key Takeaways
- IT modernisation programs fail primarily because the current-state architecture is insufficiently understood before transformation begins.
- Sparx EA builds the current-state application landscape at the Application layer: every application, every dependency, every integration: creating the architectural foundation that modernisation planning requires.
- Tagged values on Application Components capture End-of-Support dates, vendor support status, and total cost of ownership: making legacy risk visible and quantified.
- The Strangler Fig and Cloud-First reference architecture patterns are modeled in Sparx EA as reusable Architecture Building Blocks.
- EA GraphLink enables executives to query modernisation program status in real time via Copilot/Kernaro.
The Legacy Landscape: Why Modernisation Is So Hard
Modern enterprises: public sector organizations, financial institutions, healthcare systems, manufacturers, insurers: carry decades of accumulated IT investment. The legacy landscape is characterized by:
Monolithic applications: Large, tightly coupled applications that combine business logic, data access, and presentation in a single deployable unit. Changing one part requires testing the whole. Scaling requires scaling everything. Examples: COBOL mainframe applications handling core banking or benefits administration, Oracle Forms/Reports applications running financial management or HR, SAP ECC installations that have been customized beyond recognition over twenty years.
Unsupported platforms: Applications running on platforms that have reached End of Support: Windows Server 2003, Oracle database versions no longer patched, middleware products whose vendors have ceased trading. These platforms carry unmitigated security vulnerabilities and cannot run in PCI-DSS or FedRAMP-compliant environments.
Proprietary databases: Custom database formats, flat-file systems, or obsolete database products (dBase, FoxPro, CA-IDMS) that cannot be accessed by modern tools without custom adapters.
Critical but undocumented integrations: Point-to-point integrations built by developers who have since left the organization, connecting systems that appear unrelated but share critical data flows. These are the dependencies that cause unexpected failures when a system is decommissioned.
Vendor-locked technology: Applications built on technology stacks that a single vendor controls, creating lock-in at the licensing, support, and skills levels simultaneously.
The combination of these characteristics creates a modernisation environment where the first risk is not technical: it is informational. Program teams do not know what they are dealing with. They cannot inventory the systems accurately, they cannot enumerate the dependencies, and they cannot estimate the scope of the migration because the current state is not documented.
Building the Current-State Application Landscape
The foundational deliverable of any IT modernisation program is a comprehensive, accurate current-state application landscape. In Sparx EA, this is built at the Application layer using ArchiMate notation.
Application Components represent every discrete application in the estate. The inventory is populated from multiple sources: IT service management tool (ServiceNow, Jira Service Management) CI database, vendor contract registers, infrastructure monitoring data (AppDynamics, Dynatrace), and application team interviews. Each Application Component carries tagged values that make the legacy risk visible:
Application NameandVendorVersionandRelease: is this version still supported?End of Vendor Support Date: when does the vendor stop providing security patches?Hosting Model: On-Premises / Colocation / IaaS / SaaS / PaaSPrimary Language/Platform: COBOL/IBM z/OS, C++/Solaris, .NET Framework 4.5, Java 8, etc.Annual Cost: licensing plus infrastructure plus supportBusiness Criticality: Critical / High / Medium / LowModernisation Status: Current / Legacy / End of Life / In Migration / DecommissionedTarget Disposition: Retire / Replace / Re-platform / Re-architect / Retain
Application Interfaces represent integration endpoints: REST APIs, SOAP web services, message queue connections, file-based interfaces (FTP, SFTP, AS2), database-level integrations (direct SQL queries across database boundaries), and legacy integration (MQSeries, IBM DataPower, TIBCO).
Data Flow relationships connect Application Interfaces, labeled with the data being exchanged and the integration technology. These data flows reveal the hidden dependency web: the application that appears isolated on an org chart is, architecturally, deeply connected to six other systems.
Dependency Mapping: The Core Risk Management Activity
The most valuable output of the current-state landscape exercise is the dependency map. In Sparx EA, ArchiMate Usage relationships (Application Component A uses the services of Application Component B) and Access relationships (Application Component A reads/writes Data Object B) create a complete dependency graph.
This dependency graph answers the questions that derail modernisation programs when they cannot be answered:
- “If we decommission the mainframe policy administration system, which other systems will break?”: answered by tracing Usage relationships from the PAC to all dependent Application Components.
- “Which systems read directly from the legacy Oracle database?”: answered by tracing Access relationships from the Oracle database Data Object.
- “What is the impact of the Windows Server 2003 application going offline?”: answered by tracing the data flows from the WS2003 application to all downstream consumers.
In Sparx EA, the dependency graph can be visualized as an Application layer diagram showing all downstream dependencies of a target decommission: making the impact scope visible before the decommission decision is made, not after.
Tagged values on Usage relationships record the dependency type: Dependency Type = Hard (the consuming application cannot function without the dependency) / Soft (the consuming application can function with degraded capability) / Temporal (dependency is time-based, e.g., nightly batch). Hard dependencies must be resolved before decommissioning; soft dependencies can be managed with fallback procedures.
Risk Profiling: Quantifying Legacy Debt
The tagged values on Application Components enable risk profiling: a structured assessment of the risk each legacy system represents to the organization.
A risk heat map generated from Sparx EA data (via EA GraphLink to Power BI) shows:
- 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 EOS, high cost) are the highest-priority modernisation candidates. This view provides the investment prioritisation rationale: not “we should modernize because modernisation is good” but “these five systems carry critical business functions, lose vendor support in 18 months, and cost $4M per year to run, making them the highest-priority modernisation investments.”
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 models the target state as a separate architecture version: either a parallel package or a Scenario: allowing as-is and target states to be compared.
Cloud-First Reference Architecture: The target architecture typically adopts cloud-native patterns. In Sparx EA, a Cloud-First reference architecture is modeled as a set of Architecture Building Blocks (ABBs): API Gateway (Application Component), Microservices Runtime (Kubernetes/ECS: Technology Node), Event Bus (Kafka/EventBridge: Application Component), Managed Database Services (RDS/Cosmos DB: Technology Node), Identity Provider (Azure AD/Okta: Application Component), and CI/CD Pipeline (GitHub Actions/Azure DevOps: Technology Node). These ABBs are the approved building blocks for new application architecture: architects selecting target state components use the ABB library rather than making unconstrained choices.
Strangler Fig Pattern: The Strangler Fig is the preferred modernisation pattern for large monolithic applications that cannot be rewritten in a single program. New functionality is built as modern microservices that “strangle” the monolith: gradually replacing its capabilities while keeping it running. In Sparx EA, the Strangler Fig is modeled as a Transition Architecture: the monolith continues as an Application Component, new microservices are added as separate Application Components, and an API Gateway (or Backend for Frontend) routes requests to the appropriate service based on business capability. Work Packages represent each capability extraction: the sequence by which functionality migrates from the monolith to the modern service.
Big Bang vs Incremental: The architecture decision between replacing a system all-at-once (Big Bang) or incrementally (Strangler Fig or phased migration) is documented as an Architecture Decision element in Sparx EA with the decision rationale and key constraints. Most programs favor incremental: Big Bang migrations carry the highest execution risk: but for simple, low-criticality systems, a clean replacement may be the most pragmatic approach.
The Migration Roadmap
The transformation roadmap is built in the Implementation and Migration layer as a series of Work Packages arranged in waves or phases. Dependency relationships between Work Packages make sequencing logic explicit and auditable.
A typical modernisation roadmap structure:
Phase 0 (Months 1–3): Foundation
- Establish cloud landing zone (target platform infrastructure)
- Implement identity and access management modernisation
- Stand up CI/CD pipeline and DevSecOps toolchain
Phase 1 (Months 3–9): Quick Wins
- Retire/replace low-criticality EOS systems (re-platform to SaaS or cloud IaaS)
- Migrate first candidate microservice from the primary monolith
Phase 2 (Months 9–24): Core System Modernisation
- Strangler Fig extraction for 3–5 core business capabilities from the monolith
- Legacy database migration (proprietary DB → PostgreSQL/RDS)
- Integration modernisation (point-to-point → API/event-driven)
Phase 3 (Months 24–48): Transformation Completion
- Monolith decommission (once all capabilities extracted)
- Remaining legacy system retirements
- Technical debt remediation
Each Work Package is linked to: the Application Components being deployed or retired, the integrations being replaced, the Business Processes being enabled or improved, and the risk profile elements being resolved (EOS dates being addressed, cost savings being realized).
EA GraphLink: Executive Modernisation Dashboard
EA GraphLink connects the Sparx EA modernisation model to Power BI and AI interfaces. Executive sponsors and steering committee members can monitor program progress without opening the EA tool:
- Modernisation Heat Map: Live view of the application portfolio coloured by modernisation status (Current/Legacy/End of Life/In Migration/Decommissioned)
- Cost Savings Tracker: Actual decommissions against plan, with realized cost savings cumulated
- Dependency Resolution: How many hard dependencies remain unresolved for target decommissions
- Phase Completion: Work Package progress by phase and wave
Copilot/Kernaro queries: “What is blocking the mainframe decommission?” returns the specific dependency Work Packages not yet complete. “How much annual cost have we retired from the legacy portfolio this year?” returns the sum of Application Component annual costs where Modernisation Status = Decommissioned and decommission date is within the current year.
FAQ
Q1: How do we handle applications with no available documentation for the current-state assessment? Undocumented applications are common in legacy estates. Discovery approaches include: infrastructure scanning tools (ServiceNow Discovery, Azure Migrate Assessment, AWS Migration Hub) that detect applications from network and server inventory; integration engine analysis (examining active channels in MuleSoft, TIBCO, or IBM DataPower); application team interviews; and network traffic analysis (packet capture or flow analysis to identify active communication between systems). Sparx EA can be populated iteratively as discovery progresses: partial information is better than no information.
Q2: What is the right level of detail for the current-state application landscape? The current-state landscape needs enough detail to support the key modernisation decisions: which systems to retire first, which dependencies must be resolved before decommissioning, and which systems are safe to isolate. This typically means: every application as an Application Component, every significant integration as a Data Flow, and every system running on EOS platforms clearly tagged. It does not mean documenting every API endpoint or every data field: that level of detail belongs in integration design specifications, not the EA model.
Q3: How does Sparx EA handle applications hosted by third-party managed service providers or SaaS vendors? Third-party hosted applications are modeled as Application Components with Hosting Model = MSP / SaaS tagged values. Integration dependencies are modeled normally: the fact that an application is externally hosted does not change the dependency relationships. For SaaS applications, the modernisation disposition is typically “Retain” (SaaS applications are inherently cloud-native) unless the SaaS vendor is itself at risk of business failure or capability decline.
Q4: How do we manage the transition architecture as the program progresses? Transition architectures: the intermediate states between as-is and target: are managed in Sparx EA as dated architecture baselines. A baseline is created before each major phase begins, recording the state of the architecture at that point. As Work Packages complete and the architecture changes, the live model reflects the new state. Comparing the current model to a previous baseline shows what has changed: useful for stakeholder communication and program assurance.
Q5: What is the typical timeline for building a comprehensive current-state landscape for a mid-sized enterprise? A mid-sized enterprise with 100–300 applications can typically build a comprehensive current-state landscape in six to twelve weeks, depending on the quality of existing documentation, the availability of application owners for interviews, and the accessibility of the integration engine for active channel analysis. Sparx Services’ Discover engagement delivers this as a defined output, with a structured discovery methodology that maximises accuracy and completeness within the agreed timeframe.
Q6: How does technical debt quantification work in Sparx EA? Technical debt in Sparx EA is captured through tagged values: Technical Debt Score (1–5 scale, assessed by the architecture team), Technical Debt Description (a brief description of the primary debt items), and Estimated Remediation Cost (where available). These tagged values feed a Power BI technical debt dashboard via EA GraphLink, showing the distribution of technical debt across the application portfolio and the estimated investment needed to address it. This quantification supports the business case for modernisation investment.
Q7: What happens to the Sparx EA model after the modernisation program completes? The Sparx EA model does not end with the program: it becomes the living architectural baseline for the modernized estate. The target architecture becomes the new as-is, and subsequent changes to the application landscape are governed through the model. This ongoing governance value is a key reason to invest in Sparx EA for modernisation programs: unlike a one-time migration tool, EA pays dividends throughout the lifecycle of the modernized estate.
Q8: What Sparx Services engagements support IT modernisation programs? Most modernisation programs start with Discover (building the current-state landscape and risk profile), followed by Connect (building the target architecture and migration roadmap, and activating the EA GraphLink migration dashboard). For organizations that need ongoing architecture governance through a multi-year modernisation program, the Amplify engagement builds internal EA capability alongside the program delivery. Total investment for a full program architecture capability is typically $75,000–$245,000 depending on scale and duration.
Work With Sparx Services
IT modernisation programs need architecture, not just project management. Sparx Services’ Discover engagement builds the current-state foundation: a complete application landscape, dependency map, and risk profile: that every modernisation program needs before making a single transformation decision.
Connect then builds the target architecture and EA GraphLink migration dashboard.
Discover from $25,000 | Connect from $50,000. Contact us to discuss your modernisation program.
