Skip to content

The API in the Sky

Around the office, VirtualForge has a nickname: the API in the sky. It started as a joke and stuck, because it turned out to describe the thing better than the formal language did.

The formal version: VirtualForge is EEI's cloud-native, technology-agnostic integration platform. That sentence is accurate and tells you almost nothing. The nickname does better, because it points at the actual idea — one place in the cloud that everything can talk to, instead of a growing tangle of point-to-point connections between systems that were never designed to know about each other.

The problem with the alternative

Integration usually accumulates rather than gets designed. A historian needs to reach an analytics platform, so someone builds a link. Then the ERP needs to reach the historian. Then a new plant needs both, slightly differently. Each connection is reasonable on its own; collectively they become the thing nobody wants to touch.

The cost shows up as brittleness. Every connection is a private arrangement between two systems, with its own assumptions and its own failure modes, understood by whoever built it. Change one endpoint and you discover the others by breaking them.

A hub changes the shape of the problem. Systems connect to the platform rather than to each other, which turns a mesh of private arrangements into a set of well-defined relationships. Adding the next system stops being a combinatorial problem.

What "integration cloud" means here

Three things, specifically:

It coordinates, not just transports. VirtualForge applies the logic, context, and metadata that make an exchange mean something. Moving bytes is the easy half.

The picture usually drawn — including on our own website — has your services on one side (historians, ERP and MES, partner platforms like Seeq) and the edge on the other (IoT devices, process equipment, instrumentation). That is the case most people arrive with, and it is not the only one a hub makes possible:

Combination Example
Service ↔ edge A device's readings reaching Seeq; a historian's context reaching an instrument
Service ↔ service Metadata from an ERP shaping an asset tree in Seeq, with neither system having to learn about the other
Edge ↔ edge One device's state informing another's, coordinated through the hub rather than wired directly together
Either ↔ the platform itself A Tool on VirtualForge doing real work on data in flight, rather than only relaying it

Once systems connect to a hub instead of to each other, the useful direction is any participant to any participant. The last row is the one worth noticing: because the platform is a participant rather than only a wire, work can happen in the exchange and not merely at its ends.

It is technology-agnostic on purpose. The industrial estate is heterogeneous and will stay that way. The platform is built to reach whatever is actually there rather than to prefer a stack.

It is a managed service. VirtualForge is hosted and operated by EEI on AWS, multi-tenant, with strong isolation between customer organizations — so your data is separated from every other tenant's at the storage layer, not merely by a filter in an application.

Because everything we build runs on it, capability compounds: each new connector or tool on the platform is available to combine with the others, and the useful combinations grow faster than the list of parts.

Being straight about maturity

The nickname is playful; the status should not be.

An early version of VirtualForge was built and deployed for specific use cases — hand-built, quickly, to prove the idea. It worked, and it was a proof of concept, so we stopped developing it rather than making a temporary design permanent. The platform today is a ground-up rebuild.

What is shipping and in customer production throughout is the layer above it: individual VirtualForge connectors and tools. So it is honest to say our connectors are built on VirtualForge today, and equally honest to say the platform beneath them is being rebuilt rather than merely planned.

We would rather tell you that than let you discover it later. If a capability matters to your decision, ask us where it actually stands — we will answer specifically.