Architecture as Decision Making

Architecture Is Not a Diagram

There is a persistent misconception that architecture is a picture — a box-and-line diagram on a slide deck that shows "the system." It is not. Architecture is a set of decisions that constrain the solution space and enable capabilities. The diagram, if one exists, is a consequence of those decisions — a view, not the thing itself.

Every architecture decision has two effects: it closes off alternatives (you cannot easily reverse it) and it enables capabilities that would be impossible without it. Deciding to distribute processing across multiple nodes closes off the simplicity of a single processor but enables horizontal scaling. Deciding to centralize data storage closes off local autonomy but enables consistent querying. These trade-offs are the substance of architecture.

This framing connects directly to MBSE (DGTLENG 201): architecture decisions are the design choices that structural elements, behavioral models, and interface definitions in the system model express. The model does not generate the decisions — it formalizes them so they can be evaluated, traced, and communicated.

What Makes a Decision "Architectural"

Not every design decision is architectural. Choosing a bolt grade is a detail decision. Choosing whether the system uses a centralized controller or distributed controllers is architectural. The distinguishing characteristic is reversibility: architectural decisions are the ones that are hardest to change later.

Martin Fowler's heuristic applies across disciplines: "Architecture is the decisions that you wish you could get right early because they are hard to change later." This holds for software (monolith vs. microservices), aerospace (fly-by-wire vs. mechanical linkage), civil (steel frame vs. reinforced concrete), and electrical (analog vs. digital signal chain).

The cost of reversing an architectural decision grows exponentially with project maturity. Changing from centralized to distributed control during concept design costs a model revision. Changing it during integration test costs a program restructure. Changing it after deployment may cost a complete redesign. This asymmetry is why architecture matters most at the beginning — and why deferring architectural decisions "until we know more" often means deferring them until they are too expensive to change.

Architecture Topologies

Most systems adopt one of four fundamental topologies — or a deliberate combination. Each topology constrains the solution space differently and enables different capabilities.

Centralized

A single authority coordinates all subsystem activity. One controller, one database, one decision point. The central node has visibility into the entire system state.

Enables: global optimization, consistent decision-making, simpler reasoning about system behavior, straightforward auditing and compliance.

Constrains: scalability is limited by the central node's capacity, the central node is a single point of failure, subsystem autonomy is minimal, latency increases as the system grows because all decisions route through one point.

Where it fits: systems with tight coordination requirements and bounded scale — nuclear reactor control rooms, early-phase satellite command processing, small-team software applications, manufacturing cells with a single PLC.

Distributed

Multiple autonomous nodes operate independently, coordinating through defined protocols. No single node has complete system state.

Enables: horizontal scalability, fault tolerance through redundancy, local autonomy and responsiveness, continued operation under partial failure.

Constrains: global consistency is hard to achieve (the CAP theorem in software; coordination overhead in physical systems), debugging is complex because behavior emerges from interactions, interface management burden grows with the number of nodes.

Where it fits: systems that must scale or survive partial failures — microservice architectures, distributed electrical power grids, multi-vehicle aerospace formations, sensor networks in environmental monitoring.

Federated

Semi-autonomous domains maintain their own authority within boundaries, coordinating through shared agreements. Each domain owns its data and decisions but publishes to a common framework.

Enables: domain autonomy with cross-domain interoperability, incremental adoption (domains join the federation at their own pace), governance without central control, preservation of existing investments.

Constrains: cross-domain queries require mediation, semantic alignment between domains is an ongoing effort, governance of the shared framework is politically and technically complex.

Where it fits: multi-organization systems — defense enterprise architectures, healthcare information exchanges, federated MBSE environments where different teams use different tools but share a common data backbone.

Hybrid

Deliberately combines topologies at different levels or in different regions of the system. Centralized at the system level, distributed within subsystems. Federated across organizations, centralized within each organization.

Enables: tailored trade-offs — each part of the system uses the topology that best fits its constraints. The hybrid approach is the most common in practice because real systems face different constraints in different regions.

Constrains: increased architectural complexity, requires clear documentation of which topology governs which region, interface management between topology regions adds overhead.

Where it fits: most large-scale real systems. A modern vehicle is hybrid: centralized body control, distributed powertrain management, federated infotainment ecosystem. A hospital network is hybrid: centralized patient records, distributed bedside monitoring, federated inter-facility data exchange.

Architecture Drivers

Architecture decisions are not made in a vacuum. They are driven by constraints and objectives that the system must satisfy. These drivers shape which topology fits, what trade-offs are acceptable, and where the architecture must be most robust.

Performance. Throughput, latency, response time. Performance requirements constrain topology choice — a hard real-time control loop cannot tolerate the latency of a distributed consensus protocol.

Scalability. How the system handles growth in load, users, data volume, or geographic scope. Centralized architectures hit scaling walls; distributed architectures are designed to push them further out.

Safety. The consequences of failure. Safety-critical systems (nuclear, aerospace, biomedical) often mandate architectural redundancy, fail-safe modes, and deterministic behavior that constrain topology choice.

Cost. Development cost, operational cost, and the cost of change. Centralized systems are often cheaper to build initially; distributed systems are often cheaper to scale and maintain.

Schedule. How quickly the architecture must be operational. Federated approaches allow incremental deployment; centralized approaches require the center to be ready before anything works.

Maintainability. How easily the system can be modified after deployment. Modular, well-interfaced architectures cost more upfront but pay dividends in maintenance and evolution.

These drivers rarely align. A safety-critical system may need centralized coordination (for deterministic behavior) but also distributed redundancy (for fault tolerance). Resolving these tensions is the core work of architecture — and it is why architecture is decision-making, not diagram-drawing.

Architecture Decisions in the System Model

When architecture decisions are captured in the system model (DGTLENG 201), they gain traceability. A decision to use distributed processing is reflected in the structural decomposition (multiple processing nodes rather than one), the behavioral models (consensus protocols, message passing), the interface definitions (inter-node communication specifications), and the requirements allocation (which requirements are satisfied by which nodes).

This traceability means that when a driver changes — a new performance requirement tightens the latency budget, or a cost constraint forces consolidation — the impact on the architecture can be assessed by traversing model relationships rather than by convening a review board to search their collective memory.

Step through each topology card above. Notice that no topology is universally superior — each enables capabilities that the others constrain, and each introduces risks that the others avoid. The architecture decision is choosing which trade-offs your system can accept.

Assessment