Architecture and the Remainder of Design

In the one comment made to the earlier post Architecture in Context [Revision 1], different aspects are put forward that I also see as key elements in a defining story but in quite different ways as proposed.

One, on which I fundamentally differ in opinion, is about the interpretation of a quote by Grady Booch (@Grady_Booch), a well-known and widely accepted truth about architecture:

All architecture is design but not all design is architecture.

The deduction that I make is that architecture is a part of a whole called design which leaves another part, the remainder of design, resulting in following questions:

  • Is there any primacy in these parts?
  • Where does architecture end and the remainder of design begin?

In the comment referred to above, is stated that Grady Booch meant to differentiate otherwise, between objective/subjective aspects.   No doubt the objective versus subjective stand towards fit-for-purpose is an important element in a defining story – one that I will later come back to  – but I disagree that the concern is what differentiates design from architecture.  It plays a role but in an other way.

In fact, I cannot find any proof of Grady stating so. Moreover, there is a well-known addition to the quote by Grady Booch (original reference) that points in quite a different direction.

What followed is:

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

That more or less has always been my understanding and has a consequence.  It means that the part representing architecture is a relative notion.  Significant means “significant when compared to the cost of change of the whole”.

I’ll present an example taken from the tangible world, to clarify.  If urban architecture is your perspective, the architecture of one specific building is usually not significant. It is therefore part of the remainder of design, at least from that perspective.  If only the building is your perspective, architecture is made up by a part of a whole that in the former perspective completely ended up in the remainder of design.

Grady Booch refers to significant “cost of change” which seems to point to financial measure.  I believe that such an understanding is too restrictive.
Therefore I refer to significant “barriers to change” instead, thereby generalizing more specific barriers like:

  • significant number of dependencies. In fact the remainder of design is secondary design as it depends on the architecture and thus will be seriously impacted by change to the architecture
  • significant reach, level and/or period of non-operation due to change in progress
  • the need for significant transition architecture(s) to overcome the previous
  • significant financial cost to change in comparison with the financial cost of the whole, for sure
  • significantly hard to gain empowerment needed to enact the change

The latter specific barrier is a reason why most cities have retained old structures over centuries but Paris is an exception.  Napoleon III had not only a considerable amount of power at his disposal but was also a good communicator, hence he succeeded in acquiring the necessary empowerment, to have realized what has been referred to as Haussmann’s renovation.

Hence significant in this context also means that such a change when started abruptly and incautiously is likely to cause anything close to destruction and subsequent recreation with the newly desired fundamental structure. In between old and new, the action would cause the whole to be significantly non-operational.

This all leads to following observation:

Architecture itself is that what is inherently not agile.

The remainder of design is on the other side of the barrier, thus:

The remainder of design is that what is inherently agile.

Thus this makes architecture about agility distribution, structures that can be changed easily and others that cannot:

Agility Distribution

That distribution may be a reality that we simply find or it may be something that can be influenced through the act of designing thereby turning architecture into an agility distribution instrument, in fact:

Although architecture is “the” prime enabler of agility, architecture itself is that what is inherently not agile.

10 thoughts on “Architecture and the Remainder of Design

  1. Hi Kris,

    I think you may have missed part of what Grady Booch was saying – it is also something that Ruth Malan discusses – which is that architecture is about making those decisions which have a significant cost to reverse (or change). Thus it is not that architecture is not-agile (though there is some truth in that), but that it is about understanding which decisions are costly (which I take to mean more than just financial cost, could include time, effort, emotion or politics) to change or reverse once they are made. Thus the agility comes in making just-in-time those decisions that need to be made then, and deferring the ones that don’t need to be made until later, and leaving reversible or low-cost decisions to non-architects. I hope that makes sense.

    Doug

  2. Hi Doug, thanks for your comment. Indeed you mention an additional barrier to change i.e. the cost of “reversing” or “change the change”. It does however not change my view that architecture is the non-agile part in the distribution of the whole. It only enforces that. It adds another barrier. I should add however that “agile architecture” is often being referred too. Does that make sense given the above statements? Yes, I think so. Agile architecture is architecture that pushes desired variability points to the edge with or into the remainder of design (or configuration) hence realizing desired agility. Agile architecture is not architecture that is agile which is an oxymoron, but one that has the distribution right, thus effective.

    Grady Booch made his statements in the context of software architecture. I am considering these in the context of all architectures, especially enterprise architecture.

    • I think there is a distinction between “agility” and “agile” that we are both glossing over. Agile architecture (or more properly “agile architecting”) is architecture that takes the “Agile manifesto” seriously. Agile architecture is a (software development) process. Agility is a property of systems or enterprises. You can architect for agility without doing it in an agile fashion, and vice versa. So the process can be agile, and the resulting architecture have no agility. I take it that a key point of any system or enterprise architecture is designing in those points of flexibility that support desires for enterprise agility, and designing in points of inflexibility where the business does not desire agility.

      Doug

      • Hi Doug, this is an interesting comment at a right moment. It made me realize that there is even more ground to cover than I had in mind. Anyhow more to reflect on and blog, hopefully with results soon. Thanks.

      • Hi Kris,

        Thinking about this a little more. Another way to capture what I was trying to get at is to consider the word “agile” as either an adverb (modifying an activity) or as an adjective (modifying a thing). Both are important senses of the same word, but are also importantly different.

        Doug

  3. I feel the quote is not a happy one, as I personally dislike the idea of architecture as a design task. I take architecture as a thing: the actual organization of the system elements and their relations. Now, part of dealing with that organization is actually design, when that task is defined as the decision making based on the manipulation of models that are basically abstractions of a reality. That said, you do design when you work with the real system essence, without all the details. The abstraction level is depicted by the amount of missing details. Architecture design work at high level, meaning with very few details. How few? Enough to be able to understand the whole and still work with its parts.

    So, architecture is not JUST design, and all design does not happen at architecture level, but ALL design affects the architecture anyway.

    My two cents.

    William Martinez

    • Hi William,

      Above is absolutely not the whole story. There are other dimensions e.g. the actual organization of the system elements and their relations as you bring forward, that are, no doubt, equally important. I’ll come to that in follow-up posts.

      I agree that all design does not happen at architecture level, and all design “can” affect architecture. The post is not conflict with that in my opinion, on purpose. But for deciding that architecture is not just design, I would need convincing arguments that I have never heard yet. I have come across a school that calls architecture more fluid than design but so far I find especially that argument “fluid”. Different schools often exist because of different semantics. I suspect that is the case here.

      Thanks for your time.

  4. Pingback: Tom Graves / Tetradian » Notes on architecture versus design

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s