Platform Strategy • Gregor Hohpe & James Lewis

This interview was recorded for the GOTO Book Club.
http://gotopia.tech/bookclub

Read the full transcription of the interview here:
https://gotopia.tech/episodes/323

Gregor Hohpe - Author of "Platform Strategy", "The Software Architect Elevator", et al.
James Lewis - Software Architect & Director at Thoughtworks

RESOURCES
Gregor
https://twitter.com/ghohpe
https://www.linkedin.com/in/ghohpe
https://architectelevator.com

James
https://twitter.com/boicy
https://linkedin.com/in/james-lewis-microservices
https://github.com/boicy
https://www.bovon.org

DESCRIPTION
James Lewis and Gregor Hohpe discuss the concept of dimensionality in decision-making, particularly in the context of innovation versus standardization. Hohpe emphasizes the importance of understanding and removing constraints to unlock new opportunities, citing historical shifts in technology and platform thinking as key examples.

They explore how traditional one-dimensional views often limit progress and the challenges of adapting to new paradigms, especially in organizations. The discussion also touches on the role of architects in facilitating these shifts and the strategic focus needed for internal platforms to thrive in the face of evolving technologies.

RECOMMENDED BOOKS
Gregor Hohpe • Platform Strategy • https://amzn.to/4cxfYdb
Gregor Hohpe • The Software Architect Elevator • https://amzn.to/3F6d2ax
Gregor Hohpe • Cloud Strategy • https://amzn.to/3TOS3Nv
Gregor Hohpe • Enterprise Integration Patterns, Vol 2 • https://amzn.to/3TNedQ3
Gregor Hohpe & Bobby Woolf • Enterprise Integration Patterns • https://amzn.to/3DqII9l
Gregor Hohpe • 37 Things One Architect Knows About IT Transformation • https://amzn.to/3z8uhnw

Bluesky
Twitter
Instagram
LinkedIn
Facebook

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:
https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/join

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Chapters

• 0:00 Intro
• 1:47 What’s the big deal with platforms?
• 5:23 Challenges & complexities of building platforms
• 9:25 Abstraction’s & innovation’s role in platform strategy
• 20:53 The architect elevator metaphor & beyond
• 27:02 Platform innovation & the flywheel effect
• 31:20 Practical advice for CIOs
• 33:39 Dimensionality & constraints
• 45:44 What was left out & what’s next?
• 50:12 Outro

Transcript

What’s the Big Deal with Platforms?

James Lewis: Hello and welcome to another edition of GOTO Book Club. And today, I'm absolutely delighted to be joined by Gregor Hohpe, who's written another book in his strategy series, which is, this one's called "Platform Strategy," with the subtitle, "Innovation Through Harmonization." And I'm excited, as I say, to be talking to Gregor about that today. Gregor, would you like to say a few words?

Gregor Hohpe: James, always a pleasure to chat across the time zones and the long distance here. And yes, as I've explained before, writing books is a form of therapy for me. So in a way, new books come out, but it might also reflect my mental state if they come out too frequently. It might mean that I need more therapy. But in this case, I'm actually happy. This one was a long time in the making, "The Platform Strategy." So I'm happy we can chat about that and hold that up as a finished book.

James Lewis: I've been working with or around platforms for a very long time. And I have to admit, reading your book actually was incredibly illuminating for me. I found it clarified a lot of the ideas in my mind. So I would genuinely recommend people go out there and take a look, because it is extremely illuminating. It's fantastic. But I guess we'll start off with, I guess, a big question. Why platforms? What's the big deal about platforms? Why should we be talking about platforms?

Gregor Hohpe: My sort of straight and sometimes slightly cynical view of the world of IT. So I think with so many trends that we have, platforms are driven by some reality and then a little bit of what I might call psychology or perhaps also therapy. So the reality is, of course, that the way we build software these days has become more complex. It affords us many nice operational capabilities. We build things fully distributed, loosely coupled, event driven, whatever you have. Right? But at the same time, people also realize that building that stuff is a little bit harder than the monolith. So, my joking version is, in the end, it's largely your fault. You told everybody to split things into small components. And then, you know, to make it worse, make them loosely coupled, and event driven, and asynchronous, and globally distributed. And that's fantastic. But it's also not easy.

So what people are looking for is finding a way to reduce the cognitive load, is the popular term, because they start realizing that because we solved a lot of the technical issues that now the limiting element is up here, sorta how much we as developers can absorb. So I think that's sort of the real part of it, because I see the same pain. I feel the same pressure. And then there's, of course, the joke, half joking, cynical part of it, which is, you know, corporate IT and large scale software development. It's a little bit depressing at times, right? You have to deal with a lot of stuff, and things don't work, and you have to debug and stay up late at night. And then somebody comes and says, why didn't you use blockchain? I find the industry loves to have something to look forward to. Like there must be a sort of the savior on the horizon. We always want to believe the next thing will come and solve all our ailments. And for a couple of years, at least that has been a platform. Now, I think there's a hot race against Gen AI. So we'll see how that plays out. But I definitely sense a bit of this. We just want to believe that something comes along and makes our lives easier. And platforms are the choice, the true love choice for that for the time being.

James Lewis: I have this cartoon I show sometimes with... I call it the kind of computer weekly kind of thing. Right? So we're back in the days where you'd be reading Computers Weekly, and you'd be keeping... What's all this? And you'd ask someone outside your office, what's this platform thing I keep reading about in computer weekly? Should we have one of those, you know? That's kind of the motivation. Let's get one of those. Apparently, we get a DevOps with it as well.

Gregor Hohpe: It comes with a bundle as a bonus. And I said, it helps... I mean, if it helps keep people sanity, I don't even want to say it's a bad thing. I know large scale software stuff can be tough at times. So, if that works for you, as as a sort of therapy, just like the books work for me, I'm like, that's great. Right? Why not?

Challenges & Complexities of Building Platforms

James Lewis: One of the things I find interesting about the book is the classification of the different types of platform. You get the kind of base platform, which I know you've been working with for a few years now with your current employer, AWS. And then, you know, you talk a bit about what they're trying to solve with that, with the undifferentiated heavy lifting. But I mean, yes, we can be cynical about the world of IT and corporate IT. But actually, when you chunk up a level to the sort of platform most organizations are looking to build, there's still a lot of undifferentiated heavy lifting.

Gregor Hohpe: Yes. It's always a sliding scale. And this touches on one of the key things of why it's hard to build platforms. You want to hide certain things, right, because that's the way the complexity goes down. But the question is sort of how much can you hide and how much should you actually hide? And you might know...one of my many sort of clever slogans is that you should build abstractions , but you shouldn't build illusions. So the danger is that you have this fantastic platform that makes everything oh so easy. Like, all I need to do is put a few parameters in, and here's my application sort of done fully automatically. But the question is, did the thing make a lot of decisions for me that come back later to haunt me? Like, maybe this is expensive when it scales or it's slow in other regions because it didn't know it's a global tool. But other people make a tool that doesn't have to be global. So maybe they don't want it to be distributed. So it might make decisions for you that you're not even aware of. And that is tricky. Well, it's dangerous in many ways. Because if you're not even aware that the choice is there, then when anything happens, you're really out of luck to try to fix it. Because something defines something for you that you didn't even know existed. Now, trying to fix that or debug that is extremely hard. The worst example of this is sort of the Boeing 737 Max. This was MCAS, I think, the system that automatically corrected the pitch, also known as like auto nose diver. And pilots didn't even know there's a thing that can make your airplane automatically nose dive without you doing anything.

And then luckily we don't have those situations in software. But in the end, the effect is roughly similar. You don't even know where to start looking. So that's why the base platforms have done a great job. I want things in this availability zone and that availability zone, cross region, cross account. It's all easy to do. But it also brings or either retains other complexity or in some cases, brings new complexity. Because I have new design decisions or design trade offs to make sort of... The simplest example. And I come back to it's all your fault kind of thing. When I had a monolith, I didn't have to deal with physical distribution. There was not a decision I needed to make. Like, the granularity. I didn't need to decide the locality. I didn't need to decide sync versus async. There was a lot of things that I just didn't... They weren't up for grabs. Now, it's great to have that flexibility because operationally, that's really cool, life cycle agility, la, la, la. But now I have all these decisions to make and people say, oh, that's difficult, I have all these decisions to make. And now the platforms or the Gen AI, to some extent, says, oh, don't worry, I'll make those decisions for you. But to me, that's not going back to the simpler version. You're sort of living in a tricky twilight zone of, the decisions are being made, but not by you. That can go well, but that can also not go well. And I think that's what we're feeling out collectively. Both with Gen AI and with platforms, we're feeling out like, okay, where is a reasonable balance in this thing?

Abstractions & Innovation's Role in Platform Strategy

James Lewis: It's interesting. I mean, I see parallels there with, for example, there's a lot of new tooling around or new frameworks that will promise to hide the complexity of microservice architectures from you. And I don't mean that... Because again, there's two different approaches to this. You can go, and you talk a bit in the book about, you know, using, for example, control planes or using service meshes with side cars. And that's one approach to solving that problem. Which doesn't have the complexity, it acknowledges it's there, but solves some real problems that you have in the software and the services. And then you've got these auto magical, hey, we'll just take your thing and pretend it's a monolith. But actually, it's running on lots of different computers. I mean, at that point, you're starting to get into the same problem, I think, that you describe in that.

Gregor Hohpe: A little while ago, I chatted with a mutual friend of mine named Dave Farley. We know that Dave likes the grumpy take. And he said, "Oh, this platform, Boloxy or whatever it is, like, didn't operating systems all do that?" And I said, "Yes, operating systems are a great example where we've largely gotten it right." How many times when you read or write a file, do you say, no, I really want to have transparency into how big my disk sectors are, and where they're located, and in which order. That happens one out of a million times. And the other 999,000, you're happy to take the abstraction . Network, the ratio is slightly different. Maybe if you're high frequency trading, high performance, right. Maybe there's one percent of people who want to know the size of the packet and the congestion on the network. And for the other folks, the illusion, basically, the abstraction, works fine. So we have examples where this works well. But the question you ask, like, that debate we have all the time. I am very much in the camp of exposing things, but making them easier to grasp. So I find the overabstracting, the like, hey, this thing, just just believe it's a monolith even though it isn't. I find that dangerous because when I look at the entire lifecycle, you know, that is nice while you're building it.

And let's be honest, a lot of AI demos are building stuff. Just like, hey, make me this app. A lot of no code, low code is building new things. Make this thing, right. But then the reality in large scale software delivery is, well, once the thing is built, there's new requirements, the developers leave, other ones come in, maintenance. Like, we know how the story goes. And that's where I'm afraid that over abstracting in the end comes back to haunt you. That's why I am mostly in the camp, can we expose it, like you said. A service mesh doesn't pretend the thing isn't distributed. Can we tell people, yeah, that is the fundamental model. But I give you more tooling, I give you validation to make it easier to deal with the model. So I'm very much in that corner with my personal opinion.

James Lewis: I mean, there's that side of the illusion abstraction thing. But then there's also... Again, you talk to this in the book, which is something I've seen a lot of. Which is this: almost you build it and they'll come approach, which is trying to solve all the problems that you have. It's a bit like in the old days. Hey, we'll build you a service oriented architecture, you know, 15 years ago. You'd go away for five years and come back and go, hey, this is what it should look like. It's a bit like that with the same approach to platforms. So I think you emphasize this idea of... And I think it's to do with the pyramid you described, where you've got the configuration at the top of the pyramid. And if you're trying to provide that sort of platform to people, what you're actually trying to do is solve every single imaginable problem, which is impossible. Right?

Gregor Hohpe: I tried very much to put more diagrams in the book because I know people find them useful. And I've written before on "The Architect Elevator." It made fun out of pyramids, right. And finally, I was able to go to Egypt like two months back. So I was able to see the original, but I've never been there. But basically we say like, pyramids, we look at magical things from the distant past, plus in our IT architecture documents. So that's the two places you find pyramids. So I've always been a little bit wondering like how can this be? And the idea has always been that economically, it seems very appealing to have this broad base, these undifferentiated things that you mentioned. And then sort of the higher up you get, the smaller the piece is. And then you put the cherry on the cake and sort of that solves all your problems. And the low code, no code are very much after that sort of rhetoric. To say, hey, instead of the operating system pyramid or the cloud slice of the pyramid, we put more slices on top, so the little tip gets smaller.

Now, that can work. But the tricky part is it only works if you can anticipate all needs. You need to have known what flavors the cherry comes in, or what shape or size the cherry is. Because otherwise your cake isn't going to hold the cherry. I do have a horrible metaphor for this. But you need to know what's going to go on top. And I find that that is tricky. I mean, tricky being a euphemism for like bad idea. It's like how can you anticipate everybody's needs. Or to ask maybe the other way, why would you even want to? Because if you want innovation, you shouldn't anticipate everybody's needs. They should do things that you didn't think of because that's the very notion of innovation. So, what I find a lot of people doing and I see this repeatedly, when we look at new approaches like platforms. And this could be microservices, this could be SOA, it could be anything. We fall in love with the benefits, saying, oh, this thing will let you do X, Y, Z. It's resilient, faster velocity. We're very good at enumerating the promised benefits, but we're very bad at describing the essence of, what is this thing? Like, if I make a layer, I draw a thing in my diagram. When is that a platform? And when is that just a layer? Or when is this infrastructure? Or when is this something else? Whatever the name. We're very, very bad at this. So what I'm trying to do in... And I've seen this even when people want to define platforms, right, they look at the benefit... Oh, a platform is something that provides capabilities at low friction for business benefit. I'm like, I like that. That tells me sort of what you should get, but it doesn't define what it is.

James Lewis: Or kind of how it is as well. Which is at the heart...and as you point out in the book, is at the heart of actually having a workable strategy. It's not enough to have a vision statement. You actually have to tie that to how that's going to be executed. And you've got quite a nice framework in the book to talk to that. Haven't you?

Gregor Hohpe: Great.. So it doesn't help you to sort of use the word and then anticipate all the benefits. Like behind the word is, you need to understand what are the core characteristics of this thing that make it do what you're after, but also what else you inherit, like the problems you inherit. So the tips I'm trying to give people, the advice is, give them simple tests. So I don't try to have these all encompassing definitions, but I have more of a checkpoint. And one of the definitions or one of the checkpoints I have is like, you should not try to anticipate all use cases. If the thing that you build, you believe like, hey, look, I thought this all through for you, so now you don't need to do much on top. That is exactly the pyramid. And that is exactly what platforms do not want to be. So that is part of this framework I'm trying to give people to have a reality check, because we know one other hobby in IT is to rename existing things. People say, do we have a platform? And then we look through our big IT landscape diagram and we find a horizontal box and like, oh, good, there it is. And then we take the eraser and put a platform over it. Like, yes, we have one. We know it happens. And in the end, though, then we're shockingly surprised that like, nine months later, the benefits weren't realized. Well, shockingly. So that's why I'm trying to give people this mental framework of, here are some checkpoints. Another one I said before is, platforms don't do things for you, they make it easier for you to do things. Like, there is another half of the platform, like, somebody who actually builds on the platform and doesn't just put the cherry on top, but actually builds something with it. And if you believe the platform is something that does everything for you, then you've fallen back into the pyramid model. And I find that these nuances help people sort of get over the hurdle of, okay, I know I wanted a platform because I like the benefits. But now I understand better. Like, how do I even know I made one?

James Lewis: I suppose you can dive into all sorts of how you go about doing it. One of the things I really liked that Adrian Cockroft, you know, ex Netflix and former colleague of yours, used to say is, my job at Netflix was to go around finding all the cool stuff that people were doing and then turn it into a tooling that everyone else could use. You know, or help them turn it into a tooling everyone else can use. This is an approach I've taken with some of our clients at ThoughtWorks as well. Which is, hey, you know, don't just try and build the thing for everyone. Go and look and see what people are doing. Actually get out there and sit with development teams. What are they doing? How have they solved these particular problems? Whether it's developer platforms we've build and run, or whether it's observability, whatever. Can you comment a bit on that? Is that a valid approach, do you think?

Gregor Hohpe: Well, I think a lot of the thought leaders we respect, so we're both good friends of Martin, right? And Martin Fowler has said many times a lot of his good ideas come out of hanging out with the teams, right? Observing what people actually do. So the answer is, yes, I consider that a very valid approach. There's always a nuance on top of it, right? So what I find is, and I don't want this at all to sound kind of like elevating in any way, but my favorite scenario is, I look at what people have done, and I help them understand what they have actually done. So they've built something very ingenious that maybe I could not have even have built. But when I look at this thing, I'm like, oh, this is like this, or it has this property. And then they go, oh, we haven't thought about it this way, right? They hadn't realized really where the movie sort of was playing forward to. And to me, those are the happiest moments because both sides bring value, right? They built something amazing for their local problem. But as a third party, you can come in, do maybe a little bit of abstraction and say, well, your local problem is that kind of problem. So what you've built here has maybe broader applicability or can be explained in different terms. And to me, that is sort of the happiest moment. And that's where I think a lot of so-called thought leadership actually really takes place.

James Lewis: Maybe on that point, maybe this is blowing smoke up the proverbial, in some senses. But I mean, one thing that I'm often amazed by when I read your writing or listen to you speak is your use of metaphor. And so I mean, I could think of the architect elevator as a fantastic metaphor. There's a lot of great metaphors you use in platform strategies. You talk about the automobile industry. Where do these things come from? Do they just suddenly appear fully formed in your head? Because it's pretty amazing.

Gregor Hohpe: Kind of, sort of. So hence my sort of therapy joke. My head is full of random stuff from the "Matrix" movies to cars. So I think people learn a lot about my personal life from reading my books. So I think there's two parts of it.The one thing is, for me, it took a long time to notice that these weren't just silly jokes, but they actually help people think things through. And I sort of made it a tiny bit of branding. Yes, there's a car analogy for pretty much everything. So it took me actually a surprisingly long time to reflect on it and say, hey, that is actually maybe a strength that I might have or like a good tool that I have in my toolbox. Because what metaphors can do is they can help people think with you, but in a parallel domain. If you say this is like that, and that is familiar to them, then you can think along. Versus what we do too many times... I always remind people, if you go to executives and say, hey, we need to automate our Kubernetes clusters, and we need a service mesh, and whatever it might be. What they're hearing is basically, trust me, give me money and trust me. Like, they have no idea. So the metaphors help them say, oh, this is like X, Y, Z. And then they can think this through with you. And basically, at the end, come to the similar conclusion, in the two worlds, right, the world of the metaphor and the world of the IT stuff we have. And I like that very much because it builds transparency. Because quite honestly, a lot of people like this trust me thing. Oh, just trust me. Like, you know, don't ask too many questions, everything will be fine. And if it's fine, people are probably okay. And they'll never know why it was fine. I'm not a big fan of that. So I'm a big fan of building this transparency. And it takes a lot of the intimidation out of this, like, the jargon. So yeah, over time, I've realized that this is a useful tool. And maybe the random background threats that are running all the time now have a better funnel to sort of come out at the appropriate point in time.

James Lewis: What I find remarkable is how sticky some of these are, right? Because you can find metaphors that sound superficially like they're going to work. But then when you push them, they don't. And then you end up sort of going, oh, no, actually, that doesn't make any sense at all. But then, you know, I've heard you time and time again say things like, right, I'm gonna come down into the engine room. And people... You know, this is when I'm listening to your talks. And people know instinctively what you mean by that, you're coming down levels of abstraction to start talking about, hey, I'm going to implement the service mesh, whatever the language, whatever the code base. And similarly, as you travel up, you know, it's sort of instinct that people can instinctively understand. Similarly, with the car metaphor, which runs throughout the book, you know, which I found very, very powerful. It's a really sticky metaphor. It doesn't break when you put it under pressure, which is a really sticky metaphor, I think.

Gregor Hohpe: Correct. And that's sort of the big difference, I would say, between a simple analogy and a real metaphor, right? The metaphor, as I said, you can think along in the two worlds. And the automotive one, I used the term platform actually. So in this case, the translation works well. But you can make very strong points that then stick to people. Like, for example, when the automotive manufacturers started building platforms, their goal was not to reduce diversity of the car models, their goal was to increase diversity. They wanted to make more different models for more different buyers and slices. And the economics just wouldn't work out. And, you know, Volkswagen, BMW are great examples. And I've actually attended talks by folks who helped shape those. The classic example is, Volkswagen is bigger. So BMW is easier to remember the numbers. They used to have three models, a three series, a five series, and a seven series, right? Now they have like 30, right? And Volkswagen Group has like...with all the subsidiaries, like 50 or more, right? That they could not do without a platform underneath because it's economically not doable to have like 30 passenger car models.

James Lewis: ...as well, right? So I'm just talking to you a little bit, but I couldn't have imagined doing because... And that's the other key thing about, you know, are people innovating? Can people do things on the platform that surprise you? And that's what they're doing with this, isn't it?

Gregor Hohpe: Correct. So this is exactly right now we're having fun with the metaphor, right? So basically, this is exactly what they did. You removed a constraint for them, right? Basically, the cost of making a new model went down, because it could be on a similar platform. So basically, the latent innovation, like, things that people wanted to do, but they never actually got to the conceptual stage, because it was economically not viable. Removing that constraint now makes these things possible, right? And that is really fun to talk about these metaphors. And then people like, if you bring it back into the IT world, they catch themselves as saying, oh, yeah, our platform, we don't want developers to go too far left and right, we want more governance, right? And then they're saying basically, they catch themselves that they want the platform to really restrict. But in reality, the platform should actually subtitle the book, innovation through harmonization, you want my innovation. And that's where these metaphors are very powerful.

Platform Innovation & the Flywheel Effect

James Lewis: Maybe I'll come on to the mapping bit in a second. But I mean, it drives it both ways as well, right? So it drives innovation on the top. I mean, it drives the hats to be more innovative, if you like, or whatever they're called. But it also drives, I think, again, this is... You talk about how it actually drives innovation in the platform itself. You know, so the widgets, in fact, that make up the platform, they also are...you also are able to innovate and diversify your ability to plug these things in if you've got this standard interface into the platform, both sides. And that's this flywheel thing going on.

Gregor Hohpe: Correct. And the cloud platforms, right, the base platforms in the book are able to repeat that, right? Basically, I always say, the giant data centers, the globally distributed transactional databases, those kinds of things are only economically viable because they have the scale, right? They don't do this per application, you know, we do this across slides. So you have base innovation underneath that otherwise would not be viable, right? You read some of the AWS papers or the Google papers, right? The engineering that's behind there is amazing. Nobody who runs their own data center can even think about doing that. So it drives innovation in the base layer, but it also drives innovation at the top. And that's really the magic. There's one small difference between the cars and the clouds there. And that is, as a user of that innovation, in the car, that complexity is largely shielded from you. Basically, the car manufacturer is both the platform maker and the user of the platform. So by the time you get the car, it's like three pedals and a round thing, right? So that has been like this for 100 years. So it's all good. Or two pedals for the American colleagues. Or the EV adopters. So basically, that hasn't changed amazingly, through all these technologies, right? The EV is still like two pedals and a wheel, right? But in the cloud platform, right, there's a lot more, the platform and the user of the platform are two different parties. Right? And that's why we see a lot more discussion there. Like, one of my more popular articles, I have to be careful, maybe a little bit self critical, but I like that, was, did serverless just shift the complexity from one place to another? Because all this operational stuff goes away. Perfect. But now I have asynchronous distributed things, I need flow control, I have dead letter queues, I have queues that fill up, I have restarts, cold start times, right?

And the irony might be that hiring the people who can solve all those problems might be harder to find than the people who can manage a server. So you traded, you got rid of one class of problems that was maybe well understood and easy to hire for. And the danger or the rhetorical question is, did you amplify another class of problems that is actually harder to find the skill set? And I think that is a difference between the base cloud based platforms and the automotive manufacturers. But again, the metaphor makes that easy for you to talk about. And I have learned over time, this works really well. And I should probably add, often they come out of conversations. Like, when I talk to smart people, and you know you have to explain things well, right? Because they'll catch you immediately if you make something up. So you're looking for ways. So I had a recent conversation where a good old friend of mine made the statement and it was again about platforms. And he said, "Well, it's undifferentiated heavy lifting. So it's like a power station, right? When you have a business, you don't make your own power station." And I said, "Hold on, these days, everybody makes their own power station, because we all have solar panels on the roof." Especially in Asia, right? And this was my uncontrollable background threat we mentioned before, just spotting this out. And, hold on, that is actually no longer true. And that triggered a very deep discussion around Wardley maps, componentization, commoditization, shifting constraints of architecture. Because how is it that making your own power used to be ludicrous, and now it's actually totally doable and fantastic. And we all want to do it. Like, what really happened? So conversations are a great way for these metaphors to really come to life.

Practical Advice for CIOs

James Lewis: Obviously, we've talked a little bit about sort of, I guess, more philosophical topics. I guess we should maybe touch on practicalities a little bit. So I mean, if you were thinking about, hey, I'm the CIO, I have read about building platforms in Computer Weekly. Where should I start, do you think?

Gregor Hohpe: Well, there's always something, and this is easy advice to give and hard advice to follow, right? It's always, you need to have a clear idea of what you want. Sounds trivial, right? But what are you really after? You're not after a platform, right? You're also quite honestly not after harmonization, right? These are all tools that are supposed to get you somewhere. We suffer a bit of this, like, we make the proxy goals the real goals, right? Oh, we need to standardize everything. Oh, I do need to standardize. And we sort of assume that it's already decided that standardizing is better somehow, so we don't need to argue what it's actually for. So, I see a lot of traps right there.. And of course, the opposite is also dangerous, right? If as a CIO, you say, oh, please make me platforms, and I want to shrink my IT cost by 30%. And improve the release cycle by 50%. And I have absolutely no idea where these numbers come from, right? Equally dangerous. So you need to know what you're after, but then understand the translation of that sort of into the mechanism. Like, what exactly is going to make that? Like, is it that I can make it easier for my developers to onboard to the cloud, right? Can I make debugging cycles shorter? Can everybody in my company use the same CICD pipeline? Is that maybe a way of standardization that I don't need to reinvent all the time? But in return, I get more innovation as opposed to less, right? I find that... And if it sounds a lot like architect elevator, A, I'm biased, and B, yes, it's true. But, you know, thinking through between what I'm really after and understanding the mechanisms that I think will get me there sounds easy, but it's incredibly hard. And if it goes off the rails there, like nothing else will save you. So that would be my first round of advice.

Dimensionality & Constraints

James Lewis: You mentioned standardization, right, as a cool thing. And again, there's a bit of a theme. But then coming back to the innovation subtitle, one of the really powerful tools I found in this book and in other writings of yours, is this idea of dimensionality. Or rather, the tendency that we have to treat things is a simple choice between one thing or another, maybe not a binary choice. Maybe there's like a slider between innovation and standardization, say. But actually, that's not the case, right? And actually, what we could do is add additional dimensionality, which gives us additional insight into the direction that we might want to take. So, innovation versus standardization on a 2D plane would be the top.

Gregor Hohpe: Yes, very, very important point, right? Basically, a lot of these innovations... And let me say this, like, a lot of us IT folk, we're sort of closet system thinkers, right? We all follow the goal and Goldratt. This is all the stuff we love. So a lot of this thinking comes through. And here's really... You hit on the essence of this. So let's say this platform thing is somehow new and can do something that you couldn't do before. Like, make yourself delivery faster, easier, give you innovation, despite harmonization. Now you should think about, how come? Like, were we just not smart enough in the past to like to do this? Or does the thing actually loosen up a constraint? Like, was there a constraint that we used to have that is now longer in place? Like we said with the car manufacturers, making a model used to be really expensive. Or the cloud, getting a server used to take a really long time. So, what I find or vice versa, what I advise is, be very clear on these. Like, make sure you understand these constraints that go away because they have exactly the effect that you mentioned, right? Like, a constraint makes us think in one dimension, right? You have these debates, my favorite example, people say, hey, we need to compress the schedule. And somebody else says, oh, but we can't compromise quality.

So behind that... And they can go until the cows come home, right? And behind that conversation is a one dimensional view that, you know, more time leads to better results. So if you cut time, you also cut quality, right? And I have... One of my many clever slogans is, architects aren't smarter than other people, but they make other people smarter. So the way you make these two people smarter is say, hey, listen, your whole conversation is based on one dimensionality. You think sort of quality and time are locked, it's one or the other, quick and dirty, right? Or slow and good. And if I can tell you that that is not what the world looks like, you can have an entirely different conversation. And you and I know where that goes, that's automated testing, shift left, test early, smaller cycles. We all know this. The thing to be careful about is, when you take a constraint out of something that's been in there forever so long, people's worldview kind of crumbles. And they don't want it to... As amazing as it is, they somehow don't want it to be true, because they can't imagine a world where it's actually true, right? Because your whole job has been... Like, you're a project manager, your whole job has been to balance that constraint. No, that's not really a constraint and your head sort of explodes, right? So even though you love the idea, it's like, oh, all the pain that can go away. Isn't this amazing, right? Still, your head kind of explodes.

This is a little bit what I said earlier, people have built something, but don't entirely realize what they have built. Like, this constraint going away takes a moment for you and the team to say, like, oh, you know, let's actually internalize this. I did this...a long time ago. I did a workshop here in Singapore with an insurance company, and they wanted an interactive workshop with insurance leaders. And I was like, well, that's going to be... Oh, they wanted some sort of workshop. And I'm like, oh, that looks really boring. I can fix that. Because I believe insurance is not at all boring. Basically, I gave them what if scenarios. And the what if scenarios were essentially taking constraints away. I said, what if your lifetime policy cost, like, to service somebody's policy is one penny, right? It costs you one penny, right? Just for argument's sake. How would your business change? Because I take that constraint away. Or if your business was 100x scalable, like your IT would just like 100x, no problem, whatever, right? And then I would play this back to them and say, now that we assume this constraint is gone, what can you do with the business? It was a super fun exercise because they looked at this and like, damn, we never thought about it really this way. And it's just like, they knew... I mean, super smart, successful people, so they knew that this was a really fun maneuver. But they also caught themselves getting stuck in the... They realized how hard it was for them to reach escape velocity on taking this constraint out. And that was really fun to watch them catching themselves falling back into the old constraint that we had actually just taken away.

James Lewis: I mean, by the way, I'm just gonna borrow that. Thank you very much. Write that down. Thanks for that workshop. But it really reminds me of... You mentioned Goldratt's thinking and so on. You mentioned two things that remind me of some of his work. So the first is this idea that the hardest shift is a paradigm shift, right? It's to change people's minds, to flip people's minds to a new paradigm is the hardest thing for people to do. And then the other thing is this idea of, I think it was in "Beyond the Goal," he talked about the four questions that organizations should ask themselves if a new technology appears. And they always ask the first three, but never the fourth. And the first three, I think, what's the power of the new thing? What limitations will it help us overcome? Then they say, you know, the third question is, okay, what rules do we have to manage the existing limitations, constraints, you're talking about? What do we have in place that we have to have to manage those constraints? He says most organizations stop there and forget to ask the last question, which is, what new rules, right? What are the new constraints? How can we really truly take advantage without being stuck in the past? And I think there's a lot to be said there with traditional organizations adopting platform thinking as well.

Gregor Hohpe: Oh, they absolutely are. And again, this can play at many different levels, right? We mentioned the serverless and the cloud example, right? Where it's like, I made a lot of things go away. And, you know, this leads to two things. A, right, the paradigm shift, like some constraints are gone now. And it's very hard for people to actually make that leap. And then yes, what are the new things, you know, that come with it? So I have a much simplified version of Goldratt. I always say, you know, what problems does it solve? What problems stay? And what new problems come with this new... Which is like sort of the true realized version. But yeah, absolutely. I think a lot of the platform movement that we're seeing now came out of that, where I said, hey, all this cloud stuff, all this new distributed, all that stuff is fantastic. But question number four, what are the new constraints, for example, mental constraints, like, just like, how much can we juggle in our brains, that has bubbled up. And that took like a decade, kind of sort of, right? Not everything is so fast in IT. The buzzwords always move faster than reality. So that took like a decade. And I think in fact, right, that is a driver for a lot of the internal... You know, what we're talking about now is platform engineering, in house platforms, where people say, can I absorb that for my organization?

And in some way, I tell people, yes, you're better equipped to solve that than the cloud providers. Because you have a smaller universe, you can make more assumptions, you can do things. And I give people that advice. Put things in the platform that the cloud provider per definition could not do. And people kind of, well, they have more money and they're bigger and smarter than us. Like, how could I do something that they can't do? And I said, well, you can, for example, make a database that is called, this is a database that contains customer data. And that is a database that does not contain customer data. And that's very contextual for you. You might be a bank, you might not be, you might be in the UK, you might be in the EU, bad joke there. But you might be doing different things, right? So the cloud provider can give you the dials to configure this, but they can't give you that database. Right? And, yeah, I work for the public sector, right? We have a database that stores top secret confidential kinds of things. And that was our classification. So, the cloud provider could not make that for us. And that's a good test. So yes, you can do things that they fundamentally cannot do, but it also means your platform should focus on those. Don't try to make a better container runtime or something. I think the odds are going to be pretty slim that you're going to come up with something technically superior or come back to the constraints that you want to remove. Like, you make decisions for people that they didn't know you made, bad ideas.

So where you should really put the attention is, your domain, like, your world. Right? What are things... Like, customer data that I have. Or things that are important to me as a business. And those concepts have to come in for people to build a meaningful platform in my point of view. Now, sadly, this hits on one of the sort of IT problems we've had for like, at least as old as the two of us are, which is, wow, we need to talk to the business. Damn. Like, we need to understand our business domain. Oh, how painful is that?. So that comes right down the pipe right here. If you don't understand your domain, my advice would be don't build an internal platform. It would be so tempting to do some infrastructure CI/CD kind of cute things. You can do a lot of stuff and that would be good for like the very first part. And then quickly you realize you given the developers like... I call it the the 70% cloud, right? They get sort of AWS, or GCP, or Azure, but you've taken some settings away. And then you're surprised why they're not so excited about that, right? Because they want the other 30% or 40%. So basically that will run out of steam very, very quickly. So you need to give them something that the base platform guys fundamentally cannot. And that would be, you asked earlier, right? Where do you start with this platform story? For me, that would be very important step two. Like, if that question doesn't have sort of a easy...I would almost say easy, but a sort of indicative, like, a clear answer to it, it might not come easily. But once the answer is there, it should make sense to people, right? So if that doesn't have sort of a clear answer, I would say you want to look right there. You want to rethink that step before you go further down the line. Because I've seen that not have a happy end.

What Was Left Out and What’s Next?

James Lewis: Thank you. I mean, there's so much in this book. As I say, it's been a great read for me. And as I say, I've been working in this world for quite a long time. You know, I remember when AWS first started talking about undifferentiated heavy lifting and cloud as a utility. And they used to show the slides of the power station, you know, from the sort of 1800s and the power station today, where every brewer I think used to have a power station. So as I say, I find it incredibly insightful. We haven't even the time to cover a lot of the super interesting bits of it. There's a whole set of patterns, which I found, again, were great descriptions of absolutely common problems I see out in the wild. You know, just to name a couple, you got the fruit salad or fruit bowl. That's a fantastic part as well. Or the grip wrapper, again, nicely named. But these are all real things you see time and time again in the real world. I mean, I guess coming to the end of this interview, Gregor, I guess one question would be, you know, is there anything...there's so much in there, is there anything you felt you had to leave out or wished you could have included?

Gregor Hohpe: Always a painful question. So one thing is, luckily, I self-publish, and for a reason, because, you know, we're software people, we love incremental releases. So why should books be frozen in time? So I have the luxury actually. So I was writing a chapter just now that I will add on visualizing a platform. I found it very difficult or I observed that it's difficult for people once they built a platform. And let's say it's all great, right? But even communicating that to your internal teams, what does the plan... Like, coming back to the Goldratt questions, right? Like, what constraint does this remove? What do you have to do to harvest those constraints, right? That is not easy. I would say the cloud providers probably have a decade under their belt getting better at that.  But internally, it's not much easier. So that is a chapter that I am adding. I would like to add something on platform economics also, right? Because internal economics have to be worse than the cloud provider economics. The universe is just not as big. On the other hand, you're building on top of something else. So you have a much better starting point. So those would be some topics that would be quite interesting to me. The platform topic, really, but it's already at 350 pages. So a little bit of scope control. But I think it touches on many facets, really. So, yeah, visualization and economic aspects probably would be sort of top of my list.

James Lewis: I think economics, I'm looking forward to that. Because, you know, again, we're in a very different world than we were three or four years ago, right? And people are asking very different questions about the value of a lot of the things that we're doing in big organizations and big IT. And, you know, the questions around, you know, should we carry on building products? Or should we, you know, these long live products, and have teams that are running constantly, building these things, versus are we moving back to project thinking? So, I mean, I'm personally going to be super excited to see that. So thank you very much. What's next?

Gregor Hohpe: So you mentioned right at the beginning, this is part of a series, right? So "The Architect Elevator," and, you know, just if any listeners are curious, like architectelevator.com is where they find all these kinds of things. So the way it was imagined was that the architect elevator was a different way of thinking, right? Looking at things, different levels, heavy on metaphors, heavy on decision discipline, influenced by system thinking, but not overly academic. So that's all baked into that. And then my plan was to apply this to different domains, right? So the first one was the cloud. Second one was platforms. Now, I probably need a little bit of sort of rehab time before I start the next one. But the fingers are itching. And it's been 20 years since Enterprise Integration Patterns. And I see a lot of resurgence of these topics around couplings, event driven architectures, and things like that. So that is most likely going to be the next strategy thing, either called API strategy, or integration strategy, or something along those lines, which, you know, looks between the boxes, right? Look at the lines and also help people, you know, internalize that. Again, goes from high level business strategy, API ecosystems. Like, I do a lot of things with embedded finance in Singapore with the monetary authority. Like, that is all API driven, right? And then of course, this goes all the way down to sync, async, control flow, flow control, queues, retry logic, jitter, and all that kind of stuff, right? That would be maybe a fun book to write. But this one took three years, I think, into it. So everybody, please have a little bit of patience.

James Lewis: So what we're saying is it's going to be another 5 years after the 20 years that we have to wait for the updated version of enterprise integration patterns.

Gregor Hohpe: Probably yes. But the fingers are itching. So I'm tempted to put some more patterns on the website. And so let's see, maybe we'll make a little bit of progress there as well. Or maybe API strategy is sort of the updated version of enterprise integration patterns. I think we have a few things to play with there.

James Lewis: It's funny because I remember talking with you about you were thinking about doing request response patterns, like, so more sync patterns. And then of course, the world shifted again, and everyone's back to async. Everyone's really talking about async again. So it's amazing, like, over the period of even 10 years, how we've moved from predominantly one form of API to another form of API. So I'm personally very excited that you're going to be working on that next. So thank you very much. . Thank you very much for joining us today on the GOTO Book Club. It's been a fascinating hour or so. It's always a pleasure, Gregor. And I hope to see you soon. And as I say, if you can get hold of a copy of Gregor Hohpe's book, it's well worth a read.
Thank you, Gregor.