A 20-week engagement combining Discover and Connect services to transform a stale spreadsheet-based application inventory into a live, governed EA repository with executive-accessible dashboards and AI-assisted portfolio querying.
Global financial services group. 20,000+ employees operating across 15 countries. The EA team comprised 12 architects responsible for applications, data, integration, and infrastructure architecture across the group.
The firm had grown significantly through acquisition: three sizeable acquisitions in the preceding six years, and the application landscape reflected that history. Each acquired entity brought its own technology stack, its own integration approach, and its own informal records of what software existed and what it did. The result was a technology estate that no one had a complete, current view of.
This engagement is anonymised. Metrics are as reported and confirmed by the client EA team.
The EA team knew they had a problem. Estimates put the application count above 800, but no one could say with confidence exactly what was running, what it did, or what it depended on. The official application portfolio lived in a spreadsheet that was updated quarterly, when architects had time, from whatever information they could gather from application owners and IT operations. By the time each update was complete, it was already out of date.
The EA team had Sparx EA installed. They were using it for project-level architecture work: individual initiative diagrams and integration designs. But there was no enterprise-level repository: no governed package structure, no consistent element tagging, no application inventory modeled in the tool. Sparx EA was being used as a diagramming tool rather than as a repository.
Executive pressure had been building. The CTO wanted a technology cost reduction program. The CFO wanted a view of application licensing exposure. The risk function wanted to understand which applications were approaching end of life or running on unsupported infrastructure. None of these questions could be answered from the existing documentation.
The fundamental challenge was not the size of the application estate: 800+ applications is manageable. The challenge was that documenting those applications in a way that supported rationalization decisions required solving three problems simultaneously.
First: repository governance. Without a governed MDG structure in Sparx EA, any data entered would become inconsistent quickly. Application records created by different architects would use different tagging conventions, different lifecycle status values, different capability-to-application relationship patterns. The result would be a repository that looked populated but couldn’t be reliably queried. Getting the MDG right before populating the repository was not optional.
Second: data collection at scale. Gathering accurate application data across 800+ applications in 15 countries, from application owners who had varying levels of information and incentives to share it, required a structured process. Ad hoc data collection produces incomplete, inconsistent records. The team needed a governed intake workflow.
Third: access and consumption. Even a well-governed, fully populated application repository delivers limited value if the only people who can query it are the architects who built it. The rationalization decisions that mattered were executive decisions. The risk reviews that needed to happen were happening in board-level risk committees. Architecture data needed to be in front of those audiences in formats they could actually use: not in EA diagrams, and not in quarterly PowerPoint reports.
These three problems had to be solved in sequence. There was no shortcut.
The engagement opened with a structured Discover assessment. Over six weeks, the Sparx Services team conducted:
The Discover output was a prioritized roadmap with three specific deliverables: an MDG design for the application portfolio, a data collection approach, and an access architecture connecting the Sparx EA repository to the executive stakeholders who needed it. The Connect engagement scope was defined in detail at the end of Discover.
The Connect engagement proceeded in three parallel streams.
Stream 1: Repository governance and data population (weeks 1–10)
Sparx Services designed and implemented MDG Technology stereotypes and tagged values covering the application portfolio: application lifecycle status, business capability mapping, technology risk classification, license type, business owner, and application-to-infrastructure dependency. A package structure was agreed and implemented. Import templates were built for bulk loading existing spreadsheet data.
The data collection program ran in parallel: application owners received structured intake forms; the EA team reviewed and validated entries; Sparx Services provided weekly quality assurance across the emerging repository. By week 10, 847 applications were documented in the governed repository with consistent tagging across all records.
Stream 2: EA GraphLink deployment and GraphQL schema (weeks 2–12)
EA GraphLink was deployed against the Sparx EA repository. The GraphQL schema was designed to expose the application portfolio data model: applications, capabilities, lifecycle attributes, technology risk indicators: in a form optimized for Power BI consumption. Schema design required iteration: the first version surfaced data quality issues that required repository corrections before the schema could be finalized.
The GraphQL endpoint was tested against representative queries from the rationalization use cases: applications by lifecycle status, applications by capability, applications at technology risk, application-to-infrastructure dependencies. Each query was validated against known data before the Power BI build began.
Stream 3: Power BI semantic model and dashboards (weeks 6–14)
Power BI dashboards were built over the EA GraphLink GraphQL endpoint using DirectQuery: ensuring that every report view reflects the current state of the repository rather than a snapshot. Four core dashboards were delivered:
Kernaro AI Hub was configured and rolled out to the 12-person EA team and the five executive stakeholders who required direct portfolio access. Configuration included custom prompts aligned to rationalization query patterns and governance guardrails for data classification.
847 applications documented in a governed Sparx EA repository: the first complete, current-state application portfolio the firm had ever had.
Power BI dashboards refreshing daily via EA GraphLink DirectQuery connection: compared to monthly PowerPoint reports produced manually from stale spreadsheet data.
230 rationalization candidates identified in the first executive portfolio review, within four weeks of dashboard go-live. These candidates: duplicates, end-of-life applications, and low-alignment systems: formed the initial scope of the technology cost reduction program.
Executive team querying the portfolio directly via Kernaro AI Hub: “what applications support the retail banking capability?”, “which applications have no active support contract?”: without requiring an architect to produce a report.
Architecture team time on reporting: from approximately 60% to approximately 20%: freeing 12 architects to spend more time on actual architecture work.
> “We finally have a single source of truth for the application portfolio that updates itself. The first executive portfolio review took 2 hours instead of 2 weeks of preparation.” > >: Head of Enterprise Architecture
The outcome depended on three decisions made early in the Discover phase that are easy to get wrong.
Getting the MDG right before populating the repository prevented the quality debt that accumulates when architects start entering data without governed structure. Repositories that are populated first and governed later typically require a costly remediation program before they can support reliable querying.
Choosing DirectQuery over imported data snapshots for the Power BI connection meant the dashboards stayed current without manual refresh processes: the daily data freshness that made the rationalization program credible was a technical architecture decision, not a content decision.
Scoping Kernaro AI Hub to a specific user population with specific query patterns: rather than a general rollout: ensured executive adoption. Broad AI tool rollouts to populations without clear use cases produce low engagement. Targeted rollouts against specific decision support needs produce immediate and sustained use.
If your organization has an application estate that no one can see clearly, or architecture data that isn’t reaching the people making decisions about it, the Discover service is the right first step. It identifies exactly what is needed and avoids scoping a Connect engagement against assumptions that turn out to be wrong.
Explore the Connect Service: EA GraphLink deployment, Power BI integration, Kernaro AI Hub. $50K–$185K+ depending on scope.
Start with Discover: six-week assessment, MDG health check, stakeholder interviews, roadmap. $25K–$75K depending on scope.
Contact Sparx Services: describe your portfolio situation and we will assess whether this engagement pattern applies.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.