Re-evaluating software architecture

Mon, 08 Dec 2008 20:53:27 GMT

Somebody asked a question at my recent BCS session that got me thinking about software architecture and whether we need it.

Why do we need this new software architecture stuff? We've managed fine until now and projects *have* been successful.

Some of this has been talked about recently, but of course it *is* possible to have successful software projects without architecture. Not every system needs a heavy dose of architectural input; particularly when you have small systems, simple requirements, luck or naivety on your side. ;-)

Do we really need software architecture?

But just because a team has never undertaken any software architecture doesn't mean that they'll never need to. It's definitely worth questioning the purpose of software architecture, particularly in our financially challenged world with IT sponsors wanting more for their money. Myself and the others on the site talk a lot about our experiences of software development from an architectural perspective, but these are just *our* experiences. Many of the processes, techniques and advice works well for us, but it's always worth asking yourself whether it will work for you too. What value will it bring? How will it make your project team more effective? How will it make the project more successful?

Questions like the one I was asked at my BCS session always force me to stand back in order to understand another point of view. Sometimes, a lot of what I write about seems common sense to me, which again makes me stand back and make sure that I'm not overstating the obvious. But everybody is different, and one person's common sense can be another's revelation, and vice versa. Sometimes I often question whether I should just get on with coding up the system and to stop worrying about all these other things. But then something happens that puts everything back into perspective again.

One of the projects that I've done some work on recently does have an architecture that has been explicitly defined and it's in pretty good shape. It has separate tiers with their own responsibilities, some architectural principles are in place to ensure consistency and the team have taken a good approach to quality through a comprehensive set of automated tests. The problem is this ... none of it has been formalised or shared effectively.

Is the code the architecture?

Many agile proponents will say that the code is the best documentation you can have, because it's always up to date and represents reality. I often joke about the code being the architecture, but architecture actually sits at a higher level of abstraction than the code. To put this into context, I can look at a block of code and understand what it does, but I have to look across *many* similar blocks of code to understand the underlying architectural principles behind it all.

Architecture introduces structure and guidelines

In my talks and training about software architecture, I say that architecture is about introducing structure and guidelines to a software project, and I've come to realise just how true this is. Without formalising these good ideas, a codebase with some otherwise great ideas can appear inconsistent, with the overall system lacking coherence and clarity. While this lack of consistency can make it harder for the project team to deliver a high quality system, it makes it really hard for members that are new to the team. Without formalising all of this good work and explicit architectural thinking, it's difficult for new team members to understand what's going on, how the system works and what's expected of them (i.e. writing architecturally compliant code). In the worst case scenario, this can introduce a whole host of problems around areas such as performance, scalability, security, etc.

The answer is easy ... just stick a stake in the ground, formalise your decisions, strive for consistency and share the architecture. The benefits from software architecture are worth the effort, and even a little architecture can go a long way.

Coding the Architecture - formalising tag

Re-evaluating software architecture

Do we really need software architecture?

Is the code the architecture?

Architecture introduces structure and guidelines