The boundary that prevents the three-in-the-morning argument

There is a conversation that plays out the same way in every company, always in the middle of the night and always with the same lines. "This is an infrastructure problem." "No, the infrastructure is up, this is the application." Meanwhile, the service is still down and the clock is ticking.

That argument isn't won with reasoning at three in the morning. It's avoided by writing down the boundary beforehand, when nobody is on edge.

Why the boundary always ends up blurry

Because the interesting part of the system is precisely the part in the middle. Nobody argues about who is responsible for the hypervisor or who writes the application code. The arguments are about the database engine, the certificate that expired, the scheduled task nobody remembers creating, the queue that filled up, the service someone left on manual.

It's the zone where the infrastructure provider says "I deliver a healthy machine" and the application team says "I deliver working code", and both are right while the user still can't issue invoices.

A matrix that actually works: component by component

Our split is explicit and signed before we start. The cloud platform and the operating system are ours: availability, patching, monitoring, backups and security posture. The database engine and the application layer remain the client team's responsibility, with one clarification that matters: we provide technical support on the engine, included at no additional cost, because refusing to look at a database while the service is down is an expensive way to be right.

For a matrix to work, each row needs four things, and almost none include them:

• The component, named precisely. "Database" is not a component: the engine, the instances, the backups, the storage and query performance are, and they can have different owners.
• Who operates and who decides. Executing a change is not the same as authorizing it.
• What happens outside business hours. A responsibility that only applies Monday to Friday leaves a two-day gap.
• The rule for the unexpected. No document covers every case; what can be defined is who coordinates while things get sorted out.

The commitment that makes the matrix hold

Writing down the split isn't enough without response times to back it up. For a critical incident, thirty minutes to respond and four hours to resolve, with coverage seven days a week and progress updates every hour. And if a case isn't moving forward, it escalates on its own: to the service coordinator at sixty minutes, to the solutions architect at one hundred twenty and to operations management at two hundred forty.

That last part is what gives the most peace of mind, and not because of the number: because of what it means. The client doesn't have to push the case. It doesn't depend on someone from their team staying awake and insisting for the issue to move up a level.

How it's built, in practice

1. A real inventory of components, taken from the environment and not from a three-year-old document.
2. A joint walkthrough, with the client's application team in the same room, row by row.
3. The awkward cases first: the certificate, the scheduled task, the overnight job nobody claims.
4. A review whenever the environment changes, not once a year because the calendar says so.

It takes half a day. The incident in which you discover nobody wrote it down takes a lot longer.

If you'd like to see what that boundary would look like in your case, write to us and we'll draw it with your inventory.