Architecture And Design

‚ÄčThe following short essay was written in reply to a question asked by Nancy A. Neff on Linked In: "In an Agile or Lean software development context, what do you consider the difference to be between software architecture and software design? Just the level of detail? Are there different definitions of architecture vs. design in other software development approaches?"

To discuss architecture vs design, I'd like to highlight something obvious but still needs to be said, which is that these are informal terms that are weak, both in their practical usage and in academic studies. As agile practice typically embraces concepts that are hard-edged ("test passes") and shuns those that are blurry ("90% complete") we should expect these ideas to be downplayed in the context of agile development. And that's exactly what I see in the agile development world.

Of the two words, I think "architecture" is the easier to pin down. In context, architecture is a description of a computational system in terms of process (or process-like concepts such as threads or coroutines), the communication channels between processes, data stores, and the encoding of data on the channels. In particular, it excludes the functions that the system carries out. Hence an architecture describes the structure for performing function but not the function itself.

Defining an architecture has a meaningful role in agile development because it is a big picture view. Agile practice is focused on small units, so issues such as architecture and security, which require a complete overview, need to be given some special consideration because they do not necessarily get the attention they deserve when working on small units.

"Design" is a much looser word. In software engineering, it has historically been used to describe the iterative process of refinement of a high level representation. I do not believe that there is much evidence to support the implied model of development: which is that first there is a high level view which is then successively refined. I certainly have very little time for this use of the word.

An alternative and common meaning of the word "design" is the process by which we go from an idea (or "product vision") to product. This is a much weaker but, to my way of thinking, more honest usage that acknowledges the inadequacy of our formal understanding of design. In this second sense of the word, "architecture" is simply part of the design process.

A third use of the word is as a noun, as in "the design", which I take to mean the intermediate, summary descriptions of a system or its components units used as stepping stones to their implementation in code. Prior to the rise of modern programming languages, there was a strong need for these intermediate representations to be maintained. Now, with languages such as Python, C# and Java being popular, that seems a good deal less worthwhile.

One of the most interesting trends in agile thinking is the argument that design should emerge from the development process. The argument is that it should arise inductively from repeated refactorings. The elephant in the kitchen is, of course, that "design" is ill-defined and so although some design tasks emerge inductively, it is difficult to assess whether or not these are the important design tasks. (It is my opinion that they are not. But it is a bold speculation and worth chasing.)

I believe that the consensus of agile design in the field is actually quite clear: practitioners emphasize the just-in-time elaboration of requirements and that immediately implies small-scale just-in-time design too. This is underpinned by their confidence that even large scale changes can be made cheaply.

The upshot of this is that agile development will be weakest when large-scale design considerations dominate. To ameliorate this, there is a widespread adoption of "frameworks", which are pre-fabricated large-scale design solutions. Indeed, anyone coming to the world of agile practice for the first time is likely to be intimidated by the plethora and dominance of runtime frameworks!

This line of argument illuminates why agile practitioners have abandoned worthless snake-oil design methodologies in favour of Heath Robinson lash-ups :)