What Is Business Observability?

The new business observability platform is live. Eight executive dashboards. Eighty-four KPIs. Real-time refresh on the metrics the leadership team named as critical.

The CFO calls a question into the meeting that nobody on the dashboard team can answer with the dashboard. The data is in there, somewhere. The question was not in the spec.

I have lived this on green screens, where dspjoblog-first tells you everything that happened on the system in painful sequential detail and tells you almost nothing about whether the business outcome was the one the company expected. The joblog is omniscient about execution. It is silent about meaning. The job that ran flawlessly produced the wrong result because nobody declared what the right result was.

Business observability platforms are the same instrument with a friendlier UI. The telemetry is good. The dashboards are pretty. The questions the platform was configured to answer are answered with high fidelity. The question the executive actually has at 2 p.m. on a Tuesday is usually not one of those questions.

Step One — The Wrong Assumption

"We have a business observability platform. We have visibility."

"We deployed the platform, configured the eight executive dashboards, and the leadership team gets real-time metrics. We have visibility into the business."

The first instinct treats observability as a tooling problem. Pick the platform, ingest the metrics, configure the dashboards, declare visibility. The premise is that the dashboards are the visibility — that if the right numbers are on the right screens, the business is observable.

The premise is wrong because dashboards answer the questions they were configured to answer. They do not, by themselves, answer the next question, which is almost always the one the executive actually has. A platform with eighty-four KPIs is a platform that has answered eighty-four pre-written questions. The eighty-fifth question is the one that matters today, and it requires either a new dashboard, a new ingestion path, or an analyst with custom-query access — none of which the platform's "visibility" claim accounted for.

Step Two — The Partial Signal

Three of four telemetry layers are healthy. The fourth is whether anyone knows what to ask.

The technical layers of observability are well understood. Logs, metrics, traces — the three pillars from the SRE world — are now joined by a fourth, "business events": revenue posted, contract signed, support ticket resolved, KYC passed. Vendors sell the integration of all four layers as the differentiator of "business" observability versus the operational kind.

The four layers can be measured cleanly. What none of them tells you is which question is currently being asked. Telemetry without a question is data. Telemetry with a question is observation. The platform's responsibility ends at producing telemetry; the question-formulation responsibility lives with humans, and humans are the limiting factor most rollouts ignore.

This is the partial signal. Coverage of the four layers rises. Question-formulation maturity stays roughly constant, because no platform can solve it. The dashboards look comprehensive and the executive's actual question still requires a custom analysis run by someone who understands both the business and the data model.

Step Three — The Failed Fix

You add more KPIs. The dashboard becomes unreadable.

The natural response to a question the dashboard cannot answer is to add the metric the dashboard was missing. The platform makes this easy — that's its core value proposition. After two quarters, the eight executive dashboards have grown to fourteen, the eighty-four KPIs have grown to two hundred, and the executive whose question prompted the additions stopped opening the dashboard around month three.

The reason is straightforward and demoralizing. A dashboard with two hundred metrics is harder to read than a dashboard with eighty-four, which was already hard to read. The information density crosses the threshold where humans stop pattern-matching and start asking analysts to interpret the dashboard for them. The platform that was supposed to give executives self-service visibility ends up generating the same analyst-mediated reports it was meant to replace.

The fix did not fix anything because it added density without adding intelligibility. More metrics is not more visibility. It is, past a threshold, less.

Step Four — The Real Failure

It was never a tooling gap. It was that nobody owns the question-formulation layer.

The actual failure is in the absence of a function whose job is question formulation — deciding which questions the business needs answered, in what form, by whom, on what cadence. Observability platforms produce telemetry. Question-formulation produces the spec for what telemetry to surface. Programs that fund the platform and skip the function produce comprehensive telemetry attached to last year's questions, and the gap between last year's questions and this year's questions widens every quarter.

The IBM i operations specialist learned this in the 1990s, on different hardware. The joblog had every answer in it. The art was knowing which question to ask of the joblog, which message ID to grep for, which subsystem to inspect. The skill was not running the joblog — running the joblog is automatic. The skill was knowing what to look for. Modern business observability is exactly this skill, applied to a richer telemetry surface, and it is exactly this skill that platforms cannot ship.

Programs that work at the platform layer alone produce visibility into the questions the platform was configured for. Programs that build a question-formulation function alongside the platform produce visibility into the questions the business actually has. The two are not the same investment. Most rollouts fund the first and assume the second will emerge. It does not.

Step Five — The Definition

Now the definition lands.

Business observability is the continuous instrumentation of business outcomes — revenue, contracts, customer health, operational throughput — alongside the technical telemetry that produces them, organized around questions the business needs answered rather than metrics the platform happens to expose. The platform is the instrument. The question-formulation function is the discipline. Programs that ship the first without the second produce comprehensive answers to questions nobody is currently asking.

Most definitions describe business observability as the unification of technical telemetry with business KPIs. The description is accurate and skips the discipline that makes the unification operational. The discipline is question formulation: deciding what to look at, why, and when the answer should change behavior. Without it, the platform is a more elaborate version of the joblog, which has been telling operators everything and answering nothing for thirty years.

The art is not the platform. The platform makes the art possible. The art is knowing what to ask.

What Solix Enforces

Observability lives at the boundary; the records are what survive the platform.

What Solix's governance and archival platform enforces in this category is the data layer underneath the observability platform — the archived, queryable record of business events that survives the platform's lifecycle, the vendor's roadmap, and the question-formulation function's quarterly reorganization. When the executive's eighty-fifth question lands, the answer is in the archive even if the dashboard does not yet exist for it.

For SAP ECC, Oracle E-Business Suite, custom application retirement, and the long tail of operational systems whose data feeds business observability, the same model applies. Records survive the source system. The questions the business asks of those records can change without the records having to be re-captured. The observability platform becomes the latest consumer of a stable archive, not the system of record itself.

Three things to do this week

• Audit the gap between dashboarded KPIs and executive questions. List the questions executives have asked in the last quarter that required custom analysis. Compare them to the metrics on the executive dashboards. The diff is your question-formulation gap. Programs with diffs greater than 30% are ones where the dashboard is theatre, not visibility.
• Name the function that owns question formulation. If the answer is 'the analytics team' or 'data engineering' or 'whichever director funded the platform,' the function does not actually exist. Question formulation needs a named owner with authority to commission new dashboards, retire old ones, and connect new telemetry sources. Without a named owner, the platform drifts toward whatever was easy to ingest and whatever was politically convenient to display.
• Co-locate the platform with a real records archive for the underlying events. The platform answers today's questions. The archive answers tomorrow's questions about today's data. Programs that fund the platform and treat the underlying event store as ephemeral end up unable to retroactively answer the questions that turn out to matter. Build the archive once, expose it through whatever observability platform is current, and accept that the platform will be replaced before the archive is.

References

• Forrester Research — The Forrester Wave™: Data Governance Solutions, Q3 2025. Report ID RES184107
• Gartner Peer Insights, market category — Augmented Data Quality Solutions. Reviewed 2026
• Gartner — Data Quality (topic page).