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.
Architects frequently play a critical role as connecting and communicating element between multiple parties. Especially in large organizations such communication is an important factor: too many parties speak different languages to convey different, and often conflicting, objectives. Many layers of management only exacerbate the problem as communicating to corporate leadership resembles the "telephone game" where a circle of kids relays a message one-by-one just to realize at the end that the message has completely changed along the way. In the enterprise IT world, the worst case scenario happens when people holding relevant information are not allowed to make decisions and the decision makers lack relevant information. Not a good state to be in, especially in the days where IT has become a driving factor for most types of business.
Architects can fill an important void: they work and communicate closely with technical staff on projects, but are able to convey technical topics to upper management without losing the essence of the message. Conversely, they understand the company strategy and can translate it into technical decisions that support it.
This is what I call the architect elevator: architects ride the elevator up and down to move between the board room and the engine room of a large enterprise. Such a direct linkage has become more important than ever: if the board room (or the bridge) believes the engines are in reverse and the rudder is turned in hard, but in reality the engines are running ahead, major disasters are preprogrammed. This is one reason why (good) architects are such a critical asset in the enterprise today.
The number of floors an architect has to ride in the elevator depends on the organization. Flat organizations may not need the elevator at all -- a few flights of stairs are sufficient. This may also mean that the up-and-down role of an architect is much less critical: if management is keenly aware of the technical reality at the necessary level of detail, fewer "enterprise" architects are needed. However, classic IT shops in large organizations tend to have many, many floors. So many in fact, that a single architect elevator may not be able to span all levels. In this case it's OK if a technical architect and an enterprise architect meet in the middle and cover their "half" of the building. The value of the architects in this scenario should not be measured by how "high" they travel, but by how many floors they span. This is a common mistake in large organizations where the folks in the penthouse tend to see only the architects in the upper half and assume that they have more value. Conversely, many developers or technical architects consider "enterprise" architects less useful because they don't code. This can be true in some cases -- these architects enjoy life in the upper floors so much that they are not keen to take the elevator ever down again. But an "enterprise" architect who travels half way down the building to meet up with technical architects can have a significant value.
Invariably you will meet folks who ride the elevator, but only once to the top and never back down. They enjoy the good view too much and feel that they did not work so hard to be still visiting the grimy basement or engine room. Frequently you will hear the following comment from these folks: "I used to be technical". I often can't help but retort: "I used to be a manager" (it's true) or "Why did you stop? Were you no good at it"? If you want to be more diplomatic (and philosophical) about it, cite Metropolis with the slogan "the head and the hands need a mediator". In any case: the elevator is meant to be ridden up and down. Eating caviar in the penthouse while the basement is flooded is not the way to transform corporate IT.
Riding the elevator up-and-down is also an important mechanism for the architect to obtain feedback on decisions. As before, obtaining feedback on decisions is a general challenge for architects. If by the time the architectural decision actually had an impact, the architect is only enjoying the view from high up, the dreaded authority without responsibility anti-pattern has been reached and all hope for feedback cycles is lost.
In the past IT decisions were fairly far removed from the business strategy: IT was pretty "vanilla" and the main parameter (or KPI = Key performance Indicator) was cost. Nowadays the linkage between business goals and technology choices has become much more direct, even for "traditional" businesses. For example, the need for faster time to market to meet competitive pressures translates into an elastic cloud approach to computing which in turn requires applications that scale horizontally and thus should be designed to be stateless. Targeted content on customer channels necessitates analytical models which are tuned by churning through large amounts of data via a Hadoop cluster, which favors local hard drive storage over network storage. The fact that in one or two sentences a business need has turned into application design or the choice of storage attachment highlights the need for architects to ride the elevator. Increasingly they have to take the express elevator, though, to keep up with the pace at which business and IT are intertwined.
If you are riding the elevator up and down as a successful architect you may encounter other folks riding the elevator with you. You may for example meet business or non-technical folks who learned that a deeper understanding of IT is critical to the business. Be kind to those folks, take them with you and show them around. Engage them in a dialog -- it will allow you to better understand business goals and needs and maybe they will take you to some higher floors you have not been to.
You may also encounter folks who ride the elevator down, look around to pick up ideas and buzzwords and take them up, selling them as their own suggestions. We don't call these people architects. We call them corporate opportunists, who have learned that much ignorance in the penthouse supports a solid "technical" career without going too deep. More colorful names taken from the animal kingdom, inspired mostly by things sucking blood or biting ankles, exist. You may be able to convert some of these folks and get them more genuinely interested in what is going on in the engine room. You may not succeed, though, and then it's best to maintain the prototypical elevator silence, avoiding eye contact by examining every ceiling tile in detail. Keep your "elevator pitch" for those moments when you have a senior exec with you, not a mere messenger.
Me friend Stefan Tai expanded the elevator analogy by another common pattern: people who ride the elevator down, but never really get out of the elevator to interact with people in the engine room. Instead they may catch some ideas or vocabulary to take back up. People who ride the elevator but don't get out are not called architects. They are called "lift boys".
Are you frequently riding the architect elevator in a large organization, enjoying hands-on work in the "engine room" as much as connecting technology evolution to business strategy? Do you converse equally well in DI/IOC and TDD or PaaS and HPC as you do in IT Transformation, 2-Speed Architecture, and Business Case? Then you should consider joining in my team! I am looking for a handful of seasoned IT architects in cloud infrastructure, but also in middleware and data architecture, to augment my current team at Allianz in Munich, Germany. The team is just 6 months old, rapidly growing, and has direct visibility to the Group and Business unit CIO's as well as all Chief Architects. And most importantly, we are a bunch of passionate, smart, and fun folks who are challenging and transforming "big" IT! Sounds interesting? Here is the job listing.
I took the elevator photo inside the Taipei 101 tower elevator, which claims to be world's fastest. The elevator to the exclusive and somewhat elusive Summit 101 club is clearly visible.
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.