Evolving Architectures – Part V – Leaps

When talking about “evolving architectures” a “leap” is one of the worst things that can happen. In the previous installment in this series I defined Kent Beck’s “Leap” design strategy in the context of Software architecture as

“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. From the practical perspective that would mean breaking the build until a few related changes are in place”

Basically making an architecture leap means that what we did so far is not good enough for us to go forward on. It also means that the current architecture is too far from something useful to bother with taking the more evolutionary approaches to getting it there.

This sounds very much like a catastrophe and it can be if you find out you need a leap towards or after you went into full production. In my opinion, however, there are circumstances when making a leap is a valid and reasonable (and maybe even expected) strategy :

• When the project at hand is breaking new grounds (or is a new ground for the team)
• When the goal of the development phase was for a specific – e.g. The goal was time to market or better understanding the of the technology/business constraints (a.k.a. throw-away prototype).

For instance, when we started out on a new project and .NET was new (beta of 1.0) we took our best developers and sent them off-site to work with Microsoft to build a prototype architecture. This served both for getting the team up to speed on the technology and to understand the limitations of the technology so that when we designed the architecture later we made less mistakes.

It is probably needless to say but the above scenarios are likely to be at the early stages of a project. The question then is does the advice I provided in part IIIto invest some up-front design is still valid – if you are going to leap anyway, up front design seems like waste.

My opinion (and experience) is that you need to set up a working architecture for the first phase because

• You need to make some architectural decisions just to start moving – for example in one of my past projects we had several teams that were geographically dispersed, in order to begin moving forward we had to somehow divide the work so the teams would be as independent as possible – that’s an architectural decision right there.
• The initial architecture can still serve you well – For example when I worked on Biometric systems we’ve built 2 smaller scale solutions (stand-alone station and client-server solution) based on a simple(r), less scalable architecture before we turned to building the full-scale platform. We were still able to sell those systems as they provided business value
• You can’t be sure you’d even have the time to do a leap – For example in xsights, god rest her soul, our first priority was time to market, we wanted to let the marketing and sales people stop hand waving and show what we can do as soon as possible, being a startup we weren’t sure we’d have the time to change so we invested a little more time, than I would normally do, to get a good architecture rolling. So yes, we had to change it and yes it had to be a leap but it also served us to get the marketing people going on time; it was modular so a lot of the business logic survived to the new architecture. Not to mention that the architectural structure allowed us to get the team working on different parts of the solution in a way that allowed us to quickly get a fully integrated system (and get to continuous integration and automated tests)

If you are starting out, building on the assumption that you may have to abandon the initial architecture, it is important to build flexibility or at least modularity into the initial architecture. In projects where we did that, we were able to reuse most of the business logic moving from between the different architectures. Sometimes it is very simple for example, again in xsights, we moved a monorail MVC solution to a ASP.NET MVVM one in a couple of days. The other elements required more work (to strip down infrastructure dependent code) and to move business logic to a cleaner architecture which was, among other things, more evolvable – but that’s for the next post

---

illustration by ywel

Need your architecture evaluated?