Can a team of experienced, empowered developers successfully design the architecture of a product? Sure.
Can a team of experienced, empowered developers successfully design the architecture of a product without a unified vision of how the architecture should be structured to accomplish its purpose? Probably not.
Can a team of experienced, empowered developers successfully design the architecture of a product while staying within the bounds of their role as developers? Absolutely not.
A lot of ink, both physical and virtual, has been spilled arguing over the utility of architecture and architects. A common misunderstanding among the anti-architect faction is that an application is the sum of its parts. This is particularly prevalent with those espousing the view that if the team does the “simplest thing that could possibly work”, the architecture will just emerge. To be honest, an architecture will emerge from this method. Whether that architecture is coherent, performant, scalable, secure, etc. is quite another matter.
In order to have an informed opinion on whether or not a particular role is need, it is necessary to understand the nature of that role. For example, while the ability to code is a critical qualification for both application and solution architects, it is not the sole qualification. While architects are concerned with the structure of the code, that structure is a means to meet the needs of a customer, not the end in itself.
The purpose of an architect is to understand the needs of the stakeholders and meld his/her knowledge of code, platform (OS, database and web server, etc.), and environment (machines and network) into a cohesive whole that accomplishes the mission. This means the architect’s focus must be on the product as whole, not just a particular project or release and also not on just one aspect (code) of the product. The evolution of both code and platform (hardware, supporting software, and network) needs to be managed across the lifecycle of the product in order for it to remain useful.
For smaller products and teams, it may well be possible for the team to undertake the tasks listed above in addition to their duties as developers. As the scale of the product grows, however, dealing with multiple levels of abstraction and achieving timely consensus across multiple feature teams becomes problematic. At this point, coordination and specialization becomes more important. The architect role then becomes responsible for collaboratively developing and maintaining a unified high-level vision, providing sufficient guidance to keep the product coherent as it evolves while avoiding the trap of Big Design Up Front.
Whether the role is fulfilled by an individual or multiple individuals or the entire team as whole is less important than whether the role is handled effectively. Both “Whiteboard Architecture” and the classic “Big Ball of Mud” need to be avoided.
Form Follows Function 
While I am convinced on the need for an architect, I am less convinced that developers should be constrained to specific role (or that an architect should be constrained to a role either).
LikeLike
Absolutely. Everyone needs to be able to see beyond and step outside of their particular role(s) and see how the pieces fit together to form the larger picture. Each person needs to have an understanding and an appreciation of all the various roles that make up an effective team (I’ll eventually get around to the post explaining why I, as a developer, appreciate testers so much).
LikeLike
I believe experience is the key. If one worked as a developer for long, he/she will develop improvised / refined approach in application development techniques. If one worked as part of team making architectural decisions he/she will grow gradually as making single application designs, then providing decision on a solution level to be an enterprise architect. Some developers with passion may go out of their way and inquire or learn about how the architectural research was made to reach the decisions. Even then unless they get a chance to use this knowledge practically it is not much of use. You can not expect an experienced construction engineer building houses to suddenly lead the architecture of a township. Can you?
LikeLike
Nikhil,
I tend to value balance very highly. Depth of knowledge is important, but breadth provides context. That context allows the developer to participate meaningfully in design discussions, which I consider to be a very practical usage of that knowledge. Likewise, that context allows the developer to make better choices in his/her daily work.
LikeLike
The best analogy to this argument I have ever heard is in reference to the Winchester house, designed and built by over 170 builders and no architects. The house features over 10 stairways to nowhere, skylights in the floor, doors that open to brick walls, etc. The story is that the maiden of the house, Sarah Winchester, widow to the founder of Winchester arms, built the house to confuse the spirits of the people killed by the weapons they made. If the intention is to build something confusing, abstract, and random, setting a bunch of builders loose with no common direction is an effective way to achieve it. If you want to get them all on the same page, building toward the same goal, you need an architect.
LikeLike
Indeed…it’s an analogy I’ve used in the past (not to mention a great visual). The “team as architect” approach can work with teams that are very small, very focused, and very professional, but it doesn’t scale. Collaborative design is extremely important, but ultimately decisions need to be made in a coherent manner.
LikeLike
To become a computer programmer you need to learn how to create user interfaces, how to save the data displayed to databases and how to add the necessary logic to perform the required calculations or manipulations to the stored data.
To be a software architect you must to have this same knowledge – but you also need to learn:
> how to use design patterns to reduce complexity in your programming,
> best practices in database design, security, reliability, testing and data modeling,
> numerous competing technologies so that you can determine the best one for each situation,
> numerous approaches in software structure in order to solve the same problem,
> the latest ideas, technologies and best practices in the software industry
> and much, much more ….
Typically someone can become a successful programmer in just 2-3 years. To become a knowledgeable and experienced Software Architect will typically require 8-10 years.
A programmer with 10-15 years of experience is not automatically an architect. If the person does not take an interest in pushing his skill set to this level, they will be an experienced and valuable programmer but may never reach the level of understanding that a software architect can offer.
LikeLike
I used to be convinced that the role of the architect is indispensable. But I am not that sure anymore. Clearly, leaving the work to just programmers or just programmers and testers is not enough. On the other hand, leaving the work to highly experienced professionals, who understand the customers’ context as well as the implications of various software aspects (who also possess programming and testing skills) – in my view – can be sufficient. Even in complex products.
The problem I encounter time and again is that organizations hire programmers and testers, rather than software professionals. Not that these people are not skilled to do that kind of work. Usually they probably are. More that from the onset their role is limited by organizational structure and dynamics to these boundaries.
LikeLike
I think it depends on how you define the role. In my opinion, the understanding of the customer’s context and the implications of the technical choices is the heart of the role of architect. Who, or how many handle that role is a secondary concern, so long as it’s handled effectively and coherently.
As to those who stay within the narrow confines of testing or coding, I agree that’s a huge problem. Whether those boundaries are set by the organization or the person, everyone gets cheated. I think the difference between “this is what I do” and “this is why I do what I do” is one of the hallmarks of professionalism.
LikeLike
Exactly. A question that remains is: what is the meaning behind why in a given organization architects are responsible for understanding the customer’s context and the technical implications, whereas programmers and testers are responsible for getting these understandings into actions? Moreover, what is the meaning in the wider context of software organizations that such a dynamic prevails? I would like to hypothesize that this signifies an anxiety in this industry that stems from the relatively short ‘shelf life’ of professionals (or at least perceived so) on one hand, and from the fast pace of emerging technologies on the other. It will be interesting to collect supporting evidence for this to prove or disprove this hypothesis.
LikeLike
I believe there are several factors that contribute to it. I’d love to believe that the turnover issue you refer to is significant, but I don’t think people are that rational, it’s probably more a matter of tradition. I think the short-sighted approach to development (thinking in terms of projects instead of products) is a big factor as well – in fact, that’s the theme of the post I’m working on now.
LikeLike
Pingback: Design By Committee | Iasa Global
A balanced and informative treatment of the “do we need architects?” question. Thanks!
LikeLiked by 1 person