Someone asked me why SOM didn't exist before. It's a good question. Manufacturing invented the BOM decades ago. Sima Qian invented the annals-biography format 2,000 years ago. The principle is simple: define the unit, assign an ID, connect everything. So why hasn't the software industry done this?

It's not a technical reason. The technology was there all along.

It's an organizational reason.

The Food Chain

Every software project has a food chain.

Project Hierarchy
Management
Commissions the project, controls the budget, defines success. Has the authority.
↓ pressure
PM
Coordinates schedule and scope. Reports up, directs down.
↓ pressure
Planners · Devs · QA · Ops
The people who actually build and maintain the software. Where the pain concentrates.

In this structure, quality problems originate at the bottom — and the bottom is where they hurt.

Planners have no language to verify that what they designed was actually built. Developers work overtime writing test documentation retroactively, the night before a deadline. QA translates their findings into coverage numbers and sends them up, but management can't truly read what those numbers mean. Operations inherits a delivered system with no clear record of what was tested, and meets failures cold.

The pain concentrates at the bottom. The authority to change the structure sits at the top.

Why the Structure Never Changed

From management's perspective, the current structure works fine.

The project gets delivered. The audit passes. The coverage number clears the threshold. Whether that number actually means anything — which features were verified, which ones have gaps — there's no particular need to know. When problems surface, accountability flows downward anyway.

If planners can't read test results, that's not a management inconvenience. If the PM can't interpret quality metrics, that's not a management problem. If reports arrive in a language only developers can parse, management looks at the number and signs.

The Core Structure
The people who feel the problem have no authority.
The people with authority don't feel the problem.

This is why the structure hasn't changed in decades.

26 Years of Watching It Up Close

I spent 26 years in the field. Six of those years were in ITO — IT outsourcing engagements.

In ITO, the food chain is even more visible. There's the client and the vendor, and within the vendor there's another hierarchy. The definition of project success is the client manager's signature. Every person below that line is working toward that signature.

In those environments, I saw the same things repeat.

Field Testimony · 26 Years
  • Deliverables written retroactively. All-night spreadsheet sessions two days before the deadline.
  • "I'm not sure what this coverage number means, but it's above the threshold so we're fine."
  • Planners with no way to verify the build — so they just trusted what the developer said.
  • Post-delivery failures with no trail. Nobody could trace what had gone wrong or why.

If this were a technology problem, it would have been solved long ago. The technology was there.

It's a structural problem. A structure in which the people who suffer cannot change the structure.

Staring hard at that — painfully — a single question formed.

"What if everyone at the bottom
could speak the same language?"

What SOM Actually Does

SOM cannot change the structure.

It cannot make management care about quality. It cannot stop clients from treating delivery metrics as the only truth. It cannot dissolve the food chain itself.

But it does one thing. It makes things visible.

What SOM Changes
With SOM IDs, planners can read test status directly. QA doesn't need developers to translate their numbers. Operations can look up exactly which features were verified and how. PMs can see for themselves which functions are affected by this release.

The people at the bottom of the food chain can finally speak to each other in the same language.

In ways that are hard for management to notice, the information asymmetry quietly shrinks.

Code Is Equal, But

Code is equal. Code written by a first-year planner and code written by a 26-year veteran stand before the same compiler as equals. It works or it doesn't. One or the other.

But the organizations surrounding that code are not equal. Quality in software isn't defined by compilers — it's defined by people. And between those people, there is hierarchy.

Software quality management existed for so long only in developers' language not because developers were uniquely selfish. It's because the system was designed that way. Pressure flows top-down. Information struggles to flow bottom-up.

SOM is the attempt — within that structure — to find a way for the people at the bottom to connect with each other.

Not a Perfect Answer

There's something I want to be careful about in writing this.

I don't want to claim that SOM solves organizational inequality. That would be an exaggeration. It would be a lie.

But this much I can say: when information becomes transparent, accountability becomes transparent. When everyone can see which features were verified and which ones have gaps, "I didn't know" is no longer a valid answer.

What is visible is hard to ignore.
That is the small but real force SOM can exert in the field.

A Closing Thought

SOM was not born in a laboratory.

It was born in the field. From retroactive documentation the night before a deadline. From coverage reports no one would ever read. From histories that scattered after delivery and were never recovered. Looking hard and painfully at all of that — this is what came out.

If this theory one day becomes a paper, a standard, a tool — it should return to the people who suffer in the field. Not to make management reports look more impressive. But for the day when planners, developers, QA engineers, and operations teams can finally speak the same language.

SOM is pointed in that direction.

For those who are still in that field today...