Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Evolving Architectures: Part III Starting Out

May 16, 2010

As promised starting with this installment I'll talk about what to do. But before we delve into the what/how let's do a quick recap on the why we're here:

  1. Architecture is important to software projects
  2. Architecture and agile have some conflicting forces that needs to be reconciled (e.g. up-front work, hard to change vs. delivering business value quickly and embracing change)
  3. design can be emergent but architectures can't and must be grown instead

Another important point to remember is that sometimes you can get away with it. By "get away with it" I mean you can make 1 day or less design session opt for an off-the-shelf architecture, usually that also means choosing a product (e.g. Rails or Django) and it would be good enough for your project. This is usually true for small project or for projects which are ver/y familiar (and thus rather predictive and for the most part can be handled by waterfall processes).

If your project does not fall under the above mentioned category let's move on :). Here is a list of "Do"s and "Don't" which is based on my experience.

  • Do start with "iteration 0" -- Iteration 0 means an iteration (though it may take more than one) that is focused on building architectural and infrastructure. It may seem like waste at first since your not delivering business value (at least apparent one). However I find that it pays off. Especially if you are working with multiple-teams and need to allow them to continue in parallel.
  • Do Elicit architectural requirements as scenarios (which makes them similar to user stories). Describing architectural requirements as scenarios helps in making sure that the requirements are tied to things important to the system (not just we need 99.999% uptime but also the business scenario where it really matters). Another benefit is that you can align the implementation of the architectural requirement with the delivery of the business value it delivers. You can look for scenarios based on the deliverables in your release plan.
  • Don't think you get them [architectural requirements] all -- requirements change and architectural requirements change as well (hopefully in a slower rate). Try to find the minimal set that can take you forward
  • Do Spike risky stuff. It is worth exploring and evaluating your architectural decisions (see also SAF -- Architecture Evaluation -- Evaluation in Code. When the risks are around stuff you'd need too far in the future (the definition of "too far" can vary but, say, 6 month in the future is probably too far) it is probably safe to disregard them -- but if you make such a decision add this into the technical debt and risk list to make sure it isn't forgotten
  • Do try to build the minimal architectural skeleton. Even though we're spending some effort up-front, we still want to deliver business value as fast as possible. Maybe some of the identified architectural components can be stubbed or partially implemented. For example in a xsights, the communications infrastructure only handled optimistic scenarios (e.g. assuming resources will always be there) for several months.
  • Do try to separate business logic from architectural and infrastructure constructs. If we embrace the idea that chance will come, it is wise to get ready for it. Separation of business logic from the rest means it will be easier to move that around when/if we will need to (it doesn't guarantee we will be able to do it but it would be easier). Another way to look is this is to try to build flexibility in. Yes, I know it is easier said than done but some things work better than other. An example is event vs. procedure calls (both local or over then network) with events you don't know in advance what will handle the call, with a procedure call you do. choices like that can have a lot of impact on the ability to shuffle things around later on.
  • Don't fall in love with the architecture you got. Probably the most important thing, it is going to change. Fred Brooks said it long ago in the Mythical man-month "Plan to throw one away, you will anyway"

That's it for now, the next installments will cover strategies to deal with the changes and evolving the 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.