How architectures fail – 1: Architecture vs design

How do architectures fail? One way is that key distinctions between architecture and design can get blurred – so how do we avoid that trap?

My recent webinar ‘How architecture fails, and what to do about it‘ (see slidedeck on Slideshare, and full 90min video via link on this post) explored three common causes of architecture failure:

We’ll explore each of these fails in turn, using a modified (service-oriented) version of the Zachman rows as a common reference on which to illustrate the fails:

(The main difference from Zachman is the addition of two new rows, one each at the top and bottom of the stack. Respectively, row-0 ‘Enterprise’ represents a stable ‘unchanging future’ that provides the ultimate anchor for the enterprise-story, and should not change; whilst row-6 ‘Action-record’ represents the ‘unchangeable past’ after action has taken place, and cannot change.)

For the first two fail-types, we only need the Zachman rows, as above: we’ll add the Zachman columns – who, what when, where, how, why – when we get to explore Fail #3 on content-constraints.

This ‘realisation-stack’ connects most-abstract intent at the top, to real-world action at the ‘Now’ and then the unchangeable past at the bottom. Each layer downward brings us closer to reality, adding more and more specific detail at each step:

For our purposes here, ‘architecture’ and ‘design’ represent two distinct types of task within that process of realisation – a overall process of change to take an abstract intent and make it real.

As above, each layer ‘downward’ brings us closer to reality; yet the overall change-process is iterative, going up and down the stack…

  • things are usable to the extent that they’re ‘architecturally-complete’
  • things are re-usable to the extent that they’re ‘architecturally-incomplete’

In this sense, ‘architecturally-complete’ means that we can give exact real-world answers to each of the Zachman questions: who? what? where? when? how? why? Whatever we do or plan, it only becomes fully real when we can answer – and have answered – each of those questions. Architecture and design are how we work towards those real-world answers, to realise – literally, make real’ – that initial intent.

So what are architecture and design? – what are the differences in their tasks?

For architecture, we could perhaps start with the IEEE-1471 definition:

“fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”

As a verb, ‘to architect’, or ‘architecting’, would thus be the processes for development for those items.

Yet architecture would also be about the human story that underpins the initial intent or enterprise. To quote Matthew Frederick’s ‘101 Things I Learned In Architecture School‘, this equally-essential aspect of architecture is:

“an exercise in narrative… a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theatre of everyday life”

In this sense, architecture provides a means to connect the current layer back ‘upwards’ to the broader-scope constraints, and refine them for the design-work at the current layer:

By contrast, we might define design as:

“specifications towards implementation, in accordance with defined constraints, and at the requisite level of detail for the current stage of realisation”

Again, the respective verb – ‘to design’, or ‘designing’ – would thus be the processes for development for those items.

Design adds the detail needed for the current layer, reaching ‘downwards’ toward the real:

(Note that, in effect, the process of design at each layer also provides the architecture for the next layer down towards reality.)

If we consider each layer as a distinct viewpoint, then architecture and design represent distinct views that are available from each and all of those viewpoints:

As different views from any given viewpoint, architecture and design also represent different tasks: don’t mix them up!

At each layer, core questions for architecture would include:

  • What are the underlying vision, values, desires, drivers, stories?
  • For options, what are the constraints, boundaries, laws, standards?

Architecture is not design, yet is also not complete without design: if we only do architecture, we get stuck in analysis-paralysis, never getting any closer to reality.

At each layer, core questions for design would include:

  • Given the constraints, what is the most effective option?
  • Given the constraints, what is the best way to make that option real?

Design is not architecture, yet is also not complete without architecture: if we only do design, we wander out of scope, build on untested assumptions, or get stuck with ‘vendor-driven architecture’.

Architecture and design are different tasks: don’t mix them up!

So to avoid the risks that arise from blurring between those distinct roles of architecture and design, note that:

  • architects will work most on architecture, but will also do some design – such as to illustrate how the current architecture would apply at the respective layer
  • designers will work most on design, but will also do some architecture – such as to confirm that the current design does align with the architecture-constraints for the respective layer

At all times, we need to be clear which type of task we’re doing – architecture-tasks and design-tasks do not have the same purpose, and are not the same!

At all times, we need to remember which layer we’re working on, and the type of content and detail that it requires – the layers are not the same!

At all times, we need to remember which way we face, either ‘upwards’ for architecture, ‘downwards’ for design – their tasks are not the same!

To summarise, How to avoid Fail #1: Blurring between distinct roles of architecture and design:

  • Be clear about the differences between architecture and design
  • Know which to use at each moment
  • Know which layer you’re working on at each moment

In the next post in this brief series, we’ll explore how to avoid Fail #2: Starting architecture too late and/or finishing too early in the realisation-stack.

Leave a Reply

Your email address will not be published. Required fields are marked *