Is software architecture a poorly done and frequently neglected aspect of software projects? That’s the position put forth in a recent blog post by Simon Brown, an independent consultant and founder of CodingTheArchitecture.com. Brown contends that miscast architects and a casual approach to architecture on agile projects have contributed to the poor state of the architecture discipline.
Disconnected, ivory tower architects continue to hurt the reputation of software architecture, according to Brown. Instead of working closely with development teams and designing a practical, thorough solution, many architects work independently from developers and hand off dense, high level specifications. When software architects fail to add direct value to a project, the result can be a marginalization of formal architecture work which leads to unprepared developers assuming responsibility for software design. Brown sees this as a major problem and thinks that agile projects have exacerbated the issue. He claims that agile projects often neglect solid architecture principles in the name of rapid delivery.
What's all this old-fashioned software architecture stuff anyway? Many software teams seem to think that they don't need software architects, throwing around terms like "self-organising team", "YAGNI", "evolutionary architecture" and "last responsible moment" instead. If they do need an architect, they'll probably be on the lookout for an "agile architect". I'm not entirely sure that this term actually means, but I assume that it has something to do with using post-it notes instead of UML or doing TDD instead of drawing pictures. That is, assuming they get past the notion of only using a very high level system metaphor and don't use "emergent design" as an excuse for foolishly hoping for the best.
All is not lost. Brown maintains that there is a role for solid architectural principles in all types of projects but he challenges the software architecture community to do a better job of explaining its value and investing in the architects of tomorrow. InfoQ reached out to Brown and asked him a few questions about the state of architecture and how to advance the craft.
InfoQ: To quote one of the commenters on your post, "what exactly does a proper architect do?"
Brown: One of the big problems with the term "architect" is that each person, team and organisation has their own definition. For me, the software architecture role is about introducing technical leadership into a software team. I'm a firm believer that there's a degree of up front design needed in all software projects and the trick is to apply "just enough", which in a nutshell is about creating the initial high-level structure, dealing with the major risks and creating a vision that the rest of the team can work with. In addition to the up front work, the architecture role is also about owning and evolving the initial design throughout the delivery lifecycle as necessary. It’s worth highlighting that what I’m talking about here is a role rather than a rank, and that role can be undertaken by one or many people on the team. I recently ran a workshop at the QCon London 2012 conference where we answered a number of questions related to the software architecture role. You can see a summary at http://www.codingthearchitecture.com/2012/03/13/photos_from_my_qcon_london_2012_tutorial.html and it's really interesting that the role we discuss is so different from what you typically find in many organisations.
InfoQ: Why do you think that software architecture is still such a misunderstood discipline? What will contribute to a better understanding of this role?
Brown: I think that software architecture is misunderstood because the software architecture role has a bad reputation in the industry, plus much of the educational content out there about the discipline is seen as too high-level or academic. Throwing around terms like "business technology strategist" and "value proposition" is going to push most software developers away from learning about the discipline rather than pull them towards it. The reason we created the "Coding the Architecture" website was to provide a down to earth, pragmatic view of software architecture that software developers could relate to. Why? Because too many software projects fail for basic reasons and I'd really like to see software architecture as simply an inclusive part of the software development role, where every software developer has a basic grounding. Every software developer being a software architect is certainly a step in the right direction to those self-organising teams that we aspire to create.
InfoQ: In this blog post, you pose the rhetorical question "Does agile need architecture or does architecture actually need agile?", but how would you actually answer that?
Brown: All software projects, regardless of how agile they are, need to consider "architecture" because significant non-functional requirements and constraints don't go away. So yes, agile projects need the software architecture role but unfortunately in their haste to adopt agile, many teams forget this. On the flip side, there's a lot to be learnt from applying a lightweight approach to software architecture on traditional projects, with agile successfully demonstrating that we don't need to do big up front design for everything.
InfoQ: Do you think that the role of architect is a natural evolution for a developer, or do you see those as divergent paths with different skill sets?
Brown: This is one of those "it depends" type answers. Some software developers are driven by writing code and being creative at that level, while others enjoy the challenge of software design at a larger scale. The best software architects I know have a deep technology background and have moved into the role after becoming "master-builders". Understanding the technologies you are dealing with is essential, as is stepping back to see "the big picture" to understand what the driving forces are behind the software and the environment in which it will be deployed. A good software architect needs to be able to do both, which is why it's not necessarily the next step on the career ladder for all software developers. And to dispel the myth, becoming a software architect doesn't mean that you need to give up coding.
InfoQ: How do you "grow" an architect within an organization?
Brown: This is something that unfortunately doesn't happen in many organisations, with software developers either being thrown in at the deep end and struggling because they receive no support or they're pushed into a management position. Growing software architecture skills is easy if you make the role collaborative, encouraging the people that are already in the role to coach and mentor those that aren't. The whole of the software team need to buy in to the software architecture, so why not get them involved in helping to create and shape it? In addition, organisations can run internal "architecture katas" where people can practice how to design a piece of software from scratch. After all, how many software developers get to do this on a regular basis?
You can see http://www.codingthearchitecture.com/2012/01/05/contextualising_just_enough_up_front_design.html for some more guidance on practicing software architecture.
