“Imagine you want an extension on your house and the builders come along and start building a wall straightaway. As the client, you’d be concerned but that’s the approach a lot of people are taking to software development these days.” As with all good metaphors, it’s both simple and effective, succinctly describing a major problem, which in Simon Brown’s view, afflicts software projects around the world.
If anyone is in a position to have a global view of software development, it is Brown. His views on the role of the architect are widely sought and he has found himself speaking to groups and organisations in dozens of countries. The fact that his extensive writing, which includes both a book and six years’ worth of blogging, has been translated into several languages, adds credibility to the idea that he isn’t the only person who thinks along these lines. Brown’s own experience shows that there are plenty of development teams out there that feel something isn’t quite right with the way many projects operate.
Of course, there are plenty of reasons why an individual project may not progress strictly according to plan but when looking at the bigger picture, Brown believes that a lot of teams could perform better if more thought had gone into the pre-build design – the architecture.
As a result, Brown has found himself on a mission to help people understand the value of the software architect, helping them see the designer as a key player in the software development process.
If Brown is right, and demand for his services suggests that he is, then it begs the question: Why has the software architect become so devalued?
According to Brown, there are two principal forces behind the decline in the role of the architect. Firstly, the job itself became over-inflated in terms of status, leading to a hierarchical concept of architecture as the next step up the career ladder instead of being an integral part of the development process.
“Traditional approaches to software architecture usually result in a dedicated software architect, triggering thoughts of ivory tower dictators who are a long way removed from the process of building software,” he writes in his book, Software Architecture for Developers.
The software architect’s transformation from being a useful team member with a clearly defined function into a role that denotes a separate position within a hierarchy, is a compelling reason for the fall in the value of architecture. This decline also fits neatly with the enormous rise in popularity of Agile approaches, which in Simon’s view is the second reason for architecture losing its popularity, and can be seen as something of a reaction against the architect’s role.
“The architectural side got to the point where people were dictating to their teams and were not keeping up with the technology, so you ended up with teams who ignored the architect and got on with the job themselves. In their move towards becoming Agile, some teams are now saying ‘we don’t need these architects.’
For many developers and project managers, the Agile principal of self-organising teams was a welcome antidote to the problems that had developed as the architect’s role had changed. Agile approaches are about delivering working software (and therefore value) to people quickly, in small chunks and embracing feedback to ensure that what is delivered meets its goals. The problem is that many Agile teams forgo any upfront design in the rush to deliver working software. It's the delivery focussed agenda that seems to conflict with Agile approaches.
It is this tension between architecture and the Agile way that Brown seeks to resolve. He is not anti-Agile but is clear that by dispensing with the software architect, and therefore the planning process, he sees that many teams have gone too far. Instead of having to choose between having an architect and running a project by following the Agile principals, Brown sees the two as being integrated.
“The traditional approach is that you keep coding and architecture separate but I try to get coders thinking of architecture as being a significant part of a lightweight and collaborative process and architects as being hands on.”
On the surface, Brown’s message is simple but as with all cultural change, implementation can be more difficult. The clear demand for his take on the role of the architect shows that developers around the world are listening and bit by bit, he is helping people see the value in good software architects who deliver excellent architectural practice.