Observations on Software Architecture

I am currently reading the book “Practices for Scaling Lean & Agile Development” by Craig Larman and Bas Vodde. This book is full of very interesting material that covers the full spectrum of the software development domain and is the “sequel” of “Scaling Lean & Agile Development – Thinking and Organisational Tools for Large-Scale Scrum” published in 2009. Software architecture and design is one of the topics discussed in the books and I want to share with you some of the authors’ thoughts, starting with five principles that they propose on software architecture and design:

1. The sum of all the source code is the true design blueprint or software architecture.
2. The real software architecture evolves (better or worse) every day of the product, as people do programming.
3. The real living architecture needs to be grown every day through acts of programming by master programmers.
4. A software architect who is not in touch with the evolving source code of the product is out of touch with reality.
5. Every programmer is some kind of architect – whether wanted or not. Every act of programming is some kind of architectural act – good or bad, small or large, intended or not.

The authors then outlines some of the software architecture issues that many of us may have witnessed in large organizations:

“In a large product group with (1) the mental model that the weak metaphor of architecting and building a software system like a building is believed to be a good metaphor; (2) the lack of realization that the true architecture is in the sum of the source code; and, (3) a cadre of architecture astronauts, all this leads ironically to a degrading architecture over time.”

“Also, what happens to the code – the real design – in a group with the following cultural value and message?… There is the architecture group over there; you regular programmers are not architects. They naturally feel that the architecture is not their responsibility, and degradation of architectural integrity continues.”

“Certainly it is important to have a great architecture. It is so important that every act of agile modeling and programming for the life of the system should be treated as an architectural act.”

Architecting software is not an easy task and I remember a conference speaker saying that the architect role is more a journey than a status. As it is also sometimes a question of style, you might have three answers if you asked how to design an application to two programmers. I will be however difficult to build and maintain a good software architecture if all the members of the development teams are not concerned and involved in the process. As Craig Larman and Bas Vodde wrote it “Think ‘gardening’ over ‘architecting’ – create a culture of living, growing design”.

Reference: Practices for Scaling Lean & Agile Development – Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison Wesley, ISBN 978-0-321-63640-9