ANONYMIZED CASE · CPG
A connected, queryable IT portfolio
A leading mass consumer goods organization validated Live IT Inventory over the IT portfolio of its operation —applications, owners, criticality, supported processes, vendors and integrations— structuring it as a graph connected to the process, instead of parallel spreadsheets and tribal knowledge.
The validation showed that the solution works over the client's operation and the value it delivers: a governed portfolio, connected to the process and queryable in natural language, where who responds, what each application supports and what depends on what are answered from the graph and not by hand.
The challenge
In a mid-sized or large consumer-packaged-goods organization, the IT portfolio usually exists —but it exists scattered. Applications live in parallel spreadsheets: IT has its own, each business unit its own, Procurement one focused on vendors, Audit another focused on criticality. There is no single catalog.
- Owners by tribal knowledge. Knowing who owns an application means asking, and the answer changes depending on whom you ask. Facing an incident, an audit or a portfolio decision, the chain of responsibility is rebuilt every time.
- Criticality as opinion, not as traced data. Prioritization, continuity and replacement decisions are justified with the IT team's perception, not with documented criticality connected to the processes the application supports.
- Integration map rebuilt project by project. Before a change, a migration or a replacement, someone manually assembles a map of "what depends on what". The next project starts again from scratch.
- The two traditional options are extremes. Implementing full enterprise architecture with a formal metamodel is a long and costly project; keeping parallel spreadsheets is lightweight but neither scales nor is governed.
What is missing is a living portfolio foundation that organizes applications, owners, criticality, supported processes, vendors and integrations, connected to the operational graph and queryable in natural language —without forcing a heavy enterprise-architecture implementation from day one.
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 the EAFlow Operational Graph Platform, that organizes the IT portfolio as a governed graph instead of a spreadsheet. The validation covered, over the IT portfolio of the client's operation:
- Application catalog structured as a graph. Each application is registered with its operational metadata —name, owner, criticality, supported processes, associated vendors, main integrations and status—. The operational difference from a spreadsheet is that the graph is queried, cross-referenced and maintained.
- Owners and accountable parties connected to each application. When a change, an audit or a portfolio decision touches an application, the graph surfaces who responds, without rebuilding the chain by polling several teams.
- Functional and operational criticality traced to processes. Each application receives a criticality profile anchored to the processes it supports; prioritization stops relying on perception.
- Visible integration and dependency map. The graph records the integration points between applications and external systems; before a change, you can see what depends on what.
- Executive portfolio dashboards by criticality, owner, vendor, supported process and integration status —the executive view is a query against the graph, not a report assembled by hand.
- Natural-language queries with Max over the inventory. Questions like "who owns this application?", "which applications support this process?" or "which integrations would be affected if this application is retired?" are answered citing application, owner, linked process and evidence, always with human control. Max does not invent: it answers over the corpus of the inventory and the connected processes.
- Traceability and provenance: every change to the inventory is recorded with author, date, reason and prior state.
Populating the inventory is governed, not universally automatic: it is done with the client's architecture team from existing sources (spreadsheets, inventory tools or a CMDB when applicable), by a scope agreed in discovery and by the maturity of each source. Network-scan discovery is not part of the scope. When an enterprise CMDB exists, the inventory coexists with it without replacing it.
What was validated
The experience was run over a bounded segment of the IT portfolio of the client's operation. The architecture team went through the full cycle: governed loading of the catalog, owner registration, criticality traced to processes, integration map, executive dashboards, natural-language queries with Max over the inventory and the connected processes, change traceability and preliminary impact-analysis queries. When the process corpus was also connected, applications were automatically linked to the processes they support, on a single graph and not two parallel repositories.
Demonstrated capabilities
- Operational Graph as the common context foundation.
- Application catalog structured as a graph, not as a spreadsheet.
- Owners, criticality and integrations connected and traced to processes.
- Executive portfolio dashboards as a query against the graph.
- Natural-language queries with Max over inventory and processes, with citation to source and human control.
- Traceability and provenance of changes to the inventory.
- Preliminary impact analysis over the graph.
Observed outcome
The IT portfolio moved from "living in parallel spreadsheets" to being a governed graph, connected to the process and queryable. Portfolio questions —who responds, what this application supports, what depends on what— stopped being reassembled by hand and started being answered from the graph with citation to evidence; criticality stopped being opinion and became data traced to processes; the integration map stopped being rebuilt project by project.
The validation confirmed that the solution organizes and governs the IT portfolio over the client's operation, as a lightweight entry point that naturally evolves toward full Enterprise Architecture Governance when the client decides to go deeper —on the same graph, without re-implementing.
Why it matters for other organizations
The pattern repeats in mid-sized and large companies: the IT portfolio exists, but scattered across spreadsheets and teams, without unified governance. Organizing it as a graph —connected to the process, the owner and the integrations, without universal automatic discovery and without replacing the existing CMDB— reduces the risk of every portfolio decision and the cost of rebuilding context on each project.
Starting with the live inventory is also a low-risk entry point: the same foundation evolves toward full architecture governance when the problem warrants it, without forcing a heavy implementation from day one.
How it scales — related solutions
The governed portfolio is reused on the same Operational Graph:
- Toward architecture governance Enterprise Architecture Governance
The same foundation evolves into a live repository with a configurable metamodel, quality rules, domain governance and formal impact analysis, on the graph that is already connected.
- Toward processes Process Knowledge
When applications are connected to modernized processes, decisions stop talking about "loose applications" and start talking about "processes at risk if this application fails".
- Toward risk and control Risk & Control Assurance
Critical applications are connected to the risks and controls that apply to them; criticality becomes an input to the assurance model.
- Toward service operations Operational Graph for Service Operations
Tickets gain automatic context about the affected application —owner, criticality, supported processes, integrations, vendor—.
- Toward vendors and contracts Vendor, SLA & Contract Intelligence
The vendors in the inventory are connected to contracts, SLAs and backlog.
- Toward continuity Operational Continuity & Resilience
Functional criticality becomes a direct input to BIA, RTO/RPO and critical dependencies.