Beyond the SW Architectue
Software ArchitectureOriginal Context:
Today’s vehicles are often described as “computers on wheels.” OTA (Over-The-Air) updates have become routine, dozens of ECUs are connected over complex networks, and software now interprets driving environments in real time while coordinating both safety-critical and convenience features. We have clearly entered the era of the SDV (Software-Defined Vehicle). Yet, despite this massive technological shift, one fundamental failure continues to repeat itself inside automotive software organizations - and it is strikingly primitive.
Architecture dies in documents, while implementation survives in code.
Over time, this gap widens, eventually dragging entire organizations into the swamp of technical debt.
Organizations proudly proclaim:
“We follow the V-Model.”
“We’ve adopted Agile and CI/CD.”
“We comply with ISO 26262 functional safety processes.”
But the reality experienced by developers on the ground is often the exact opposite:
“The architecture document isn’t up-to-date.”
“The architecture is only a reference; it doesn’t match the real implementation.”
“We don’t have time to update documentation because of deadlines.”
“When changes happen, implementing and testing quickly is more urgent.”
“Schedules are tight, so we don’t have enough time or people for proper reviews.”
In many automotive software teams in Korea, architecture becomes something everyone agrees is necessary, yet quietly accepts as something that inevitably diverges from actual development. Its presence is symbolic - acknowledged, but rarely lived.
The more I reflect on why this happens, the clearer it becomes that the root cause is not a single issue. It is the combined result of organizational habits, cultural tendencies, developer psychology, leadership pressure, and how processes are actually practiced - not how they are documented. And unfortunately, no matter how many times a company changes its development model, the same cycle will continue as long as the organization does not truly respect architecture as an essential discipline.
1. Processes Evolve, But Mindsets Do Not
Agile, DevOps, MLOps, and CI/CD are no longer unfamiliar terms in the automotive industry. We use these words frequently, and on the surface it appears that our development practices have evolved. But there is a fundamental question we must ask:
“The process has changed, but has our mindset changed with it?”
In many cases, what people call Agile is nothing more than a Waterfall process broken into smaller pieces. DevOps often means little more than a CI server and a branching policy. A Sprint is frequently just a different name for schedule pressure. In other words, we have imported the form of modern processes, but have neglected the thinking behind software design and architecture - the very essence that should guide development.
As a result, development activities continue to revolve around modifying and updating code, while architectural artifacts quickly fall out of sync. When requirements change, developers focus on updating code first, and updating architecture documents becomes a “nice-to-have” - something nobody has time for. Organizations produce countless templates and guidelines in the name of process compliance, yet few truly understand when or how they should be used. In many cases, this becomes just another box to check rather than a practice that supports real engineering discipline.
In Software Architecture in Practice (2012), software architecture is defined as “a set of structural decisions and quality attributes.” However, in many software organizations, these structural decisions are treated as nothing more than documents, and quality attributes are mistakenly seen as something that can be verified only at the testing stage. This mindset undermines the role of architecture, rendering it largely meaningless in practice. In the automotive domain where I work, I see this problem even more frequently and more severely.
2. Structural Pathologies Repeated in Automotive Software Organizations
When you closely observe automotive software organizations, you begin to notice a strange and unsettling pattern: the same failures recur again and again, regardless of the individual competence of the engineers involved. Developers work late nights, leaders speak about responsibility, and organizations call for improvement - yet projects keep returning to the same miserable outcome. They begin with “This time will be different” and end with “Next time, we’ll do better,” only to repeat the same pitfalls in the next cycle. At some point, I couldn’t help but wonder whether these failures are not accidental at all, but symptoms of structural pathologies embedded in automotive software organizations.
“Right now, the architecture isn’t the priority. The schedule is.”
The first and most visible symptom is that timelines outrank architecture. Automobiles operate under numerous constraints: safety, security, regulations, certification, quality, and lifespan. Yet, the metric that dominates leadership discussions is not structure, quality, or long-term sustainability - but the SOP date. The schedule becomes a sacred value that must never be touched, while architecture becomes a negotiable item that can always be sacrificed. In that moment, architecture loses its authority, and developers begin to respond in predictable ways:
“Architecture? It may not be up-to-date, but… let me show you the code instead.”
The second pathology is a conditioned resignation among developers - “code is reality, documents are not.” Under constant schedule pressure and weak architectural governance, developers naturally learn survival tactics. They repeatedly witness that documents become outdated, while code remains the only reliable source of truth. Because automotive software engineers are exceptionally smart, they learn this truth even faster: architecture is an ideal defined before reality, while code is the reality they must confront now. Applying changes quickly, testing fast, and shipping a fix becomes more valuable than maintaining a coherent architecture. Inevitably, architectural documents fall behind and eventually lose meaning.
The third pathology is organizational siloing. An automobile is a system-of-systems: ECUs, functional safety logic, networking, middleware, applications, and increasingly cloud-connected services. Yet the organization decomposes this complexity into narrowly defined teams. The problem is that no one owns the integration gaps created between those boundaries. Each team optimizes locally and rationally, but from a vehicle-level perspective, the system collapses into inefficiency or fragility. This is precisely why architecture matters in automotive software: local optimization cannot guarantee global optimization.
The fourth pathology is the ritualization of reviews. Automotive organizations love process: checklists, gates, templates, signatures, and recurring reviews. But too often, reviews become ceremonial rather than directional. Instead of serving as moments where a technical decision can actually change course, reviews devolve into justification exercises for work already completed. Once reviews become rituals, architecture loses trajectory, and the organization loses speed with intention.
The final pathology is asymmetric responsibility. In automotive systems, a single mistake propagates across the entire vehicle. Yet when failures occur, the blame dissolves into the abstraction of “the system.” Decisions are made without ownership, and architecture becomes a domain where no one is held accountable. Responsibility without ownership leads to decisions without principles, and eventually to structures without integrity.
These five pathologies intertwine and shape organizational behavior. Over time, the organization stops controlling complexity and instead becomes controlled by it. No matter how many times the process is changed - whether to Agile, MLOps, or DevOps - the result will remain the same if the underlying architectural mindset is not addressed.
The fundamental issue facing automotive software organizations is not technical capability - it is the mindset conditioned under structural pathology. As long as this mindset remains, architecture will continue to exist in theory but fail in reality. And the cost of this failure will eventually return, in the form of quality degradation, safety risk, and mounting financial burden.
3. Architecture Is Not a Document, but a System of Enduring Constraints
When automotive organizations talk about software architecture, what often comes to mind first is a polished diagram, a Visio file, or a PDF stored on a server somewhere. Many organizations treat architecture as nothing more than a deliverable. But in reality, architectures that exist only in documents are routinely ignored by code, overridden by schedules, and eventually abandoned under waves of change. Over time, one truth inevitably remains:
“The document is not the architecture.”
As stated earlier, the true essence of architecture is not documentation, but a system of constraints that ensures the system behaves as it should. A document can describe those constraints, but it cannot enforce or sustain them. This distinction is especially critical in the automotive domain, where software must honor strict rules across multiple systems. A vehicle is the sum of interconnected subsystems - no single ECU, software module, or line of code stands alone. Dozens of controllers, safety rules, timing constraints, communication protocols, and operating scenarios must all align for the system to function. In such complexity, architecture must serve as the discipline that preserves structural decisions and prevents uncontrolled divergence.
When architecture collapses, the system may still “work,” but it becomes something that cannot be responsibly maintained. Developers continue adding features, testers continue finding issues, and schedules continue compressing - but the internal consistency of the system decays. The vehicle becomes a structure that happens to run, rather than one that is designed to run. When field issues occur, no one truly knows why, or how to prevent recurrence. In these situations, no amount of documentation can describe reality, because architecture has ceased to govern the implementation.
A sustainable system of constraints requires three essential properties:
① Constraints must precede and govern implementation.
Unrestricted freedom in software is not creativity - it is chaos. In automotive software, constraints represent principles such as safety, security, timing, resource limits, communication rules, and separation of responsibility. Without constraints, features may accumulate, but reliability never will.
② Constraints must endure even under change.
Automotive software never stops changing - OTA updates, recalls, cybersecurity patches, and platform evolution are constant. If architectural constraints crumble at each change, the system will lose coherence over time. Good architecture does not block change - it absorbs change without losing structural integrity.
③ Constraints must be upheld by systems, not individuals.
The weakest form of architectural governance is: “Someone will remember to enforce it.” People change teams, projects, and companies. If constraints are not institutionalized, architecture degrades into fragile tribal knowledge. Sustainable architecture requires rules that persist even when humans rotate.
In this sense, architecture must function as a discipline, not a record. Documentation without discipline is a façade - an architecture that exists on paper but not in practice. Despite the rising complexity of automotive software, many organizations still equate “creating a document” with “establishing an architecture.” Reality disproves this every time.
“Documentation can explain a system, but only constraints can preserve it.”
To uphold architecture in automotive development, we must stop viewing the system as a collection of functions and instead recognize it as a living, organic structure built on consistent rules. Documentation is valuable only insofar as it serves this purpose; it is a tool for continuity - not the architecture itself.
4. Conclusion: Preserving Architecture Is Preserving the Future
Automotive software is no longer about implementing a single function. It is the ongoing effort to sustain a living, organic system composed of dozens of ECUs, hundreds of signals, thousands of scenarios, and tens of thousands of interdependent constraints. In this reality, architecture is not an optional layer - it is the minimum order required for a system to remain a system. It only has meaning when it is upheld continuously, not merely defined once.
Creating architectural documents achieves nothing by itself. Adopting a new process does not change how people think. And organizations that repeatedly choose “what works right now” over “what will remain stable later” will eventually find themselves in a place where code survives, but the system does not. In the SDV era, the true capability required is not speed in adding features, but the ability to evolve without losing structural integrity. Organizations that lack this capability will not withstand the accelerating pace of software-driven change.
The problem we face today is not a shortage of technology. We already possess abundant tools, methodologies, and processes. What we lack is the will and discipline to operate them through an architectural lens - and the endurance to enforce constraints rather than leave them on paper. Architecture is not a deliverable, nor a diagram, nor a step in a process. It is a stance, a continuous choice, and a principle an organization refuses to abandon.
Ultimately, the question becomes very simple:
“Are we here to build features, or are we here to build a system?”
If the answer is the latter, then we must move beyond document-centered architecture and embrace constraint-centered architecture. Only organizations that keep constraints alive can maintain coherence amid constant change, manage complexity instead of being ruled by it, and preserve quality in a predictable and sustainable manner. Those that do not will repeat the same failures indefinitely - and the cost of that repetition will grow harsher every year.
Automotive software has entered a phase where no innovation can survive without structural sustainability. To protect architecture is to protect the future of the product, the organization, and ultimately the customer. And the only way to prove that commitment is not through words or documents, but through consistent execution of constraints - every single day.
#SoftwareArchitecture #AutomotiveSoftware #SoftwareEngineering #SoftwareSustainability