Skip to the content

Software Architecture: Why and When?


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.


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.

About the author

Stuart Muckley

Stuart Muckley

I’ve been a programmer and IT enthusiast for 30 years (since the zx spectrum) and concentrated on AI (neural nets & genetic algorithms) at University. My principle skills are concentrated on Enterprise and Solution Architecture and managing effective developer teams.

I enjoy the mix between technical and business aspects; how technology enables and how that (hopefully) improves profit/EBITDA & reduces cost-per-transaction, the impact upon staff and how to remediate go-live and handover, and risk identification and mitigation. My guiding principle is “Occams Razor” that simplicity is almost always the best option by reducing complexity, time to build, organisational stress and longer term costs.

We're Honestly Here to Help!

Get in Touch

Got questions?  We're always happy to (at least) try and help.  Give us a call, email, tweet, FB post or just shout if you have questions.

Code Wizards provide an extremely rare mix blending business and technology expertise. This enables their service/technology designs and implementation to add to business strategy and service objectives. The contribution to TheGivingMachine's mission, social impact as well as service implementation has been amazing - thank you!

Richard Morris, Founder and CEO TheGivingMachine

Working In Partnership

We're up for (almost) anything.

Our partner network is continuing to grow with like-minded companies that can add value to our mutual client offering. If you would like to learn more about how we can grow together get in touch.