Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Evolving Architectures - Part II but Design is emergent

March 11, 2010

This is part II of a series on agile architecture.In the previous installment I provided a definition for software architecture and raised the apparent friction between the up front design implied by software architecture and the YAGNI approach and deferred requirements prompted by agile development in the large. This installment take a look at an additional angle of the problem which is the difference between design and architecture (while architecture is a type of design I cam calling design the code or close abstractions of it that don't yet fall under ";architecture"; as defined in the previous post). The difference between the two, as the title suggests, is that while design can be emergent, Architecture, unfortunately needs to evolve.

Unless you've been living under a rock, you've probably already know about Test Driven Development (TDD) or its cousin BDD. If you've actually used TDD, you've probably noticed the impact it has on the actual code. Writing code only to cater for defined tests coupled with refactoring that keeps the design tight we get to a result that, more often than not, simpler than going through the more traditional design first (you can take a look at Uncle Bob Bowling Kata for a simple, albeit synthetic , sample)

In fact, a more accurate expansion of the TDD acronym is Test Driven Design. Yes the tests are there to make sure the code adheres to the specified requirements. However, the iterative process (test,code & esp. refactor) makes the design emerge . The emergent design effect, works very well with the goals and tenets of Agile and Lean methodologies as it helps eliminate wasteful future-proofing code that we don't need; eliminate waste of extra component (due to pre-design) etc.

This sounds great, so it is very tempting to take that to the architecture level, after all Architecture is a type of design, wouldn't it be efficient to do TDA (Test Driven Architecture) as well. I think that in theory it might be possible. However as the old adage goes ";Theory and practice are the same - at least in theory";. So in practice, the problem is that architecture is global and have solution-wide consequences. Time and size (of work) constraints make us want to set the playfield for the solution as soon as possible. Architecture decisions are hard to postpone on the one hand and have extensive influence on the other. E.g. a buy vs. build decision; 3-tier vs. SOA; RDBMS vs a NoSQL solution etc. if we try to have the architecture grew the way ";regular"; design can the ripple effects will be devastating to the development process.

What we have to do instead is evolve the architecture. Start with something that is in the ball park and then when we know more about the problem make changes, evolve the architecture over time. This is beneficial since requirements also tend to change over time so if we find a way to evolve the architecture we can deal with that as well.

In the next part I'll try to give a couple of examples on how this can actually be done i.e. how you can evolve an architecture

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.
 


Video