While I’m no fan of business titles in general, I do recognize there is a blunt need within (and beyond) an organization to be able to label individuals and groups of individuals. However, ancient titles from the happy days of Waterfall really has no place in an Agile environment. The main reason for this is, collaboration.
Citing Wikipedia for a definition of an Architect; “An architect is a person trained in the planning, design and oversight of the construction of buildings.” Although we’re into software rather than buildings, the traditional role of a Software Architect is generally thought of as being just that of a traditional Architect – that is, planning, designing and overseeing the construction of software.
Sticking to this method of designing software, including Big Design Up Front, may or may not lead to working software. However, keeping a single individual (or a team of individuals in the case of an over-sized project [resulting in even further issues, but that's a whole different post]) responsible for all design aspects of the intended software will likely render the project vulnerable to disturbances. Disturbances come in all shapes and sizes, ranging from real obstacles such as illness to changing or previously unknown requirements.
However, the key issue with this setup is the team environment it produces surrounding the software being built. Developers in general are curious folks (I’m aware that this may be a cultural thing, but this is true for all my current, previous and definitely future colleagues and programming friends) that thrives in finding good solutions to tricky coding and design problems. If all major design decisions were to go through a single entity (The Architect), where would then all the other great ideas spawning from the collaborative forces of the team be captured? Probably down the bin, or in a good scenario into the software, ignoring the Ever-So-Busy-Architect-That-Never-Tends-To-Pick-Up-An-Editor-And-Actually-Produce-Code.
I do recognize that this is an oversimplification, I’m however fully convinced that a collaborative effort triumphs that of a single individual, each and every time. The key is collective ownership of the software being built.
So, what are the alternatives, if any? Most projects will do just fine with a close team of Developers (disregarding the fact that the project most likely will need other qualities besides the technical ones) with a common goal and an agile approach to design and implementation. However, dealing with more complex systems as currently are being built all around the globe, I do agree that there are some projects that require someone with a different set of priorities, with a broader sense and understanding of both technical and business issues.
It comes down to the organisation itself whether there is an actual need for an additional business title for this individual. A common term surfacing around the web is Tech Lead (TL), or Lead Programmer. Depending on what you want to accomplish, this role may require one or several of the following qualities:
- Facilitate deployment of good practices. Preferably, it should be in the interest of the entire team to stay on top of current techniques and practices. The TL can however drive this process by making sure that a good idea is always pursued. TDD, XP, BDD, DDD, Continuous Integration, Camping, Memcached, Scala or Cassandra, the list is endless.
- Keep a technical overview of the major parts of the system. Since most developers in a team are highly focused on certain aspects of a system, it’s easy to loose track of the long term goals and make decisions that may be overly costly to change later on.
- Write a lot of code. This is probably the biggest difference in comparing a TL/LP with a Software Architect. A TL is never far from the nitty gritty, and thrives in solving difficult programming problems in the most elegant and/or high performing way. The TL is always a good partner to discuss programming issues with.
- Facilitate collaborative ownership. In order for a successful collaborative environment to flourish, it’s essential that the TL brings his A-game and encourages continuous improvements to the software by the entire team and all its individual members.
And most important of all, this individual should thrive in improving both herself and her teammates skill and delivered quality. This work is never done, it has merely begun.