Thursday
Mar162006
Role of the The Software Architect
Thursday, March 16, 2006 at 11:38PM
A client in the process of adopting Agile / IID development practices recently asked me to meet with them to discuss the role of the architect. The concern is that some Agile approaches appear to devalue the role of the traditional architect. I disagree with this point of view, as does my client, and for good reason: they are in the security space, and written documents of architectural choices are essential for engaging vulnerability assessments (among other things).
The meeting gave me an opportunity to reflect on the role of the architect. I'm still heavily influenced by 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).
A second area I highlighted is that of final decision maker 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 neary impossible.
To balance this authority it is best to educate the development team on the kinds of decisions that really require an architects attention. The taxonomy of system change presented in Software Architecture in Practice is especially useful here. The authors of this book identify three areas 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 (descreasing over time as the architecture matures), and should always be involved in the third.
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 I discuss extensively in Beyond Software Architecture: Creating and Sustaining Winning Solutions.
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. When your CFO understands and supports your desire to rearchitect your system to add SOA capabilities, you're on your way.
The meeting gave me an opportunity to reflect on the role of the architect. I'm still heavily influenced by 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).
A second area I highlighted is that of final decision maker 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 neary impossible.
To balance this authority it is best to educate the development team on the kinds of decisions that really require an architects attention. The taxonomy of system change presented in Software Architecture in Practice is especially useful here. The authors of this book identify three areas 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 (descreasing over time as the architecture matures), and should always be involved in the third.
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 I discuss extensively in Beyond Software Architecture: Creating and Sustaining Winning Solutions.
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. When your CFO understands and supports your desire to rearchitect your system to add SOA capabilities, you're on your way.
Reader Comments (2)
Hi Luke -- Great insight!!! I'm going to point to this as a discussion-starter tonight, at the Atlanta chapter meeting of IASA (International Association of Software Architects) www.iasahome.org
There are some Fred Brooks and Luke Hohmann fans lurking around our neck of the woods here in the Atlanta, Georgia metro area (the one in the USA -- I haven't visited the USSR).
Keep sharing your insights!
Thanks again,
--ken
PS, We generally meet the 2nd Wednesday each month...in case you are in the neighborhood. I'm sure you would have a warm reception here if you were able to stop by for an evening and address our chapter. ;-)