I still struggle to believe that, even in 2014, the role of software architects remains hugely misunderstood by many people in our industry. We generally understand the role of software developers, business analysts, project managers, ScrumMasters, testers, etc but a common definition of the software architecture role still seems to elude us. There's nothing new here, I've spoken and written about this before, as have many others. The thing that irritates me the most is the common knee-jerk reaction along the lines of...
There is no such thing as a software architect and we don't need people telling us what to do. Software architects should write code along with the rest of the development team.
I agree 100% with the coding part of this statement. There are a number of reasons why software architects should be involved with the day-to-day coding activities on a software team. This is *my* preferred way of working. The "there's no such thing as a software architect" and "we don't need software architects" is shortsighted though.
Our industry is very hype-driven and it's common to hear people speaking at conferences about their "flat teams where we're all just developers". The implication here is that all of the other disciplines needed by the team (project management, business analysis, testing, etc) are also being accounted for by the team, typically through self-organisation, perhaps by agreeing that everybody is jointly responsible. In the latter case, this implies that the software architecture duties are being shared amongst the team too. In this situation, everybody is a software architect, except when they're not.
While I agree that software architects should be developers, most software developers are not architects. This is an important distinction. Many software teams out there are operating without anybody who understands the value of the software architecture role, let alone have anybody doing it. It's a technical leadership role and a lack of technical leadership leads to a whole raft of problems.
To give a real-world example, Troy Hunt wrote a great blog post last year called Should websites be required to publicly disclose their password storage strategy? that talks about how many websites are much less secure than they would make you believe. Some of the commenters suggest that perhaps the developers simply don't know any better, particularly when it comes to securing user passwords in a database. I agree, and while it would be great if all software developers had a thorough understanding of security, that's not going to happen overnight. Besides, we can't be experts in everything, but then we don't need to be. Such stories point to a lack of technical leadership. Every software team needs at least one person who is able to take a holistic view of the software being built, create a vision for the team to work with and ensure that any high priority risks are identified and mitigated. I'd say that these risks include security breaches.
If you think about software architects as being the equivalent to structural engineers in the building world, then it's not surprising that many software systems crash and burn. This frightening letter on Uncle Bob Martin's blog additionally highlights the need for more professionalism in the industry. I think it's time we started looking at how to tip the scales in balance of software development being more about engineering than craft, especially as we seem to be telling the next generation that coding is easy. Explicitly identifying those responsible for the technical leadership role, and educating others about it, is a step in the right direction.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.