Everybody is an architect, except when they're not

Single point of responsibility or shared amongst the team?

I went to a couple of great presentations on the "Software Craftsman" track at the QCon London 2011 conference last week that, together, provide a really easy way to explain how software architecture fits into modern software development teams.

Everybody is an architect

The first session, entitled Craft and Software Engineering by Glenn Vanderburg, explored the relationship and conflict between the craft and engineering of physical construction and software development. Really interesting session and I recommend downloading the slides or watching it if you get the opportunity. For me, one of the eureka moments was when he presented this picture from his Extreme Programming Annealed essay. Basically, it shows the scale at which the XP practices work.

Extreme Programming Annealed

I've highlighted collective ownership. Yes, it is about the code but collective ownership implies that everybody on the team needs at least some basic understanding of the "big picture". Think about your current project; could you jump into any part of the codebase and understand what was going on?

Imagine if you did have a team of experienced software developers that were all able to switch in and out of the big picture. A team of genuinely hands-on architects. That team would be amazing and all of the concerns you usually associate with software architecture (non-functionals, constraints, etc) would all get dealt with and nothing would slip through the gaps. From a technical perspective, this is a self-organising team. Think of them as a solid concrete dam blocking a fast flowing river, through which nothing can escape.

Except when they're not

My big problem with the whole self-organising team idea is that I rarely see it in practice. This could be a side-effect of working in a consulting environment in that my team always changes from project to project and I don't tend to spend more than a few months with any particular customer team. Or, I suspect that true self-organising teams are very few and far between. Striving to be self-organising is admirable, but most teams have bigger problems and the sort of scenario played out in my recent Software Project SOS session is indicative of the problems that I see.

And that brings me on to the second session, Team Leadership in the Age of Agile by the guitar playing Roy Osherove. Again, the slides are available to download. The session was about what you need to do in order to lead a software team, highlighting the fact that not all teams are equal. Roy categorises teams using a simple maturity model, which you can see described in more detail at The 3 maturity stages of a software team and how scrum fails to identify them. The three stages are: chaotic, learning/maturing and self-organising/matured. In essence, each maturity level requires a different approach to leadership.

As I said above, a team where everybody was an experienced software developer/architect would be amazing but this isn't something I've seen happen. Most projects don't have *anybody* on the team with experience of this "big picture" stuff and this is evidenced by codebases that don't make sense (big balls of mud), designs that are unclear, systems that are slow and so on. This type of situation is the one I see the most and, from a technical perspective, I recommend that *one* person on the team takes responsibility for the software architecture role. Roy also suggests that most teams are in the chaotic stage and, similarly, need more of direct leadership approach early on.

Whether you're talking about team leadership or technical leadership, the principle is the same. The chaotic team is like damming a fast flowing river with a bunch of twigs. It'll slow the water down for a very short amount of time but it soon becomes ineffective and you'll struggle just to keep stationary. A more direct leadership approach in these early stages will show you what you can't see and allow for some solid advice on which holes should be filled immediately.

Agile projects still need software architecture

Unfortunately, many teams view the "big picture" technical skills as an unnecessary evil rather than an essential complement, probably because they've been burnt by big design up front (BDUF) in the past. Some are also so focussed on the desire to be "agile" that other aspects of the software development process get neglected. Chaos rather than self-organisation ensues yet such teams challenge the need for a more direct leadership approach. After all, they're striving to be agile and having a single point of responsibility for the technical aspects of the project conflicts with their view of what an agile team should look like. This conflict tends to cause people to think that agile and architecture are opposing forces and that you can have one or the other but not both. It's not architecture that's the opposing force though, it's BDUF.

First things first then. Agile software projects still need architecture because all those tricky concerns around complex non-functionals and constraints don't go away. It's just the execution of the architecture role that differs.

From chaos to self-organising

As Roy said in his talk, a self-organising team doesn't need a dedicated ScrumMaster. Likewise, it doesn't need a dedicated software architect either. With collective code ownership, everybody needs to be able to work at the architecture level and so everybody *is* an architect. Teams that aren't at the self-organising stage will struggle, though, if they try to run too fast. Despite people's aspirations to be agile, collective code ownership and a distribution of the architecture role is likely to hinder chaotic teams rather than help them. Chaotic teams need a more direct leadership approach and they will benefit from a single point of responsibility for the technical aspects of the software project. In other words, they will benefit from a single person looking after the software architecture role. Ideally this person will coach others so that they too can help with this role.

One software architect or many? Single point of responsibility or shared amongst the team? Agile or not, the software architecture role exists. Only the context will tell you the right answer.

About the author

Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.



Re: Everybody is an architect, except when they're not

My best experiences by far of distributed design responsibility is in open source projects that I've run and participated in. The in-built peer review, combined with a longer than average vision horizon for developers (it's assumed by all that an open source project will be around for many years, so design quality carries greater weight) tends to naturally encourage better quality architecture. No-one wants to be the guy whose designs, which are displayed very publicly, look like the back end of a donkey. I've also worked with teams at the two other ends of the spectrum (in corporate projects) - no design knowledge at all, or some rock-star architect with a resume that looks impressive until you realise he's basically grazing the surface of every project he's been on. I have absolutely no time for dedicated architects - those highly paid consultants that flit from project to project without ever deploying anything (because they move on way before you get to that nitty-gritty stage) and have seen many an architecture that looks beautiful on paper that totally fails in the real world, or ages really badly just because it was 'best practice' in theory 5 years ago but those theories hadn't had time to be proven properly yet. Real design isn't done until the code is running live, and preferably until you've been through a couple of post-live cycles. Even if your architect really is an ace, and sticks around for deployment & revisions, vesting that amount of responsibility in one person is extremely bad risk planning. What if he's ill? Or leaves? Who's next in line, and have they really been *doing* it, rather than just watching? Senior developers who have a strong grasp of architecture and design and guide / mentor other coders, but most importantly implement this design by example, are where it's at. And you need more than one of them, otherwise where is your peer review, or your succession plan? Design is a never-ending process - people talk about pair programming, code review, agile development, but if there's anything that needs reviewing, revising and revisiting regularly, it's the design that everything else hangs off. Building an architecture-aware team that doesn't need a single dedicated architect is absolutely doable - almost all large open source projects operate with multiple people at the design helm. They may well 'own' particular submodules individually (casting vote, elevated authority), but the design process is most definitely collaborative, and all the better for it. In practice this isn't confusing or chaotic at all, so long as your communication is good - which is likely the actual root of many failed attempts at such a setup.

Re: Everybody is an architect, except when they're not

Agreed ... it's amazing to think that (many) external open source projects work so well when internal corporate projects fail so spectacularly! The difference? Well, your average 9-5'er doesn't get involved in open source but they *are* involved in those corporate projects. It's the same with people that read blogs and attend conferences. They're a self-selecting audience and tend to be the people that need the least help. It's the remainder of the profession that we need to get to!

Re: Everybody is an architect, except when they're not

I think the sad thing is that true '9 to 5ers', the sort of people that wait for people to train them, are not really 'professionals' at all. Being a professional means being responsible for developing and maintaining your own skill base, and trying to grasp the whole picture, including design, business aspects, and so on. I think one of the problems with our 'profession' is that too many people think they're professional when really they just want to muck about writing code, and believe they don't have to try to understand anything else, because that's Somebody Else's Problem. BCS tries to address that to a degree, by requiring that you need to have higher level knowledge to claim you're a certified practitioner, but then kind of shoots itself in the foot by wanting to pidgeon-hole everyone a little too much. I think in general, we need to have better standards, and not accept this attitude that there are people that cut code, and people that design things, and people that understand the business. Everyone should have a solid grasp of these things. Many corporate projects go tits-up simply because things fell between two stools, because everyone thought someone else was handling it (or paying attention more than they were). This is directly related to the silo mentality.

Re: Everybody is an architect, except when they're not

I don't think they're professionals either but they do know how to game the system (often better than people who actually give a damn). This is where the whole software craftsmanship thing comes in too ... but getting people to appreciate the benefit of being craftsman rather than 9-5 code monkeys and generalised specialists rather than jack of all trades, master of none is impossible sometimes. :-/

Re: Everybody is an architect, except when they're not

"I suspect that true self-organising teams are very few and far between." I suspect this, also. And I offer an explanation (at least, maybe a partial explanation): The vast majority of (Ad-hoc or Analytical) knowledge-work organisations out there do not tolerate self-organisation within e.g. teams. (Actually, there's lots of other effective policies and practices they don't tolerate either, but I digress). So, relatively very few (e.g. Synergistic) organisations - where self-organisation can take root and flourish - even exist. And even with a tolerant or, better, a supportive environment, self-organising teams take time, effort, and diligent application to form, storm, norm and (ultimately) perform. This latter issue is only compounded by the widespread practice of repeatedly setting-up and tearing-down teams, in the context of "projects" and project work. Little wonder, then, that high-performance self-organising teams seem so rare? - Bob (@FlowchainSensei)

Re: Everybody is an architect, except when they're not

Do you also think it comes back to giving teams enough rope to hang themselves? I've seen teams that have been "told" to "get on with it" and self-organise, but they've screwed it up. In the past, such teams would rely on management to manage risks, issues, timescales, budgetary concerns and so on. But this is exactly the stuff that gets thrown out of the window (or perhaps, forgotten) when teams are told to "get on with it on their own". Are these teams capable of self-organising? Yes. Can they? Clearly not.

Re: Everybody is an architect, except when they're not

I don't think any but the most severely dysfunctional (read: psychopathic) management knowingly set teams up to fail. Of course, many times teams are set up to fail, unknowingly. :{ And yes, if teams are "thrown in at the deep end" of self-organisation and expected to sink or swim, without lifebelts, swimming aids or lifeguards, I'm not surprised that many sink (and drown). Many organisations don't realise how "deep" the agile end of the pool is (and the power of the undertow there). - Bob

Re: Everybody is an architect, except when they're not

Yes, I don't think those teams are purposely setup to fail, but I think it's more to do with management trusting the teams to do the right thing. Which they often don't.

Add a comment Send a TrackBack