I’ve noticed recently that it almost seems fashionable to pour scorn on the concept of an Architect role in a dev team. Probably the first time that I really noticed this was when I read a post at subbu.org charmingly entitled “Architect – Overrated!“. This post consists of a neat set of bullet points:
- You always talk about the big picture.
- You think you know how the system ought to be built.
- You are unhappy that the team is not executing your ideas the way you want them.
- You don’t have a working build.
- You spend a lot of time on documents that are not code.
- You can prototype – but your code is not production worthy.
- You spend too much time in meetings.
- The best code you wrote is a few years old.
- When asked for opinions you tend to speak in general terms.
- Your team members secretly joke about you.
- You start to take analysts and tech blogs too seriously.
- You are a dinosaur.
Code. Don’t wiki. Don’t powerpoint.
Reading the comments on architecture related articles on sites like Hacker News is also enlightening, here is a good example. Even the featured article paints the architect in the light of someone that mainly cleans up after and ever so gently guides the team in some fuzzy appropriate direction.
Even the agile manifesto states it as a clear principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”. Indeed, architects do not have a clear place in most agile methodologies. In Scrum, you have a Team (without roles), Product Owner, and Scrum Master. XP roles align closely, with the addition of a tester role.
I’m currently reading Lean Architecture, wherein I found this gem:
“We still avoid that term in this book for three key reasons. First, having a role named ‘architect’ suggests that people filling that role are the ones responsible for architecture, when in fact a much broader consituency drives system design. Second, the word often raises a vision of someone who is too far removed from the feedback loop of day-to-day coding to be effective.
Third, most valuable contributions of good architects are captured in the other roles mentioned above: domain experts, the business, and developers.”
Hold on. Here the authors claim that they avoid the word ‘architect’… in a book entitled ‘lean architecture’. The book goes on to explain an architectural approach largely driven by writing code. And these authors are not alone. The marketplace is brimming with books on how to make architecture work in modern software development, usually by using a minimal approach.
Worst of all, I cannot find myself really disagreeing with any of the above, though my job title at work is, in fact, ‘Architect’.
So is there any place for architects? My personal view (after a few years on either side of the debate) is yes, there is. I will even say that there is a place for the kind of architecture that mainly involves talking to managers and drawing pictures, and never seeing code – though this is marginal and I presently have no desire to do this myself.
The biggest problem I see with the architectural backlash, is that 90% of the arguments are only focused on design, and even then largely on domain modelling. The conclusion is this: Drawing pretty pictures and typing up large documents simply does not stack up to writing useful code.
However, there is another side to the coin. I would argue that most modelling and especially domain modelling can and should be left to developers. I consider most modelling to be detailed design. A great argument can be made that design of anything functional is distinct from architectural work. The architect should only be designing patterns to be reused, so the problems that come up over and over again does not have to be solved by each individual developer every time it is encountered. To allow the architect to do this, it’s important that he looks at the designs being produced by the team, as well as the code, to understand where these fundamental building blocks are required in the actual system being built. I’d say that the architect should be able to jump in help code as and when required – not just for prototypes.
The second problem with the argument, is that much of what I do on a day to day basis simply cannot be expressed in code. How, for example, do you write code to indicate that all queues in the system must be monitored for message depth within certain thresholds? Also unless you are working on a monolithic application, most systems these days consist of many deployed applications using a wide variety of technologies. It is near impossible to describe the required layering and patterns across these layers by using code. I also often hear that these kind ideas should be conveyed using a whiteboard, which is persisted if required by taking a picture and uploading to a Wiki. In my experience, pictures of whiteboards are unintelligible a few weeks down the line – I know because I’ve tried this approach.
While we’re on the topic of layers and composite applications, there is another important point to the argument. In my view, architects play a crucial role in smoothing the abyss between ops and infrastructure, development, and testing (business also, though I’d prefer to stick to the core technical disciplines for this discussion). For example, someone needs to come up with a comprehensive deployment model and plan, that suits the requirements and the technical solution. In my experience, developers want to focus on what is important to them – development, and specifically, coding. But that is never the full picture, especially in a complex composite application. There would typically be no single team that knows or cares about how everything fits together. Does this mean that the architect only ever talks about the big picture? I don’t think so. A good architect would understand all of the systems and technologies involved in the solution to a very low level of detail, and keep discussions with teams to the part of the picture that is relevant to them.
So is the architect absolutely crucial? No. Teams can and will rise to the challenge of doing everything themselves when required to do so. But having someone that is extracted far enough out of any particular piece of development to focus on all the peripheral and cross cutting issues is in my experience usually of great value. Though it’s good to fail often and fail hard in order to learn, a good architect can pre-empt much of the failure and help a team deliver value faster.
In my experience, this can be achieved if architects follow some simple guidelines:
- Stay close to, but not elbow-deep in, the code on a daily basis
- Let teams do their own designs
- Talk to everyone, and especially developers, as the primary means of communication. Email is not talking. Documents are not talking. Discuss, discuss, discuss.
- Persist the big picture into a proper, published model. Augment it with sufficient descriptions.
- Use technical means to communicate where appropriate – code, xsd’s, directory structures, interfaces, etc
Ok, so that’s my 2c. I’ll go back to sitting in my architectural cave and just growling at passers-by now.