Software Architecture: Why and When?

Synopsis

In this blog post we're going to cover where architecture fits in the new world of agile development and why it is still required.

What is Software Architecture?

It's best described by making use of an analogy.

I have a problem: I need an office..

The Architect helps me to formulate what I need versus the budget I have; how many people?  how many desks?  what facilities etc.  Then they design the structure in a formal fashion so any Builder/Developer can produce the product.

In IT we typically don't go as far as traditional architects because we're largely interested with flows, the constraints and the solution as a whole.  We want our Developers to utilise their expertise and knowledge to build around the requirements.

But that's not all, in IT Architects help determine risk and costs.  They also understand how the business and IT elements interrelate (and where they don't!).

Why is it important?

In smaller development teams architecture can be managed as part of the development however it often helps to have some form of technical plan/blueprint (let's call it an "outline architecture") to work with so everybody can understand the direction of travel and the common elements.

For larger teams collectively building a solution architecture is very important.  It sets the keystone in place and allows better working practises and concurrency.  Most important it shows how the solution meshes together so individiuals/sub-teams can work on key areas without having to understand all the moving parts.

Architecture also has a massive impact on due dilligence (buying or selling a company or a part of an organisation) processes.  Code is important however how it fits, what the roadmap looks like, how the intellectual property is managed and the flows of information (and money) around those IT assets are as important.

How does it fit with Agile structures?

The most militant agile structures try and remove architecture from the equation.  Unfortunately (in our experience) this leads to a process of re-development and sometimes failures to meet key requirements that aren't considered early on.

A good example is with the creation of a web store.  Creation is easy (so easy that often people start before any planning takes place) but after a few months the tougher stories enter the sprints: how to handle differing VAT/GST structures for example, or variations in discounting and shipping costs dependant on order levels.  These mean large changes to the base code (and the testing and validation that occurs).  Then the bombshell is dropped that transaction rates need to be 10x the current.. suddenly the entire code structure is in question as nobody did the modelling/architecture to ensure that it scales as needed.

Our process with agile is to do some pre-sprint work and map out the base architecture, then utilise architecture as part of each sprint both for better development and also to ensure QA of the code is in line with what's required.  In this way we can de-risk the approach.

Summary

Software Architecture is probably more important than ever: building your foundations from a solid bedrock (and ensuring quality within your process) is the key to scaling, delivering on time and getting what you really want.