Should Data Observability Be Built Into Enterprise Integration Platforms?

Even a perfectly working data pipeline can produce the wrong information. The link is established, the transfer is completed, and all systems report success. Meanwhile, the data coming in at the other end is stale, incomplete or wrong. 

That’s a problem that typical integration monitoring can’t always catch for companies with hundreds of connected applications and data platforms. Even more worrying is when the information is fed to artificial intelligence systems that can make decisions or take actions autonomously. 

Boomi has announced the acquisition of data observability supplier Elementary Data, with ambitions to add data reliability features to its enterprise integration platform. The deal was announced on 19 October 2026. It raises an interesting architectural question. 

Should data observability be built into the platforms that govern the movement of company data, or should companies maintain a separate, holistic view of their data environment? That depends on what those platforms can actually observe, and what happens when something goes wrong outside their reach.

Why Integration Monitoring Alone Isn't Enough

Traditional data integration monitoring shows teams if a process is operating as it should.

• Was the connection successful?
• Did the scheduled job run?
• Was the file transferred?
• Were there any errors?

These checks are important, but they don’t tell you whether the information itself is reliable. Imagine a client database that pushes updated records to a sales platform every hour. The integration works, but changes to the source system mean some customer records are missing crucial fields. Nothing crashes and the transfer occurs on schedule. 

But now the sales staff has incomplete information to work with. Data observability takes this a step further by looking at the health of the data as it passes through different systems. It helps teams detect unexpected changes in data volume, freshness, structure or values, even when the underlying operations seem to be running just fine. 

When wrong information gets into automated systems, the implications are more significant. Somebody reading a report might see something weird and investigate. An AI agent with the same information may make a decision before any human even knows there's an issue.

The CDO Insights 2026 research from Informatica found that 57% of the data executives surveyed said data reliability is a critical obstacle to bringing AI projects from pilot to production. Enterprises need to know more than whether their integrations are running. They need to know if they can still trust the data those connections provide.

What Changes When Observability Is Built Into Integration Platforms?

Data observability has typically been implemented with dedicated tools that connect to databases, warehouses and data pipelines. These tools gather statistics on data health and help teams investigate issues across supported systems. When you bake observability into an integration platform, part of that monitoring moves. 

Organisations might be able to check data reliability in the same environment where they manage their connections, transformations and workflows, rather than having to use an external application. This could provide some important operational context. An integration platform already knows what processes executed, when they executed and if specific steps were successful. 

If it additionally tracks data quality, teams may be able to link an unexpected change in the information to the workflow that created it. For example, a curious drop in customer records could be studied alongside a recent connector change or transformation failure. 

If the platform enables it, teams could also halt processing or redo affected workflows without jumping between multiple tools. Boomi's acquisition of Elementary shows where the company is going. Elementary includes capabilities such as automatic monitoring, data testing and column-level lineage, which follows individual data fields as they pass through their transformations. 

But the companies’ aspirations to extend reliability monitoring to business applications and AI workflows shouldn't be seen as a completely proven end-to-end capability right now. At the time of its announcement about joining Boomi, Elementary also confirmed that the company’s independent product and open-source project would continue. 

There's another constraint to consider. An integration platform may know a lot about the processes it governs, but enterprise data rarely lives in a single environment. A problem may originate in a source application, pass through many integration services and only be noticed when an AI application consumes the generated information. 

Watching one segment of that journey isn't necessarily going to tell you what happened the rest of the way.

Embedded vs Independent Data Observability: What Are the Trade-Offs?

It’s not just about which tool offers more monitoring options when choosing between embedded and standalone observability. The more relevant distinction is the extent to which each approach can see the data environment of the company, how easy it is for teams to investigate incidents, and who controls the information needed to address them.

Where embedded observability makes sense

If an organisation runs most of its essential data workflows through one integration platform, then embedded observability can be a real option. Monitoring information can be quite useful for teams who are responsible for running workflows. They may also more easily get details about particular connections, transformations and execution failures. 

Where the platform offers detection and remediation, engineers can study an issue and fix it in the same environment. But these advantages depend on the capabilities available, not on the fact that monitoring is built in. Organisations still need to verify if the platform can detect data-quality concerns, trace them back to their roots and offer adequate evidence for a proper investigation.

Where independent observability becomes important

When an enterprise has many integration platforms, data environments and business applications, independent data observability is even more valuable. A dedicated monitoring layer can aggregate data from numerous systems and provide a more uniform view of data reliability across systems. 

Picture an organisation that uses one platform for application integration, another for data engineering and a different cloud warehouse for analytics. If an issue impacts all three, monitoring on any one platform will only show part of the picture. You need the integrations and metadata to be there, but an independent approach can help join those observations. 

It also provides companies with more control over how monitoring is managed across multiple providers. Independent tools, however, don't necessarily offer a holistic view. Their visibility depends on the systems they support and the information those systems make available.

Why a combined approach may be necessary

In many complex contexts, the choice may be a combination of the two. Embedded monitoring may give rich context into particular operations, and a common observability layer allows teams to explore issues that cross platform boundaries. The difficulty is getting these capabilities to work together without adding extra complexity.

• If two tools detect the same problem, which one should sound the alarm?
• Who looks into it?
• And what happens when their results don't agree?

If responsibility isn't defined, adding more monitoring might lead to teams dealing with multiple alerts and disconnected evidence. So a combined strategy involves more than just technical interconnections. It requires a defined process for handling incidents with well-documented ownership of detection, investigation and remediation.

What Should Enterprises Evaluate Before Choosing an Approach?

You can best judge a data observability architecture by looking at the systems an organisation really runs and the problems it needs to investigate. A feature list can tell you what a platform claims to support. Testing a real-life situation tells you if those capabilities work together when the organisation needs them.

Can you trace an incident across platforms?

Start with a business-critical data flow across multiple platforms. For example, an AI application may produce an incorrect customer recommendation. Can the monitoring architecture tell what information the application used, where that information came from and whether it changed along the way? 

That question calls for more than an alarm. Teams may need data lineage, transformation records, execution logs and information about affected datasets. Open standards can help make some of this evidence easier to share. The OpenLineage specification for data lineage provides a uniform way to describe jobs, their execution and the datasets they consume or produce. 

Meanwhile, OpenTelemetry provides a standard for collecting application and infrastructure signals such as logs, metrics and traces. The project reached CNCF graduated status in May 2026. These standards serve different objectives, and neither offers complete data observability. 

But they can help organisations connect evidence from systems that would be difficult to investigate in isolation.

Can governance and incident response stay consistent?

Finding a problem is only useful if the organisation knows what to do about it. Ownership records and escalation procedures may differ by platform. One system may consider a delayed dataset important, whereas another system may consider the same delay normal. 

This makes it more difficult to keep data reliability rules consistent, especially when the same data is used by different teams. According to the 2026 State of AI Reliability study by Monte Carlo and CDO Magazine, only 19% of the senior data and AI executives surveyed said they have unified observability across data and AI systems. 

A further 37% said they used separate approaches that weren't well integrated. Those findings describe fragmented monitoring, but don’t show whether embedded or independent approaches are more successful. For enterprise architecture decisions, the practical questions concern accountability.

• Who is notified?
• Who knows which applications are affected?
• Who determines if an automated workflow should be suspended?

Teams need to have access to the records behind those decisions, especially when examining incidents after they've been addressed.

Can you retain control if your platforms change?

Integration platforms are long-term investments, yet enterprise architectures are rarely static. Organisations add new applications, update existing systems and change vendors as their requirements evolve. Their monitoring architecture has to be able to cope with those changes without losing essential operational information. 

That makes interoperability something to consider before you commit to an embedded observability approach.

• Can the platform export monitoring events, lineage records and incident histories in a format other systems can use?
• Can an independent tool access the data required for investigations?
• And if the organisation switched to a different integration platform, would the historical evidence still be there?

Open standards can help eliminate some of those dependencies, but supporting a standard doesn't ensure that the product exposes every useful detail through that standard. There are financial considerations as well. Embedded monitoring could remove the requirement for further integrations or tools but could introduce migration costs down the line.

Independent monitoring has its own costs in terms of licensing, maintenance and integration effort. The point isn't to get rid of vendor dependency altogether. It's to identify what capabilities and data the organisation would struggle to replace, and whether those dependencies are acceptable.

How to Decide Where Data Observability Belongs

Having identified the trade-offs, the next step is to test them against the organisation's real data environment. Instead of starting with a platform demo, identify the data flows that enable critical business processes. 

Pay particular attention to information that automated systems use. Errors there may lead directly to actions. Then do a practical assessment:

• Map the vital data flows. Identify the systems involved, where the information changes and what applications rely on the outcomes.
• Identify monitoring gaps. Find out what each platform can see and where its view ends.
• Test an incident that spans multiple platforms. Introduce or simulate a controlled data-quality failure and evaluate if teams can determine the root cause and downstream impact.
• Assign operational ownership. Determine who detects, investigates and resolves incidents, including incidents across several platforms.
• Consider the evidence and exit options. Verify what monitoring information may be exported, retained and reused should the architecture change.

The results will help assess if embedded capabilities give adequate coverage, if an independent layer is needed or if a combination is more practical. It's also worth repeating the assessment when conditions change. 

A monitoring strategy that works for today's integrations may not be enough when new apps, automated workflows or data platforms are deployed.

Final Thoughts: Data Observability Must Extend Beyond Platform Boundaries

It makes sense to extend data observability into enterprise integration platforms. These technologies already control major aspects of how information flows within an organisation, and closer monitoring could make some problems easier to identify and solve. But the organisation’s responsibility for reliable data doesn't end when it leaves an integration platform. 

As organisations connect more systems and give AI more influence over business processes, they need to understand what happens to information on its journey. This requires monitoring systems that allow for investigation and accountability beyond the boundaries of separate platforms. 

The right architecture is the one that enables teams to follow a problem wherever it goes, understand its consequences and take action. It’s a helpful idea to take into wider enterprise data architecture considerations, particularly as integration, automation and operational reliability grow more tightly connected. 

It's also a question that sits at the heart of EM360Tech's ongoing conversations about how enterprises can maintain visibility and control as their technology environments become more complex.