Why do we need software architecture?

Over the past twenty or so years I have been involved in many software development projects, code reviews, and software factory implementations. Although I had stretched the virtues of good software architecture for decades, it wasn’t until a series of recent event, that I really started re-valuing of having a sound software architecture in place. And to me a well-defined software architecture merely describes the patterns used, the layers applied, the types of classes in these layers, and how they collaborate. Primary goal would be to create structure and a clear separation of concerns in your application code.

Code is like ivy

In October and November, I was running a code audit on a 1.4 million lines of code ASP.NET web application, the second large audit I did in a short period of time. Both products where web applications that were targeted at big audiences, and that were meant to last for a long time. And in both cases the software architecture was set up really bad. In one example, I couldn’t even discover a decent software architecture through the code. In just three years this application had grown from a small web application to an enterprise web portal, and a few dozen developers, partly external from the company, had written code in a wide variety of styles. With no architecture in place, the code grew like ivy on a moisty garden shed, resulting in poor maintainability and low productivity in adding new features to the product.

Midst November, I found myself in Barcelona, visiting the Microsoft TechEd conference, where a number of new frameworks were presented – although most of them still in beta. Some of these framework already made their way into full swing projects, one the largest run for one of our Belgian customers. Looking at the presentations, and talking to developers, it occurred to me that a lot of people have their software architecture dictated by the frameworks they apply.

Just think of this. One of the developers I talked claimed to have a good software architecture just because he was using the ASP.NET MVC framework. My vision however is different. It should simply be the other way round. You have a sound software architecture in place, that expresses the business needs and the technical concepts to implement these business needs. Then if you’re interested in applying a particular new framework, you should only need to map the concepts of that framework, say ASP.NET MVC or the Entity Framework, to the concepts in your software architecture. And if it fits, use it. And if it doesn’t either don’t use it, or encapsulate it, so that it will fit in.

Benefits of a sound software architecture

So concluding, if your organization has a software architecture in place, this will offer some rather relevant benefits, which include:

• Higher productivity. It is easier to add new features to existing software, since the structure is already in place, and the location for every new piece of code is known beforehand.
• Better code maintainability. It is easier to maintain existing software, as the structure of the code is visible and known, so it’s easier to find bugs and anomalies.
• Higher adaptability. New technical features, such a different front ends, or adding a business rule engine are easier to achieve, as your software architecture creates a clear separation of concerns.
• Hype agnostic. Last but not least, it will allow you to see hypes and fads in the industry – or which there are a lot – in the light of your current structure, and to fit these hypes and fads in if so required.

So?

So why is it so many organizations and project to not adhere to having such a software architecture in place? It’s beneficial and it doesn’t require a big up front state of art research & development. Just common sense and best practices.