Architecture vs Design

Architecture vs Design

What makes Software Architecture different from Software Design?

This is a provocative question. What is the motivation behind this question? Does it matter whether one is doing architecture or design? Isn’t the point of both is to figure out how a system is going to be built, and to communicate that?

Well, yes. In smaller teams, a single person or a few people may be doing architecture and design, along with development, and it is the final product that really matters anyway, so there is no need to split hairs.

In other projects, there may be a mandate to keep distinct architecture and design documents, and distinct people involved in system architecture and design. In fact, there are dedicated Architects in most companies, who do this activity called System Architecture, and who produce System Architecture Documents. What to they do that is distinct from design?

Definitions, definitions…

The core problem is that there is no canonical definition of the term Software Architecture. So, different people have different takes on it. Consider some definitions of Software Architecture:

  • “…is a depiction of the system that aids in the understanding of how the system will behave.” — SEI
  • “…is the set of structures needed to reason about the system, which
    comprise software elements, relations among them, and properties of
    both.” — Wikipedia, quoting Documenting Software Architectures: Views and Beyond, Second Edition
  • “The architecture of a system is its ‘skeleton’. It’s the highest level of abstraction of a system. What kind of data storage is present, how do modules interact with eachother, what recovery systems are in place… Software design is about designing the individual modules / components. What are the responsibilities, functions, of module x?” — Someone on the internet

Ad infinitum. One can see that there are many definitions, some broad and some specific, some vague and some precise, and some that seem to make sense and some that you might not agree with. Most of them seem to be clustered around an unsaid consensus: none of them might claim to be the definition, but on aggregate they seem to be talking about the same thing. Some definitions, while making sense on their own, don’t give guidance on how Architecture is different from design. Others, focusing on the distinction, seem to be saying things that don’t seem quite right (“skeleton”? Really? And what is meant
by the “skeleton of a system”? When does a skeleton stop being a skeleton?)

It seems, the definition of Software Architecture is like the definition of Object Oriented: There is broad consensus, at least in terms of people who practice the art, but just try to get a bunch of people to agree on the one true definition of it and work will come to a halt while debates rage. On the other hand, people seem to be doing fairly ok with creating object oriented software and are able to learn and teach it, without, gasp!, the one true definition.

This does not help the Architect, who needs to decide when to stop refining and detailing and declare the Software Architecture as done, and pass the baton to the downstream people to design and implement.


The problem with thinking of architecture vs design as being “high level” and “low level” or “abstract” vs “detailed” is that it just re-defines the question in even
more vague language. I mean, just try finding a clear cut definition for abstract vs detailed.

Perhaps the answer lies not in the definitions of the terms, but in the goals? What is an Architect trying to achieve with his Software Architecture that is different from the Designer?


Let’s agree with the fact that (a) a system’s life begins with a set of requirements, (b) that an Architect will product a System Architecture Document (SAD), and (c) developers will develop a system according to the document, with some Design documents being produced before or during
the development phase.

A system has functional requirements, and some non-functional ones. There are also
quality attributes: flexibility, maintainability, and—oh—multiple people need to be able to develop the system in parallel. It is the architect’s job to describe the system to be built in a way, and in enough detail, that all the things that need to be described to meet these goals are documented, and anything else is left to the discretion of the designers and developers.

So, its not really about the detail or abstraction level. If some particular part of the system can be adequately described as “…does <well understood task> in 20ms”, then so be it: the architecture does not need to go into more detail. On the other hand if there is a critical SOAP service whose granularity, operations, and semantics will affect the function, evolution and performance of the system, then the Architect must go into the nitty-gritty details and demonstrate just how the needs of the stakeholders will be met. No hand-waving will do.

What about modules? Does an Architecture have to deal with Modules? What about sub-modules? Sub-sub-modules? Modules are recursive: they can always be broken down into smaller modules (and again, there is no universal definition of the term).

Regarding how far to go in de-composing a system into modules, the Architect must balance two needs: (a) a project manager, or development manager, or team lead needs to have enough de-composition so that teams or individuals can be put to work on design or development in parallel, so there must be sufficient de-composition that the desired level of parallelism is achieved; (b) the developers should have maximum design flexibility: they should be able to implement the system in any way possible as long as it meets the requirements and quality attributes.

As soon as the Architect has de-composed the system into sufficiently granular parts that parallel development can be scheduled, the de-composition can stop. The Architect is responsible for spelling out how the modules will work together, and impose any conditions or restriction on the individual modules’ design and development that affect the overall system requirements and quality, and the rest can be left for “downstream”.

An individual module may be large or complex enough that it may merit its own Architecture, but from the outside, Architect has done his job or the overall system if the module has been described in sufficient detail for the team responsible for it to be able to design and develop it correctly.


In conclusion, an architecture is what an Architect does, and the Architect needs to do enough of it so that the requirements of all the stakeholders of the system will be met if his/her architecture is followed. An architect’s job is to ensure that the correct system will be built by the people who follow his architecture. This implies that the Architect needs to consider the context: what are those things that must be specified and constrained for it to meet it objectives, versus those things that can be left to the discretion of the implementers?

here is a fairly detailed description
of all the things that an architecture
needs to consider or might affect.

Post a comment or leave a trackback: Trackback URL.


  • khigia  On May 3, 2012 at 11:36 am

    Good article … only small glitch is the last link doesn’t work for me.

    • parijatmishra  On May 3, 2012 at 11:44 am


      I fixed the link.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: