Jason, Interesting your question but what does it mean ? Do you think that architects cannot be accountable about what they design ? Thanks

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:

• Architect is no longer on the team come judgment day (too expensive/busy/important)
• Drivers (requirements, constraints, assumptions) no longer valid
• Design authority, and therefore responsibility, has been shared (diluted?) amongst the development team

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.

It's because creating software is inherintly an engineering task that's being performed by people who aren't engineers and the necessary discipline is lacking in the programming profession. For the latest trends, we look to blogs over professional organizations. Gaining specialized expertise in the latest technology matters more to us than gaining professional credentials that show that we understand the theory behind what we do. Here's an MSDN article explaining why our profession belongs to the field of engineering, and not art or science. http://msdn.microsoft.com/en-us/library/bb508955.aspx AS to the software architect question, it's simple, a software architect is the senior guy who's either tired of programming and/or wants to make more money. Does he have a masters? Probably not. What about a certification, such as those put out by the SEI? Probably not. In other professions, they expect more. An accountant is not a CPA until he passes the exam. There are tiered certification levels for actuaries. Other engineering professions have accredidations as well as masters programs.

"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.

I think they are held accountable... but in different ways than you might think. Architects are not only responsible for deciding how to technically implement something. They are resposible for the skills of the technical teams they work with, the technology platform, assisting with planning (Particularly prioritization of tasks vis-a-vie technology, availability), technology strategy, and last but by no means least communication with developers to ensure that they understand what is expected of the team. So how does a project usually go on the rocks? The first indicator is often some sort of slippage... in the time line, feature set, or approach to implementation. Why does this occur? There are *many* reasons, but consider this: An architecture can be proposed for a sub-system or component and a development team could "spin" on the implementation... for a number of reasons: insufficient understanding of the technical design, a gap in their own technical skills, or the architecture may have highly complex implementation requirements. Looking at each scenario: Insufficient team understanding - This would ultimately be a failure of the architect to communicate sufficiently with the team and ensure appropriate "hand-off" of the technical design. A gap in developer/team technical skills - This is a failure of the architect as a coach and mentor. Part of an architects job is to assess team skills and facilitate growth in the development staff so that developers can perform the technical tasks that they require. Architecture with highly complex implementation requirements - Architectures must be matured to ensure a clearly defined and reasonable effort and approach to implementation and it is the responsibility of the architect to do this. If you look at all of these failings they do come back to the architect, but in a more systemic way. The converstation that I as a Director would have with an Architect in these scenarios is much more about their job performance and those are conversations that SHOULD be held privately. In contrast, a teams failure to deliver a unit of work through splippage, etc is an event that SDLCs and Project Manangement methodologies purposefully make very visible. That is why the focus is on overall team committment and delivery not the individual. My point: architects are held responsible... privately. They are leaders of the technical team and as a result their failure is viewed as an individuals failure. Since their individual failings translate directly into their reviews whereas team failings have far less impact on individual reviews, these matters are typically handled privately.