EAFLOW · CASE · FINTECH
A live IT-portfolio inventory over the graph, alongside the legacy EA tool
A leading financial-technology and payments organization, with an operation in Chile, validated Live IT Inventory alongside its enterprise Enterprise Architecture tool: the legacy tool remains the source of authority for the architecture model and EAFlow adds a live portfolio inventory layer —applications, owners, criticality, vendors, integrations— navigable and with portfolio dashboards over the Operational Graph, without migrating the repository.
The validation showed that the solution works over the client's real operation and the value it delivers: the IT portfolio available as an inventory layer queryable by the rest of the business, connected to the processes the applications support and to their vendors, without touching the authority of the existing architecture model.
The challenge
Financial-technology and payments organizations that govern their architecture in a legacy enterprise EA tool face the same pattern. The architecture model is valuable, but hardly accessible to the rest of the business and isolated from the operation.
- The architecture model is an asset of the specialist team, but operations, business areas and management do not query the repository: the adoption curve is steep and the tool is designed for specialists.
- The operational inventory of the IT portfolio —current owners, functional criticality, integrations, vendors— is reassembled in parallel spreadsheets for each decision, even though the EA tool holds the model.
- The architecture repository is isolated from the operation: the applications in the EA model are not connected to the operational processes they support, nor to vendors, nor to data, in a view queryable by the rest of the organization.
- Replacing the EA tool all at once is risky and often unnecessary: migrating the entire model to a new platform is a long, high-risk project, and when the current tool fulfills its role of authority, full replacement is not the best first decision.
- Bringing in AI from the start is not always wanted —or possible—: due to data governance, maturity or internal policy, the organization may prefer a live inventory and structural querying layer in a first phase.
- Inventory initiatives remain vulnerable if they depend on a single technical reference; technical ownership must be resolved for the inventory operation to be sustainable.
What is missing is a live IT-portfolio inventory layer over the Operational Graph that coexists with the legacy EA tool: preserving its role of authority, making the portfolio queryable by the rest of the business and breaking the isolation from the operation.
The EAFlow solution
Live IT Inventory is a cross-cutting solution in the EA/BPA Modernization area, built on the common Operational Graph layer of EAFlow Platform, operating alongside the client's Enterprise Architecture tool —which remains the source of authority for the architecture model. The validation covered, over the IT portfolio of the client's operation, the coexistence scenario as a live inventory layer:
- The legacy EA tool remains the source of authority. The architecture team continues governing its architecture repository in the current tool; EAFlow does not replace that authority.
- Live IT-portfolio inventory layer over the graph. The application portfolio —with owners, criticality, supported processes, vendors and integrations— becomes available as a lightweight inventory layer, queryable by the rest of the business and connected to the operational graph.
- Structured and navigable application catalog. Each application is registered with its operational metadata, navigable by criticality, by owner, by vendor and by supported process, with a visible integration and dependency map for change analysis.
- Governed synchronization with the EA source of authority. What lives in the legacy EA tool is synchronized to EAFlow's inventory layer in a governed way: the legacy tool keeps authorship of the model, EAFlow keeps the live inventory layer, navigation and portfolio reporting, with origin traceability.
- Operational Graph as the destination of the inventory layer. Applications, owners, criticality, supported processes, vendors, integrations and data are connected as first-class entities, with event-level traceability of each synchronization.
- Analytical and deterministic support. Portfolio dashboards —by criticality, by owner, by vendor, by process, by integration status—, the navigable catalog and structural querying operate deterministically, breaking the isolation of the architecture repository from the operation.
Populating the inventory is governed, not universal automatic discovery: synchronization comes from the legacy EA tool and from the client's complementary sources (spreadsheets, CMDB) with governed loading. The actual level of integration with the legacy tool is validated by maturity and technical validation in discovery (the tool's API or governed export). The foundation is left ready to incorporate natural-language querying as a later evolution, without that capability being part of what was validated in this experience.
What was validated
The experience was run over the IT portfolio of the client's operation, in continuity with prior coexistence inventory work. The architecture team went through the full inventory layer: governed synchronization from the legacy EA tool to the inventory layer, construction of the application catalog with owners, criticality, supported processes, vendors and integrations, mapping of integrations and dependencies, and connection of the applications to the processes they support and to their vendors when those corpora were available. The portfolio dashboards, the navigable catalog and portfolio reporting worked deterministically over the graph, with traceability of the origin of each synchronization.
Demonstrated capabilities
- Operational Graph as the common context foundation.
- Coexistence with the legacy EA tool as the source of authority for the architecture model.
- Governed synchronization to the inventory layer, with origin traceability.
- Structured and navigable application catalog (owners, criticality, supported processes, vendors, integrations).
- Portfolio dashboards (criticality, owner, vendor, supported process, integration status).
- Integration and dependency map for change analysis.
- Applications connected to processes and vendors when those corpora are available.
- Deterministic portfolio reporting (inventory coverage, applications without an owner, without criticality, unmapped integrations).
Observed outcome
The IT portfolio moved from "being reassembled in parallel spreadsheets for each decision" to being available as a live, navigable inventory layer connected to the graph, queryable by the rest of the business and linked to the processes the applications support and to their vendors. The legacy EA tool remained the source of authority for the architecture model throughout the entire experience, without the architecture team losing its role.
The validation confirmed that the solution sustains the coexistence inventory layer over the client's real operation, leaving the evolution-path decision —expanding the coverage of the inventoried portfolio, incorporating natural-language querying over the inventory already connected, or evolving in the future toward full Enterprise Architecture Governance on EAFlow— in the hands of the architecture team, with the inventory executed as evidence and not as a forced decision.
Why it matters for other organizations
The pattern repeats in financial-technology and payments organizations with years of investment in an enterprise EA tool: the model is valuable but hardly accessible, the operational inventory lives in parallel spreadsheets, and replacing the tool all at once is perceived as risky and unnecessary. Demonstrating, over the client's operation, that the IT portfolio can become a live, navigable inventory layer queryable by the rest of the business without touching the authority of the architecture model turns an "all or nothing" decision into a decision informed by evidence.
Starting with the live inventory is also a low-risk entry point: the same Operational Graph that sustains the coexistence inventory later sustains processes, architecture, documents, risk and operations.
How it scales — related solutions
The live IT-portfolio inventory is reused on the same Operational Graph:
- Toward architecture governance Enterprise Architecture Governance
If the client later decides to consolidate the architecture repository on EAFlow (metamodel, quality rules, domain governance), the inventory is the foundation, as a distinct scenario.
- Toward process knowledge Process Knowledge
The processes the applications support are connected to the client's process corpus, including the process layer coexisting with the legacy BPA tool.
- Toward vendors and contracts Vendor, SLA & Contract Intelligence
The vendors in the inventory are connected to contracts and SLAs with compliance evidence.
- Toward change and roadmap Change Impact
A change to an application in the inventory is assessed by its impact over the graph before deciding.
- Toward risk and control Risk & Control Assurance
The criticality of applications is connected to the risks and controls of the assurance model.