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 design and coding perspectives. Architecture is design, but at a higher level and with more system-wide consequences, so (I think) there are a 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 you’re adding features and everything, but you’re probably heading into a big ball of mud. It is better to avoid working this way if possible, 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), a prototype, or a 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 expensive 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 architectural perspective, getting to a core simplified architecture you can grow later is challenging. 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 simultaneously and gradually migrate to the new way. 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 is 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 when you know where you’re heading and can afford to stop everything until the new way is in place. From an architectural 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.