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