Beyond Diagrams: The 8 Layered Skills That Define Real Architecture

Many people mistake architecture for drawing diagrams — layering, frameworks, boxes and arrows. But a diagram is merely a photograph of architecture; the photograph does not equal understanding. True architectural ability consists of eight layered actions that build on each other.

Architecture vs. Architecture Description

Architecture is the fundamental concepts and properties of a system in its environment — its elements, their relationships, and the principles governing its design and evolution. Architecture Description (AD) is the human-made artifact: views, models, documents, diagrams, matrices. Its purpose is threefold: to express, record, and communicate architecture. As ISO/IEC/IEEE 42010 states, architecture description is not architecture , just as a map is not the territory. Architecture can exist only in someone's mind, never written down; once written, it becomes description.

Therefore, beautiful layer diagrams, deployment diagrams, and block diagrams are only descriptions. Real architecture lies in the judgments behind the diagrams: what to abstract, what to discard, where to draw lines, what to trade.

01 Abstraction: Extracting the Decisive Attributes

The first action is abstraction. A navigation map shows a single line, but that line is not a simplified street — it is a set of attributes : position, connectivity, direction, congestion. Those four attributes answer "how to get from A to B." A real road has countless attributes: pavement material, tree species, building ages, sign colors, sidewalk width, asphalt grade. The map ignores all of them.

Abstraction is not "making things simpler"; it starts by answering "What am I describing?" then extracts the minimal attributes that decide that question. The result is called a model. A car dashboard shows speed, RPM, gear, fuel, warning lights — not because they were picked from thousands of bus signals, but because the concept "vehicle operating state" was defined first, then the minimal attributes needed to describe that state were chosen.

Good abstraction is judged by two criteria: Do the extracted attributes suffice to describe the problem? and Will the omitted attributes reverse the conclusion? Two failure modes exist: under-abstraction (missing critical attributes like battery over-temperature) and non-abstraction (dumping raw sensor waveforms onto the screen).

02 Focus: Admitting Limited Resources, Tackling the Primary Contradiction

Abstraction decides "what to look at"; focus decides "what to do first." Emergency rooms use triage: when ten patients arrive simultaneously, doctors don't follow registration order — they treat the dying first. This isn't callousness; it's the only responsible approach when resources are limited.

Architecture faces the same reality: requirements exceed resources, features exceed schedules, optimization points exceed headcount. A core architectural act is explicitly deciding what this version will NOT do . Saying "no" is hard because "yes to everything" sounds agreeable. The result is often twenty non-functional requirements — high concurrency, low latency, strong consistency, offline capability, cross-platform, extensibility, zero downtime — each written down, none properly achieved. Twenty metrics equal no metric.

Focus is not cutting requirements; it is ordering them: identify the three red lines that must hold, relegate the rest to "if capacity allows." Once this ordering is fixed, every subsequent technical choice has a basis — because you know what you are sacrificing for. Focus governs "do or not do," not "how to split." It answers "which red lines come first," not "how many modules." Mixing the two yields neither focus nor clean decomposition.

03 Decomposition: Large Systems Cannot Be Designed All at Once

After focus, implementation looms: the system is too large to design, build, or test in one go. Moving house, you don't shove everything into the truck; you pack boxes — kitchen, books, fragile items — each independently movable, placeable, verifiable.

Complex systems are the same. But how to split is the real question. In 1972, David Parnas gave a counter-intuitive answer in "On the Criteria To Be Used in Decomposing Systems into Modules": do not decompose by process steps; decompose by "which design decisions are likely to change."

Decomposing by flow yields modules for validation, calculation, storage, output. It looks clean, but changing the storage format forces changes in validation, calculation, and output because each directly depends on that format. Decomposing by "decisions that may change" hides "how data is stored" inside one module with a stable interface; format changes then affect only that module. This is the origin of information hiding , which later evolved into encapsulation, interfaces, and microservices.

Decomposition has a granularity sweet spot: too coarse and it won't hold; too fine and coordination costs eat the gains. A practical test: can it be independently delivered and independently verified? Abstraction reaches upward; decomposition reaches downward. They must appear together: abstraction without decomposition leaves ideas grounded; decomposition without abstraction leaves a fragmented mess.

04 Boundaries: Splitting Without Lines Magnifies Chaos

Focus and boundaries both sound like "drawing scope," but they govern different things: focus decides "which things to do"; boundaries decide "how the chosen things are divided." The former is trade-off; the latter is ownership. A system can be sharply focused on three tasks yet have chaotic boundaries — three tasks tangled in one module, no one knows which code belongs to whom. Conversely, boundaries can be pristine while focus is wrong — seven unnecessary tasks, each cleanly separated. The two steps cannot substitute for each other.

Anyone who has shared an apartment knows: common-area cleaning never happens unless someone explicitly owns "this week." Splitting is only step one; without lines, chaos doesn't disappear — it just shifts from "one big mess" to "many small messes."

Architecture must draw at least four lines:

Module boundaries : who groups with whom. Cut by change frequency, not org chart.

Responsibility boundaries : who owns what. One capability, one owner.

Data boundaries : who may read/write. Data has a single owner; others request access.

System boundaries : inside vs. outside. Crossing this line requires a contract.

Symptoms of fuzzy boundaries: a tiny logic change breaks a wide area; incident meetings stall because no one claims ownership; a new feature requires coordination with five modules first.

A real automotive case: an actuator controlled by two controllers, each believing it owns the actuator, produces a tug-of-war — one commands "open," the other "close." Debugging is agonizing because each module's logic is correct in isolation; the error is no one ever defined who has the final say . Clear boundaries yield three dividends: smooth collaboration, stable iterations, localizable faults.

05 Contracts: Collaboration Across Boundaries Runs on Contracts

Travel adapters exist because plug shapes and voltage standards differ. Yet the plug itself is a brilliant engineering invention: "I don't care how the wire behind the wall generates electricity; I promise you 220V, 50Hz, two holes." Any compliant appliance plugs in and works; any power plant upgrade leaves home appliances untouched.

That is a contract. It completely separates "how you implement" from "what you deliver." Architectural contracts typically specify four things: interfaces, protocols, sequencing, data formats. Once written, both sides can work independently — one swaps implementation, the other changes zero lines.

The most common crash is implicit contracts : undocumented assumptions like "you must call A before B." They work until they don't, then cause system-wide accidents because they're on no one's checklist. A harsh but accurate rule: no contract, no architecture. Contracts are the prerequisite for evolvability — you dare replace a module not because of courage, but because "what I promised hasn't changed."

06 Trade-offs: The Architect's Real Craft

An SUV cannot become a sports car — not for lack of technology, but because physics forbids it. High ground clearance raises the center of gravity; high center of gravity causes body roll in corners. Wanting both forces compromise on both, yielding a vehicle that can neither off-road nor track.

Architecture faces this daily:

Performance ↔ Cost: more headroom, more money

Reliability ↔ Iteration speed: more redundancy, slower changes

Simplicity ↔ Backward compatibility: longer baggage, heavier architecture

Short-term delivery ↔ Long-term evolution: ship now or lay foundations first

Novices treat trade-offs as "compromise" — split the difference, pick a middle value. Real trade-offs are explicit prioritization and acceptance of consequences . Example: "This version prioritizes launch, sacrificing some extensibility" — a valid trade-off because it states who yields and what the price is. "I'll try to balance everything" is not a trade-off; it's unclear thinking.

Write the rationale down — not for management, for yourself six months later. By then you'll have forgotten why you decided; even if you remember a few points, they're likely post-hoc rationalizations — people unconsciously rewrite their own decisions to sound more reasonable.

07 Adapting Constraints: All Architecture Dances in Shackles

Retrofitting an elevator into an old apartment building tests design skill to the limit. Constraints are absurd: structural load capacity, fire lane encroachment, ground-floor daylight, pipe relocation, budget allocation, low-floor resident consent. Each one can kill a proposal.

Yet these constraints determine the solution — external mount, walk-through entry, or staggered entry — not the designer's aesthetic preference. Architecture is identical. The constraint list includes at minimum: time, cost, team capability, existing tech stack, compliance, usage scenarios.

Discussing architecture without constraints is empty talk. "Optimal architecture" does not exist; only "optimal solution under this set of constraints" exists. Change the constraints, the answer changes.

Automotive electronics pushes this to the extreme: components must survive -40°C to +125°C, software must meet functional safety processes, vehicle lifecycle exceeds ten years, unit cost is capped. These constraints immediately disqualify many practices taken for granted in internet systems.

Flip the view: constraints are not enemies; they are design inputs . The standard interpretation puts it sharply: architecture looks outward at the system and its environment; design looks inward after boundaries are set.

08 Evolvability: Good Architecture Grows, It Isn't Built Once

After the first seven steps, one question remains: how long will this hold? Poured concrete sets once; adding a window means smashing walls; changing layout means rebuild. Lego is different — its studs and tubes let you add what's missing, and the old pieces keep running.

Good architecture is the latter. A once-and-for-all perfect architecture doesn't exist — requirements change, technology changes, teams change. What decides a system's lifespan is not today's elegance but its capacity to absorb change .

That capacity is the compound result of the previous steps:

Abstraction done right — new requirements land in the correct layer, not as scattered patches.

Boundaries clear — swapping one piece doesn't ripple everywhere.

Contracts stable — replacing implementation doesn't force callers to change.

Thus evolvability is not an independent trick; it is the compound interest of all prior actions.

A plain litmus test for architecture quality: when a new requirement arrives, how many places must you touch? One place — good architecture. Five — acceptable. Ten — modules have grown together; pulling one thread drags the whole knot.

Closing

Why do so many equate architecture with drawing? Because diagrams are visible; judgments are invisible. Yet what truly determines a system's fate are those invisible judgments — which attributes you extracted, which requirements you dropped, where you drew the lines, what you traded away.

The eight actions are not eight parallel words; they form a chain:

Abstraction and focus — see the system clearly.

Decomposition and boundaries — split it cleanly.

Contracts, trade-offs, adapting constraints — make it cohere.

Evolvability — make it last.

From seeing clearly, to splitting cleanly, to cohering, to lasting — that is the entire craft of architecture.

Architecture isn't drawn; it's thought through. Diagrams are the output; judgment is the skill.