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 architectural leap means that what we have done so far is not good enough for us to go forward. 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 move 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 ground (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 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 to get 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 fewer mistakes.

Needless to say, the above scenarios are likely to be at the early stages of a project. The question then is whether the advice I provided in part III to 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 geographically dispersed teams. In order to begin moving forward, we had to divide the work somehow 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 built two 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 make a leap – For example, at xsights, our first priority was time to market. We wanted to let the marketing and salespeople stop hand waving and show what we could 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 the transition 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 an 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.

---