Evolving System Design vs. Total Architecture

March 8th, 2013

My friend Eldon, over at SenseMaking showed me a slideshare, a while back, of one particular “bowling game” kata. It touches on the difference between a pre-architected system, and one where behaviors are specified and then implemented.

The point of the presentation is pretty straightforward, architecting and designing to specification don’t necessarily lead to good results. Implied, I think, is that being far from plan, but having a working solution should make us think differently about starting at, and building to an architecture spec.

I thought about it again this morning while considering an exercise we’d just gone through at work. We have an API that is designed to adhere to very strict REST Level 4 standards, and one of the data stores that our business layer must access does so over HTTP. There is an AJAX front end.

The problem is not so important as the process we went through to get our solution. The first instance of our solution was the one that requires the least amount of code, but it may have a significant problem: it could potentially multiply into 100 follow-on queries.

Immediately, we went into architecture mode and conceived of throttling and caching mechanisms as long term solutions. A less severe approach has us moving the calls back to the middle (API) layer, and this seemed more reasonable than our third solution — putting business logic into the storage layer.

The exercise was useful for two reasons. First, we had a map of what our world might look like. Our decision to just go with what we have and see what happens is a reasonable place to start, in that it shows results the fastest, and requires the least intervention in new code. Second (and this is an important point that may be lost in an agile environment), we are able to communicate the limitations of our first iteration ahead of time, while having a plan in hand for any non-technical stakeholders’ questions that will undoubtedly follow.

Resisting the urge to write code, though, will be the important thing here. The fact is we don’t know what the strengths and limitations of the system are – we’re working with all new technology, as we often do, so better to make an incremental, and evolutionary change to our system, when it’s needed, rather than to develop against what are possible, but only imagined scenarios.

The best philosophical objection I’ve heard to intelligent design theories is that no one would have engineered a human as we are, where our breathing apparatus and sustenance port have a shared infrastructure, often to disastrous ends, not to mention the proximity between our refuse and linking systems. Despite those shortcomings, it’s a pretty amazing system, as a whole.

The distinction should be noted. We have tried the Intelligent Designer’s way. So, for now, take a cue from Mother Nature, not the Designer, and yes, do some planning, but try and let your system evolve, naturally.


Leave a Reply