Two things have been established so far.

Software quality management has three fractures — language, standards, and records. And manufacturing solved a similar problem with a BOM: assign a number to every part, and let that number become the common language for the entire organization.

Connect these two ideas, and one question remains: What if software had its own Bill of Materials?

The Declaration

Treat the components of software as parts.

Login screen. Sign-up process. Order cancellation function. Admin statistics dashboard. These are not merely a feature list. They are the actual parts that make up a piece of software — the things users directly hold and operate, like a car's brake disc or steering wheel.

Assign numbers to these parts. Give each one a name and an ID at the planning stage, and keep that ID alive through development, testing, operations, and documentation. Like a Bill of Materials.

This is SOM —
Software Object Model.
A system for treating software's UI components as business-unit assets

SOM organizes software components as business-unit assets — not code files, but program units. Not classes, but screen units. Not commits, but function units. And by assigning IDs to those units, it makes planners, developers, QA, and PMs all speak the same number.

When a Name Appears, Reality Appears

Philosopher Wittgenstein wrote: "The limits of my language mean the limits of my world."

The same principle applies to software quality. If there is no unique ID for "the sign-up screen," there is no way to connect its history. A name exists, but without a number, conversation is possible — traceability is not.

The moment a SOM ID is assigned, that screen transforms from a mere feature into an asset.

Assets have history. When it was planned. What requirements it carries. What tests it went through. What defects were found. Which parts of the codebase it connects to. All of this is linked under a single SOM ID.

The Asset Principle
Just as you can look up the complete history of brake disc P-4471 in a factory, SOM lets you look up the complete history of "sign-up screen SOM-0042" — at any point in the software's life.

How SOM Addresses the Three Fractures

Fracture #1 — Language
Planners, developers, and QA all communicate through SOM IDs. "Is SOM-0042 tested?" is a question everyone can answer with the same context. No developer needs to dig through file paths. No planner needs to backtrack through Jira tickets.
Fracture #2 — Standards
SOM's unit is a business unit from the start. Coverage is measured against SOM. "What percentage of all SOMs have been verified?" is a number any planner can understand immediately — not code coverage 78%, but feature coverage 78%.
Fracture #3 — Records
The unit of test execution is SOM. The unit of documentation is also SOM. Because they share the same unit from the beginning, no retroactive work is needed. The moment of execution becomes the moment of documentation.

What SOM Is Not

To be clear
SOM is not a new test tool. It does not replace Playwright, remove Jira, or overturn existing development practices. SOM is a reference framework — a layer that creates common language on top of existing tools.
SOM is not a methodology. It doesn't say "work this way" like Agile. It defines reference units, assigns names and numbers — that's all. The rest is handled by existing processes and tools.
SOM is not a silver bullet. The root causes of quality problems often lie in people, process, and organizational culture. SOM doesn't fix those. What it does is make them visible — which functions were not tested, which screens are in the blast radius of a change, where defects keep recurring.

Visible problems can be fixed. Invisible ones cannot.

The Weight of a Declaration

Declaring a new theory is not easy. The world already has many quality management methodologies: ISO 29119, ISTQB, TDD, BDD — decades of work by serious experts. Standing before them and saying "we need something different" takes a certain kind of courage.

But the field is still hurting. Test documents written retroactively the night before an audit. Coverage numbers that planners cannot understand. Function histories untraceable after delivery. No matter how sophisticated the theory, if it doesn't work in the language of the field, it doesn't matter.

SOM began in the field. In Korean public sector software delivery rooms, audit offices, meeting rooms. It was built by watching the same problems repeat. That's why its declaration is not grand. Parts. Numbers. Connection. That's it.

This essay is based on the author's ideas and experience, written with the assistance of AI (Claude, Anthropic).