On Software “Architects”
I’ve always had a disdain for the term “architect” in the context of software development. Possibly due to my not-so-fond experience with an “architect” during my days at Factiva.
I popped open Fred Brooks’ The Mythical Man Month last night searching for a specific passage on project management, but stumbled on another passage that I had highlighted which caught my attention:
The manual, or written specification, is a necessary tool, though not a sufficient one. The manual is the external specification of the product. It describes and prescribes every detail of what the user sees. As such, it is the chief product of the architect.
The manual must not only describe everything the user does see, including all interfaces, it must also refrain from describing what the user does not see. That is the implementer’s business and there his design freedom must be unconstrained. The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation.
I think this is a golden rule that is often broken by software architects. The reason that it’s so common to break this rule is that in most organizations and teams, the architect is not necessarily:
- labeled as such; instead, the term that might more commonly be used to describe such a person would be “business analyst”,
- a distinct position/role, which means that a high level/senior (read:”been here the longest”) developer assumes the role of architect,
- accustomed to the practice of separating usage from implementation.
On point 1, by Brooks’ definition, an architect is not necessarily a developer, but an individual more aligned with the business side of the client/company with perhaps some technical background or maybe even a trusted technical advisor. The architect must be able to interface with business users and extract the information required to create the right product. Such incorrect labeling of the position often leads to conflict. When Confucius was asked what his first measure would be as a minister in the court of Wei, he commented:
It will certainly concern the rectification of names. If names are not rectified, then language will not be in accord with truth. If language is not in accord with truth, then things cannot be accomplished. If things cannot be accomplished, then ceremonies and music will not flourish.
— Confucius (Chan, A Source Book in Chinese Philosophy, p.40)
The role of architect and developer should be distinct and well defined. This is not to say that the architect shouldn’t have a development background. Quite the opposite is true; the architect should know the technologies and know the tools, but should refrain from telling others how to implement a feature. By Brooks’ definition, the architect should only tell others what to implement.
In any case, the architect can still guide the development process by continually updating the specs, conveying user feedback, and offering implementation advice when requested, but the architect must not dictate the details of the woodwork. Doing so always inevitably causes friction between those that create the code and those that create the specification. For, as Brooks says, the act of software engineering is, ultimately, a creative process for the programmer and by restricting this aspect, only begrudging compliance can be achieved.