Architecture Beyond Diagrams: ISO 42010's Meta-Model for Stakeholder Conflict Resolution

01 The Common Misunderstanding: Diagrams Are Not Architecture

In daily work, "architecture" is often reduced to three activities: drawing box diagrams, layer diagrams, and deployment diagrams; selecting technology stacks, frameworks, middleware, and main controllers; and filling out standardized documents, interface lists, and design specifications. A neat diagram, clean technology selection, and complete documentation appear to be a qualified architecture solution.

However, when engineering lands, reality is messy:

Diagram logic seems seamless, but during integration contradictions erupt frequently; timing assumptions between modules cannot align.

Layered structure looks clear, but one requirement change forces modifications across multiple layers; the system becomes tightly coupled.

Every team claims their demands are satisfied, yet when integrated, no one feels the solution is reasonable.

The root cause is not poor diagramming skills but equating "system structure" with "system architecture." This cognitive bias stems from education focusing on layered modeling, diagram drawing, and modeling languages, while workplace assessments only check diagram delivery and template completion. Few review whether the design actually resolves multi-party conflicts. Over time, diagramming ability is mistaken for architecture ability.

Only decomposing structure produces diagrams; balancing multi-party conflicts constitutes true architecture.

What is the essence of architecture? ISO 42010 provides a core concept relationship diagram that makes this clear. We first deconstruct this diagram, then redefine architecture.

02 Stakeholder Side: How Conflicting Demands Arise

First understand the standard diagram, then split the logic. The whole diagram clearly divides into left (people and demands) and right (views and design).

1. Entity of Interest

The target we develop: whole vehicle, domain controller, software system. The standard treats it as an independent node because the first step in architecture design must clarify: for whom are we building the architecture?

2. Environment

External constraints on the target system: industry regulations, external interfaces, vehicle operating conditions, service life. Environment is not optional background; it is the source of hard constraints. The same domain controller hardware, when installed in passenger vs. commercial vehicles, faces completely different compliance clauses and operating requirements.

3. Stakeholder

All teams and individuals with demands on the system: functional development, functional safety, testing, cost control, project management, end users, compliance audit.

4. Stakeholder Perspective

This is the most easily overlooked link. Conflicts arise from perspectives, not individuals. A safety engineer sitting in a review seat will view problems from a safety angle; replacing the person without changing the role leaves the contradiction intact.

5. Concern

Perspectives generate concrete demands: safety team seeks controllability and traceability, cost team strictly controls BOM expense, performance team pursues low latency and high real-time capability. The standard notes: this matter is crucial to that stakeholder.

The logical chain is clear: concerns are not produced by personal subjective will but determined by role perspectives. Pure interpersonal coordination cannot resolve contradictions; as long as roles remain unchanged, conflicts will recur.

03 Architecture Design Side: How Views Are Designed

Now examine the right side of the diagram, which responds to various demands.

1. Viewpoint

A fixed set of observation rules: from which dimension to cut, which elements to include, which information to express. Safety viewpoint, timing viewpoint, hardware deployment viewpoint belong to this category. A viewpoint is not a diagram; it is the specification that drawing must follow.

2. View

A model drawn strictly according to viewpoint rules: logical view, physical deployment view, timing interaction view.

3. Architecture Description

The collection of all views, models, and design documents — the complete set of architecture deliverables.

4. Architecture

The intrinsic essence of the system that views and documents intend to express.

Four core logical threads, sequence absolutely cannot be reversed:

Viewpoint frames concern : clarify which class of problems this type of view solves.

Viewpoint constrains view : drawing must follow rules, no arbitrary improvisation.

View responds to concern : this is the sole value of a view's existence.

Multiple views integrate into architecture description , finally expressing the system architecture.

The third thread is most critical. No matter how exquisite a diagram, if it cannot respond to any party's core demand, it is merely an engineering-worthless waste diagram.

Must distinguish a core concept:

Architecture Description ≠ Architecture, just as Map ≠ Actual Territory.

Architecture is the system's inherent internal attribute, invisible and intangible; architecture description (diagrams + documents) is only the carrier used to present architecture. Most architecture quarrels essentially confuse the two: everyone repeatedly argues whether diagrams are well drawn, but rarely discusses whether the architecture solution itself is reasonable.

04 Connecting Both Sides: One Sentence Summarizes the Entire Logic

Organize the complete chain:

Lock the target system to be developed, identify all stakeholders; stakeholders generate their core concerns based on their role perspectives; we define different viewpoints to establish observation rules, then produce corresponding views to respond to each category of demand; all views integrate into architecture description, finally fully expressing the entire system's architecture.

This meta-model diagram reveals a core fact: drawing architecture views is never for drawing's sake; every view precisely corresponds to a certain stakeholder's concern. The architect's core work is to make trade-offs among multi-party pulling demands and finally achieve global unification.

Three nodes in the diagram are easily missed, yet they are the root cause of frequent pitfalls in later engineering:

Environment — Omitting it leads to only considering internal functional design, discovering too late that regulatory requirements cannot be met, forcing a complete redesign.

Perspective — Omitting it leads to blaming individuals, thinking replacing the contact person solves the problem, unaware that unchanged roles mean perpetual conflict.

Aspect — Omitting it leads to using a single view to cover the entire system, treating a partial aspect as the whole picture, leaving hidden dangers undiscovered.

Two connections are also often ignored:

Stakeholders concern architecture itself : they care not only whether functions can be realized, but also the system's construction logic. This is why architecture reviews require all parties present: they are not there to hear reports, but to confirm whether their demands have been properly handled.

Views correspond to only a single system dimension : no single master diagram can cover all design. Multi-view modeling is not optional; it is inevitable for large systems.

05 Small Systems Don't Need Architecture, Large Systems Must Have Architecture

Many question: I independently develop small tools, never drew architecture diagrams, projects still run stably.

Reason: small projects have negligible architecture contradictions.

One person writing a log processing script has a single goal, no multi-party collaboration, issues can be directly rewritten — no architecture constraints needed.

But once the team expands to three people, architecture problems immediately surface: who defines interfaces, who owns exception boundaries, how to unify log formats. These are no longer technical implementation issues but lack of unified conventions. Without rules, everyone codes by habit, and conflicts concentrate at integration.

Small systems : single-person development, single goal, minimal constraints, only need to solve "can function be implemented".

Large systems : multi-team parallel, multi-layer constraints overlapping, multi-party interest games, must solve "can system coexist long-term, iterate continuously, land stably".

The essential difference: ordinary development solves function implementation problems; architects solve system coexistence problems.

As soon as a second team appears, demand conflicts follow: frontend pursues iteration speed, backend emphasizes system stability; business wants flexible configuration, safety requires convergence control; project team rushes delivery, testing insists on full coverage verification. More teams, more complex constraints, easier for system to tear apart.

Without architecture governance, contradictions only postpone, finally erupting at integration. Modifying interfaces during integration often drags multiple teams, multiple contracts, even entire production lines, with rectification costs multiplying.

06 Automotive Domain Controller: The Most Real Multi-Party Demand Game

Take automotive domain controller development as example: five major teams' demands are inherently opposed.

Functional team : pursues flexible configuration, extensibility, hopes new features support plugin dynamic delivery, shortening version iteration cycles.

Safety team : insists on minimal execution paths, traceable code, immutable runtime; fewer branches, easier functional safety certification.

Performance team : strictly controls latency, guarantees control loop 10 ms cycle stable operation, rejects multi-layer forwarding latency loss.

Cost team : strictly controls hardware compute power; if chips can be shared, never add extra hardware; saving tens of yuan per SoC saves tens of millions at volume.

Project team : solution should stay stable, avoid repeated revisions; once missing vehicle model project window, entire development voided.

Putting these demands together reveals: functional team wants to add branches, safety team demands cutting branches; performance team wants exclusive hardware resources, cost team demands resource sharing. Each demand alone is reasonable, together they are completely contradictory.

Most typical contradiction: functional team proposes dynamic plugin loading for remote feature upgrades; safety team explicitly requires all executable code certified before production, runtime changes prohibited. Both cannot be satisfied simultaneously.

Without architecture governance: each side insists, whoever has more authority wins; system becomes fragmented through compromises, leading to massive rework at integration.

With good architecture governance: decouple strong coupling points through layered decoupling, rely on clear boundary delineation of responsibilities, then clarify conflict trade-off rules through priority decisions. Contradictions won't vanish, but become controllable, explainable, traceable.

We must face reality: conflicts can never be completely eliminated. The contradiction between functional expansion and safety convergence exists in any architecture solution long-term. The architect's job is not to eliminate contradictions but to form written decisions on trade-offs, making them evidence-based and fully auditable.

Architecture never pursues single-point technical optimality, only global interest balance.

07 Architect's Core Value: Only Do Four Things Well

From ISO 42010 standard perspective, architect's core work decomposes into four concrete matters, none related to drawing or coding.

First, completely identify all stakeholders.

Clarify all teams that will influence the system and be influenced by it. Missing any party guarantees later rework. Most common pitfall: at development close, legal suddenly raises data link non-compliance with outbound regulations, forcing entire architecture redesign.

Second, precisely locate core conflict points.

Not simply listing demands, but finding fundamental contradictions where "A's demand is exactly B's red line." This work easily goes to two extremes: either missing real conflicts, leaving hidden dangers to integration; or treating all disagreements as conflicts, afraid to make trade-offs, resulting in a balanced but toothless solution.

Third, adopt multi-view decomposition design.

Use different views to match different teams' concerns: show logical view to functional team, physical deployment view to hardware team, timing view to testing team. A single master diagram convinces no one. Presenting logical structure to hardware team, their first question: "Which hardware do these components deploy on?"

Fourth, global trade-off, form convergent decisions.

Make trade-offs above all views, and fully record trade-off reasons. This is the hardest and most valuable part of architecture work. Typical fear of trade-offs: try to satisfy everyone's demands, seemingly comprehensive, actually pushing all contradictions to coding phase, where frontline developers make ad-hoc decisions with no decision records.

Retaining decision reasons has mature industry practice: Architecture Decision Records (ADR). Each record writes four items: current problem, alternative technical solutions, final selection, core reason for choice. Corresponds to architecture rationale in ISO 42010.

Without this record, three years later no one can explain why another solution was abandoned; same arguments repeat, new batch of people quarrel again.

None of these four things belong to drawing or coding work.

Code solves local functional problems; architecture solves system long-term structural problems. They correspond to completely different capability models and assessment standards.

After decision records are written, we can use four questions to quickly verify whether an architecture description is qualified:

Are all stakeholders fully covered? Missing teams will eventually come knocking.

Which party's core concern does each view correspond to? If you can't answer, that diagram is self-amusement.

Can multiple views align with each other? Logical layer components not finding corresponding carriers in physical deployment indicates design not converged.

Are key conflict trade-off reasons documented in writing? No text record equals no real decision made.

Only when all four questions pass does the architecture solution possess value for aligned review, auditability, and long-term maintenance.

The skin of architecture is layered structure; its soul is trade-off and unification.

Conclusion

Demands are always divergent; interest conflicts are engineering norm; views merely split the system into different aspects.

Architecture's ultimate destination is achieving global consistency and unity.

Understanding the ISO 42010 meta-model diagram marks true entry into architectural thinking: architecture never lies in how neatly system diagrams are drawn, but in giving a well-reasoned, consensus-reached trade-off solution amid multi-party pulling demands.

Data Sources

ISO/IEC/IEEE 42010:2011 "Systems and software engineering — Architecture description", current version ISO/IEC/IEEE 42010:2022.

Concepts such as Stakeholder, Concern, Viewpoint, View, Correspondence strictly follow the standard meta-model; "architecture as multi-party conflict trade-off convergence" is a reasonable inference based on the model, not standard original text.

Automotive domain controller case comes from frontline engineering practice, used only for methodology illustration, no specific project information involved.