Direct Answer
Digital banking transformation — moving from a monolithic core banking platform (Temenos T24, FIS Profile, Finastra Fusion) to a composable, API-first architecture — is one of the highest-risk and highest-value change programmes a financial institution can undertake. It fails most often not because the technology is wrong but because the architecture is undocumented: integration dependencies are unknown, data migration boundaries are unclear, and the relationship between current applications and target banking capabilities is undefined.
Sparx EA addresses this by providing the architecture repository where the current-state application portfolio is documented, mapped to BIAN Service Domains, and connected to a migration roadmap. EA GraphLink connects that repository to Power BI, giving transformation programme managers a live dashboard showing migration wave status, BIAN domain coverage, and decommission schedules — updated automatically as the model evolves, without manual exports or slide-deck reporting cycles.
Key Takeaways
- Core banking modernisation fails without documented integration dependencies and data migration boundaries — Sparx EA provides the repository where these are governed.
- BIAN Service Domains (Channel Services, Customer Management, Product Management, Operations, Risk/Compliance) provide the canonical decomposition for mapping current applications to target architecture.
- The BIAN Architecture Canvas in Sparx EA defines the target-state banking platform in terms of BIAN domains, API surfaces, and orchestration patterns.
- MDG tagged values on Application Components carry BIAN domain classification, enabling automated reporting without manual spreadsheets.
- EA GraphLink connects the Sparx EA repository to Power BI — giving programme managers a live migration governance dashboard without requiring access to Sparx EA.
Why Core Banking Modernisation Is an Architecture Problem
The Monolithic Legacy
Core banking platforms like Temenos T24, FIS Profile, Finastra Fusion, and Silverlake Axis were designed in an era of batch processing and tightly coupled subsystems. They manage the system of record for current accounts, savings, loans, and payments — but they do so through internal data stores, proprietary APIs, and processing logic that is deeply intertwined. Channel applications (internet banking, mobile, branch), product engines, risk systems, and regulatory reporting are all wired directly into the core.
This coupling creates the modernisation problem. When a bank wants to replace or componentise its core banking platform, it discovers that:
- Integration dependencies are undocumented. Nobody has a complete list of which downstream systems call which core banking APIs, at what frequency, and with what data contracts.
- Data migration boundaries are unclear. The core banking database typically holds data that belongs to multiple logical domains — customer records, product definitions, transaction histories, and accounting ledgers are often co-mingled in a single schema designed for performance, not separation of concerns.
- Decommission sequencing is unknown. Without a complete map of what depends on the current core, programme managers cannot sequence the decommission safely.
These are architecture documentation failures. They are solved by building the architecture model before the transformation begins — not during delivery, when the gaps become costly.
What Composable Banking Requires
The composable banking architecture — the target state most banks are moving toward — replaces the monolith with a set of loosely coupled, API-first components that correspond to distinct banking capabilities. The BIAN (Banking Industry Architecture Network) Service Domain model provides the canonical decomposition.
A composable banking platform is governed by:
- Clear domain boundaries — each Service Domain has a defined scope and owns its data.
- Published API contracts — all inter-domain communication goes through documented APIs, not internal procedure calls.
- Orchestration patterns — complex banking processes (account opening, loan origination, payment processing) are implemented as orchestrated sequences of API calls across Service Domains, not as monolithic transaction logic.
Getting from the monolith to this target state requires knowing exactly what the current state is — which is why Sparx EA and BIAN together are the right foundation for the transformation architecture.
BIAN Service Domains in Practice
The BIAN Model
BIAN is an industry association that defines a canonical service domain model for banking. A Service Domain is a self-contained banking capability with a defined scope, a defined set of control records (the data it owns), and a set of behaviour qualifiers (the operations it performs). BIAN defines over 300 Service Domains, organised into functional domains:
Channel Services — the customer-facing touchpoints: Internet Banking, Mobile Banking, Branch Operations, Contact Centre Operations, ATM Network Operations.
Customer Management — customer lifecycle management: Customer Profile, Customer Relationship Management, Prospect Management, Customer Servicing.
Product Management — the product catalogue and product lifecycle: Product Directory, Product Agreement (for specific customer-product relationships), Current Account, Savings Account, Consumer Loans, Mortgages, Credit Cards.
Operations — back-office banking operations: Payment Execution, Nostro Reconciliation, Currency Exchange, Clearing and Settlement, Position Keeping.
Risk and Compliance — risk and regulatory compliance: Regulatory Reporting, Compliance Reporting, Financial Accounting, Fraud Evaluation, Credit Risk Operations, Customer Tax Handling.
BIAN provides a reference for what a bank’s current applications should be mapped to — and where there are duplications, gaps, or boundary ambiguities.
The Current-State Mapping Exercise
The first architecture activity in a core banking modernisation is mapping the current application portfolio to BIAN Service Domains. This reveals:
- Duplication: Two or more applications that both implement the same BIAN Service Domain. Common examples: multiple customer data stores, multiple product catalogues across different product lines, multiple payment engines for different payment types.
- Gaps: BIAN Service Domains for which no current application provides coverage — capabilities the bank needs but has not formally built (often managed by ad hoc processes or spreadsheets).
- Misalignment: Applications that straddle BIAN boundaries — implementing partial capabilities from multiple domains in a single codebase. These are the hardest components to componentise.
This mapping is the architecture foundation for the transformation. Without it, the transformation programme is building toward a target state without knowing where it is starting from.
The BIAN Architecture Canvas for the Target State
The BIAN Architecture Canvas is the target-state architecture document: a view of the future banking platform organised by BIAN Service Domain clusters, showing which Service Domains will be provided by which technology components (a new cloud-native core, a retained legacy system, a third-party fintech, or a newly built microservice), and which BIAN API contracts govern the interactions between them.
In Sparx EA, the BIAN Architecture Canvas is an ArchiMate Application layer diagram in which:
- Application Components represent the technology components of the target platform.
- Tagged values on each Application Component record the BIAN Service Domains it implements.
- Application Interfaces represent the BIAN API contracts between components.
- The migration path from current-state components to target-state components is documented through ArchiMate Implementation layer Work Packages.
Sparx EA: Building the Core Banking Architecture Repository
Current-State Application Portfolio
The starting point is a structured inventory of all applications in the current banking technology estate, modeled as ArchiMate Application Components in Sparx EA.
Each Application Component carries MDG tagged values defined by the bank’s custom BIAN MDG profile:
- BIAN Domain: The primary BIAN functional domain (Channel Services, Customer Management, Product Management, Operations, Risk/Compliance).
- BIAN Service Domains: The specific BIAN Service Domains this application implements (may be one or several).
- System of Record flag: Whether this application is the authoritative source for its domain data.
- Technology status: Current (actively maintained), legacy (in maintenance mode), strategic (target platform), or decommission-target.
- Core banking dependency: Whether this application has a direct integration dependency on the core banking platform.
- Integration count: The number of known integration points (populated from the integration inventory).
This tagged value structure means the application portfolio can be filtered, grouped, and reported by any combination of attributes — directly from the EA repository, without manual pivot tables.
API Architecture Documentation
The integration topology is documented through ArchiMate Application Interfaces. Each Application Component exposes interfaces representing its integration points. Application Interaction relationships connect interfaces across components, carrying metadata:
- Integration standard (REST/JSON, SOAP/XML, proprietary message format, batch file).
- BIAN API conformance level (where applicable — whether the interface conforms to the BIAN Semantic API standard for that Service Domain).
- Direction (inbound, outbound, bidirectional).
- Trigger type (event-driven, request-response, scheduled batch).
- Criticality (P1 — real-time availability required, P2 — same-day recovery, P3 — batch recovery acceptable).
This integration topology is what enables safe migration sequencing. When the programme needs to replace the current account module of the core banking system, the Application Interface view shows every downstream system that calls the current account APIs, with their integration standards and criticality levels. The migration sequence can be planned without missing dependencies.
Migration Roadmap: ArchiMate Implementation Layer
The migration roadmap is modeled in the ArchiMate Implementation and Migration layer. Work Packages represent transformation deliverables — each corresponding to a migration wave, a system retirement, or a new capability deployment.
Each Work Package in the migration roadmap is linked to:
- The Application Components it delivers (new target components).
- The Application Components it retires (decommission targets).
- The predecessor Work Packages it depends on (sequencing constraints).
- The BIAN Service Domains it addresses (domain coverage progress tracking).
This linkage is what makes the migration roadmap architecture-grade rather than project-plan grade. The Work Packages are not just tasks in a Gantt chart — they are connected to the application portfolio and the BIAN domain model, enabling automated progress tracking through EA GraphLink.
EA GraphLink: Live Transformation Governance in Power BI
EA GraphLink connects the Sparx EA core banking transformation model to Power BI via a GraphQL API. The transformation governance dashboard provides programme managers with a live view of the migration, refreshed automatically as architects update the model.
Migration Wave Status: A summary table showing each Work Package (migration wave), its planned and actual start/end dates, and the Application Components it delivers and retires. Programme managers see at a glance which waves are on track, which are delayed, and which have unresolved dependency conflicts.
BIAN Domain Coverage Heat Map: A BIAN domain grid showing current coverage (how many BIAN Service Domains are covered by current-state applications), target coverage (how many will be covered by target-state applications), and the gap (which Service Domains are not yet addressed). The heat map shows transformation progress at the capability level, not just the project level.
Decommission Schedule: A timeline of planned application retirements, linked to the Work Packages that retire each system. Programme managers can see which applications are due for decommission in each quarter, which are dependent on other work packages completing first, and which have open integration dependencies not yet migrated.
Core Banking Dependency Map: A network diagram showing all applications with direct core banking dependencies, coloured by migration status (unresolved dependency, dependency in progress, dependency migrated). This view is critical for sequencing the core banking platform replacement.
API Conformance Tracker: The percentage of integrations that are BIAN API-conformant in the current state versus the target state. This metric tracks the transformation’s progress toward composable, standards-based API governance.
All dashboard views draw from the live Sparx EA repository. When an architect updates a tagged value (marking a dependency as migrated, or updating a Work Package’s completion status), the Power BI dashboard reflects the change at the next scheduled refresh — without any manual export or data entry.
MDG Design for BIAN Banking Architecture
A BIAN-aligned MDG profile for core banking modernisation defines the following stereotypes:
«BIAN-Application» — extends the ArchiMate Application Component stereotype with BIAN-specific tagged values: BIANDomain, BIANServiceDomains (multi-value), SystemOfRecord (boolean), TechStatus (enumeration: Current | Legacy | Strategic | Decommission), CoreBankingDependency (boolean), BIANAPIConformance (enumeration: Conformant | Partial | Non-conformant | N/A).
«BIAN-API» — extends the ArchiMate Application Interface stereotype with: BIANSemanticAPI (the specific BIAN semantic API standard this interface conforms to, if any), IntegrationStandard (enumeration: REST | SOAP | Batch | Proprietary), Criticality (enumeration: P1 | P2 | P3).
«BIAN-WorkPackage» — extends the ArchiMate Work Package stereotype with: MigrationWave (wave number), BIANDomainsAddressed (multi-value list of BIAN Service Domains addressed), CoreBankingPhase (enumeration: Pre-migration | Migration | Post-migration).
These stereotypes are defined in the MDG technology XML and applied through the Sparx EA stereotype picker — ensuring all architects on the programme apply consistent classification without relying on naming conventions or unstructured notes fields.
FAQ
Q1: What is BIAN and why does it matter for core banking modernisation?
BIAN (Banking Industry Architecture Network) is a non-profit industry association that publishes a reference architecture for banking — the Service Domain model, which decomposes banking capabilities into over 300 discrete, bounded domains, each with defined scope, data ownership, and API contracts. BIAN matters for core banking modernisation because it provides the shared language for mapping current applications to target architecture components. Without a reference model like BIAN, different stakeholders (IT, business, vendors) use different terms for the same capabilities, making it impossible to build a coherent transformation roadmap. BIAN gives the transformation a common vocabulary and a target decomposition.
Q2: Which core banking platforms does Sparx EA work with architecturally?
Sparx EA is platform-agnostic — it documents the architecture of the banking technology estate regardless of which specific core banking platform is in use. Sparx Services has structured architecture models around Temenos T24 and Transact, FIS Profile and Modern Banking Platform, Finastra Fusion Banking, Silverlake Axis, Thought Machine Vault, and cloud-native cores like Mambu and 10x. The BIAN mapping exercise applies equally to all of these — the goal is to understand what BIAN Service Domains each platform provides and where the gaps and duplications are.
Q3: How long does the BIAN mapping exercise take?
For a mid-sized bank with 50–150 applications in the transformation scope, the BIAN mapping exercise typically takes four to eight weeks as part of a Discover or Connect engagement. The effort depends on how well the current application portfolio is documented, the availability of technical subject matter experts for each application, and the complexity of the integration topology. Sparx Services conducts the mapping through a structured workshop series combined with repository analysis — using EA GraphLink to interrogate any existing Sparx EA data and combining it with structured interviews and documentation review for gaps.
Q4: Can Sparx EA model the BIAN semantic APIs for the target architecture?
Yes. BIAN publishes semantic API definitions for each Service Domain — Open API specifications that define the exact request/response structures for BIAN-conformant interfaces. These API specifications can be imported into Sparx EA as Application Interface elements with detailed operation modeling. For the target-state architecture, the BIAN semantic API definitions provide the contract layer between components — documented in Sparx EA as Application Interfaces on each target Application Component, with tagged values recording BIAN API version and conformance level.
Q5: How does the migration roadmap in Sparx EA connect to project management tools?
The ArchiMate Implementation layer Work Packages in Sparx EA represent architecture-level transformation deliverables, not individual project tasks. They connect to project management tools (Jira, ServiceNow, MS Project) through tagged values that record the corresponding project artefact IDs — enabling traceability between the architecture roadmap and the delivery plan without attempting to replace the project management tool. EA GraphLink can query Work Package status and surface it in Power BI alongside project delivery metrics, providing programme managers with both the architecture view and the delivery view in a single dashboard.
Q6: What is the biggest architecture mistake in core banking transformation programmes?
The most common and most costly architecture mistake is beginning vendor selection and contract negotiation before documenting the current-state integration topology. Banks frequently select a new core banking vendor based on capability demonstrations, then discover during implementation that the integration complexity of their existing estate is far greater than anticipated. Integrations that were assumed to be simple REST calls turn out to be complex batch processes with business-critical timing dependencies. Sparx Services consistently recommends investing in the as-is architecture documentation (Discover engagement) before committing to a core banking replacement programme.
Q7: How does EA GraphLink handle the security requirements of banking data in the architecture repository?
The Sparx EA repository contains architecture data — application names, integration topology, tagged values — not banking customer data or transaction data. The architecture repository itself requires appropriate access controls (role-based access in Sparx EA Pro Cloud Server, network-level controls on the PCS server), but it does not constitute a sensitive data system in the regulatory sense. EA GraphLink connects to Power BI using service account authentication and exposes only the architecture metadata — not any system-of-record content. Banking clients typically deploy the Sparx EA Pro Cloud Server within their internal network with EA GraphLink connecting to their existing Power BI tenant using their standard enterprise identity platform.
Q8: What engagement does Sparx Services recommend for a bank starting a core banking transformation?
Connect is the recommended engagement for most banks — it delivers the current-state application portfolio mapped to BIAN Service Domains, the target-state BIAN Architecture Canvas, the integration topology, the migration roadmap Work Packages, and the EA GraphLink connection to Power BI for live transformation governance. Banks that need to scope the transformation before committing to it start with Discover, which delivers the as-is application portfolio and BIAN domain mapping as the basis for business case development. Connect pricing starts from $50,000; Discover from $25,000.
Work With Sparx Services
Core banking modernisation governance requires architecture that stays current as the programme evolves — not a static document produced at the start and ignored during delivery. Sparx Services’ Connect engagement builds your BIAN-aligned application portfolio and migration roadmap in Sparx EA, then connects it to Power BI via EA GraphLink so your programme managers have a live transformation dashboard from day one.
Connect from $50,000. Contact us to discuss your core banking transformation architecture.