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.
On point 2 and 3, in most cases, companies do not always specifically allocate the role of “architect” without also making sure that said individual does not lead the direction of development. In smaller organizations, it’s perhaps not an option to create such a distinct role. In these cases, the architect-developer must be able to separate the responsibilities of the duties of both roles. The problem that arises when this happens is that the developer-cum-architect needs to have the discipline to switch contexts between architect mode and developer mode. The individual must not think of interfaces in terms of code, but in purely terms of use cases. This is a difficult task as when I’m presented with a proposed interface (be it visual or programmatic), my natural reaction is to wonder “how will I implement this feature?“, “what libraries can I use?“, and other such thoughts instead of focusing on dissecting the features of the interface from a use case perspective.
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.
