Getty Images/iStockphoto
Should software architect responsibilities include coding?
There are many variations to the role of the software architect in today's IT teams, and a lingering debate is over whether they should all be hands-on with code.
Since at least the early 2000s, there have been numerous debates regarding how hands-on the average software architect should be within the codebase. Some argue that the monotony of coding tasks interferes with the architect's ability to focus the higher-level decisions they need to make; others say that the only way for an architect to completely understand the systems they supervise is to spend time in them.
The Software Architecture and Design InfoQ trends report from April 2021 lists "architects serving as technical leaders" as a coming trend. Despite the claim, InfoQ does not go into great depth on the issue, only saying that "understanding all the emerging leadership patterns, antipatterns, and techniques is essential for a modern software architect."
What does this trend mean in terms of how much an organization should require their architects to code? And how does it affect architects who want to code versus those that do not? This article explores different scenarios architects may find themselves in, common ways organizations calibrate an architects involvement in the codebase and what architects that absolutely do not want to code can do.
Four types of software architect rostering
There are many ways the software architect role manifests itself within an organization. Each of these entail a different level of responsibility for the codebase, from direct involvement to complete detachment.
A company I once worked with as a software consultant had architects doing hands-on work that resembled an infrastructure specialist role. Using virtualization software, the organization enabled technical teams to create their own deployment environments -- or even production environments -- on-demand, albeit within the bounds of approved specifications. These architects focused on managing system infrastructure, supervising developers and setting standards around databases types or operating systems. Decisions about the mobile devices that populated the network, for instance, fell upon IT security teams rather than the architect.
Another consultee was a Fortune 500 software company with hundreds of separate software teams. In that case, there was considerable value in creating standards, especially regarding tools, vendors and licensing fees. However, some of these groups had the architects make periodic rotations between the software teams specifically to embed and write software, perhaps for three to six months at a time. This rotation would keep the architect current on the state of the software, and even provide them an opportunity to consider transferring into an engineering role.
Alternatively, a third company had an architect role promoted from an engineering position. Architects reviewed designs, discussed strategy and had side projects that made real technical contributions. After a year or two, the architect transitioned out of the role back into hard engineering. In a sense, architecture became a temporary activity that provided software engineers with a wider view of the company's technical operations.
Finally, other companies had more traditional software department structures that typically included a web development team, a group of database specialists and a few programmers who worked on something like electronic data interchange. In this case, one member from each of these three groups received the designation of architect. This architect would collaborate on higher-level architectural decisions while simultaneously supervising the day-to-day activities of their respective group.
A future for hands-off architects?
Most organizations expect the architect to have a broader scope, which is the problem. In time, a web programmer is bound to have more direct knowledge of web development than an architect who supervises an entire system. This is even more the case if that architect spends significant time writing code for another type of development group.
All the examples above come closer to this vision of an architect as a technical leader. For now, there may need to be more than one way to define software architect responsibilities. What happens, then, to the architect who wants to stop at the directing decisions level and keep their hands clean of everyday coding chores?
In an enterprise, end users are likely members of internal, business-side departments that are not concerned about specifics like JavaScript implementations or the APIs that connect a database. They just want to understand the system as a whole. That has led to a way of thinking where architects illustrate systems by drawing diagrams with circles and arrows. If it's done well, there may still be room for someone like this.
For example, there may be frequent disputes within IT over system integration concerns. When outside vendors become involved, these disputes can lead to issues with purchase orders, support contracts, and legal compliance. An architect might be able to add value here in a sort of CTO role. Larger organizations may even want to have one of these types of architects per business unit. Those that have specific knowledge of the systems' overall technology stack as well as the business side of things may be able to translate this into a larger enterprise architect role.
Many software architects are already technical leaders that build prototypes for proofs of concept and may even head up the initial design and implementation of new technologies. Those that are not may find value in becoming Certified SrumMasters, Six Sigma process improvers, database administrators, or DevOps specialists. Keep in mind, however, that different businesses have a different definition of architect, and professionals will have to adapt their job to that definition.
