Sunday, May 17, 2009

The Software Architect's Professsion. Or Delusion?


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 flawed by asserting an apparent causal relationship when in fact only coincidence had 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.

7 comments:

LewisC said...

I am a database architect (a kind of software architect). Talk about specialization.

I prefer to think of myself as a database star ship captain. I lead the ship where no one has gone before.

Of course that makes DBAs the klingons and java developer's the romulans. Script language programmer's are the little short guys with the big foreheads (can't remember the name).

;-)

LewisC

Paul said...

nuqneH, Commander Lewis!

Now a "database architect" I can accept - it is a well defined field of expertise. The upper layers are well standardised, and I am sure that you are concerned with all that occurs within your Kingdom, from physical layout and distribution on storage devices, to process monitoring, to the logical organisation of data and the optimised translation of application requests into database units of work. And of course how best to roll in the edge of the envelope, be it grid technology or beowulf clusters, or virtualised cloud computing.

The 'starship captain' concept may sound like a joke, but it is far closer to what I have seen work best in practice than the idea of a 'software architect';-)

william said...

Hi! Your blog is simply super. you have create a differentiate. Thanks for the sharing this website. it is very useful professional knowledge. Great idea you know about company background.
Increasing your web traffic and page views Add, add your website in www.itsolusenz.com

JasonOng said...

I like the part abt premature specialization.

Interestingly I visited Da Vinci's exhibition yesterday and thought to myself that this Renaissance man's a genius because he dedicated his entire life exploring scientific advances of his time and perfecting the blend of beauty and form in his arts, all under the constraints of being a hired hand of a nobleman.

Perhaps what's lacking in this age is the concept of a journeyman?

Paul said...

Hi Jason, timely reminder about the Da Vinci exhibition .. I wanted to see that!

Thinking about careers in terms of a progression from journeyman to master craftsman makes a lot of sense. There's a discipline and patience implied that doesn't always sit well with today's culture of instant gratification though;-)

JasonOng said...

Getting a mentor is essential for the journeyman and finding one seems difficult in today's approach to learning where we get information without the interaction?

Hey Paul, Patrick (was present at the last SRB) created a wikipage for geekcamp SG. Would you like to speak on any topics on the upcoming geekcamp sg? Let me know yah? :)

http://geekcamp.pbworks.com

Paul said...

Mentors: too true Jason. Either you're 'working for da man' and you may have limited opportunity to find new, good mentors, or if you are contracting/freelancing then everything can get overshadowed by the 'next deliverable'.

In an ideal world, mentoring opportunities would be a major factor when deciding who to work for, and you'd have the time to cultivate external mentor relationships.

This is the real world though. But the light on the landscape has got to be the community organisations - kudos to what you've been doing with srb and #geekcamp - the opps are there for those who care to get off their butts;-)

I'll be at #geekcamp SG; if there's anything I think I can talk passionately about, I'll throw the ideas in the ring..