The architect elevator

Podcast transcript

Neal Ford:

Hello and welcome to the Thoughtworks Technology podcast. My name is Neal Ford, I'm one of your regular hosts, and I'm joined today by another of our regular hosts, Mike.

Mike Mason:

Good morning, Neal.

Neal Ford:

Good morning, and we are chatting today with a figure who's well known in the software development world. Many of you have one of his seminal books on your bookshelf, Enterprise Integration Patterns. He's former Thoughtworker, but has gone off to other adventures since then, and has recently written a fascinating book that we will talk to him about. So, please welcome to the podcast, Gregor Hohpe.

Gregor Hohpe:

Hello everyone, yeah, and it seems my adventures took me far away all the way here to Singapore, and I never thought of myself as a figure, but that's a nice way of thinking about it. And of course, I'm excited to talk about my book, The Software Architect Elevator.

Neal Ford:

Yeah, so let's talk about your book. This book, I first became aware of this book at the O'Reilly Software Architecture Conference. You were doing a workshop about this, and described the metaphor to me, and I thought it's a brilliant metaphor to talk about different communication levels. So, would you take a moment and describe your metaphor? Because it's not, I'm assuming, a book about how to architect elevators, but rather about architects who ride elevators, correct?

Gregor Hohpe:

Yes, that is true, and the very early search rank actually was a little bit confused about that, but then the search engine got ahold of it, and now if you search for Elevator Architect, it will steer you the right direction, which is architects riding the elevator. So, the metaphor is based on my experience working at large organizations, and particularly as a change driver. Right? It's almost a given these days that if you work in a large enterprise, enterprise IT, they're going to be in some sort of change or transformation scenario. 

Gregor Hohpe:

And my take was that architects play a critically important role in such a scenario, and that role is to ride the elevator, and that means to connect the penthouse, which we see as the folks who do the strategy and have the long term vision, and then riding the elevator down into the IT engine room where actually the technology decisions are being made. 

Gregor Hohpe:

And the reason we put the elevator in, is because in traditional enterprises, there's a lot of middle layer, a lot of staircases, a lot of steps, it takes forever for things to get from one end to the other. Often, they don't even make it, so there's a lot of intransparency and a lot of disconnect, and I think architects are best equipped to actually forge that connection. So, they get into the elevator and make sure that the penthouse and the engine room actually aiming the same direction.

Neal Ford:

Well, that's true. Architects should be uniquely qualified for this, because they should have both technical skills and presentation skills, and should be able to at least somewhat talk in business terms. But that becomes more difficult the higher in the elevator you get, because they want to talk more in terms of profit, loss, and business strategy. And a lot of domain architects get lost there, so is there a limit to how far up the elevator you can ride before you become a different kind of architect?

Gregor Hohpe:

True, and whether becoming a different kind of architect is a good or bad thing, we'll park that for a little bit later. The joke I always have, we know, what was it called? The astronaut architects, right? The higher you go, the thinner the air gets. If you run out of oxygen, that is probably not the kind of architect you want to become, but I have actually quite different experience. 

Gregor Hohpe:

So, assuming you are in an organization that has a long history and actually profitable, like many of these corporate ITs are, we always make bad jokes about them, and takes them two months to get a server and whatever all is not working, but they're often 100 years of business, they have billions of dollars of profits, so something must be working right. And what I've found is that the leadership is well aware in most cases of the limitation of all the different layers and all the disconnects. 

Gregor Hohpe:

So, two answers to this. In one hand, so they're aware, and they often welcome an architect actually getting near the penthouse. You'll be unexpectedly welcome, because they also want to have more transparency. The reason they tolerate it, if you wish, right, you might ask, "Well, if they know of the limitation of all the layers, why did they run it this way?" And the reality is that in a slow moving world, if things are fairly static, there isn't a lot of uncertainty, all these layers aren't so horrible, and they shield the executives from a lot of the complexity, right? 

Gregor Hohpe:

They don't need to know what kind of mainframe we are buying, or which database out of the two choices you're making, right, in the old days. So, it made their lives simpler. But, they know well that those days are gone. The rate of change has gone up, there's more uncertainty, so they actually also want to have more insight into the engine room. So the biggest challenge I've found is actually getting the door to open in the penthouse, but once you actually manage to get out and say hello and say something meaningful, they will fall in love with you actually fairly quickly.

Neal Ford:

That's an interesting observation, because it seems that enterprise architects are the ones whose role has been most changed over the last decade by automation and agile engineering. I meet with a fair number of enterprise architects who, on the side, tell me, "I'm not sure exactly what my job is supposed to be anymore." And a lot of it is because they had that very penthouse view, and didn't talk much to the engine room, but I think to be successful in modern organizations, you have to have some connectivity, at least some connectivity from the top to the bottom.

Gregor Hohpe:

Oh yes, and what I highlight even in the book is that the elevator goes both ways. You will find folks in your career who ride the elevator up once, and then they find out that in the penthouse, the view is better, the food is better, the bathrooms have golden faucets, right? So, they never want to go back down, and for better or worse, some of those folks will carry titles like enterprise architects, but I would not take them as indicative models, right? They actually rather give this a bad reputation. 

Gregor Hohpe:

This is not what we're talking about, right? The elevator is there to ride up and down, to make the connection, and I think you used a good word. To translate, and I like the word translating because what doesn't help is if you tell different people completely different stories, right? If you tell everybody what they need to be happy, you have maybe a short term booster or success, but that doesn't fix anything in the enterprise. So, it needs to be the same root and the same core of the story, but told in different ways, so that different audiences can relate. 

Gregor Hohpe:

And the perennial penthouse residents, they generally fail there. They create some sort of illusion up there, and there's no element of connection back down into the engine room. So, in my view, that neither qualifies as an elevator riding architect, nor does it really qualify as proper enterprise architecture. 

Mike Mason:

And Gregor, you mentioned the story, the architect riding the elevator is telling. What is the story? Is it the direction that we're going in? Is it the reasons that we're stuck? Or the motivations for change? What is the story that you're talking about there?

Gregor Hohpe:

That's good, and I mentioned this a bit in passing, but it's great that you honed in on it, because storytelling is a important element of all this. And I would say there's two parts, right? There's the act of storytelling, because as we all know, stories engage people and make things more tangible and less scary, and the more IT can actually weave things into a meaningful story, the more the penthouse can relate and say, "Yes, I get it." There's the second part though, is like, "Well, the story needs to be about something." Right? 

Gregor Hohpe:

There needs to be a moral of the story, and an essence of the story. Now, that will vary a little bit by the situation the organization is in. We often joke, there's no stack overflow for cultural change and transformation, right? It's not a copy and paste exercise. At the same time, though, there might be some common themes in these stories. And one story that I see a lot of times is that the penthouse understands that there's new technology, and that that new technology brings new capabilities, right? 

Gregor Hohpe:

All of the high priced consultants do their job well, and inundate the penthouse with all the things they could be doing with IOT machine learning and they could becoming agile and DevOps, and post DevOps, and you name it, right? So, they've seen all of those parts, but what is completely unclear in their head is exactly how can I behave differently to really take advantage of these new technologies? 

Gregor Hohpe:

What are the mechanisms behind these buzzwords? What constraints are being removed or changed? This is true for things like cloud and DevOps, right? We're changed, we're removing important constraints, so that allows us to work in a different way. And forging that connection, I think, is often the key element of the storyline.

Mike Mason:

That's interesting, because one of the things I wanted to ask you about was connecting business and IT strategy. So, for a long time, business strategy ruled the world, and people would decide what to do from a business perspective, and then IT would be tasked with going and making that happen. But as we've seen technology and business become much closer together, there's been an increased need, at least as you just said, for business to understand the capabilities that IT's giving. 

Mike Mason:

But sometimes IT folks would say, "Well, no. Actually technology strategy needs to drive the business strategy." And sometimes business folks will still say, "No. Business, we're the thinkers here. I need to know a little bit about IT, but business is still driving the strategy." Is it one or the other, or somehow both?

Gregor Hohpe:

Very good question, and I just this morning, I had a presentation, and we talked about this. Which drives which, right? And at the end, this was with a large IT organization, and at the end of the day, it's clear, it is a business. So, somewhere the business outcome has to be at the beginning of this. But the metaphor I used in that conversation, which I'm starting to like is, the word value chain is actually a really good word. I thought of the value part, but the chain. The metaphor of a chain. 

Gregor Hohpe:

Now, a chain has a beginning of an end you use. So, to pull a certain direction, right? And you pull the direction from the business. But in a chain, all links, all elements, are equally important. So, I think where this mix up, and a lot of this debate comes from, that they think if you drive from the business side, somehow this makes the business either more important or more fancy, or have the upper hand, and I don't think that part is true, right? They're just links in a chain. 

Gregor Hohpe:

If one link breaks down, you have nothing, and in a good way, it has to go both directions as well. So, having the objective, the overall objective, being business success, which I think is clear. All your tech is no good if you all guys go under, right? So, I think that's non-negotiable, but I think what you shouldn't do is, you shouldn't translate the objective into your working model, right? 

Gregor Hohpe:

The working model is not that the business tells the IT what to do, and the IT says, "Aye aye, sir." It is definitely a dialogue, and even in my book, I define the role of enterprise architecture as closing the gap between the business and the IT. Making that dialogue, that bidirectional chain linking happen with the objective of running a successful business, but with an operating model of a healthy dialogue.

Neal Ford:

So, if we extend your chain metaphor a little bit further, I love this metaphor by the way, if you choose a technology before you understand the business, it's like trying to push a chain, and that never works, because it just goes slack and it doesn't go anywhere.

Gregor Hohpe:

Exactly. Yeah, you guys know I like metaphors, so we need to make sure we don't drift off into space where the air is thin. But, I really like this, because if you push on a chain, let's put it this way. If you do this a tiny bit, you push and maybe tuck a little bit to make sure the chain intact, I think that's okay. 

Gregor Hohpe:

So, we experiment with technology, we make sure the chain is still connected, I think that is all legit. But if you're trying to push the chain to actually move something, I really love the way you put this, that of course is not going to work. You need to know what's attached on the other end, and you need to make sure that the chain links are actually all connected.

Mike Mason:

So, Gregor, you... we talked about change early on, and I confess I haven't read the book, but I have been on the website, and I watched one of your talks, so hopefully this is a relevant question. But you mentioned that change and transformation is hard because each of the pieces of the system are locally optimized. Can you say a bit more about that?

Gregor Hohpe:

True, and of course the first part of the answer is yes, you should read the book. There's a lot of stuff in there. The second part is yes, and I have used this in recent presentations more often, and that is how do we optimize what we do? Because we want to optimize so many ways, right? We want to have efficient business, we want to have a well run IT, we want to be smart with the money, we want to be successful, so there's many things we want and we need to optimize. 

Gregor Hohpe:

Traditionally, organizations have been set up to optimize locally, and again, there's a good reason for that. I always come back to this. It's so easy to say, "Oh, this is all wrong. This is all stupid, how can you guys possibly do this?" But then you look at the 100 year old organization that is highly profitable, so it cannot be all that wrong. And the answer always is that it used to be right, and it used to be right because local optimization is easy to do. It's very visible, and it gives clear accountability. The problem with local optimization is that your customer doesn't care, right? 

Gregor Hohpe:

Your customer sees the end to end picture. One metaphor, a more tangible metaphor I give often, right, you guys know now I work for AWS, so part of Amazon. Our customers would not give us any applause if the package is 98 percent delivered, right? You say, "Oh, we've made a fantastic warehouse, inventory automation, the way the packages are stacked in the truck. It's all super optimized, and we almost rang your doorbell, but we didn't." Right? 

Gregor Hohpe:

That gets you nothing, and that is a good reminder that the customer sees end to end, and I believe that has changed in the last decade or so what customers are willing to put up with. As long as everybody have these different departments, the customers are stuck with it, right? You make a call, you ask a question, and then they need to transfer you to a different department, because they're locally optimized, and that was just the way it was. 

Gregor Hohpe:

Now, some people have shown that that doesn't have to be this way, and of course the customer expectations go up, and now it behooves every large enterprise to not expose their internal structure to the users, and to make sure that they at least also optimize globally. I don't think one replaces the other, there certainly is space for some local optimization, but then it needs to be supplemented by an end to end global optimization, because that's what your customers see, and today your customers will expect that.

Neal Ford:

Well, and I think that's... so another way of talking about local versus global optimization is tactics versus strategy, because very often people who are closest to the code have to take tactical decisions and architecture, because they have to get stuff to work. They have to get stuff to ship. 

Neal Ford:

I've got a hard date, it'd be nice to go and draw pictures on white boards for a few weeks, but I've got to ship some code, and so what I find in a lot of organizations is there's this huge disconnect between the enterprise architects who own this grand beautiful strategy, but it never gets translated because everything happening where the decisions are made are tactical. 

Neal Ford:

And I think that's part of the benefit of this metaphor is to connect the strategy and the tactics, and one of the ways I say it is, you really want the solution architects and the enterprise architects to be equally unhappy in the middle. Because if the strategic people are super happy, that means you're not being tactical enough, and if the tactical people are too happy, that means you're not following through with your strategy. 

Neal Ford:

So, it's a way to meet in the middle, maybe in one of the middle floors at the cafeteria or something in your metaphor. Resolve and come to an equal place of well, we're equally unhappy now.

Gregor Hohpe:

Yeah, that's a great observation right, because the strategy is often made in the penthouse or near the penthouse, and of course in the heat of the battle of coding and delivering, you need to make tactical decisions. The way I would describe the key benefit, because linking the two, that is the essence of the architect elevator, and again linking not in one direction where the penthouse tells the engine room just what to do, right, but linking it bidirectionally, because that way it provides feedback. 

Gregor Hohpe:

Since we are heavy on metaphors here, we seem to like metaphors, another one I use in this context is when you want to climb a mountain, you don't go straight up, right? You usually go a zigzag. You have certain towns where the road is built or the path is built. Now, if somebody was going to look just at your tactics, the direction you're marching, they would say, "Dude, you're going the wrong direction. You're not actually going up the mountain. You're going sideways. Shape up." Right? 

Gregor Hohpe:

This way is up, people. That's where we need to go. If you zoom out a little bit, and you understand the strategy, and you have the translation between the strategy and the tactic, then of course it makes all sense in the world to go in a zigzag, because that is the rate of change you can accommodate, and the key element of the zigzag is well, three minutes down the road, you can make a 150 degree or something turn, and you go the other way. And if you don't see that middle connection that you've got to make turns, it's very easy to throw rocks at the other side. 

Gregor Hohpe:

One side's saying, "Oh, you're marching the wrong direction." The other side's saying, "Oh, you're crazy. Nobody can climb such a steep hill." And you can debate until the cows come home. So, this is a really nice example of where the elevator connecting element allows these two parties to have a much more meaningful discussion, say, "Hey, this is a natural way of doing it. This is how anybody would take a steep hill." And everything is fine, and that's a great success story for an elevator architect.

Neal Ford:

I like the hill climbing metaphor as well, because we're all three writers, so we can call this episode Metaphor Madness or something, probably. So, have you found a good way to... because if you have a map of a mountain, it's easy to show somebody the overall picture of the map and trace the zigzag and point out that there are local optimizations reaching a global optimization. 

Neal Ford:

Have you found a good way to document that within a large organization? Because that kind of visual would be invaluable as a communication aid as you rode up and down the elevator, because you would get everybody in the same context very quickly. Have you found anything that's particularly useful for that?

Gregor Hohpe:

So, I've dabbled with this quite a bit. My current state of mind is that a universal map that could do that may not exist, or at least I have not found it. And I think that's okay. What we often forget is when we look at maps, let's stay with a physical metaphor like mountains and rivers and cities and stuff, right? There are many different maps depending on which question you ask, and there is no one best map, right? We have political maps, we have population density maps, we have freeway maps, we have topographical maps, right? 

Gregor Hohpe:

If we stay with our hiking and climbing up the hill metaphor, so the right map to use really depends on what you're trying to achieve. So, I think having a catalog of maps is probably the way I would go. I don't believe in this Highlander there can only be one kind of thing. It is all based on context, and which question you're trying to answer, and it is almost always about the organizational context as well, right? So, the best map for you hinges on what you're trying to do, and it hinges on where you currently are. 

Gregor Hohpe:

Like, if you're in the middle of the ocean, the topographical map, it's not going to be all that helpful, right? So there's two important parameters, and what I'm trying to do with my books, I'm often trying to say, "I don't tell people what to do. I'm trying to tell, or to help people how to think about these problems." I want to help you to find your own map, come to your own conclusion, so it's less prescriptive, but it's taking a step back and saying, "Here's a good way to think about it, here's how you could go about coming up with a useful map." 

Gregor Hohpe:

Now, some people say, "Oh, I want a clearer recipe. I want the solution." My current state of mind on this is, these recipes are dangerous. I know everybody longs for them, but copy and pasting as we said earlier, and following the same recipe in a transformational change scenario, I think can cause you more trouble than it might give you benefit. You need to understand the mechanisms behind it before you apply one of these recipes.

Mike Mason:

Yeah, I think that's an extremely important point. I think there's even the possibility that the organization doesn't actually know where it's going to get to when it makes a particular transformational decision, and that you need to be able to start making decisions, getting feedback about whether those have been useful and the right direction, and then being able to double down on something that's working and kill off something that's not working. So, I'd even say there's a learning or a change muscle building thing that organizations need to do.

Gregor Hohpe:

I totally agree. This is one of the first most important steps in any transformation scenario, and it's a common theme that we often touch on. It's the theme of iterations and feedback, and if you think about a lot of the agile methods, many other things are built on it. The problem is it doesn't help to throw a buzzword at people. It's like, "You need to be agile." Because they've already been told 20 times, and they've become certified in all sorts of stuff, and it hasn't helped them. What I instead try to do is bring it down to very simple stories. 

Gregor Hohpe:

Let's come back to that, and the reason, or the way I try to motivate why feedback is so important, is because feedback is the quintessential learning mechanism, right? In school, we got feedback depending what school you went to. You got grades, or but you get some indication, right, that if you did wasn't right, somebody told you that it wasn't right, and that is a key element of learning, right? If I read a book, and I never try any of it out, how do I know I actually understood what I read? That's why there's problems to be solved there. 

Gregor Hohpe:

We always make a little code sample, or we always try something out. So, I think I would pose it that it's extremely difficult to learn without feedback. Maybe you're some sort of mad genius who can do this. I certainly cannot, and a transformation scenario is a learning scenario. You need to find your path, you need to learn how this works for your organization. So, trying to do that without feedback is probably one of the most certified failure scenarios, so getting a form of feedback in there is an enabler for learning, and that learning is the essence of actually being able to make this change.

Neal Ford:

I'm now compelled to beat this map metaphor completely to death. So, what Mike's really talking about here is a Dungeons and Dragons map, where you can't see what's coming in the future, because if you got... if some other industry's already made this transformation, you can follow their game plan. But what if you're in an industry that's never really done this kind of transformation before? 

Neal Ford:

You're literally exposing more parts of the map as you discover things, and the roll of the dice there is iteration. You need to reevaluate every time you roll the dice and learn more about the dungeon you're in, to make sure that you're outfitted for the monsters that may show up around the next corner.

Mike Mason:

I mean, I would even argue that being in the same industry and seeing somebody across the road who's done something successful doesn't necessarily tell you very much about what you might do. I think all of us on the podcast here would groan whenever we hear, "We're implementing the Spotify model." Because that's the classic cut and paste from somebody else's culture even. 

Mike Mason:

So it's not even necessarily just what is the business that you're in, and therefore what is some new structure that will be useful to you. There's even what are you currently doing, what historically has happened to you? Rebecca, the Thoughtwork CTO always mentions a client in the UK where they would say, "What if we lost Scotland?" 

Mike Mason:

Because in some previous piece of technology, they had lost their communications link with all of their stores in Scotland, and so now suddenly everything that you did from an architectural perspective had to take into account that PTSD, organizational stress, that they had about that thing that happened in the past.

Gregor Hohpe:

Yeah, so I think we can rename this episode into the Masters of Metaphor, right? So, we've gone from elevators, to chain links, to Dungeons and Dragons and maps. I really enjoy this, because at the end, these are the tools that helps architects sharpen their thinking, and I would attempt to make a linkage between what Mike just said. Another thread through the book is really that you can apply architectural thinking much more to organizations and organizational change than architects commonly believe. 

Gregor Hohpe:

So there's a subliminal message in there, and it's two-fold. The first part of the message is, if you don't concern yourself with the organization and bringing change, you won't be successful as a, what I sometimes call, large scale architect. Maybe call it enterprise architect, right? All the tech is going to do you no good if you're not concerning yourself with the other side. Now, that's a challenge. That makes your job more interesting, but it's a challenge. The second part of that thread of that insight is, you are likely much better equipped for this than you might think. 

Gregor Hohpe:

And even in the book we touch on this, right? You mentioned the copy pasting culture, right? The Spotify model, right? Which, Spotify admittedly didn't implement 100 percent either, right, so you're copying something that wasn't actually real, but as an architect, when I look at something... as architects, we're often the folks who as kids like to take things apart, right? And the reason we like to do this is because you need to understand the inner workings, the constraints, and assumptions that are baked into a particular solution, right? 

Gregor Hohpe:

So, when you see a buzzword, useful approach, right? Buzzword always sounds a little bit negative. Some of these actually, very good things. But the first thing you need to understand is, how does this black box function internally? What constraints and assumptions are baked in? In which context was this successful, and is this context essential to the working of this mechanism, and is my context similar or different, and therefore is it plausible that this mechanism would function in my context? And I think you do this for technical systems. 

Gregor Hohpe:

If you migrate or port something, like I work for a cloud provider, right? A lot of people move people to the cloud, right? And they're like, "Well, did I have constraints, assumptions in my system on premises that keep it from running in the cloud, or keep it running well?" So, you have a similar thought process, but with organizations, it's exactly the same. 

Gregor Hohpe:

If somebody else was successful doing something, you open the little black box, you see what's inside the constraints and assumptions, and that's the essence to me of architectural thinking for both technology, transformation, as well as for organizational transformation.

Mike Mason:

And Gregor, you've talked about reverse engineering the IT organization and looking at who the CIO reports to, whether that's the CFO, which would make IT a cost center, or maybe the CIO has a seat at the table, reports to the CEO, and is considered much more strategic, but we're all talking about transformation in general. Where does IT end up? Is the IT department eventually going to go away, and IT becomes a natural part of the business, or is there always going to be a role for the IT department?

Gregor Hohpe:

I think that's a good question. Yeah, so I know the slide of the talk you're referring to, where I give people a hint of saying you can easily find out where on this transformation journey your organization is by just seeing where your CIO reports into, because that is part of understanding the organization. These reporting lines. They are not random. There will be objectives and success criteria given, and if this comes from the financial side, you can be sure that's related to spend. 

Gregor Hohpe:

If it comes from the COO side, it's mostly about efficiency, if it has more of a chief digital officer, chief transformation officer, and if it comes straight from the CEO, it's going to be much more about change and business success. Now the question is, so the observation is, many organizations are shifting to the right of this chart. They start with the CFO, they often go through the COO, and then they migrate up to become a full member of the board. The question is, where does this leave IT? 

Gregor Hohpe:

And again, there's two parts to this. The one is, you can look at how the purebred digitals have it, and that is insightful to do that, but as we just observed, that doesn't mean that you should copy the same thing. So, how do the purebred digitals do it? Their so-called IT is tiny, right? I've worked in Silicon Valley for over a decade, and I always say, in my decade in Silicon Valley, nobody ever said, "We need to talk to the business." Or, "We need to talk to the IT." I was a software engineer, I was a staff software engineer, tech lead manager, right? 

Gregor Hohpe:

I was the technology for sure, because we were building near-field communications stuff, conversion tracking in Japan, so a lot of technology there, no doubt. With software and hardware solutions with it, but I was also the business, because my objective was, this was mobile ads in Japan. I had economic objective. We were increasing run rates without worsening the user experience. So, I was measured by a business metric, but the tools I had on my hand were deep down technology. 

Gregor Hohpe:

Now, since we're the masters of metaphor, you could say, "Oh, how does this work and how does this relate to the elevator?" And stretching the metaphor one more time is, the Silicon Valley folks, they essentially live in a bungalow, right? If I am the same person, right, if my weekly so-called status reports, or my weekly meetings, they were around running experiments, can we move the business metric, if so we switch the experiment live. If not, we shut the experiment off and start another experiment. 

Gregor Hohpe:

So, all about business outcomes. So basically, I made all the translation in my head and with my small team. You don't need a lot of elevator. Now, the challenge is, if we look at this target picture, we start with a skyscraper with 100 floors, we say, "Oh, Silicon Valley is in a bungalow. Let me make a bungalow." Now, we all know how that story ends. It ends with a pile of rubble, it doesn't end with anything that resembles a bungalow. So, I think the realistic answer is, you want to take some layers out, and delayering has become a common strategic consulting term. 

Gregor Hohpe:

To delayer the organization, and I think you will have some success with that, but the target picture doesn't have to be to live in this bungalow. I think making some incremental change along this dimension, seeing how this works out for you, and cost-correcting like you said before, is actually plenty perfect. The one joke I would put on it, while it's not quite a joke, it also reflects why it's so difficult for enterprises to go this route is, in traditional enterprise vernacular, if there's IT close to the business, it's called shadow IT. 

Gregor Hohpe:

It's something undesired. But if you look at Silicon Valley, it's basically 98 percent shadow IT. Now, I think for you, for an organization, 20 or 30 or 40 percent is going to fine. That you have to do based on your feedback cycle, but you need to start thinking that having IT closer to the business is what enables the feedback, and we already concluded that the feedback is the core element of making the transformation happen.

Neal Ford:

So, I have a speculative question for you. So, when I first met you, we were both working at Thoughtworks, and it was the era of the orchestration driven, service-oriented architecture. The big giant integration architecture. I know you remember that well, you're probably still awake with nightmares in the middle of the night occasionally from those days. But, during that time, part of the appeal of that to architects was, it was a messy connectivity from the top, the penthouse, all the way down to the engine room because the tools enforced that web. 

Neal Ford:

And now, at the nodes where people are actually writing code, it is a lot more intensely technical now, because we have things like microservices, we have DevOps, we have containers, there's a lot more moving parts to the solutions that we're providing now. 

Neal Ford:

And do you think that makes it more difficult now for someone who's in the penthouse to actually understand enough about what's going on in the engine room to make useful decisions about it, and has that problem actually gotten worse as we've basically empowered more solutions at the tactical level? Have we made it harder for the strategic decisions to happen?

Gregor Hohpe:

Yeah, it seems like we all worked for Thoughtworks at some point or another, so I'm happy to reminisce in old times, and while as we see with Enterprise Integration Patterns, right, the book is now 17 years, and it's as popular as it's ever been. So, there is something magical about integration that never goes out of style, and a mini sidebar on this is, the reason I believe integration never goes out of style is because it is an end to end value delivery activity, coming back to the earlier topic of end to end optimization. 

Gregor Hohpe:

Integration takes something that was siloed and optimized locally, and gives it some semblance let's say at least, of an end to end optimization, and that generally delivers business value, and that's why it never goes out of style. Coming back to your question though, so we have a lot more enablement, and a lot more ability at the tactical level down in the engine room. My first thought is, that is universally positive, because the people who are closer to the action, who are doing the tactics, enabling and empowering them is always a good thing. 

Gregor Hohpe:

Faster feedback cycles, making the decisions where the problems arise. That is always positive. Now, what could possibly go wrong? Several things can and do go wrong. The one thing that goes wrong is let's be careful to not use the elevator to transport problems from one floor to another. If you shuffle all your rubbish into the elevator and push the button into another floor, and it comes out there, you have locally optimized, but you haven't really accomplished anything for your organization. And I think as a discipline or as a field, we are very prone to this fallacy. 

Gregor Hohpe:

We're like, "Oh, this top down design didn't work. Let's shift it all down." Or, "Let's make it all reconfigureable and shift all the complexity into the orchestration." Right? We always shift it somewhere else, just to be shockingly surprised that the complex really hasn't magically disappeared, it's just sticking its head out of another pipe. So, I think when we do this empowerment for the local tactics, which again I say is universally positive, we need to make sure that it isn't just shifting the complexity into a different layer, that we have the proper tooling with the proper discipline to deal with it. 

Gregor Hohpe:

To your second part of your question, does that make it harder for the folks in the penthouse? I would say no, if you use the mechanisms that are available to you. A lot of the modus operandi of traditional IT is such because transparency was traditionally incredibly low, and this is one of the constraints I'm talking about when I say, "You need to understand what constraints something was designed under." Now the cloud and web services and service meshes, and all of the other fancy stuff out in the engine room, one of the most underappreciated benefits that I observe is increased transparency. This black box slowly starts to light up. Now, the funny part is initially you're a little bit shocked. 

Gregor Hohpe:

It's like when you put a brighter bulb in your basement, you see the giant mess that you have, but I always say, "Don't blame the bulb, be happy that you see it now." So there's an initial shock, but there's huge value in increased transparency, and I think if the folks in the penthouse are willing to use that transparency, it is actually easier to understand. Now, let me say, ease of understanding isn't my main goal, even. It's easier for them to reason about it and make decisions in that context, and that's what we're after.

Neal Ford:

That's all fabulous, but The Architect Elevator book is out. What are you working on now?

Gregor Hohpe:

Great question, and what we're doing now is what I often call the landing zone, right? Once you drift into outer space or vice versa, once you dig deep into your metaphors, it's good to come back down in the landing zone back to earth and what are we going to do next. Quite honestly, the Architect Elevator had a little bit of long run up. It was iterative, just like the world it is now, it started like you guys know, as a book called 37 Things, and The Architect Elevator metaphor really came out of reader feedback. 

Gregor Hohpe:

People said, "Oh, that is the great chapter. I love the metaphor." So, that's why we decided to ultimately rename the book and say that is really a new way of thinking about the role of the architect. So, I just wanted to highlight that, and what I'm doing now is applying this thinking to different domains. Speaking about landing zone a little bit, Architect Elevator is an interesting book in a way. It's a unique book, because it's very much approachable and storytelling, right? People say they really enjoy reading it, a lot of anecdotes, a lot of stories. 

Gregor Hohpe:

At the same time, it can also be abstract, because again, it's trying to change the way you're thinking, right? There's pretty heavy duty content behind those stories. So, what I'm doing now is applying the lessons learned from The Architect Elevator to individual domains. Now, the first one I've done, that's my recent book called Cloud Strategy, right? That's cloudstrategybook.com, which it looks and feels like the elevator has 32 chapters, a lot of anecdotes, a lot of depth down below, but applied to a very tangible domain. 

Gregor Hohpe:

So you will find chapters about hybrid cloud, about organizational changes, about migrations, about containers and server lists. It has a lot more context, and that seems to be very well received. So, it could be called a little bit T shaped, if you wish. The Architect Elevator is the horizontal, and now I'm filling in different verticals. The Cloud Strategy book being the first one, the next one I have a skeleton for is platform strategy. 

Gregor Hohpe:

Again, in most large organizations, I think a very relevant topic, and I haven't found much about it, and then it gets more fuzzy on the horizon, right? On the horizon is perhaps API strategy and data strategy. That would be Gregor's box set collector's edition of everything an elevator architect needs to, right? You got to have to be a little bit patient, because of course these books are written as I'm going through the actual experience in real life.

Neal Ford:

Well, it's great to catch up with you, and we will let you get back to writing. Sounds like you've got a lot of writing to do, and we're looking forward to the output of that. So, thank you very much for joining us today, Gregor.

Mike Mason:

Thank you, Gregor. This was super fun.

Gregor Hohpe:

Yeah, great. Well, thanks for the great chat, and thanks for amplifying the metaphors. I think if we do this again, we can crank it up another notch on the metaphor meter. Thank you guys.

Neal Ford:

I'd be afraid of that. Thanks.

Gregor Hohpe:

Me too.