I disagree with this point of view, as do our clients, and for good reason. For example, one of our clients in the information security space must track architectural choices fastidiously to conduct effective vulnerability assessments. The architect plays a critical role in this tracking process.
These discussions gave me an opportunity to reflect on the role of the architect, and I’ve identified four major areas of responsibility.
1. CONCEPTUAL INTEGRITY
I’m heavily influenced by the work of Fred Brooks, and therefore started with the importance of conceptual integrity in system design and all that this entails. Conceptual integrity includes many concepts, ranging from the seemingly mundane (naming conventions on database tables) to more substantive choices of system structure (error codes or exceptions, blocking or non-blocking calls to system architectures, and so forth).
2. FINAL DECISION MAKING AUTHORITY
Technical teams are bound to disagree with various choices, but decisions must be made. I have found it best when the architect is given sole authority to make the decision when the team cannot agree. This authority is the twin of conceptual integrity, and without such authority the architect will find their job nearly impossible.
To balance this authority it is best to educate the development team on the kinds of decisions that really require an architect’s attention. The taxonomy of system change presented in Software Architecture in Practice is especially useful here. The authors of this book identify three elements of change: local (to a module or function), non-local non-architectural (such as adding a new feature by simultaneously touching many parts of the architecture but not fundamentally changing the architecture), and architectural (changing some significant portion of the system). Architects should rarely be involved in the first, have varying degrees of involvement with the second (decreasing over time as the architecture matures), and should always be involved in the third.
3. MAPPING THE EVOLUTION OF THE SYSTEM
A third area of responsibility is mapping out the evolution of the system. Simply put, systems are not static, and architectures must evolve over time. It is critical that this evolution be coordinated with the market facing needs of the system, a topic discussed extensively in Luke Hohmann’s Beyond Software Architecture: Creating and Sustaining Winning Solutions.
4. COMMUNICATIONS: THE “ZERO” AREA
The “zero” area of responsibility is the management of the social and political forces that go into being an effective architect. If you want to be an architect, you’re going to have to learn how to stop focusing solely on technology and/or technology arguments and learn how to communicate with other leaders in functional areas. For instance, when your CFO understands and supports your desire to rearchitect your system to add microservices capabilities, you know you’re on your way.
Need more guidance on the role of the software architect?
If you need more information or guidance in determining the role of the architect as you adopt Agile development practices, our experts at Applied Frameworks can help. Contact us to learn more or speak to one of our Agile adoption experts.