Do Architects Need to Code?

In part, architecture is about enabling many people to work on a complex system, and still achieve something that is coherent. So the architect needs to have technical insight that comes from technical experience, and the architect needs to be good at achieving alignment with the technical direction, and getting buy-in to the architectural decisions that shape the system and resolve the big challenges. This takes persuasion and influence, skills we associate with leadership and organizational politics.

In an autocratic culture, we may be able get away with less of the politics and influence and rely more on the authority vested in the architect role. But in the highly collaborative, consensus-oriented cultures that characterize most of the businesses we work with, the broader the scope of the architecture, the more the architect has to rely on leadership and organization politics skills to influence and persuade, align and get buy-in. Of course, if the architect has no credibility with the development community, all the political skills in the world will not overcome this deficit.

Several blog posts (e.g., Ramkoth, Johanna) have levied criticism at architects who don't code, and there's not a whole lot of empathy for the tension that the architects themselves are placed under. Many architects I know would love to have time to code (in their day job, too), but they have to carefully choose where to spend their bandwidth. The architect knows he could do a good job of the code, but if he was writing that part of the system, and that part, and that part, pretty soon he would run up against even his own high productivity ceiling and have to face the fact that complex systems cannot be built by one great architect/developer alone. Then you have to take more people on board. Then you need to communicate to them what to do. Then you need to take more people on board because that communicating meant you had less time to personally code, bringing down your own coding productivity ceiling... But if you do a good job as an architect then you raise the productivity ceiling of the team. And so it goes.

There may be junior architects or technical leads who "own" components and absolutely, yes, still write code. And senior architects responsible for complex system architectures, with a number of junior architects and developers reporting to them for technical direction. This is a big job, and leaves little time for code reviews, let alone writing code. Many of these senior architects ask how they can stay in touch better with the technical frontier and maintain the respect of developers they work with. My best answer is to refer to those architects that I have worked with, who have retained the respect of the development team even though they no longer have the bandwidth to cut code. They are extremely smart. They pay attention to many sources, inside and outside their organization. And they pair up with developers to solve challenges they face. Their role is to abstract and extract, create models, bring their own and others expertise to bear on creating and validating the architecture, synthesize practices to make common across the team, find the mechanisms to use consistently across the system. And this role is seen as valuable and necessary to the team's success. The alternative is to see the architect as a threat, constraining, interrupting, intervening but walking off with the title and salary. This is why we say goodwill is the real silver bullet—again, if your team lets you do a good job as an architect, then you raise the productivity ceiling of the team.

Architects are very much about expanding the creative capacity of the team, and achieving system integrity, system-fit-to-purpose and system-fit-to-context. Everyone plays a role in creating successful products and applications; not architects alone, not developers alone, not testers alone, not managers alone, nor marketing and business analysts alone. Yes, architects have an important role to play, and we need to let them play that role! In large projects, the architect's role should not be undercut by challenging the architect to load up on coding responsibilities and simultaneously keep the architecture solid and up-to-date. Something will have to give, and it will be the architecture. Just because a project enters the construction phase does not mean that the architects role is done and now the architect can take on a fully-loaded developer role. If we are trying to do less waterfall and more agile modeling and development, then we have to recognize that we are spreading architecture work out through the entire construction phase.

When construction begins we should not view the architect as a freed resource that we can pull off onto another architecture project nor, for that matter, should we move the architect back into a (full-time) developer role, loading her up with coding responsibilities. The architect is needed through construction, and through all the releases, to explain and defend the architecture, and to modify it when the architect is persuaded this must be done. During construction, the architect is needed to explain, mentor and coach, help problem-solve, to watch for misapplication of the architecture, to watch for obstruction of the architectural intent, and to learn!

To get the benefits of architecture in terms of decreasing lifecycle costs and increasing productivity (and agility) and predictability, we need to make sure the architecture is protected from accommodations that weaken the structure and integrity of the system, and improved as faults are discovered, and that the architecture as documented keeps pace with the architecture as implemented.

Building a sky-rise is technically and organizationally complex. Man-hour for man-hour, building software is probably even more so! In software, from start to finish, we are creating as we go; we are not just executing on a plan. But we do need a plan to provide the context within which we can allow more people to create. Architecture in our software world is very much about enabling more effective collaboration. Collaboration that scales up to the kinds of numbers that we rely on to get complex products and applications shipped, has to be enabled. We can't just assume it will happen. We can't expect it to happen in the large, without processes and tools to facilitate the communication and co-ordination involved. By tools, I don't necessarily mean computer-supported tools, though they could be. I mean, at least, the architecture diagrams and documents explaining and justifying the architecture decisions and approach. But all these architecture documents cannot stand alone. Collaboration is about personal involvement, and people are best at activating personal involvement—people with good leadership, persuasion and influence skills, that is. Yes, good to great architects! Architects who understand that it is not just about the technical soundness of the architecture, but about getting the development community actively and effectively engaged in a collaborative effort with customer and business value as the goal.

And in his rather timely way, The Pragmatic Architect has a synergistic post on his blog. This is the kind of blog I find really exciting, because it tells the story of an architect's personal journey.

Source: https://www.ruthmalan.com/Journal/2006JournalMay.htm#Need_to_Code