On Design vs Architecture

Thu, Oct 30, 2025 ❝On the concerns of design vs. architecture.❞

Contents

As mentioned in interim: impersonal feedback, I originally started writing this post on 2019-07-09.

An outline of the fundamental differences between architecture and design. How to distinguish between the two? What is the impact when one - unintentionally, or at least it should be - influences the other?

Defining the boundary

First, we need to be clear on what the boundary is between architecture and design. All too often, this is not clear and instead is being argued by “reasonable influence” or “undesirable situation” whether or not something is or is not part of architecture. Way too often, does architecture unnecessarily influence (e.g. restrict) design and as a consequence quality of an application.

Boundary condition: the actual vs. the conceptual

• Design: “looking inward”, suitability of the solution itself
  What are the requirements to make the solution work? Design is specific to one particular solution.
• Architecture: “looking outward”, suitability to the larger context (business problem and so much more)
  What are the requirements to make any viable solution suitable in view of the larger context? Architecture is independent of any particular solution.

The boundary is the strict line between inward-looking requirements and outward-looking requirements.

Going with this idea that ‘architecture’ are all requirements “looking outward”, then one might match functional requirements to the business domain, i.e. business requirements. Architecture itself is broader concept than “merely” software-architecture as software-engineers know it. There are notions of architecture at the strategic level too. Consequently, ‘architecture’ may indeed be defined as above. Even if this broad definition will not work for your specific case, the strict distinction between the two opposing notions is still really helpful as a guide.

Necessary and sufficient condition

The idea of requirements usually works from the notion of necessary condition. That is, what is needed at minimum to adhere to the larger context (architecture), or to provide a viable solution (design).

Sufficient conditions on the other hand, are deceptive. Although they guarantee a solution is acceptable, they may (unintentionally) impose additional restrictions as a consequence of over-specifying the necessity.

An example of a sufficient condition often imposed at the architectural level, is the demand a certain programming language is used. That is, “if a team implements a solution in Java, it would be acceptable to the company”. However, the actual concern a company would most likely struggle with, is having certainty that a solution is maintainable in the long term. A necessary condition might be to “use a programming language that is already established within the company”.

A one-off experiment concerning a new idea, might lend itself more to experimenting (prototyping) with a novel programming language, as the company would not expect long-term maintainability yet. Instead, if the prototype is successful, they may at this point decide whether their gamble on this new technology is worth it. (Or impose additional restrictions on the final solution.)

Functional, operational, developmental

There is this idea of partitioning requirements in one of three categories: functional, operational, developmental. For this article, I’ll go with this idea. I intend to provide only the barest explanation, and I recommend looking up reliable first-hand resources for precise use.

• Functional, are usually requirements that originate from “business”, i.e. requirements in the business domain. “What functions does the solution offer to assist business?”
• Operational, are requirements concerning operating and managing the solution. These are usually matters concerning system-administration, up-time guarantees, disaster recovery, interoperability and compatibility, traceability, configurability, etc. and any such expectations.
• Developmental, are similar requirements but focused on solution characteristics such as error recovery, crash mitigation, protective characteristics, error analysis and debugging.

Properties of design

So, what are the relevant properties of design? Let’s discuss some key properties.

1. Design is concerned with development of a particular solution, i.e. concrete.
   Any design concerns focus on making the solution work, meaning it focuses on actual issues to work around, as opposed to conceptual problems that are independent of any single solution. The design is specific to a solution in that it (also) adapts to the components that are part of the solution.
2. Design is specific for a particular solution, so any non-essential (unnecessary) properties will result in technical debt.
   This results in technical debt for the reason that we will need to maintain this code, but at the same time it does not provide any essential functionality, and may interfere with future designs.
3. Design is concerned with actual working solutions for present needs.
   The emphasis is on ‘present needs’, due to the fact that we should not attempt to preselect a solution for a future problem.
4. Design is restricted by (imposed) architectural requirements.
   Requirements dictate what makes a solution acceptable (in the larger context). Hence, any suitable solution must adhere to the architectural requirements. A solution may be viable of itself, but be wholely unsuited for adoption in the company.
5. Design is restricted by existing practical limitations.
   The design is focused on making the solution work. We have to make the solution work given any existing circumstances. Hence, design has to work with or around existing practical limitations.

Properties of architecture

The architecture, on the other hand, are not really interested in the solution, but rather whether “whatever-it-is” fits into the larger context.

1. Consists of a definition (on some level of abstraction) composed out of individual requirements.
   There is a certain selection of requirements that is necessary to achieve a certain business goal, i.e. the problem definition. We expect these individual requirements to be available.
2. Concerned with characteristics of acceptable solutions to the problem statement. I.e. only restrict as much as necessary to make the solution work.
   The selected requirements are relevant to the characteristics that are required to achieve a given business goal.
3. Unnecessary requirements result in pointless restrictions of possible implementations (solution-space).
   We aim to select only requirements that contribute to desirable characteristics. Any irrelevant requirement will further restrict the solution space in which viable solutions can be found.
4. Expressed as high-level requirements only.
   “What are you trying to ensure?” “What are you trying to avoid?” Details and technical specifics and solution-specific matters are to be avoided. Going into such details, requires making assumptions on the direction of a solution, hence restricting or pre-selecting for particular solution.
5. Requirements can be traced to business goals.
   In the end, all requirements must lead to business goals. Otherwise, why put in effort to achieve the requirement?
6. Is not concerned with one specific solution or restrictions dictated by implementations.
   Any concerns specific to a particular solution should be left as design concerns, while architecture expresses what is expected for whichever solution to be acceptable within the larger context, e.g. the company or department, or even globally.

Conflicting or contradictory requirements

Architectural concerns and design concerns may end up conflicting or contradicting. These do not always result in impossible situations. One may end up designing a solution consisting of several partitions, e.g. layers, that allow for loosening or redefining architectural constraints within the solution itself. The solution as a whole adheres to the restrictions imposed by the architectural requirements. However, within the solution, certain strict boundaries are defined, such that it is possible to relax restrictions within certain parts of the program, if the architectural constraints can be maintained for the whole.

An example of this is in the area of error handling. Typically, programs are best designed to “crash early” in case of errors, unsupported situations and unanticipated cases. However, the last thing a company wants is to have their application crash every few hours. Instead, one can define a separate “management layer”, or possibly a framework, that covers certain over-arching concerns such as for managing unexpected situations, while the application core can be wholely unbothered by such “trivialities” and instead be designed and implemented properly. Some people encourage crashing programs early and often, and e.g. have an overarching “supervisor” intervene in such unexpected cases. Consequently, an application designed to “crash early and often” can still be (part of) a solution that offers stability and reliability.

note And, to dispel any misunderstanding on this topic, “crash early and often” refers to how you handle when things go wrong, mostly in unexpected ways. Not “crashing early/often” may result in more insidious problems, such as silent data corruption or problematic behavior due to inconsistent state (management), and over-all in problematic situations that are harder to understand and fix because errors crept in over the course of a time.

Consequences of overstepping boundaries

The consequences of overstepping boundaries or over-specifying or otherwise imposing demands to an excessive level, is that requirements become unnecessarily restrictive. This, in turn, risks reducing the solution space within which designers find the (best) viable solution. This forces designers into working around inconvenient and (seemingly) senseless and meaningless demands. This in turn leads to more elaborate solutions, more intricate constructions and more complicated code. That is, with excessive restrictions, one excludes simpler and more elegant solutions.

Similarly, we can consider future developments. Excessive restrictions of any kind, pose hurdles in future designing efforts. Either, these restrictions need to be revisited, or future designs will be impacted. Anticipating or pre-selecting for future developments, usually does not work well. Changes to a solution are not developed in isolation. A solution’s design as a whole is revisited when incorporating changes. When one (partially) anticipates or pre-selects for a future change, we do not take into account the solution design as a whole, meaning that we are not covering all of the available solution space.

In closing

The core idea I want to present is the simple but strict distinction between design and architecture. I think it covers what these concepts mean in spirit, even if specific cases of architecture on the work floor in every day scenarios may have more intricate meanings. I think this serves well as a general case and guideline.

In addition, the idea of architecture as imposing additional restrictions upon solution design, thus reducing the number of available, viable solutions. The rest serves predominantly to further explore these notions.

Changelog

• 2025-10-30 Initial version of article.