The work of software architecture belongs to every developer on a software team. So, what is the role of those given the title Software Architect? At its most basic, I believe it is to be a leader in mentorship of their teams. They should be excellent developers in their own right, promoting their team’s principles, refining their team’s practices, and guiding their fellow developers toward the same.
Other Responsibilities
Many understandings of the role of software architect incorporate a variety of seemingly non-technical responsibilities. And, I believe those other concerns are valuable; but I’m not sure of their primacy. I think Gregor Hohpe’s perspective is a helpful one, although it is connected to ideas tied up in traditional IT structures in many respects, as well as the particular concerns of certain larger organizations. However, I think one of his initial observations is fundamentally correct:
Traditionally, architects were considered to be those folks who make major design decisions on a project, draw architecture diagrams, and direct developers. Those tasks are in fact better handled by the development team and modern tooling than by a single person.
And, I think that initial observation is wrapped up nicely by one of his closing points as well:
It’s the combination of technical acumen and organizational skill that makes modern architects valuable
And, it is on that last bit that I think the role of software architect can be distinguished from that of a developer, even an architecturally interested one. The fusion of technical capability with a team-orientation and priority is at the heart of what I think the software architect role should be.
Architect Is Loaded
I have come to dislike the title of Software Architect. A big part of this is due to my observation that it is ill-defined in many organizations and comes with too much baggage, both from within and outside our industry. I am far from the first person to make such an observation. I was reminded recently that Martin Fowler and some of his ThoughtWorks colleagues were struggling with much the same concerns back in 2003.
Part of the problem is that the title architect is borrowed. The title can be conceived as having a more generic meaning, but its roots are in the field of building and construction. While I think there are some good things to learn from this analogy, I believe it also unduly constrains our thinking in many regards.
I have been searching for a better title to encapsulate and reveal what I believe software “architects” should be, but I have yet to find anything fully appropriate. And, perhaps I never will. But, I think there is an alternative metaphor that can help clarify understanding about how what we call “architects” can and should be functioning within software development teams.
Towards A Better Metaphor
The two terms I keep coming back to as I consider the ideal of the role we call “architect” are that of shepherd and guide. Given my educational background in Biblical Studies and Christian History, I suspect my affinity for the term shepherd is rooted in a strong knowledge bias. So, while I want to favor that metaphor, I think the metaphor of being a guide is actually more familiar to most people.
Both metaphors include in their scope the notion of being a caretaker or steward. And, both lend themselves to recognizing that the stewardship being exercised is over a group, not a thing. And, I think this is the first thing we ought to recognize:
Being a software
architectguide makes you responsible for a team, before your technology.
The Dive Master
While growing up in Florida, my father and I became certified scuba divers. The process of learning to be a scuba diver is where I want to ground this metaphor of the software guide. The reason is that everyone who teaches or learns to dive is a fully engaged participant.
A well-qualified scuba instructor has to be capable of doing all the things they are teaching others to do. They must have mastery of various hardware and dive scenarios and be a competent practitioner. Within the field of scuba diving there are even sub-specialties for scenarios like wreck and cave diving; as well as for such things as the use of specialized equipment. We see comparable areas of technical competency in the field of software development.
But having mastery of the equipment, techniques and scenarios are not sufficient to qualify a diver for the role of dive master, or instructor. Both require additional training and certification. And, I think we could easily apply such a framework, minus the formal certification, to the role of a software guide. The blending of technical capability with training, instruction, and leadership skills are very similar. A good software guide should be competent in the field of software development. They also need to demonstrate a concern for the other members of their team, and a mentorship mindset. And I think this is distinct from what we tend to assume about the notions of education and training.
When a dive instructor is preparing a class for certification, only a portion is about instructing in mere knowledge. There are examinations necessary for dive training, but the more critical elements come through experience. It is not enough to hand a trainee the manual, or describe the function of a buoyancy control device, or regulator. They must actually put it on and know how to operate it in real environments. This normally begins on land, then in a pool, and finally in open water. And so it should be with a software guide, they should be engaged in the work with their team.
The best software guides don’t merely instruct, they demonstrate. And this is what makes the metaphor of the guide so compelling to me. The software guide goes with their team through the process of developing software. Instructing at times, but demonstrating far more often. They work with their teams to distribute the knowledge of how to craft software well. They encourage everyone to become more competent in their shared craft. They communicate the requirements that they hear, and help their teams recognize when certain things are being implied by other stakeholders. They encourage and engage their team in actively refining their processes and techniques in light of their common principles. They help others grow to think and work like themselves.
The best software guides don’t merely instruct, they demonstrate.
Being a guide prevents one from becoming aloof or in any way separated from the team. The software guide is an integral part of how the team functions. And, they are both positioned and able to train practitioners to become better, and to train up new guides. A guide is not just a higher-level practitioner, they are also a trainer of the next cohort of excellent practitioners and guides. In contrast, and “architect” unable or ill-positioned to raise up other “architects” is a constraint, rather than an asset.
This same pattern of guide can be found beyond just the setting of scuba diving. It is also common in mountaineering, spelunking, and even sports. At the youth level most coaches are guides to their athletes, demonstrating the appropriate techniques, not merely describing them. And, we can see a not dissimilar model in any discipline that involves formal apprenticeship.
Software Guides versus Software Architects
Some might object to eschewing the role or title of architect for any number of reasons. Some might argue that a guide being embedded in the team prevents them from having the broader view that being an “architect” might afford due to its autonomy. But, I doubt that many of the guides leading treks up Mount Everest are unaware of the big picture of what they are doing and where they are going. Nor can a dive master lose site of the dive plan discussed with their group before they entered the water and lost the ability to communicate apart from much beyond hand signals. It is entirely possible to maintain a broad vision while also working in the code with one’s team.
The assumed benefits of the “architect” who is separated from the team are illusions. They are pretenses for behaviors and activities that often deliver far less value and sometimes are actively harmful to their organizations and their teams.
Consider the “architect” who consults with a product manager, designer and even a customer before contemplating, designing, and eventually advising their team on how to build a new feature. They are, in fact, an active impediment to responsive development and are undermining everything from their team’s ability to react to changes in requirements, to their relationship to the customer, to the very idea of delivering iterative value. For those in shops that don’t care for the principles of agile software development, this may not seem like a problem. But, for those, like myself, who find those principles and the practices that flow from them invaluable, this conception should be more than a little concerning, if not repugnant.
How would such a process be different with a software guide? First the guide would not seek to insert themselves between the team and the other stakeholders. They would look for ways to knit the whole team closer together. Further, they would involve the team in any requirements investigation and would actively solicit and discuss any possible approaches with the team. But, most importantly, the guide would not stop at giving direction or advice to the team. A guide would engage with the team in the act of building the solution they had arrived at together. They would help lead the team to react to changes that come up. They would reinforce and help refine sound practices. And, whatever the outcome, the software guide would be a part of it.
Practices of the Software Guide
The key theme should be evident: guides are part of the team, in a way that many “architects” seek to avoid.
Guides Design (With Their Team)
Guides will involve their teams in the design phase of software development. They will actively seek the input of the others who will be working to build the software. They will not just seek to inform them. They will solicit their input, so that the design can be refined. The guide will help the team work through both the functional and quality attributes of what is being built. The guide will help the team learn about the process of research and ideation that happens between a customer stating their problem and beginning to write code. The guide must demonstrate how to do design, not merely do it for the team.
Guides Write Code (With Their Team)
Guides will write code with their team. Not for their team; nor while their team watches. The guide will work with the team to write the code necessary to deliver value to their customer. This means, even if pair programming is not a regular practice for your team, that your guides should do it and be good at it. This is one of the key ways the guide can transfer knowledge to the team, but also how the guide can refine their own ideas about the software being built. Some might try to substitute code reviews, but they are not enough to pass on skills and knowledge since they provide less context than one gets when pair programming. And, when guides code with their teams, any upfront design will have to stand-up to actually being coded, and the guide will have a front-row seat to that activity. This is where the guide gets to live with their decisions, and be in a much better position to fix their own mistakes.
Guides Suffer & Celebrate (With Their Team)
Whether a project goes well, or not, the guide should go through it with their team. This is an extension of the notion of the guide living with the consequences of their decisions. If their design works out poorly, they should be around to help clean it up; and to help their team learn from the mistakes. And, if it goes well, they should encourage the team to celebrate their success. The guide should be a part of the team’s full experience of the software development lifecycle.
Guides Help Improve Their Team
The guide is not only concerned with the technical design and development of the team. They should also be able to help the team spot and resolve inefficiencies. They can not do that effectively if they are not engaged in the team’s regular work. They should be able to identify opportunities to refine the teams practices, whether that means helping them break down requirements, effectively assigning work, or guiding another developer to take on new leadership responsibilities within a team. They should also help negotiate the concerns of the various stakeholders, whether they be customers, product designers, developers, or other parts of the business.
Considering Some Objections
For smaller teams and organizations the practices and the pattern of the software guide should not be too onerous or give much room for objection. It is possible such organizations may not like the metaphor, or more likely those who fancy themselves “architects” don’t like the responsibilities and competencies such a model entails. But, I think those objections are more emblematic of a culture or personalities obsessed with the notion of the lone genius, which I am more than comfortable dismissing outright as such a rare occurrence that no one should plan around it.
Larger organizations with architects overseeing teams in the hundreds, or thousands may have a difficult time with this model. I am sympathetic to such scenarios. However, I think there is room to strive for the better model that is represented by the software guide, instead of our traditional notions of the software architect. Whether it comes from investing in and promoting more developers to be guides; or dismantling elements of the hierarchical nature of large organizations. I think it is worth finding ways to encourage more collaborative, learning, and growth-oriented cultures. So, I don’t think architects in large organizations are off the hook when it comes to considering this model. I think the steps necessary to implement it will take longer, and may entail broader organizational changes; but I think the cost is worth the effort.
Put The Team First
Being a guide makes you responsible for a team, before your technology. I think that is the underlying element of what it means to embrace the architect as guide metaphor. And, I think it is the key to why the title of architect may be worth abandoning in the long run. We ought to put our teams ahead of the technology. We ought to value our teams more than our own ideas and ambitions. And, we ought to prioritize our teams ahead of our deadlines. We need to figure out how to better prioritize what really matters in relation to those deadlines. In the end, I think good software development leader must always be focused on their team and their needs, because it is that team that does the bulk of the work anyways.
Top comments (0)