Agile Architecture is applying agile methods and disciplines to the practice of IT Architecture.  This post is about the agile discipline of Test Driven Development and how to apply to the establishment of your Technical Architecture.  Technical Architecture or Infrastructure Architecture addresses:

• selection of underlying technology services such as Database;
• selection of hardware;
• deployment of software components onto the hardware components; and
• network communications.

Benefits of Test Driven Development

In TDD a developer first codes the unit tests that must be passed by a given component then codes the component.  The most obvious benefit of writing the test first is that the test actually gets written.  Frequently automated tests are left until last and then left out entirely because time has run out.

Another benefit of TDD is it forces a thought process of how am I going to prove this? or How will I know it is done? With TDD, the developer creates the test and an imperical measure of completeness.  If it passes, it’s complete.

When a product has been developed using TDD, automated unit test cases will be in place that reduces the risk and cost of change to your system(s).

Test Driven Architecture

If we apply this Test Driven concept to our Technical Architecture, we can achieve the same benefits of TDD, and arguably more.  In Test Driven Architecture, we first establish a capability to test our architecture, then we implement the architecture.  Frequently instrumentation and monitoring is included in the architecture as a non-functional requirement or quality.  Further, large high risk projects will generally include load testing as a phase in the project.  But being Test Driven takes this awareness of the need to test and monitor to a higher level.

Acceptance Criteria in Scrum User Stories

A key aspect of Scrum User Stories is the inclusion of Acceptance Criteria.  Acceptance Criteria serve to elaborate or further constrain the story to be more specific.  We can apply this method to describing our Architecture requirements.  They syntax or template for an acceptance criteria is:

Given [context]

And [some more context]…

When [event]

Then [outcome]

And [another outcome]…

SEI Architecture – Quality Attribute – Scenarios

Quality Attributes are part of the SEI Architecture Tradeoff Analysis Method (ATAM).   The Quality Attribute technique is a means of describing the qualities or non-functional requirements of a system that the architecture must fulfil.  Quality Attributes are frequently known as the -ilities ( scalability, reliability, availability, adaptability and performance).  But rather than be satisfied with vague statements such as, the sytem must be scalabie, quality attributes are expressed using a scenario structure which is very similar to the Scrum Acceptance Criteria described above.

The SEI folks have devised a Scenario based approach for evaluating architecture in the ATAM.

Given the Requirements, Develop the Test

So whether you choose Scrum Acceptance Criteria style or SEI ATAM Scenarios, you now have a mechanism to define the requirements of the architecture.  Next step is to develop your architecture tests.

I’ll write about that in my next post.