Monday, April 02, 2007
Architects don't really create Architectures
Lately, I have noticed a trend where many of my industry peers who have the title architect in some form or fashion, actually are spending more time drawing pretty cartoons in Powerpoint than doing anything remotely that feels like architecture. Should the business community call us on it?
Architecture may be what Architects do, but I think in more cases it better describes what architects know, recall and use. This may be a subtle point. What I'm trying to say is that in aggregate, by pushing toward big-boned integrity, architects foster the emergence of Architectures. This is different from a single architect on a project sitting back and inventing a new architecture for the project. I think the latter rarely if ever occurs. At the same time, architects, armed with their historical perspective on architectures of the past, are able to guide and sometimes preempt emergence on a given project. The relationship between Architect and Architecture is, therefore, a two-way phenomenon.
A good architect should have good awareness of forms that have been built in the past and judgement for when they may be applied with benefit to new work. A good architect should also be sensitive to emergent design principles (e.g. SOA, Patterns, etc) and skilled at suppressing prematureprocess-oriented governancearchitectural discipline when the energy on a project is moving toward invention (distinct from innovation).
Over the weekend, I was thinking about a comment made several weeks ago by a highly-respected architect who has an extreme business focus who keeps talking about the differences between engineering and sales whey they exist in the same functional organization which has floated over most folks head but I thought was important enough to think about.
Within enterprises, the ideal state says that there should be a separation between the folks who sell the product (whatever that is) and those who actually have to do the job. The notion of a strategy is part of the selling aspect and contains lots of cartoons done in Powerpoint to help others understand direction. Strategy is not architecture. Likewise the need for describing architectures in terms of documents especially in the throw-it-over-the-wall culture promoted by outsourcing says that detailed understanding of patterns and practices is in order.
It is difficult to find these distinct skillsets in the same individual and even when you do, it is still painful for the individual themselves to constantly context-switch. The large consulting firms have a structure that I believe corporations should consider implementing. What if we took all the folks who draw Powerpoint cartoons all day and eliminated the word architect from their titles and figured out a way to compensate them like Partners, would the world of IT get better?
In consulting firms, the partners sell and also allow the real work to get done unimpeded by allowing otherwise unproductive context-switching to occur. Likewise, this would add a good layer of transparency that would allow us visibility into fundamental aspects of how IT spends money. Imagine if IT were required to put in their quarterly reports, the value of projects delivered that quarter, rather than the value of projects booked/in-flight, staff utilization, etc. I suspect things would change radically...
| | View blog reactionsArchitecture may be what Architects do, but I think in more cases it better describes what architects know, recall and use. This may be a subtle point. What I'm trying to say is that in aggregate, by pushing toward big-boned integrity, architects foster the emergence of Architectures. This is different from a single architect on a project sitting back and inventing a new architecture for the project. I think the latter rarely if ever occurs. At the same time, architects, armed with their historical perspective on architectures of the past, are able to guide and sometimes preempt emergence on a given project. The relationship between Architect and Architecture is, therefore, a two-way phenomenon.
A good architect should have good awareness of forms that have been built in the past and judgement for when they may be applied with benefit to new work. A good architect should also be sensitive to emergent design principles (e.g. SOA, Patterns, etc) and skilled at suppressing premature
Over the weekend, I was thinking about a comment made several weeks ago by a highly-respected architect who has an extreme business focus who keeps talking about the differences between engineering and sales whey they exist in the same functional organization which has floated over most folks head but I thought was important enough to think about.
Within enterprises, the ideal state says that there should be a separation between the folks who sell the product (whatever that is) and those who actually have to do the job. The notion of a strategy is part of the selling aspect and contains lots of cartoons done in Powerpoint to help others understand direction. Strategy is not architecture. Likewise the need for describing architectures in terms of documents especially in the throw-it-over-the-wall culture promoted by outsourcing says that detailed understanding of patterns and practices is in order.
It is difficult to find these distinct skillsets in the same individual and even when you do, it is still painful for the individual themselves to constantly context-switch. The large consulting firms have a structure that I believe corporations should consider implementing. What if we took all the folks who draw Powerpoint cartoons all day and eliminated the word architect from their titles and figured out a way to compensate them like Partners, would the world of IT get better?
In consulting firms, the partners sell and also allow the real work to get done unimpeded by allowing otherwise unproductive context-switching to occur. Likewise, this would add a good layer of transparency that would allow us visibility into fundamental aspects of how IT spends money. Imagine if IT were required to put in their quarterly reports, the value of projects delivered that quarter, rather than the value of projects booked/in-flight, staff utilization, etc. I suspect things would change radically...
