Platforms · 14 min read · September 2, 2026

Your Systems Are Green. Your Customer Is Still Waiting.

By Anjaneyullu Tamma

Enterprises are very good at observing systems and considerably less capable of observing the business process that passes through them. We know whether an API call succeeded. We don’t always know whether the customer promise will.

Imagine looking at the operational dashboard for a company at 10:00 Monday morning.

ERP is healthy. The integration platform is processing messages. The warehouse management system is online. APIs are responding within their SLAs. EDI transactions with suppliers show successful transmission. The transportation system is available.

Every technical dashboard is green.

And a customer’s order that was promised for Tuesday is not going to arrive.

Nothing in that scenario is unusual. It happens because most enterprises are very good at observing systems and considerably less capable of observing the business process that passes through those systems.

That distinction becomes increasingly important as enterprises become more connected, supply chains extend beyond organizational boundaries, and business processes depend on suppliers, logistics companies, service providers and customers over whom the enterprise has only partial control.

The next step in observability may therefore have surprisingly little to do with another infrastructure dashboard. It is about making the business commitment itself observable.

We instrumented the technology. We didn’t always instrument the business.

Modern technology observability has become quite sophisticated. Distributed tracing can follow a request across services. Metrics tell us how systems are behaving. Logs help explain individual events. Correlation IDs allow engineers to reconstruct transactions across distributed applications. OpenTelemetry, for example, provides a common model for traces, metrics, logs and contextual information propagated through distributed systems.

All of that is essential. But consider a customer’s order for a product. A single order might travel through:

Customer → Commerce → CRM → ERP → Integration → Supplier → Warehouse → 3PL → Carrier → Customer

The customer does not care that the ERP API responded in 180 milliseconds. The customer cares that the product arrives Thursday as promised.

The ERP might successfully create the order, the integration platform might successfully transmit a purchase order, and the warehouse might have no application errors. Yet the supplier may already be three days behind production. Technically, the transaction succeeded. Operationally, the commitment is already in trouble.

That is the gap between technical observability and business observability.

A business process produces more than transactions. It produces operational evidence.

There is an important idea already embedded in modern supply-chain standards. GS1’s EPCIS standard models visibility through business events that describe what happened, when it happened, where it happened and in what business context. A product may be commissioned, packed, shipped, received or observed under a particular environmental condition. Those events collectively provide evidence about the state and movement of the product.

The more important architectural idea is not limited to physical goods. The same event model can describe a service process whenever the enterprise can define meaningful business events. In business aviation, for example, the event is not necessarily “pallet shipped.” It might be:

Fuel service confirmed · Landing permit approved · Catering delivered · Ground handler accepted service request

The domain changes, but the underlying pattern remains the same: a business commitment progresses through a sequence of observable events. Instead of asking only “Did we send the purchase order?” we can ask “What evidence do we have that the commitment is progressing toward fulfillment?”

For a product order, that evidence might include inventory allocation, supplier confirmation, production completion, carrier pickup and delivery. For an aircraft trip, it might include permit approval, vendor acceptance, service completion and passenger readiness. Each event reduces uncertainty around the original promise.

But there is another important category of evidence: the event that should have happened but didn’t. A carrier normally sends a pickup confirmation within 30 minutes, but none arrived. A supplier has not acknowledged a purchase order. An aircraft handler was expected to confirm a service request two hours ago.

Absence can itself become evidence. That matters because enterprise observability cannot assume that every participant will provide perfect telemetry.

The same architecture applies when there is no product at all

Business aviation makes this particularly clear. Consider an international business aircraft trip. There may be no traditional product moving through a supply chain, but there is unquestionably a supply chain of services. A trip may depend on ground handling, fuel, catering, ground transportation, hotel accommodations, landing and overflight permits, airport slots, customs and immigration coordination, security, deicing, hangar space and other aircraft services.

Imagine an aircraft scheduled to depart Paris tomorrow at 09:00. Fuel, catering, transportation and handling are all confirmed, but the landing permit at the destination is still pending. Every completed service may appear green. The mission is still at risk.

Now suppose the departure changes from 09:00 to 06:30. That single change may affect FBO operating hours, fuel availability, catering delivery, chauffeur scheduling, airport slots, customs arrangements and ground-handler staffing. A change to one business event can invalidate assumptions distributed across multiple organizations.

That is exactly the kind of problem observability needs to expose.

Products and services look different, but architecturally they have the same problem

In manufacturing, the commitment may be produce 5,000 units by Friday. That depends on components, supplier capacity, production lines, labor, machine availability, quality inspection, warehousing and transportation.

In retail: deliver this order to the customer by Thursday. That depends on inventory accuracy, allocation, fulfillment capacity, carrier performance and last-mile execution.

In business aviation: have this aircraft, its passengers and all required services ready for a safe departure at 09:00. That depends on fuel, handling, passengers, crew, permits, catering, transportation, airport availability and other conditions.

The physical things differ. The architectural pattern doesn’t. There is a commitment, a network of dependencies, a sequence of expected events, and a deadline or service level against which progress can be evaluated.

That suggests a different unit of observability. Not the server. Not the application. Not even the integration. The business commitment.

Four kinds of telemetry tell the complete story

Making that commitment observable requires correlating information that enterprises traditionally manage separately.

No individual layer tells the complete story. A purchase order in ERP represents intent. A successful EDI transmission proves that a message moved. A supplier acknowledgment provides stronger evidence. A production-complete event strengthens it further. A carrier pickup confirms that another dependency has been satisfied.

The architecture becomes useful when those signals can be correlated around the commitment they collectively support.

But correlation alone is not the goal. The value comes from progressively reducing thousands of technical and operational signals into the handful of business situations that actually require attention — a form of signal-to-decision compression that becomes increasingly important as the volume of observable data grows.

The missing architectural layer is business correlation

This raises the difficult technical question: how do you correlate a business transaction that might last eight weeks across twenty systems and five companies?

A distributed trace may follow a request through microservices for 800 milliseconds. A customer order might live for two months. An aircraft trip may be replanned repeatedly over several days. Trying to extend a technical trace across that lifecycle is the wrong abstraction.

Instead, enterprises can create a business correlation layer above their existing systems. ERP remains ERP. WMS remains WMS. TMS remains TMS. Legacy applications do not have to be replaced.

Events generated by those systems can move through an event-driven architecture using technologies such as Kafka, cloud event buses, enterprise messaging, integration platforms or APIs. Where applications cannot publish events natively, integration flows, change-data capture, adapters or process instrumentation can generate them.

But an event backbone only moves events. It does not tell us that they belong to the same business commitment. That is where the harder problem begins.

Correlation is really an identity problem

Inside one application, an order may be SO-48219. The supplier may know the same transaction by its own sales-order number. A logistics provider may reference a shipment ID. The carrier may work with a bill of lading or tracking number. The customer may know only its own purchase-order number.

None of those identifiers is guaranteed to survive intact across organizational boundaries. So business correlation cannot depend on a single universal correlation ID. It needs an identity-resolution model capable of relating multiple identifiers to the same business context.

The most useful anchors may include customer or enterprise order numbers, supplier purchase-order references, shipment or tracking identifiers, bills of lading, product, service or asset identifiers.

Sometimes those mappings are deterministic. Sometimes they depend on reference data or relationships captured during integration. Sometimes they have to be inferred from combinations of time, location, quantity, asset, partner and sequence.

The architecture should therefore preserve not only the relationship, but also how confidently that relationship was established. That is a much harder problem than propagating a trace ID through microservices.

The result is a graph, not merely a stream

Once identities are resolved, events can be projected onto a durable model of business state and dependency. For a product supply chain, that might look conceptually like:

Customer Commitment → Order → Inventory → Production → Component → Supplier → Shipment → Carrier

For business aviation:

Mission Commitment → Trip → Flight Leg → Airport → Service Request → Vendor → Operational Dependency

Each node has state. Each dependency introduces risk. Each event changes what the enterprise knows about the overall commitment. A delay at a supplier can therefore be propagated upward to the customer orders that depend on that supplier. A delayed permit can be propagated to the flight leg and the larger mission it supports.

State machines, workflow engines, event projections, process-mining models and graph technologies can all contribute to this layer depending on the problem being solved.

The key architectural point is that this is an observability overlay, not another system of record. Business observability is the capability. The business correlation layer is what makes that capability possible.

If this is so useful, why isn’t everyone already doing it?

Because the difficult part is not collecting more events. It is creating shared meaning across boundaries.

Legacy applications were not designed around common business events. Different business units model the same concepts differently. Trading partners use different standards and identifiers. Suppliers and carriers may expose only the information required contractually. Some data arrives through EDI, some through APIs, some through portals and some through emails or spreadsheets.

Commercial control-tower platforms may provide visibility inside their own ecosystem while creating new integration boundaries elsewhere. And partners do not necessarily have an incentive to expose their internal operations simply because another company wants better visibility.

There is also an organizational problem. An order may move through sales, planning, procurement, warehousing, logistics and customer service without any one team owning its complete lifecycle. A business event spanning two companies may not have an obvious owner at all. Definitions such as “late,” “at risk” or even “complete” may vary between functions.

Those questions are not solved by Kafka. Neither are the economics. Identity mappings, event semantics, partner integrations, state models and historical data all have to be maintained. That is why business observability should usually be built incrementally around high-value commitments rather than as an enterprise-wide “boil the ocean” program.

Start where delayed or failed commitments have meaningful customer, operational or financial consequences. Then expand the correlation model as value is demonstrated.

And sometimes the enterprise simply doesn’t know

Even after the architecture is in place, external boundaries create another reality: evidence will be incomplete.

Your ERP may generate excellent events. Your warehouse may expose APIs. Your integration platform may provide detailed traces. But one supplier might send EDI twice a day. A local service provider may send an email. One carrier may expose rich real-time tracking while another provides only periodic status updates.

Business observability therefore has to work with asymmetric evidence.

Suppose a carrier normally provides an EDI 214 shipment-status message after pickup, but no message arrives. That does not prove the shipment wasn’t picked up. It means the enterprise has lost certainty about its state.

The observability model should therefore be capable of distinguishing between states such as:

Confirmed · Expected · Inferred · At Risk · Unknown

That distinction becomes enormously important once AI begins analyzing the process. We should not confuse an inferred state with an observed fact.

From observation to prediction to intervention

Once business events, transactions, technical telemetry and external context are correlated, AI has something much more valuable than a collection of logs. It has operational context.

Imagine that a supplier normally acknowledges purchase orders within four hours. One has been waiting seven. Lead times for the requested component have increased for three weeks. Several other orders from the supplier are already late, inventory at the assembly plant covers only another two days of production, and dozens of customer orders depend on the component.

Nothing may have technically failed yet. But the pattern tells a different story.

AI can move the enterprise from PO acknowledgment missing to high probability of component shortage within 72 hours. Because the dependency graph connects that component to production and customer commitments, the system can also estimate downstream impact. An illustrative output might look like:

37 customer orders at risk · 12 delivery commitments potentially affected · Estimated revenue exposure: $184,000

The numbers are hypothetical, but the architectural capability is not: the point is that the system can translate a low-level operational signal into business impact.

The same reasoning can identify warehouse queues that predict fulfillment delays, integration retries that quietly add latency, carrier patterns that threaten delivery commitments, or airport/vendor combinations that repeatedly create service delays.

The next step is prescription. For a product supply chain, AI might compare alternate inventory locations, secondary suppliers, production resequencing, split shipments, alternate carriers or expedited transportation. For a business aviation trip, it might determine that the original ground handler is unlikely to meet a revised arrival and identify an approved alternate that can handle the aircraft type, accommodate the new schedule and meet service requirements.

The useful output is not simply handler at risk. It is closer to:

Handler A has a high probability of missing the revised arrival. Handler B can accommodate the new schedule. Switching requires reconfirming catering and transportation and will increase estimated service cost by X.

That is where observability becomes decision support.

Recommendation does not mean autonomous authority

There is an important architectural boundary here. Prediction does not imply unrestricted autonomous action.

Automatically reallocating ordinary inventory may be acceptable. Changing regulatory arrangements for an aircraft probably deserves different treatment. Substituting a supplier may affect quality, contractual terms or compliance. Expediting transportation may exceed financial authority. Canceling a service may incur penalties. Customer communication may create contractual commitments of its own.

The architecture therefore needs a deliberate progression:

Observe → Correlate → Predict → Recommend → Authorize → Execute

That sequence matters. Observability establishes what is happening. Correlation establishes what it means. Prediction estimates what may happen next. Recommendation proposes an intervention. Authorization determines whether that intervention is permitted. Only then does execution change the real world.

AI can progressively participate in each stage, but authority should depend on risk, reversibility, policy and consequence. The more consequential the action, the stronger the authorization and human oversight should become.

From observability to foresight

This is also where the traditional idea of the supply-chain control tower needs to evolve. A dashboard displaying 4,000 exceptions has not solved the problem. It has merely centralized the noise.

The real value is signal-to-decision compression: turning thousands of technical, transactional, operational and external signals into a much smaller number of business situations that deserve attention.

A useful observability capability should be able to establish what actually happened, compare it with what should have happened, identify gaps or uncertainty in the evidence, understand which commitments depend on the affected process, and surface the interventions that remain available.

That changes the progression of enterprise operations. We spent years building systems that could tell us something failed. Then observability helped us understand why did it fail? Business observability asks what does this mean for the commitment we made? AI allows us to ask something more useful: what is likely to put that commitment at risk, and what can we still do about it?

Getting there requires connecting application telemetry with business events, enterprise transactions, partner signals and external context. It requires resolving identity across systems that were never designed to share one. It requires distinguishing observed facts from missing or inferred evidence. It requires modeling dependencies rather than merely collecting events. And increasingly, it requires AI capable of detecting patterns across operational evidence that no human team could continuously analyze.

That is the point at which observability stops being about watching the enterprise and starts helping the enterprise change the outcome.

Author's note:The scenarios in this article are illustrative and combine general architectural patterns and lessons drawn from experience across complex enterprise environments. They do not describe the architecture, operations, customers, systems, or proprietary processes of any specific organization.