Evolving Architectures – Part IV – Design mechanics

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 three ways to evaluate architecture in code
• 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