Since at least the early 2000s, there has been a lot of debate about how the average software architect should be practical in the code base. Some argue that the monotony of coding tasks interferes with the architect’s ability to focus on the higher-level decisions he needs to make; others say the only way for an architect to fully understand the systems he oversees is to spend time in them.
InfoQ software architecture and design trend report As of April 2021, “architects serving as technical leaders” is an upcoming trend. Despite the assertion, InfoQ does not go into detail, simply saying that “understanding all emerging leadership models, anti-models and techniques is essential for a modern software architect.”
What does this trend mean in terms of how much an organization should ask its architects to code? And how does that affect architects who want to code versus those who don’t? This article explores different scenarios architects may find themselves in, common ways organizations calibrate architect involvement in the codebase, and what architects who are absolutely unwilling to code can do.
Four types of software architect list
There are many ways in which the role of a software architect manifests itself within an organization. Each of them involves a different level of responsibility for the code base, from direct involvement to full detachment.
A company I worked with once as a software consultant had architects doing hands-on work that felt like 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 approved specifications. These architects focused on managing the system infrastructure, overseeing developers, and setting standards for types of databases or operating systems. Decisions about which mobile devices populated the network, for example, fell on IT security teams rather than the architect.
Another consultant was a Fortune 500 software company with hundreds of separate software teams. In this case, there was tremendous value in creating standards, especially when it came to tools, vendors, and licensing fees. However, some of these groups have asked architects to make periodic rotations between software teams specifically to integrate and write software, perhaps for three to six months at a time. This rotation would allow the architect to keep abreast of the state of the software, and would even give him the opportunity to consider a transfer in a engineer role.
Alternatively, a third company had an architect role promoted from an engineer position. The architects reviewed the designs, discussed the strategy and carried out side projects which made real technical contributions. After a year or two, the architect returned from his role to hard engineering. In a sense, architecture became a temporary activity that gave software engineers a broader view of the technical operations of the company.
Finally, other companies had more traditional software department structures which usually included a web development team, a group of database specialists, and a few programmers who worked on something like electronic data exchange. In this case, one member of each of these three groups received the designation of architect. This architect would collaborate on higher level architectural decisions while overseeing the day to day activities of their respective group.
A future for architects without intervention?
Most organizations expect the architect to have a broader scope, which is the problem. Over time, a web programmer is bound to have more direct knowledge of web development than an architect who oversees an entire system. This is even more the case if that architect spends a lot of time writing code for another type of development group.
All of the above examples come close to this vision of an architect as a technical leader. For now, it may be necessary to have more than one way of defining the responsibilities of software architects. What then happens to the architect who wants to stop at the level of management decisions and keep his hands free from the daily coding chores?
For example, there may be frequent disputes within the IT department regarding system integration issues. When external vendors are 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 some sort of CTO role. Large organizations may even want to have one of these types of architects per business unit. Those with specific knowledge of the overall systems 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 who build prototypes for proofs of concept and can even lead the initial design and implementation of new technologies. Those who are not may find value in becoming Certified SrumMasters, Six Sigma process enhancers, database administrators or DevOps specialists. Keep in mind, however, that different companies have different definitions of an architect, and professionals will need to adapt their work to that definition.