Case study · Anonymised client
Turning observability into a decision system, not a dashboard collection
An organisation already had metrics, logs and dashboards. Release and architecture decisions still relied heavily on tribal knowledge because telemetry did not answer the risk questions teams actually had to decide.
- Industry
- Software and digital services
- Region
- Europe
- Decision to make
- What observability architecture supports change-risk decisions without rebuilding the entire telemetry stack?
Intervention
What we delivered
- Decision-oriented observability map
- Architecture options with explicit trade-offs
- Adoption sequence and ownership recommendations
Observed impact
What actually changed
- Signals required for release decisions were separated from nice-to-have telemetry
- Tool expansion was deferred until ownership and decision questions were resolved
- The architecture trajectory became explainable to both engineering and governance
The real problem
The client did not lack data.
Metrics, logs and dashboards already existed. Yet when teams had to approve a release or assess a risky change, they still went back to the same people who could reconstruct dependencies and likely consequences from memory.
The problem was not telemetry volume. It was telemetry’s relationship to decisions.
What we found
Dashboards answered some operational questions well: saturation, component availability and infrastructure state.
They answered much less reliably:
- which service could be affected by a change;
- which signal should actually allow or block a release;
- who owns that signal;
- which missing evidence should stop a decision.
Adding more collectors or dashboards would have increased information volume without correcting that design flaw.
Our intervention
We reversed the usual reasoning.
Instead of starting from available tools, we started from the decisions teams needed to make: go/no-go, change risk, incident ownership, potential impact and expected evidence.
For each decision, we assessed the existing signals, identified gaps, then designed a target architecture and adoption sequence that preserved what was already useful.
The trade-off
The choice was not “which new tool should we buy?”
The choice was to defer part of the technical expansion until the minimum evidence set, ownership model and decision questions were explicit.
That avoided an expensive greenfield replacement while giving subsequent investment a clear direction.
What changed
Telemetry stopped being discussed only as a technical stack. It became connected to identifiable decisions.
Teams could distinguish a signal required for a release decision from a dashboard that was merely useful for operational comfort. The architecture trajectory became easier to defend with both engineering and governance.
What we learned
An observability platform does not create confidence because it collects a lot of data.
It creates confidence when a team knows which question each signal can answer, who owns it, and what happens when that signal is missing.
Evidence scope and publication limits
Published outcomes for this case are qualitative. No number is added without a verifiable baseline.
Limits
- Published outcomes are qualitative; no latency, error-budget or MTTR delta is claimed
- The context is anonymised and bounded to the architecture decision reviewed
Out of scope
- No full OpenTelemetry migration during the engagement window
- No organisation-wide vendor consolidation
Remaining uncertainty: The model must evolve with new services, dependencies and vendors to remain useful.
Facing a similar decision?
Frame the problem before starting a programme.
Omnivya works on cloud, platform, Kubernetes, reliability and observability decisions when the cost of a wrong trajectory exceeds the cost of a review.