Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
I recently wrote about architects and the role they play in large organizations. Still, the question often remains what an architect should be doing besides riding the elevator. Let's try another analogy: movie characters.
Before the movie starts, we'll watch some previews or commercials, in our case the origin of the work "architect". It derives from the Greek ἀρχιτέκτων ("architekton"), which roughly translates into "chief builder". We have to keep in mind that this word was meant for people who built houses and structures, not IT systems. We should also note that the word implies "builder", not "designer" - an architect should be someone who builds, not someone who draws pretty pictures. But now to the main feature...
If you ask (tech) folk to name a prototypical architect in the movies you are likely to hear The Matrix trilogy. The architect of the Matrix is a "cold, humorless, white-haired man in a light gray suit" (Wikipedia), which he largely owes to the fact that he is a computer program himself. Wikipedia also describes that the architect "speaks in long logical chains of reasoning", something that many IT architects are known to do. So perhaps the analogy holds?
The Matrix architect is also the ultimate authority: he designed the Matrix (a computer
program to simulate reality to humans being farmed by machines as an energy source)
and knows and controls everything. Enterprise architects are sometimes seen as such
a person - the all-knowing decision maker. Some even wish themselves into such a role,
partly because it is neat to be all-knowing and partly because it gets you a lot of
respect. Naturally, this role model has some issues: all-knowingness is a little
(too) challenging for humans, meaning we should expect a fair amount of bad decision
making and all sorts of other problems. Even if the architect is a super smart person,
he or she can base decisions only on those facts that are known to them. In large
companies, this inevitably means relying on PowerPoint slides or statements from middle
management as it is impossible to be in touch with all technology that is in place.
Such an information channel to the supreme decision maker tends to be heavily guarded
by people who understand its value as an influencing vehicle, which results in the
architect being fed indirect, often biased information, as opposed to reality. Making
decisions based on such a model is dangerous. The antidote would be to ride the elevator more often, but that won't be feasible on a broad scale in complex environments.
In summary: Corporate IT is no movie and its role isn't to provide an illusion for humans being farmed as power sources. We should be cautious with this role model.
Fun fact: Vint Cerf looks awfully similar to the Matrix architect. Considering he designed much of the Matrix we live in this may not be a coincidence.
A slightly more fitting analogy is that of a gardener. I tend to depict this metaphor
with a character from one of my favorite movies, Edward Scissorhands. Large-scale IT is much like a garden: things evolve and grow on their own. Weeds
tend to grow the fastest. The role of the gardener is to trim and prune what does
not fit and to establish an overall balance and harmony in the garden, keeping in
mind plants' needs, for example by planting shade-loving plants near large trees or
bushes. A good gardener is no dictatorial master planner and certainly does not make
all the detailed decisions about which direction a strain of grass should grow --
Japanese gardens being a possible exception. Rather, the gardener sees him or herself
as the care taker of a living ecosystem. Some gardeners, like Edward, are true artists!
I like this analogy as it has a "soft" touch to it. Complex enterprise IT does feel organic and good architecture has a sense of balance, which can also often be found in a garden. Top-down governance with weed killer is unlikely to have a lasting effect and usually does more harm than good, as does planting flowers in winter to mimic a beautiful garden. Whether this thinking leads to a new application for The Nature of Order I am not sure yet. I should go read it.
Erik Doernenburg, ThoughtWorks' Head of Technology Europe, introduced me to another very apt metaphor. Erik closely works with many software projects, which tend to loathe the ostensibly all-knowing, all-decision-making architect who is disconnected from reality. Erik even coined the term architecture without architects, which might make some of us architects worry about our career.
Erik likens an architect to a tour guide, someone who has been to a place before many
times and can gently guide you to pay attention to special aspects or also warn you
about certain risks. This is a guiding role: tour guides cannot force their guests
to follow their advice, except maybe those who drop a bus load of tourists off at
a tourist trap restaurant in the middle of nowhere.
This type of architect has to "lead by influence" and has to be hands-on enough to earn the respect of those he or she is leading. The tour guide also stays along for the ride and does not just hand a map to the tourists like some consultant architects are known to do. An architect who acts as a guide often depends on strong management support because evidence that good things happened due to his or her guidance may be subtle. In purely "business case-driven" environments this could be limiting the "tour guide" architect's impact or career.
A great movie analogy for the tour guide has not yet come to my mind. Charlie tours the kids around the Chocolate Factory, but he certainly has a stronger and slightly more devious agenda than the tour guide we are thinking about.
Update: A unconventional guide out of another one of my favorite movies is the blind DJ SuperSoul from the 1971 road movie Vanishing Point. Like so may IT projects the movie's protagonist, Kowalski, is on a kind of death march with an impossible deadline to meet and numerous obstacles along the way. He is not delivering code, but a 1970 Dodge Challenger R/T 440 Magnum from Denver to San Francisco - in 15 hours. Kowalski is being guided by the blind DJ SuperSoul who has tapped the police network - just as with architects being plugged into the management network is crucial. The guide tracks progress and keeps the hero clear of all sorts of traps police / management has setup. After Super Soul is compromised by "management", the "project" gets adrift and ends like too many IT projects: in a fiery crash.
Architects can sometimes be seen as wizards that can solve just about any technical
challenge. While that can be a short-term ego boost, it's not a good job description
and expectation to live up to. Hence by the "wizard" architect analogy I don't mean
an actual wizard waving the magic wand, but the "Mighty Oz" - a video projection that
appears large and powerful, but is in fact controlled by a mere human "wizard", who
turns out to be an ordinary man who uses the big machinery to garner respect.
A gentle dose of such engineered deception can be of use in large organizations where "normal" developers are rarely involved in management discussions or major decisions. This is where the "architect" title can be used to make oneself a bit more "great and mighty": the projection can garner the respect of the general (more easily fooled) population and can even be a precondition to be able to take the elevator to the top floors. Is this cheating? I would say "no" as long as you don't get enamored in so much wizardry that you forget about your technical roots.
Similar to the wizard, another expectation of the architect is that of the superhero: if you believe some job postings, enterprise architects can single-handedly catapult companies into the digital age, solve about any technical problem, and are always up-to-date on the latest technology. These are tough expectations to live up to, so I'd caution any architect against taking advantage of this common misconception.
Amir Shenhav from Intel therefore pointed out that instead of the super hero we need
"super glue" architects - the guys who hold architecture, technical details, business
needs, and people together across a large organization or complex projects. I like
this metaphor as it resembles the analogy of an architect being a catalyst. We just
have to be a little careful: being the glue (or catalyst) means understanding a good
bit about the things you glue together. We don't talk about the architect as pure
match maker.
Which type of architect should one be? First, there are likely many more types and movie analogies. You could play "Inception" and create architectural dream worlds with a (dangerous) twist. Or be one of the two impostors debating Chilean architecture in "There's Something about Mary" or (more creepily) Anthony Royal in the upcoming "High-rise" - the opportunities are manifold.
In the end, most architects exhibit a combination of these prototypical stereotypes. Periodic gluing, gardening, guiding, impressing and a little bit of all-knowing every now-and-then can make for a pretty good architect.
Our team is still growing! I am looking for one more senior Cloud Infrastructure Architect to join my team at Allianz in Munich.
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.