That was a happy age, before the days of architects, before the days of builders. -- Seneca c.4BC-65AD
I hesitated as I reached for The Software Architect's Profession: An Introduction (Software Architecture Series) on the library shelf.
Did I really want to read another treatise on the role of the software architect? Hasn't the term architect been so abused as to now be worthless, even downright counter-productive? In this, I think I am one with Jeff Atwood and Joel Spolsky who discussed the questionable value of the title "Software Architect" on StackOverflow podcast #44. |
|
Nevertheless, my hand followed through. I think I was persuaded by the unimposing nature of this concise little 100-page book.
I was pleasantly surprised; this is a great little book for stimulating some thinking around the role of an architect
for the advanced reader. But I worry that it attempts to position itself as "An Introduction". A novice, unprepared to read the text critically, may easily be mislead by the book's definitive statements about what a software architect is and what they do.
Personally, I believe the book is fundamentally flawed in three important aspects:
1. Are we really in Crisis because we lack a Software Architecture Profession?
Firstly, the premise that today's Crisis in Software...
[the] parade of failures and half-failures that has grown over the years as a result of a world without an established profession of software architecture
...is wholly unsupported by any direct evidence. The authors' central argument is of course flawed based on the
appearance of a causal relationship where in fact only coincidence has been established beyond doubt. A number of well-known software runaways and failures are mentioned, but I don't know of any where the original case studies attributed the failure primarily to the lack of "an established profession of software architecture". The authors get around this problem by redefining the conclusions and suggesting that all faults may eventually be explained by architecture. It seems to me self-serving and circular.
2. A Flawed Analogy with Building Construction
Second, the authors attempt to reinforce their argument with the proposition that the analogy with building architecture is self-evident. Buildings need architects. Software is like building. Therefore software needs architects. Hmmm. I am reminded of Bernard Rudofsky's book "The Prodigious Builders" which celebrates the history of
vernacular architecture. That is, architecture without Architects (unfortunately a stunningly boring book for what ought to be a highly inspirational subject).
I particularly disagree with the authors' contention that software is not
developed: it is
built (with a sense of finality). The Google-inspired trend towards the
perpetual beta is the most visible evidence to the contrary. The authors object to the notion that
to develop implies to unfold, uncover, and make known. On the contrary, I find this a most apt description of what we do within the software profession: the youth and continuing innovation within the field does mean that software development and the architecture it requires is more akin to exploration, invention and discovery than to a formalised application of the tried and true.
Strike two.
3. Premature Specialisation
I began to renew my hope for the book as it explored the historical foundations of architecture. Michelangelo can truly lay claim to the title of Architect ("master builder"); his work on St Peter's Basilica epitomizes the unltimate balance between function, beauty, and structure,
Vitruvius is famous for asserting in his book
De architectura circa 50BC that a structure must exhibit the three qualities of firmitas, utilitas, venustas — that is, it must be strong or durable, useful, and beautiful. A sense of proportion and harmony is represented in Leonardo Da Vinci's famous illustration of
Vitruvian Man.
Such ideas begin to shape the conventional definition of an architect. A master who not only understands structure, utility, and beauty in order to successfully render a design into plans, but has the practical experience to supervise their realisation through construction.
At this point, I think the authors are getting onto the right track. However they stumble at the last post by then inexplicably turning this into an argument for a limited and specialised concept of a "Software Architecture Profession", where the architect only retains responsibility for
venustas (design/beauty).
Utilitas (function/utility) is the client's problem, and
firmitas (form, materials, logistics) is the province of the engineers, scientists and code monkeys.
Time for the Renaissance?
The authors' call for the codification and ossification of a software architecture practice is I think at least 50 years premature.
What an "Architect" needs to be concerned with is still going through successive waves of tumultuous change. Up to the green-screen era, computer system architecture necessarily had a strong hardware component. Come the GUIs and increasing processing power in the 90s, it seemed a singular focus on "software architecture" as a technical discipline was a valid vocation. Now the waves of web-driven innovation and the emergence of the "Rich Internet Application" is again challenging our notions of what architecture entails. And again, the "real world" is encroaching the pure software realm with the rise of increasingly powerful and widely available mobile computing platforms (think iPhone, Android), and the revolution in pervasive automation (think Arduino).
I think the Java Posse were spot on when they discussed the growing need for cross-fertilisation and collaboration between designers and developers on
podcast #247 - Design and Engineering. This is a time of divergence, not convergence, in the business of producing software & technology-based systems.
In truth, I question how appropriate both words are in the term "Software Architect":
- Software - it is perhaps only in the last 10-20 years that it has been possible to construct computer software at the level of complexity that warrants the existence of an architect in the classical sense. And I suspect that in another 10 years it will seem ludicrous to suggest that you can be an Architect of only software ("just a turn-of-the-century fad"). Software is just one component of a "built environment" that encompasses everything from the information infrastructure and systems technology to the psychology, art and design of human interaction; ultimately leading to a desired collaboration between people and machines in the context of real-world objectives.
- Architect - the common use of the term in the computing field has stripped this word of it's more noble dimensions. No longer is the architect "the person with the vision and skill to make dreams a reality". They are more likely to be the person in the corner who produces nothing but paper, leaves no fingerprints on the pages of history, and is generally ignored by those who are really making things happen.
I don't know what you should call the people who have the experience and ability to lead others to do amazing things with the information technology we have at our disposal.
I'm just pretty sure that "Software Architect" doesn't even come close to being adequate. And building a "profession" around a woefully inadequate definition is a one-way ticket to irrelevance and obscurity.
(well, actually listened to the audio version brilliantly narrated by Spider Robinson ).
at the library simply because it stuck out as an obvious "computer book" in the fiction section. I thought it had been mis-shelved and so it caught my eye.
. Whereas Ludlum was a true master at pulling together incredibly complex and outlandish plots while never for a moment losing the credulity of his audience, Van Lustbader always seems to miss the mark by a little. And as a reader, once you start questioning the realism of characters' behaviour and the uncanny role of coincidences, then the magic of the story is quickly extinguished and the author has lost you. 
at the time) 
