HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Business use cases

When does an integrated platform make more sense than specialist providers?

3 min read

An integrated approach is worth evaluating when the work spans several connected domains and your team spends effort reconciling their boundaries. A specialist can still be the better fit for a narrow requirement or a capability not enabled in the platform.

Look for a connected problem

An integrated platform is worth evaluating when the business repeatedly joins information from several domains, such as wallet context, payments, approvals, and evidence. The potential benefit is fewer disconnected handoffs and a more understandable operating model. A specialist may be preferable when the requirement is narrow or needs a capability the platform does not enable. The decision should follow the actual workflow rather than a general preference for either more vendors or fewer vendors.

Compare the same outcome

Give both approaches the same normal case and exception cases. Check whether users can identify the relevant record, understand its status, and complete the permitted next step. Include integration effort, operating responsibilities, external dependencies, and the quality of support evidence. A product with more features is not automatically a better fit if those features do not solve the current problem or introduce unnecessary complexity into the user journey.

Consider what happens after the pilot

Ask who owns changes, incidents, and service interruptions. Review how your business retains its important references and what an eventual transition would require, without assuming that every export or migration feature exists. Compare observed results with the original requirements and identify remaining gaps honestly. An integrated approach earns its value when the connections make day-to-day work clearer or more efficient, not simply when several product names appear under one brand.

Illustrative example

A pilot compares how each approach connects wallet context, payment exceptions, and retained evidence.

In plain language

An example is not a production result

The examples in this FAQ explain how to think about a workflow. They are not reports of customer results, guarantees of performance, or instructions to use real funds. A useful evaluation starts with agreed access, a non-production environment where appropriate, and data that you are permitted to use. Decide in advance what a pass looks like and what must be refused. An allowed case alone is not enough: the team should also try an unauthorized request, a missing requirement, or an unavailable dependency where the test scope permits it. Keep the result and its context so someone else can understand what was demonstrated. Passing that test provides evidence for the tested combination of product, configuration, and environment. It does not automatically enable a different operation or network. Moving to production should be a separate, explicit decision with the required owners involved.

In plain language

What an API contract tells your team

An API is a way for one application to ask another system for information or an action. The operation contract is the detailed description of that particular request: what information to send, what access is required, what a response means, and which errors can occur. It is more precise than a product overview. A read normally retrieves information; a write can create or change something and therefore needs more careful handling. Developers should use the current contract for the deployed environment rather than guessing from a similar endpoint or an old example. Business users can help by stating the outcome in ordinary language and naming who may authorize it. Both sides should agree how to identify the request later, what happens if a response is delayed, and which record establishes completion. These details turn a demonstration into an integration that people can operate responsibly.

Conditions & limitations

More modules are not automatically more value. Compare actual coverage, dependencies, operational effort, and exit requirements.

What to do next

Score both approaches against the same workflow and observed test cases.

Business solutions ↗Product directory ↗