Architecture's Hidden Cost: Not Wrong Tech, But Misaligned Concepts

01 One Term, Three Boundaries

In automotive electronics projects, the term "domain controller" triggers confusion across roles. Hardware engineers refer to the physical box—PCB, enclosure, connectors, thermal design. Software engineers mean the software platform running on it—base software, middleware, applications. System engineers see it as a functional collection—cockpit control, gateway, diagnostics. All three definitions are valid, but their boundaries do not overlap. During interface reviews, hardware says "domain controller excludes software," software says "domain controller ignores the box," and system says "domain controller spans both." Each is right, yet none align. The same problem occurs with "diagnostics": low-level software equates it to the UDS protocol stack; system engineers include fault detection, logging, and degradation; test engineers see it as reading and flashing codes. This is not a communication skill issue—it is a concept issue. A single word receives different boundaries from different roles, and those boundaries have never been formally reconciled.

02 The Two Halves of a Concept: Intension and Extension

A concept is an abstraction of common traits plus a human-drawn boundary. It does two things: extracts shared features from messy reality, and draws a line separating what belongs from what does not. Logic splits this into intension (core attributes—what it is, its characteristics) and extension (the range of instances it covers). A law governs them: the more detailed the intension, the smaller the extension. Adding constraints to "domain controller"—"cockpit-only," "single SoC"—narrows the extension until only one concrete form remains. Removing constraints expands it to "some controller in a vehicle region," too broad to guide decisions. This law is actionable because a concept's scope is its extension, and defining scope requires answering three questions: (1) What is included? (2) What is excluded? (3) Where is the boundary with adjacent concepts? The third question is critical—most trouble comes not from undefined terms but from adjacent concepts having their boundaries drawn in different places by different people. Many architecture problems stem from such boundary blur: content of concept A gets stuffed into concept B.

03 "System Concept" Is a Construct, Not an Induction

In engineering, "concept" has two distinct usages. The ordinary concept inductively generalizes a class of existing things—e.g., "sensor" covers all sensors, "automated parking system" captures the commonalities of all parking systems. This is epistemological generalization. The system concept (System Concept) is a forward-looking construct for a specific system yet to be developed—describing what this particular system will look like, do, and how it will operate, including its capability boundaries, environment, high-level principles, and constraints. For example, "the automated parking system for this vehicle program" is not a generalization but a dedicated solution for one car. Key phrases: "to be developed" and "this specific system." The difference is not scope size but direction: ordinary concepts summarize what already exists; system concepts envision what does not yet exist. ISO/IEC/IEEE 15288 defines the Concept Stage as producing a "preliminary high-level concept of the system" to support feasibility assessment and initial requirements. The standard notes: "Decisions made in the concept stage shape, in increasingly unchangeable ways, the possibilities of all subsequent stages." This explains why system concepts appear early when multiple alternatives are still open. A trap: "system concept" is a fixed term—do not parse it as "concept of a system." It means "high-level solution construct for this system," not "definition of the word system." Misreading it as a definition leads to skipping the very artifact that most needs repeated confirmation.

04 A Concept Is Not the System

A concept can refer to or describe a system, but it is not the system itself. System : objective entity composed of components, interfaces, behaviors—it actually runs. Concept : human abstract cognition, a label existing only in documents and minds—it cannot run. "Vehicle E/E system" is a concept; the running software/hardware, wiring, and real-time signals on the car are the system. This gap can be fatal. Because concepts live in documents and box diagrams, teams easily mistake completed documents and compliant diagrams for a built system. In reality, only labels are placed; harnesses are not routed, interfaces not integrated, code not powered on. Systems engineering literature states: "Once a conceptual model is verified to have sufficient potential to solve the problem, it becomes the blueprint for the physical system." Note: blueprint , not the building. The gap between blueprint and building is all implementation, integration, and verification work. Also, concepts need not map to whole systems; they can denote internal elements like a "diagnostic module"—still requiring a clear boundary. The abstraction level and scope depend on the purpose.

05 Clear Boundaries Yield Four Benefits

Why invest effort in drawing boundaries? Because once concepts are clear, they pay continuous dividends:

1. Responsibility boundaries enabling collaboration. Who owns domain controller hardware design, who owns the software platform, who owns cross-domain functional integration—these dividing lines are drawn by concepts. Clear lines eliminate overlap, gaps, and finger-pointing.

2. Unified semantics eliminating ambiguity. Same word, different meanings—"same term, different senses"—is the most common source of review disputes and the hardest to resolve because each side believes they are using the literal meaning. With defined concepts, cross-department communication, design reviews, and ASPICE assessments all operate in a shared language system.

3. Analytical framework supporting decomposition and risk identification. Analyzing a complex system relies on concept boundaries to decompose—first split, then see dependencies, gaps, and risk points. When concepts are fuzzy, analysis becomes guesswork and omissions are almost inevitable.

4. Organizational knowledge retention supporting reviews and compliance. A clear concept system becomes an organizational asset: onboarding accelerates, internal audits, external assessments, and functional safety reviews all build on standardized terminology.

These four benefits share a trait: they are not one-time gains. A concept defined once continues to benefit every subsequent review, every task assignment, every new hire.

Conclusion

Return to "domain controller." Three roles, three boundaries—none wrong, but never formally aligned. This is the essence of a concept: a human-sliced cognitive slice. Real-world business and systems are continuous and entangled, with no natural boundaries. Concepts are the cuts we make so human minds can understand, reason, and divide labor. Realizing this clarifies many architecture disputes: the argument is rarely about technical solutions but about two people holding different boundary understandings of the same word. Since boundaries are human-drawn, there is no single correct answer—only "does it serve your purpose?" Cut where it serves: for division of labor, cut by responsibility; for analysis, cut by decomposability; for reuse, cut by capability. Two final reminders: "System concept" ≠ "concept" —concepts generalize a class; system concepts construct a specific to-be-developed solution. Direction differs; do not mix or parse as "concept of a system." Concept ≠ system —concepts are cognitive labels; systems are real objects. Concepts can refer to systems but never run themselves.

References

ISO/IEC/IEEE 15288, Systems and Software Engineering — System Life Cycle Processes (definition of life cycle stages, including Concept Stage)

INCOSE, Systems Engineering Handbook and Systems Engineering and System Definitions (relationship of conceptual model to physical system: conceptual model is blueprint for physical system)

SEBoK (Systems Engineering Body of Knowledge), System Concept Definition (concept definition activities and relation to problem space and stakeholder requirements)

Port-Royal Logic (1662, first systematic distinction of intension and extension; inverse relationship between intension and extension)