Why Layer 8

The OSI model defines seven layers and stops. Network engineers filled the gap with a joke: "layer 8" is the user. Same family as PEBKAC and ID-10-T — a way of closing a ticket by assigning blame upward, out of the stack.

I named this blog after the insult because it points at the right layer and blames the wrong person.

After years of building and debugging SAP data platforms — Datasphere, SAC planning, ABAP underneath — I can count the genuinely technical failures on one hand. The expensive ones all live above layer 7. But they're not the user at the keyboard. They're the modelling decision from a workshop two years ago, the assumption someone baked into a hierarchy, the org chart that decided which team owns which space, the review nobody ran.

The machines return 200

These platforms almost never fail loudly. They fail quietly and correctly: the job runs green, the API returns 200, the data action reports success — and a wrong number lands in front of a human who acts on it.

My favorite specimen, from a productive planning system. An advanced-formula parameter, left empty by the planner. Wrapped in BASEMEMBER(...), empty means "all members". Used raw in a MEMBERSET, empty collapses to the dimension's default member — usually #, the unassigned bucket. One spelling difference. In one initialization run it silently narrowed the scope to # and dropped a nine-figure amount. Run status: successful. Error count: zero.

Datasphere keeps its own collection — previews that lie, persistence that quietly unschedules itself. I've inventoried those separately, and the planning side gets its own article too. None of them is an outage. Every monitor shows green. Someone downstream got a number, trusted it, acted on it.

Where the failure actually lives

Call that person the layer 8 problem and you've closed the ticket and learned nothing. They did everything right.

Trace the mechanism backwards instead and you land, every time, on a human decision made long before the run — usually a defensible one. Who chose the default member. Which workshop assumed version dates would get maintained. Why the space cut falls where it falls, so the team consuming a view never opens the task log where its persistence got cancelled.

These aren't defects. They're coherent, documented behaviours — some documented by SAP, some only in my field notes. What turns them into incidents is distance: in time and in org structure, between the person who made the assumption and the person who inherits it. The git blame of a data model is a meeting minute, and it's usually not written down.

What this is

Field notes from productive SAP data-platform work — plus whatever else I'm building: a homelab that keeps getting out of hand, AI agents, occasionally the garden. The durable artefacts live in the Datenrösterei repository; the next article walks through what's in there.

Two ground rules. I build on these products daily, which earns them neither cheerleading nor bashing. And every claim gets marked as documented behaviour or field observation — the first changes with release notes attached, the second rots silently, quarterly.

Below layer 7, failure is legible: timeouts, stack traces, red jobs. Above it, failure arrives dressed as success. Layer 8 is where success codes stop being evidence — that's the layer I write from.