API Integration Consulting

API integration consulting is the work of deciding which systems have to reach each other for a business decision to run end to end, what each connection has to carry, and what the smallest set of those connections is. Vivaldi is a strategy firm, not a systems integrator. We do not write code, build connectors, run middleware or staff engineering teams. We decide what should connect and why, and we hand that decision to whoever builds it. Saying so on the first screen saves a wasted meeting.

• Since 1999strategy work on business models, demand and digital platforms
• 200+published case studies
• 10 officeson four continents
• 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
• No buildwe are paid to decide what to connect, not to connect it

When companies bring us in

Nobody buys an outside opinion on integration because the engineering is bad. The trigger is almost always a process that will not finish without a person in the middle of it, or an integration bill that keeps growing while the business case does not.

• A capability works in a demo and never reaches production. It can reason about the problem and cannot reach the system where the work happens, so somebody copies the output by hand and the saving disappears.
• The tenth connection costs more than the first. Every integration was built point to point against a specific project, so the estate gets harder to change rather than easier.
• Two systems hold the same fact and disagree. The argument is treated as a data quality problem when it is a question about which system is allowed to be right.
• A systems integrator has quoted the estate. The proposal is competent, very large, and nobody internally can say which part of it pays for itself first.
• A vendor changed an API and it became a program of work. That is not a vendor problem. It is the bill arriving for a shortcut taken years earlier.

Why buying the integration before deciding it does not work

Integration is usually scoped by system. Somebody inventories the estate, draws the current state, draws a target state, and the gap between them becomes the program. It is a defensible way to write a statement of work and a poor way to decide what a company should spend money connecting.

Scoping by system produces a program sized by how much estate you own. Scoping by decision produces a program sized by how much value is stuck. Those two numbers are rarely close, and the first one is always the larger.

The deeper problem is that an estate map cannot tell you what matters. It shows every system as equally worth connecting, because on a diagram they are. Only a specific decision, a pricing call, a service recovery, a credit check, a reorder, tells you which path has to run without a person in it, and therefore which three connections out of two hundred are the ones that pay.

This is also why the firm that builds the integration is the wrong firm to scope it. It is not a question of honesty. A delivery business is structured to sell delivery, it is good at delivery, and the natural shape of its answer is more of it. We have no build revenue to protect because we have no build practice, which is the only reason our answer is worth asking for.

What our API integration consulting covers

1. Deciding which systems actually have to reach each other

We start from the business decisions and workflows that matter, not from the estate. For each one we trace the path from intent to recorded outcome and mark every point where a person currently carries context between two systems. Those points are the candidate integrations. Everything else on the architecture diagram stays where it is.

2. Narrowing the integration list to the ones that pay

Most of the candidate connections are real and not worth money. We separate the ones that remove a structural bottleneck from the ones that make a step marginally nicer, and we write down what each is worth and what it costs to keep alive. The output is a short list with the exclusions stated, because an integration list that excludes nothing has decided nothing.

3. Specifying what each connection has to carry

A connection is not just a pipe between two systems. We specify, in business terms a build team can act on, which system is the source of truth for each fact, what has to travel with a request so the receiving system can act on it, what authority a service or agent acts with and on whose behalf, and what has to be recorded so the outcome can come back and change the next decision. Engineering chooses the protocol. This decides what the protocol has to deliver.

4. Protecting the estate from its own suppliers

The single most expensive shortcut in integration is wiring one vendor’s interface shape directly into everything that touches it. We set the rule for where abstraction is worth its overhead and where it is not, so that a provider change, a model change or a replatform is contained rather than cascading. This is a commercial decision about switching costs before it is a technical one.

5. Choosing and briefing the firm that builds it

Because we do not build, we can run the selection. We turn the decision into a brief a delivery partner can quote against, compare the responses on something other than day rate, and sit on the client side of the table while the work runs. Our fee does not move with the size of the build.

How an integration advisory engagement works

1. Trace. Workshops with the people who run the process, not only the people who own the systems. We follow two or three real decisions from intent to recorded outcome and mark every manual handoff. The output is where the value is leaking, in process terms.
2. Decide. We size each candidate connection against what it unblocks and what it will cost to maintain, then cut the list. The output is a ranked set of connections with the exclusions written down and a defensible reason for the order.
3. Specify. Source of truth, context, authority and feedback path for each connection that survived, written so a delivery team can quote it and a CFO can read it. The output is a brief, not a design document.
4. Govern. The rules that keep the estate from re-fragmenting: who may create a new connection, what has to be true before it is approved, and how the first one is measured before the second is funded.

Why companies choose Vivaldi for API integration consulting

Three reasons, and the first is the limit rather than a capability.

• We have nothing to sell you afterwards. No build practice, no delivery bench, no reseller margin, no managed service. The recommendation to connect less is available to us and is not available to a firm paid by the connection.
• We come at it from the business model, not the estate. Vivaldi has spent more than twenty-five years on how value is created between parties rather than inside one company, which is the same question integration asks in a technical register: who has to be able to act on whom, and what currently stops them.
• We stay on your side of the table. Selection, briefing and oversight of whoever builds it, with a fee that does not grow when the program does.

The honest limit, stated plainly: if your design is already settled and what you need is capacity to build it, you need a systems integrator and not us. We will say so in the first conversation.

How to evaluate an API integration consultant

Including us. Worth asking of everyone on the shortlist.

• Ask how they get paid if the answer is fewer integrations. If their revenue scales with the size of the build, the recommendation to build less is one they can give but not one they are structured to find.
• Ask them to scope by decision, not by system. A firm that opens with an inventory of your estate will quote you the estate. A firm that opens with a workflow will quote you the part that pays.
• Ask what happens when a vendor changes an interface. If the honest answer is that every connected system needs work, there is no abstraction anywhere and you are being sold a maintenance liability.
• Ask how a service or an agent’s authority is defined and recorded. Permission enforced at the point of retrieval and action is a real answer. Permission assumed at configuration time is not.
• Ask who owns it in two years. Connections rot quietly. If nobody inside your organization can extend them, you have bought a subscription rather than an architecture.

Strategy advisor vs systems integrator vs integration platform vendor?

Related work

Integration sits next to several questions it is often confused with. These are the ones to read instead if the description below fits your situation better than this page does.

• Technical and DevOps architecture if the connections already exist and the constraint is how the underlying system is structured and operated, or how slowly a change reaches production. That page owns the architecture and operations question. This page stops at which connections should exist at all.
• Data strategy if what travels between the systems is not trustworthy, current or governed. Integration moves a fact. Data strategy decides whether the fact is worth moving.
• Digital ecosystem design if the systems that have to reach each other belong to different companies, which makes it a commercial design question before a technical one.
• Platform strategy if the point of connecting is to let third parties build on what you own.
• Digital products and platforms if the integration serves something being built rather than something already running.

This work sits inside our Business Technology Strategy practice at Vivaldi, the strategy firm behind the Demand Landscape and the Interaction Field.

API integration consulting in the US and worldwide

We work from 10 offices on four continents, with the integration advisory work usually run out of New York and our European offices and delivered wherever the process actually runs. In practice the engagement is remote with two or three on-site weeks, because tracing a decision end to end means sitting with the people who currently carry the context by hand.

Region matters less here than estate age and regulatory load. A US retailer with twelve years of acquisitions and a German manufacturer with a thirty-year-old core system have the same problem in different accents, and both get the same answer: decide the path before you buy the pipe.