All architecture is design but not all design is architecture — Grady Booch
This quote caught my attention because it challenges my understanding about the distinction between the two. I am initially skeptical about the quote as it sounds just like a word play but it eventually makes sense.
The idea that I have settled in is that architecture is design that has apparent consequence in the structure and behavior otherwise, it’s a design decision. For example, choosing to implement a Web API using Django or ASP.NET is a design choice. Using MySQL instead of PostgreSQL is a design choice. Choosing to implement a software component using a layered architecture or Hexagonal is a design choice. However, introducing a new component or opting for a monolithic instead of distributed architecture is an architectural decision.
Doubt
-
does splitting a component into two an architectural decision? What if it does functions the same way as the single component and just splits it to two?
By definition, this is a design decision. Although, some might argue that it does adds some “significant” (perhaps unnecessary) latency, but that decision is transparent to any component in the architecture.
I disagree with the example used by Simon Brown in his book Software Architecture for Developers supposedly highlighting the distinction:
However, while the database may no longer be considered a significant decision, the choice to decouple through the introduction of an additional layer should be. If you’re wondering why, have a think about how long it would take you to swap out your current ORM or web MVC framework and replace it with another.
Choosing whether to use an ORM is a design decision not architectural (at Container level of C4 model). ORM does give the benefit of speed in terms of migration and other maintenance stuffs but it is transparent to any other components (database wouldn’t notice that, as well as other service consuming this specific component). Although, it can be argued that not choosing to use an ORM could increase cost in development so it must be architectural. I would say that development cost is a design consequence and we have agreed that architecture is design.
However, choosing to use an ORM is “architectural” at the Components level not at the Container level.
In that regards perhaps it may be more accurate to say:
All architecture is design but not all design is architecture (at a particular level)
Trying to define architecture decision as “the things that you’d find hard to refactor in an afternoon” [1] is vague and confusing the same as any other definition in the software world.
A better definition might be that, in a particular architecture level, if a decision does not change the essence of the architecture such as what it means to be a specific component, then it is a not an architectural decision. If it did change, then it’s an architectural decision. Architectural decision does not only include (breaking) decisions but also additive ones.
Levels of Architecture
Architecture and Design exists at different levels hence it can be very confusing as to identify whether a decision is architectural or design. Usually when we say architecture we usually talk about Container level architecture. One technique that you can use to identify the architectural elements in the at this level is to give an arbitrary input to the system and you’ll discover each elements as the data gets processed by the system. All these elements is part of the architecture. But it is important to note that depending on the level we are referring to, a decision can be architectural. But in this case, I assume container level architecture.
Why is it important to know? Why should I care?
Having an understanding about the distinction between the two allows you to make quick and better decisions. Usually design decisions that are not architectural will not require too much considerations (relative to architectural ones) as, by definition, that decision is transparent to other elements and that its effect will be local to that architectural element. This kind of decision can even be left to the lead of that local team. Having the ability to spot architectural decision is a valuable skill as you know when to invest time and when to just have a run through the local trade-offs and consequences.
Top comments (0)