The Mid-Market Data Operating Model: DBA + Platform + Governance + Insights

Most mid-market companies buy data capability the way they buy furniture: one piece at a time, whenever a specific room feels obviously empty. A DBA gets hired or outsourced when performance complaints get loud. A BI tool gets bought when the board asks for better reporting. A governance policy gets written when a customer's procurement team asks for one. Each purchase solves its immediate problem and creates almost no connection to the others.

The result, a few years later, is a collection of capabilities that don't operate as a system: database administration that has no visibility into the data quality problems downstream, an analytics function built on pipelines nobody is watching, and a governance document nobody consults when decisions actually get made.

A data operating model is the alternative: thinking about database administration, data platform/engineering, governance, and insights as four connected parts of one system, rather than four separate purchases. This article lays out what that model looks like for a company roughly 50-200 people in size, and how the parts should actually connect.

The four parts, defined simply

Bought separately, each of these is a reasonable capability. Connected, they become something more valuable: a system where a problem discovered in one part is visible and actionable in the others.

Why the connections matter more than the individual capabilities

DBA feeds platform engineering

Database performance problems are frequently symptoms of platform design decisions: a poorly designed integration hammering the database with inefficient queries, a pipeline pulling far more data than necessary because nobody optimised the extraction logic. When DBA and platform engineering are disconnected, performance issues get treated as purely infrastructure problems and get "fixed" with more hardware rather than better pipeline design. Connected, a DBA function that understands the platform layer can trace performance issues to their actual root cause.

Governance feeds both DBA and platform engineering

Access control decisions (a DBA function) should be driven by classification decisions (a governance function), so restricted data has visibly stricter access controls than public data, and that mapping is explicit, not ad hoc. Similarly, pipeline design decisions (retention, what gets moved where) should reflect governance policy on data lifecycle, not just technical convenience. Without this connection, access problems and unmanaged data stores proliferate because nobody connected the policy layer to the implementation layer.

Observability feeds governance

When observability catches a data quality issue, a schema change or a volume anomaly, governance is what determines who is accountable for the fix and what "acceptable" looks like going forward. Without that connection, observability findings pile up as alerts nobody owns resolving, which is functionally the same as not having observability at all, just with better documentation of the neglect.

Platform engineering feeds insights reliability

The dashboards and reports the business actually sees are only as trustworthy as the engineering underneath them. This is why investment in reporting tools without proper data engineering so often disappoints, because the visible layer looks like the deliverable, but it's entirely dependent on unglamorous pipeline work that doesn't show up in a demo.

What this looks like when it's NOT connected (the common failure state)

This is the default state for most mid-market companies who bought capabilities individually over time:

• A DBA (internal or outsourced) manages database performance in isolation, unaware of what pipelines are doing to the workload
• A data analyst or small team builds reports against whatever data happens to be available, without governance input on whether that data is the "right" version of the truth
• A governance policy document exists, referenced maybe once a year during an audit, disconnected from daily technical decisions
• Nobody is watching pipeline health proactively, so issues surface as complaints about wrong numbers rather than as caught, resolved incidents

Each piece might individually look "fine" in isolation. The system, taken together, is fragile, because nothing connects a problem discovered in one place to a fix implemented in the right place.

Building the connected model without enterprise bureaucracy

The good news: connecting these four parts does not require an enterprise data office, a Chief Data Officer, or a large platform team. It requires:

1. Shared ownership language: the same named domain owners should be the reference point whether the question comes from DBA, engineering, governance, or reporting
2. A single roadmap, not four: DBA priorities, engineering priorities, governance initiatives, and observability coverage should be sequenced against one business roadmap, not four separately-scoped project plans
3. Shared visibility: findings from any part (a performance issue, a quality gap, an observability alert) should be visible to the others, not siloed in separate tooling and separate teams who never talk
4. One point of coordination: whether that's an internal fractional lead or an embedded outsourced team covering multiple parts of the model together

This is a significant part of why the "as a service" model, whether for database administration, the data department, governance or observability, works better when delivered by a provider capable of covering multiple parts of the model, rather than four completely separate vendors with no reason to talk to each other.

Maturity is sequencing, not completeness

You do not need all four parts fully mature simultaneously. A realistic maturity path for most mid-market companies:

1. Stabilise the database layer: reliable performance and backup/DR as the foundation nothing else can work without
2. Establish basic governance ownership: named owners for critical domains, even before full classification and cataloguing
3. Build platform engineering capability: proper pipelines and integration, replacing ad hoc spreadsheet-and-script logic
4. Add observability: proactive visibility once there's enough pipeline complexity to justify it
5. Deepen governance: classification, cataloguing, and policy enforcement layered on top of the ownership foundation

Each stage should connect to what came before it, which is the whole point of thinking about this as one model rather than four independent purchasing decisions.

One system, not four purchases

A data operating model connects database administration, platform engineering, governance, and observability/insights reliability so that a problem found in one part gets fixed in the right part, instead of four capabilities operating in isolation, each blind to what the others know. Mid-market companies don't need enterprise bureaucracy to achieve this connection. They need shared ownership, one roadmap, and visibility that crosses the boundaries between these four functions.

If your current data capability feels like four separate relationships rather than one coherent system, that disconnection is very likely costing you more than any single missing capability would.

Next step: Talk to us about how these services connect for your specific estate, or start with an assessment that maps where your current model has gaps between the parts.