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 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.
I absolutely agree with you on this article. Off-course I usually agree on your thoughts (:-)). Funny I am reading this, because I had the exact same discussion at a customer of mine with one of the externally hired lead software engineers. He was claiming that the organisation needed a good technical architecture. And, off-course, I could not repell that. But his support argument was like the argument you described about de ASP.NET MVC Framework. I think it is the exact opposite. Analyse your business processes and choose such an architecture to support the processes. If standard provided frameworks do not fit, than arrange something different!
I think it gets even better. Having a sound software architecture in place allows you to tailor “standard” provided frameworks, instead of not using them. The job is to map the components in those frameworks you would like to use to your software architecture, and certainly not the other way round. By the way, who decides what is “standard” and what not?
And, I’ve finally finalized the set of slides I use for my pragmatic software architecture and patterns for .Net. It’s a collection of over 250 slides. This post comes from the notes I’ve started to add to these slides. Once I’ve finished writing the notes, that will be the first draft of the book (with the same title?).