Mike Walker has an interesting post comparing the architect roles across the building and software industries, entitled The Nemesis of Software Architecture. Comparisons aside, there's one point that I really wanted to pick up on.
4. Accountability Inherent - Building architects are accountable for there work when their specification fail while software architects are not. An example of this is the case of an architect stealing a design for the Freedom Tower or the example of MIT that sued well known architect for defective structures. There is clear accountability whereas I still haven't heard of someone getting sued for copy & paste...
I'm a big proponent of software architects having the responsibility and authority to ensure that the projects they are working on come to a successful conclusion, but it does raise an interesting question of why project sponsors don't typically hold software architects accountable. Perhaps it's because the dynamics and roles of everybody on the project team aren't well understood in most cases. For example, what's the working relationship between a project manager and an architect; or the developers and an architect? Or maybe it's because our agile approaches tend to favour sharing the responsibility throughout the entire team, which can end up with the project lacking a single coherent and consistent direction.
In order to address this, maybe we need to go back to basics. Why aren't software architects explicitly given accountability at the outset of a project and what incentive is there for them to accept it?
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.
You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.
Accountability probably isn't the problem, being somewhat akin to shutting the stable door after the horse has bolted. I don't think bad design decisions come from a belief that you'll "get away with it" but may arise from only considering the problem with respect to your direct involvement on the project.
The reasons why a "building architect" is accountable are clear: their registration with the ARB or AIA indicates a level of ability and reliability that their client expects to be upheld. Software architects' roles are far less well understood. We always seem to come back to this point eventually!
While I don't necessarily believe it's a Good Thing for architects to be unaccountable for their design choices, I can imagine some reasons why they aren't:
There's a lot more that could be said about agile's positive and negative impact on responsibility and even achievement so I'll save that for a separate article :P
This is perhaps all just part of career growth: team members improve and take responsibility (either as a group or individually) and in so doing inherit the responsibility for decisions already made.
This is not to say that this is necessarily a Bad Thing, either! We're not involved in civil engineering and just as we don't require the same time and cost for our projects we wouldn't necessarily expect to be held accountable in the same way. Not least to avoid Analysis Paralysis.
"And I think every software architect feels the same way."
Feeling accountable is not the same as being accountable. I'd like to agree, though, that anyone worthy of the title would feel accountable, even if they were never actually held to account.