Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Evolving Architectures: Part V – Leaps

August 01, 2010

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

Check out my architecture consulting services

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.