On this page.... RSS 2.0 | Atom 1.0 | CDF
# Wednesday, 23 April 2008

Just reading the first article in the latest edition of Microsoft's The Architecture Journal.  It's called "We Don't Need No Architects" by Joseph Hofstader.  I thought, oh good, someone voicing a dissident opinion, but the article is rather a rebuttal to that claim.  I figure maybe a response to the response is in order. :)

Mr. Hofstader suggests that architects think in terms of bubbles and devs think in terms of code and, by extension, only see part of the picture.  He describes various "architectural" activities such as analyzing the problem domain, choosing and applying appropriate technologies to solve problems, and the use of patterns.

Is it just me, or is this a sort of dumbing down of the developer role in order to support a, potentially unnecessary, distinction between it and "the architect"?  I mean, a smart developer needs to do all of these things, too.  They're not just code monkeys.

In fact, in introducing such a division in responsibilities, we would actually seemingly perpetuate a long-standing problem in software development--a disjuncture between the problem and solution space because we keep trying to insert these business translators (call them technical business analysts, software architects, whatever you want) into our methodology. 

What's wrong with this?  First, it puts the burden for understanding the business onto one (or a few) persons, but more importantly, it limits that mind share to those individuals.  That is never a good thing, but it is especially bad for software.  In so doing, it also puts a burden on those individuals to correctly interpret and translate (a considerable challenge) and finally to sufficiently communicate a design to developers--enter large specification documents, heavier process, and more overhead.

On the other hand, domain-driven design, for instance, is all about instilling domain knowledge into the solution and coming to a common alignment between the business and the solution creators.  It's axiomatic in business that you need a shared vision to be successful, and this approach to software creation is all about that.  Shared vision, mutual cooperation, and a shared language. 

It eliminates the need for a translator because both learn to speak the same domain language.  It eliminates the knowledge bottlenecks (or at least really reduces them), and it increases shared knowledge.  And DDD is not burdened with the distinction between an architect and a developer.  Agile methodologies in general are geared towards reducing barriers and overhead in the creation of software (and that's why they're generally more successful, and they can scale).

I hope that all the brilliant and more-well-known/respected folks will forgive me; this is not intended as a slight, but I have to ask--are we creating the "architecture" profession unconsciously just to create a more defined career path (i.e., a way for us techies to move up the ranks)?  Are we just going with the flow from an old but broken analogy?  Are we introducing roles that really would be better served through other, non-architecty roles?

To this last point, I see some folks suggesting "infrastructure" and "business" and "software" and "whatehaveyou" architects.  Why are we so keen on the term "architect"?  I'll grant, it does sound really fancy, but it is so, so painfully clear that it is ambiguous and overloaded (and inaccurate, if you ask me) .  Maybe these other roles do need to exist in some organizations, but it seems like we're just bent on calling them "architect" for no apparent good reason other than we've latched onto it as a respectable (and well-paid) moniker. 

In choosing to proliferate the "architect" terminology, we're perpetuating and extending the confusion around it.  We're purporting to solve the problem of it being ill-defined, but in reality we're doing the opposite.  And everyone (IASA, Open Group, Microsoft, to name some just in the latest issue of the Journal) is trying to do it all at once with little coordination. 

It seems borderline insane. 

Or maybe I'm the crazy one?

there is no spoon

Wednesday, 23 April 2008 15:15:42 (Eastern Daylight Time, UTC-04:00)  #    Disclaimer  |  Comments [2]  | 
Wednesday, 21 May 2008 19:19:37 (Eastern Daylight Time, UTC-04:00)
The truth is somewhere in the middle - in this case too.

This terminology is used to let corporate guys understand we do in the market.

You know, they always ask "where" did we get that names. And they are right.

Terminology is also a pattern. It is the way we have to be more consistent.

The last issue of Architecture Journal for example, helps me to identify the difference between the roles of Technical Architect and Solution Architect.

I have been working on two roles easily, until we have to outsource our development process. This was really challenge.

We already know that there is a differente between the people who gets the bubble, from the people who knows inside the bubble, but in our market

As a evolving discipline, I think its normal.

But I also think you are correct. And I also think that in the end, we will "win". Be happy!

PS.: Sorry about my english. Please correct me, then I will always comment in your excellent blog!

Best regards,
Wanderson Santos
Wednesday, 21 May 2008 20:15:08 (Eastern Daylight Time, UTC-04:00)
Thanks Wanderson! I appreciate the thoughtful comments.
Comments are closed.

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2017 J. Ambrose Little