I first witnessed this early in my career when “the architect” would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture.
(K. Scott Allen, from “Whiteboard Architecture”)
The discussion I wish to provoke is: Is it the sole responsibility of the software architect to provide the architecture?
Or is it that the architect is best competent, skilled, verbal, and positioned to help the team (or organization) to produce the most appropriate architecture?
(Ilan Kirschenbaum, commenting on “Architecture versus Design”)
It’s easy to accumulate a backlog of ideas for posts, particularly when you write in your spare time. This one has been waiting in the wings for a while, to be forced out onto the stage by Ilan’s comment on my last post. It’s one I should have addressed a long time ago, because it touches on one of the biggest threats to software architecture: some of those who call themselves architects.
“Ivory Tower Architects” are a long standing embarrassment to the discipline. Likewise, “Architecture Astronauts” and those in love with patterns for patterns’ sake are frequently used to justify the opinion that architects provide no value. Worst, in my opinion, are the Olympians, descending to the mortal realm to dictate to the lower beings. Alone, or in combination with the above types, the “God of Architecture” is particularly adept at alienating the rest of the development team. This alienation leads to ignoring the need for architectural design, or hoping that it will emerge in some coherent form, to the detriment of the product and its users.
In “Agile Architect – What is it?”, Ilan outlined a more collaborative role for the architect:
Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)
The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.
The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.
In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.
I strongly agree. Leadership (paired with responsibility) is necessary, but a more inclusive approach makes sense from several perspectives:
- Understanding – When the other members of the team are involved in the design process, they should gain a deeper understanding of the architecture (knowing both the “whats” and the “whys”) than would be the case if the finished product were deposited in their laps.
- Ownership – Participating in the design should also engender ownership on the part of the team as a whole. People tend to be less resistant to that which they own as opposed to that which is imposed on them.
- Evaluation – The architect gets the opportunity to gauge the skills of the rest of the team and they get a better appreciation of the architect’s abilities as well. This should foster mutual trust.
- Training – Involving the team in the design of the architecture is valuable training. Team growth should be seen as a positive.
- Quality – This applies in two ways. First, a fresh set of eyes is likely to spot issues regardless of the item being tested. Ideas that survive the team approach are likely to be durable ones. At the same time, you gain the advantage of multiple skill sets. It’s unlikely that any given architect (or anyone else for that matter) is universally skillful. Working collaboratively allows you to leverage the strengths of the entire team.
The last bullet point cannot be over-emphasized. Although he was discussing enterprise architecture, Tom Graves made an important point in “Analyst, anarchist, architect” regarding the applicability of the Hegelian triad of thesis, antithesis, and synthesis to architecture:
…the antithesis is not a negation of the thesis, but a challenge to the assumptions on which the thesis is based – which then leads to a synthesis that makes real practical sense.
It’s not impossible to achieve that challenge to your assumptions when working solo, but it’s far from easy. I’d argue that one characteristic of a good architect is making efficient use of available resources. In my opinion, using the team to improve the quality of the architectural design as well as their understanding of it sounds like an efficient use of those resources. In the words of Roman philosopher Seneca the Younger: “Even while they teach, men learn”.