Gregor's Ramblings

Movie Star Architects

Aug 1, 2015

Gregor Hohpe
Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also the Chief Architect at Allianz SE, one of the largest insurance companies in the world.

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...

The Matrix - The Master Planner

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 ArchitectThe 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.

Edward Scissorhands - The Gardener

Edward ScissorhandA 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.

Name the Movie (Vanishing Point?) - Guide

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.

Tour GuideErik 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.

The Wizard of Oz

Wizard of OzArchitects 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.

Superhero? Superglue!

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.

Super GlueAmir 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.

Making the Call

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.

Looking for (Movie) Star Architects

Our team is still growing! I am looking for one more senior Cloud Infrastructure Architect to join my team at Allianz in Munich.


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is the Chief IT Architect of Allianz SE. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.