Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Evolving Architectures - Part IV - Design mechanics

July 19, 2010

If we want to evolve architectures or change an existing architecture in general, for that matter, it is important to understand design mechanics. I recently attended a seminar with Kent Beck that talked about "responsive design", where he provided a good definition for 5 strategies or types of design mechanics*:

  • Leap
  • Parallel
  • Simplification
  • Stepping Stone
  • "Just Do it"

Kent talks about these from a design and coding perspectives. Architecture is design but at a higher level and with more consequences system-wide so (I think) are are few nuances from how Kent sees this.

  • "Just Do it" is what you do when you don't exactly know where you are going and you so you're adding features and everything but you probably heading into a big ball of mud. If possible it is better to avoid working this way, but sometimes realities take us there anyway.
  • Stepping Stone is what you do when you aren't completely sure what needs to be done but you can imagine what would make the end-goal easier to reach. The way I see it, for architects that would mean an architecture proof of concept (spike), prototype of skeleton - the [intlink id="saf-architecture-evaluation-evaluation-code" type="post"]three ways to evaluate architecture in code[/intlink]
  • Simplification - is when you don't know what you want to do and it is too expansive to directly get to an end result. This is the basis of the iterative system. start small and gradually add features as you go. From an architecture perspective it is challenging to to get to a core simplified architecture you can grow later. This is useful as long as the changes in the architecture are within the expected growth path. when it is time to make a change in the architecture you'd need to go with the other strategies.
  • Parallel - is a technique to use when you know where you are going, but can't afford to stop/halt what you already have so you keep the two designs going at the same time and migrate to the new way gradually. This is probably the best technique to use to evolve architecture as it fully considers what you already have. An analogy I like to use in describing this situation is building a new interchange on a highway. The new way would be great, but you can't just stop traffic until everything will be in place so you've got to allow the old way (maybe not in full) until you can make the change safely - the same is true for a running business, nobody will halt the business until you'd get your new shiny thing up and running
  • Leap - is for when you know where you're heading and you can afford to stop everything until the new way is in place. From an architecture perspective it is a bit like starting from scratch (I'll expand on this in the next post). From a design perspective that would mean breaking the build until a few related changes are in place

The next post will expand a little on Leap, Parallel and Simplification

* Kent also discussed several other interesting subjects related to design like cohesion and coupling or this nice definition for design which are worth reading. ** Illustration by dipster1

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.