EAFlow
Book demo

EAFLOW · CASE · FINTECH

A governed process layer over the graph, alongside the legacy tool

A leading financial-technology and payments organization, with an operation in Chile, validated Process Knowledge alongside its enterprise BPA tool: the legacy tool remains the source of editing and EAFlow adds an upper publication layer, connected official documentation and structural querying over the Operational Graph —navigation, reporting and traceability— without migrating the repository.

The validation showed that the solution works over the client's real operation and the value it delivers: the process corpus published as a navigable layer and connected to the Operational Graph, with the official documentation linked to the process and structural querying available to the rest of the organization, without touching the existing modeling method.

See Process Knowledge Operational validation · early adopter

The challenge

Financial-technology and payments organizations that run their process practice on a legacy enterprise BPA tool face the same pattern. The problem is not the quality of the models: it is that the corpus lives isolated from the rest of the operation, locked inside the modeler.

  • The current modeling method remains valid: the process architecture team models with confidence in its legacy tool, and the existing curation is an asset. Replacing the editing is not the priority —nor necessarily desirable.
  • The process repository is well modeled, but it is not connected to the applications that support it, to the data it produces, to the documents that back it or to the operational owners. The knowledge stays locked inside the modeling tool.
  • The legacy BPA tool is powerful for modeling, but governed publication for the rest of the organization, the connection to official documentation and cross-cutting structural querying fall short or require manual exports.
  • The official documentation —SOPs, work instructions, policies and procedures— lives in parallel repositories, without bidirectional traceability to the process that uses it.
  • Replacing it all at once is risky and often unnecessary: migrating the entire corpus to a new platform is a long, high-risk project, and when the current method works, 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 publication and querying layer in a first phase, leaving natural-language querying for later.

Process knowledge is not sustained by an isolated modeler. It is sustained by processes that are published, connected to the graph, with their documentation linked and queryable by the rest of the organization.

The EAFlow solution

Process Knowledge is a cross-cutting solution in the Process and Architecture Modernization area, built on the common Operational Graph layer of EAFlow Platform, operating alongside the client's enterprise BPA tool —which remains the source of editing. The validation covered, over the process corpus of the client's operation, the governed coexistence scenario as an upper layer:

  • The legacy BPA tool remains the source of editing. The process architecture team continues modeling in its current tool; the existing method and curation are not touched. EAFlow does not replace the editing.
  • Governed upper publication layer over the graph. The processes published from the legacy tool become available as a queryable and navigable upper layer: value chain, decomposition levels, process and tasks, with the current version and traceability.
  • Official documentation connected to the process. SOPs, work instructions, policies, procedures and evidence from the official document repository are linked to the published process, to the accountable role and to the applicable control, without migrating files.
  • Governed synchronization with the legacy editing source. What is edited in the legacy BPA tool is synchronized to EAFlow's upper layer in a governed way: the legacy tool keeps authorship, EAFlow keeps publication, connection and structural querying, with origin and version traceability.
  • Operational Graph as the destination of the coexistence layer. Published processes, tasks, roles, applications, data, documents and relationships are connected as first-class entities, with citation to source and event-level traceability.
  • Analytical and deterministic support. Graph navigation, structural querying —by value chain, by level, by role, by application, by linked document— and reporting over the repository structure operate deterministically, breaking the isolation of the repository from the rest of the operation.

Coexistence is governed, not automatic: authorship stays in the legacy tool and synchronization to the upper layer keeps clear publication rules and traceability. 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 process corpus of the enterprise BPA tool of the client's operation, in continuity with prior coexistence work. The architecture team went through the full coexistence layer: governed synchronization from the legacy tool to the upper layer, publication of the value chain and the decomposition hierarchy as a navigable layer, connection of the official documentation to the process without migrating files, and linking of the processes to applications, data and owners in the graph when those corpora were available. Navigation, structural querying and reporting over the repository structure worked deterministically over the graph, with traceability of the published version and of the origin of each synchronization.

Demonstrated capabilities

  • Operational Graph as the common context foundation.
  • Governed coexistence with the legacy BPA tool as the source of editing.
  • Governed synchronization to the upper layer, with origin and version traceability.
  • Value chain and decomposition hierarchy published as a navigable layer.
  • Official documentation connected to the published process, without migrating files.
  • Processes connected to applications, data and owners when those corpora are available.
  • Graph navigation and structural querying (value chain, level, role, application, document), deterministic.
  • Reporting over the repository structure (publication coverage, processes without documentation, processes without an owner).

Observed outcome

The process corpus moved from "being locked inside the modeler" to being published as a navigable layer and connected to the graph, with the official documentation linked to the process and structural querying available to the rest of the organization —something the previous method only solved with manual exports—. The legacy BPA tool remained the source of editing throughout the entire experience, without interrupting the team's method.

The validation confirmed that the solution sustains the governed coexistence layer over the client's real operation, leaving the evolution-path decision —expanding the coverage of the published corpus, incorporating natural-language querying over the corpus already connected, or evaluating in the future a replacement of the legacy enterprise BPA toward portable BPMN 2.0— in the hands of the architecture team, with coexistence 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 BPA tool: the modeling method remains valid, the repository lives isolated from the operation, and replacing it all at once is perceived as risky and unnecessary. Demonstrating, over the client's operation, that a process corpus can be published as a navigable layer, connected to its official documentation and made queryable by the rest of the organization without touching the source of editing turns an "all or nothing" decision into a decision informed by evidence.

Starting with process knowledge is also a low-risk entry point: the same Operational Graph that sustains the coexistence process layer later sustains architecture, inventory, documents, risk and operations.

How it scales — related solutions

The published process corpus is reused on the same Operational Graph:

Evaluate my use case See Process Knowledge