The Role of Architects

by Kurt Cagle

James Governor, in a post recently on MonkChips, raised the issue about code architecture and complexity, (IBM architects catch lesscode virus? maybe not) that started me thinking about the specific role of architects themselves. The term (or title, depending upon how its used) has a comparatively recent currency, and I suspect really started gaining vogue only about the time that Bill Gates decided to leave the position of CEO for the somewhat nebulous title of Chief Architect. All of a sudden, it seemed, the architecture position in a company become one of the most coveted spots possible, leading to a rather dramatic inflation in the number of "architects" in the field.

When I was a kid in Boy Scouts (lo those many years ago) the troop went on a field trip to a company (likely to someone's dad, though which of us had such a cool dad I never did find out) that created scale models of prospective office buildings for architectural firms. At the age of twelve, it was perhaps understandable that I immediately equated architects with model builders, even though that wasn't completely accurate in this particular case. However, the analogy is not a bad one from a programming standpoint.














7 Comments

Bryan
2006-04-03 03:29:21
I was at a party Saturday night where I met a woman who worked in materials testing, basically testing various types of building materials for various qualities and then making recommendations to Architects (building architects) about what to use when and why using material X for building Y was not a good idea because building Y will collapse and kill everyone no matter how good material X may look.


To summarize her opinion of Architects (building architects) they're a bunch of idiots without any real world understanding of the materials they're working with, given to off-base and very dangerous theoretical speculations who only care, at the end, that their designs look interesting.


Thank god Software architects suffer from none of the failings of building architects.


len
2006-04-03 06:45:09
Modeling may be the technique but the goal of architecting models is communication. Typically, the consumer/buyer/customer/boss is not a tech savvy decision maker, or at least to the level of detail of those who try to decide if DOM or JDOM are the right technical winners. Hopefully they know other things and have other skills. The architect should be able to bridge the chasm of loss of detailed information.


So before one goes too far in the direction of calling the architect a space cadet (useless purveyor of theories and opinions), keep in mind that that programmers are often those who expose the consumer to the most choices and details that don't contribute to making choice. When faced with too many choices, there are fewer sales.


No winners in the who-has-the-best-dongle debate. If the architect is good at what they do, the programmers and the consumers are well-served. If not, YMMV.

Kurt Cagle
2006-04-03 09:03:40
Good posts, both.


I don't think that it's really a question here of who has the better dongle ;-) Ultimately, architects and developers/engineers are (or at least should be) two distinct positions that need one another - I can be both architect and developer, but because they are dealing with periodically conflicting needs, I don't think you can be both for the same project at the same time and be successful at it.


On the other hand, there are incompetents in architecture as much as there are idiots in programming (or engineering), with the one distinction here being that inferior architects can hide behind the shifting curtain of "aesthetics" to hide their own incompetency, while an incompetent programming generally cannot get away from it for very long before they find themselves either limited in their career growth or promoted out to management.


-- Kurt

Alex
2006-04-03 09:08:30
I think the danger of Architecture in either profession is when it is divorced from reality. Over the years I've started treating "architecture" as a dirty word, only because it has typically been far-removed from the important vagaries of the real world.


You can't argue with the need for taking a "big picture" view of a system. But I can't tell you how many projects I've seen "architected" through diagrams and mounds of dead trees that didn't fit the real implementation of the system. In these cases it wasn't that the coders didn't "get it", it was that the architecture didn't have it all figured out. Humility, I think, is a key to modern software development--we just can't think it all out ahead of time.


To me arguing over whether an architecture-dominated view or a developer-dominated view is a "beer and tacos" argument. Neither one is better, and it's great when you have both. However I would be very wary of working on a project where those roles are separate. Architects who aren't coding are just imagining systems that will never see the light of day. Coders who don't think about architecture (and how to get away with as little as possible) are just wearing out their keyboards.

len
2006-04-03 12:40:26
Fair enough.


You go to a meeting and they bring in the domain modeling tool to do the venerable routine of interviewing SMEs, then use that to extract nouns and verbs which become objects and methods.


1. Is that a good approach to architecture design?


2. Does it matter that one is designing a messaging system or a database?


3. How would you sort the first week of results before sending the architecture draft back to the stakeholders?


Good and bad we have in any profession or position, and in any career, we'll all be both, but mastering simplicity is the secret sauce of both because too complex and too simple are both recipes for do-over.


Good programmers can hide a lot of bad code in a compiled dll just as good architects can hide a bad design in a pretty diagram. Skill at the profession doesn't mean the right choices are made; just that the choices are better exposed or better hidden.


Did anyone take the model, Kurt, and make small bookshelves? Scale...

Robert Brewer
2006-04-04 22:24:10
...you cannot eliminate complexity from an application, you can only shift it from place to place. The role of the architect in that regard includes determining where that complexity will emerge, and to insure that the complexity is in general passed on to those programmers (or systems or frameworks or whatever) that are most capable of handling them, reducing the complexity elsewhere in the application as a consequence.


Excellent description of architects, Kurt. I would just add to the above paragraph that the complexity also gets pushed to the users, sometimes appropriately and sometimes not. That aspect is exposed even more starkly when the "users" are themselves developers (when the "architects" are working on programming languages or library or tool code instead of complete applications).


But on another note, I'm sad now. I chose my current title of "System Architect" without realizing I was emulating Bill. Guess I'll have to change it to CIO or something... ;)

sel├╝lit band
2007-12-31 09:02:00
hi kurt Cagle
sory! :(
When I was a kid in Boy Scouts (lo those many years ago) the troop went on a field trip to a company (likely to someone’s dad, though which of us had such a cool dad I never did find out) that created scale models of prospective office buildings for architectural firms. At the age of twelve, it was perhaps understandable that I immediately equated architects with model builders, even though that wasn’t completely accurate in this particular case. However, the analogy is not a bad one from a programming standpoint.