So many people say it’s important to design a system well, but few people discuss why this is important.

When we’re working on a new piece of functionality, we try to find out what is it that we are trying to achieve and (more importantly) why we are trying to introduce this new functionality. These days, understanding the business proposition behind functional requirements is considered fundamental. Understanding the ‘why’ behind a piece of work isn’t so much to validate that the work is worth doing (although we shouldn’t do things with no business value), the essence of what we are doing when we ask ‘What?’ and ‘Why?’ is making sure that our understanding of what we deliver is actually what the business is after and that we deliver the right solution.

Baring this in mind, shouldn’t we try to understand the why on technical design aspects and the technical/operational/quality requirements which aren’t explicitly defined by ‘the customer’. Before anyone goes off on one, I’m not saying these technical design aspects and technical/operational/quality requirements aren’t important, I’m saying that understanding the why allows us to deliver them better.

So, Why is a good system architecture important and what do we get from it? What and where is the Business Value in having a good system architecture?

In ‘the good old days’ when everything was done on paper, filing, organising, archiving, and cataloguing was an important part of doing business. For a small amount of upfront effort with each task, it became a lot easier and quicker to conduct business and as the business went through changes and updated processes the business was able to move, replace, update the right documents pretty easily (obviously this is relatively speaking, remember this was in the ‘paper age’). The same concepts apply with good architecture.

The purpose of designing a system well is twofold. One is obviously around the performance aspects, get it wrong, and it could mean that you end up making a lot more database calls than actually required, the system may not scale, it could run a lot slower than you want it to. The performance impact of ‘bad design’ can end up being very costly, there is much evidence to suggest that a slowness on a retailing website (as an example) reduces conversion rate significantly, even half a second can have a large impact. Scaling may end up involving a high infrastructure cost, obviously this could be make or break for a business, especially in the low margin businesses.

But one key aspect is about business agility, making sure that the business is able to make changes to the system quickly and easily, ideally with changes being isolated so that other things stay stable. One key aspect hasn’t changed from the ‘paper age’, putting a small amount of upfront effort with each task, makes it easier to to change, add or remove things in future.

Against competitors, not being able to make changes very quickly can be a huge handicap. If our competitors can churn out new functionality quicker than we can, this means they can overtake our business proposition. But there is also the consideration of cost, if (all other things being equal) it takes us longer to get new functionality ready to go live, this essentially means that we’ve spent more time/effort ‘doing it’, that’s a cost. If it takes us a month to do something which, in the ideal world should only take 1 week worth of development, that means that this feature/functionality has cost the business 3 weeks of salary(s) more than it should have. From a value point of view, being able to complete work quicker and deliver it quicker means that the business gets more usage of the feature (in this case 3 weeks more usage), this also means, for the same number of development resources we are better able to deliver more within a given year.

Designing and implementing a system architecture well allows us to be nimble and adaptable, it allows us change quickly, cheaply and easily. Having a imble and adaptable system means a developer doesn’t hold his head in his hands if requirements change half way through a project.