The way software is built has changed.
Ten years ago, the backend server generated HTML directly and pushed it to the browser. UI and logic were one piece. Testing a single feature meant verifying both at once.
Today it's different. Frontend and backend are separated. React, Vue, Next.js own the screen; dozens of microservices supply data through APIs. The two worlds move independently, connected only by an API contract.
This structural shift poses a question for QA: When UI and backend deploy independently, what should be the reference point for quality?
The Age of the UI Facelift
The automotive industry has a concept called a "facelift" — a mid-cycle update that refreshes the exterior and interior before the full next-generation model arrives. The engine and platform stay the same, but what the user sees and touches changes.
In software, the UI is increasingly operating this way. Backend APIs remain stable while user-facing screens change frequently. Design systems get updated. Button positions shift. Form fields are rearranged. Not a complete redesign — repeated partial UI changes. The function stays the same, but the appearance changes.
The problem is that these UI changes quietly break tests. Selector-based tests fail when a button ID changes. Path-based tests break when routing structures change. Nothing functional changed — but the test script collapses. When this repeats, teams stop trusting their tests.
SOM's five layers were designed with exactly this problem in mind.
The Five Layers of SOM
Moving downward, units get smaller and change more frequently. Moving upward, units get larger and carry stronger business meaning.
Layer 1 — Project
The largest unit — the entire software system as a whole. "Government civil service portal," "internal HR management system," "e-commerce platform." The unit an organization commissions and receives. The outermost boundary of quality management.
Layer 2 — Module
A Project divided by functional domain. "Member management," "order processing," "reporting and analytics," "admin settings" — areas grouped by business domain. Often aligns with how development teams or squads are organized. Module is the reference point for impact analysis: if defects keep repeating in a particular module, that's a signal of a structural problem in that module's design or development approach.
Layer 3 — Program (SOM ID assigned here)
The most critical layer in SOM. A Program is a screen or process unit that a user approaches with a single purpose — "sign-up screen," "password change," "order history," "monthly sales report." It roughly aligns with the unit in which a planner writes a screen definition, a developer creates a Controller, and QA writes a test scenario.
This is where the SOM ID is assigned. The moment SOM-0042 is attached, this Program becomes an asset. Planning, development, testing, and documentation all connect under this ID.
Even when the UI undergoes a facelift, the Program does not change. "Password change" as a function retains its identity regardless of whether the button color changes or the input fields are rearranged. The SOM ID is a stable anchor that doesn't shake with UI changes.
Layer 4 — Component
The UI element units that compose a Program. "Email input field," "password confirm button," "error message area" — the units users directly interact with. What frontend developers build as components.
The Component layer is most directly affected by facelifts. A button becoming an icon, a dropdown becoming a toggle — these changes happen at the Component level. Critically, they do not affect the parent Program's SOM ID. The blast radius of the change is contained within Component.
Layer 5 — Action
The most atomic unit of interaction with a Component. "Click," "type," "select," "scroll," "drag" — a single user gesture. What automated test code calls click(), fill(), select().
Action is the minimum unit of test automation — the most technical and most frequently changing of the five layers. But when Actions change, Components are preserved. Programs are preserved. SOM IDs are preserved. Lower-layer changes don't destabilize upper layers.
How Layers Create Change Resistance
What about a backend API change in an MSA architecture? APIs are tracked at the Program layer. By using SOM to identify which Programs use that API, the affected test scope is immediately pinpointed. Instead of re-verifying everything, only the affected Programs are precisely re-verified.
The five layers are a structure that absorbs change — not by preventing change, but by controlling the scope of how change propagates, layer by layer.