Simone Cicero

Hello everybody, and welcome back to the Boundaryless Conversations Podcast. On this podcast, we explore the future of business models, organisations, markets and society in our rapidly changing world. Today, I’m joined by my usual co-host, Shruthi Prakash. Hello Shruthi.

 

Shruthi Prakash

Hello everybody.

 

Simone Cicero

It’s good to have you. And we have an extremely eminent guest today who is joining our podcast, Gregor Hope. And Gregor is widely regarded as one of the leading thinkers and at the intersection, let’s say, between enterprise architecture, organizational design, large-scale technology transformations. He’s the author of many books, Software Architect Elevator, co-author of Enterprise Integration Patterns, and among other influential works that have shaped how distributed systems, services, integration are designed. He is also the author of his latest book, Platform Strategy, that we really enjoyed.

 

Hello, Gregor, it’s a pleasure to have you with us today. We are super excited to have you.

 

Gregor 

Likewise, look forward to the chat. Thank you.

 

Simone Cicero 

Thank you so much. 

So over your career, you held some really senior architectural role and you advise so many companies to some of the most impactful technology organizations. You know, working with Alliance, then Google, and more recently also Amazon, but also advising some public sector modernization efforts, including for example, Monetary Authority of Singapore, if I’m not wrong, with the Country Central Bank. 

 

So in the preparation of the conversation, I think we had this interesting chat. You kind of told me that the discussion about the separation between business and technology is a bit at the same time an old, but also always relevant topic.

 

Sometimes I feel like the conversation we are having on tech as an enabler for business is sometimes there is this nuance where you see the technology side of organizations that tries to cling on to being relevant in a world where ironically technology-driven forces are making technology less relevant, more mature, more embedded in the background.

 

But then, when I work with product organisations, which have maybe portfolios of products, even if they are scale-ups, they seem very agile, they end up with the same problem. So they end up with orchestration problems, scalability problems, and performance problems. 

 

So maybe as an opening question for you is, how is this conversation really going? Is it still really relevant to talk about technology and business relationships?

 

Gregor

Yeah, and I think in some funny way, the opening question could also be the closing question because it’s a long topic. It’s a big topic. So let me maybe give some of my experience with it, having worked both Silicon Valley, large enterprises and the public sector. My gold standard is always when I did work at Google, I was an engineer, and I was the business. 

 

So I always joked that in a decade in Silicon Valley, nobody ever said “We need to talk to the business”. The concept just didn’t exist. I was the business. My goal was an annual run rate improvement monetary goal. I was making mobile ads. So we measure what’s the run rate that we generate. And actually, for us, that was a lot of fun because we could track the business impact immediately. Kind of it was also good for the team because with five people, we were able to generate quite a significant revenue uptick.

 

And that made us happy and that made it easy to reward us for our work. Now that is the one extreme. And I enjoyed that. Now in large organizations, it tends to be quite different. But actually, we need to be careful when we see large organizations because Google and Amazon and Meta and what they are called are not exactly small.

 

We often make the mistake of thinking they’re small and young, and the other ones are old and large. It’s not quite true. Google is 30 years old. Microsoft is over half a century old. So I think in the end, it’s not a matter of sort of growing up where you start one way in the end of the other. But I think it’s a fundamentally different attitude. 

 

I would add the following: which I would say in the past where the technology was more stable like the old jokes, you you just buy an IBM mainframe and you’re largely done. I think this separation kind of worked, it wasn’t as bad and that’s how organizations got used to it. Because in the end, if people can put a little bit of boundaries around what they do, which is ironic because podcasts is called boundaryless. I’m a big fan of not having the boundaries, but a lot of folks have, like having boundaries, right, allows you to focus, and it also gives you some differentiation. Other people don’t do what you do. 

 

So I think human nature to some extent is to fall back into some sort of division of labor, into some sort of boundaries. And in the past that worked okay because, the technology choices you made didn’t really define what kind of business you could have. Your bank, you’re still a bank. You buy a bigger mainframe, you can have maybe more customers. Now, technology defines what business you can or cannot do. So I think the downsides of the separation have become much more pronounced. And many of my customers are sort of, well, let’s say finding this out the hard way.

 

Simone Cicero

Yes, I mean, totally. I think one interesting thing that you said for me is that you said it’s not matter of size, but attitude, right? And maybe as a second kind of question that may be helpful to connect, tie this back to the question of architecture, because when we say attitude, what do we mean, right? 

 

So typically, as you grow, you can grow as a as a siloed organization, as a hierarchy, or you can grow in a distributed manner. So the attitude often translates into the architecture. So how is the question regarding technology and business being translated into how you, let’s say, what are your choices in developing the organization, which is the third topic.

 

So when we speak about a company, there’s product side, the business, there is a technology side, and then there’s an organization side. So what is your experience of what are some starting points to start looking at this picture from these three perspectives?

 

Gregor

Yeah, so for me, maybe picking up on the architecture part first. About the worst thing you can do is making architecture another silo. Now you have three, right? That would be the worst case yet. I’m sure you see it also where you’re on the businesses over here, technologies over there, then architecture is floating somewhere in space, drawing pictures, and making five-year roadmaps that in the end nobody reads and that will never come true. 

 

So my point of view is that if you have a third element in the mix, and I think having architecture is quite valuable, the role of that third element has to be to connect the other two. Because coming back to what we said, people like the silos. The last thing we want to do is reinforce that attitude, and it happens easily. Let’s be honest, right? A lot of techie folks like to speak what we call techno babble, right? And that definitely doesn’t help with breaking down the silos. And then what the business likes to do is: “well, I don’t care about technology, just implement my grand vision”. I got a comment like that very recently. I’m like, well, if for somebody to just push us, we don’t really need a top executive, to be blunt. We can put a poster on the wall which says, hey,

 

Please deliver fast and cheap. So both of those, to me, are forms of dysfunction. So I think that architecture, in my point of view, can really add value by building a better bridge between the other two. Now, that might mean, hey, if we actually manage to connect the two elements, we wouldn’t need much architecture anymore.

 

And to be honest, I’ll be quite fine with that because I’ll have a million other things to do. Still, I don’t see that happening any time soon. So I’ll see architecture as the linking element between the business and IT. And I find that linkage to be much more relevant than it was in the past.

 

Simone Cicero 

So let’s say that architecture creates the bridge or the language to get these pieces together. Is it that technology is just there to support the business? So essentially, we have a business vision. It’s distributed. We have, for example, portfolio of of experiences that we want to make for the customers. And then we have a problem of having a supporting technology that ensures performance can be sustainable and replicable that ensures that what we want to do, we can do. 

 

And so the impression that I have from this conversation is, since we need technology to do what we do, then we create some kind of layer where technology can plug in and deliver what we need. Or is it that technology still, or information technology still have a massive importance. 

 

And when I’m thinking about this, I’m thinking about typically what I see in organizations I work with that is a pattern that I’m seeing again and again. They seem to to talk to two types of customers. One is the non-technical customers, the end user. It can be in a business company, the companies that use your products, or it can be maybe your end users like in a B2C company. 

 

And on the other side, they talk to third parties that maybe extend their product or coexist with the products or use some versions of their products. So is the technology the piece of the organization that speaks to this part of the ecosystem or is it a different architecture we are looking into?

 

Gregor 

So I have a strong opinion that the relationship between business and IT is a two-way street. Now, many people say IT is there to support the business. And yeah, that is absolutely true. Everything is there to support the business because if you don’t have a business, you don’t have an organization, unless you’re public sector. So don’t forget the public sector. But for me is if you look at innovation, it’s also about leveraging the technical capabilities. It’s a two-way street. When new technology comes around, it allows us to do things that we weren’t able to do before as a business model.

 

Give you my standard example, right? And I’m sure many of your clients have similar ideas of going from a product to a service model. This has a lot to do with ecosystems, platforms, et cetera, a very common thing. A classic example is instead of train engines, we sell passenger kilometers. Or we say, you know, like, Hilti, as an example, what do they really sell? They don’t sell drills, they sell holes. That’s what the customer works. And we all know that this business strategy is great, because for the customer, pay us. You go as a provider, you get more insight, you have more data, you have a closer relationship. So many, many good reasons why that business model is desirable. 

 

Now, the question I always ask is, well, if that business model is so fantastic, why didn’t we do this like 50 years ago or 30 years ago? And the answer is very simple. We largely didn’t have the technical capabilities. If you want to sell holes instead of drills, you need IoT, you need predictive maintenance, you need AI, you need the cloud.

 

So basically those are all the ingredients that make the business model work. Now it’s not like we never thought of this business model, but it’s definitely a two-way street. The organizations who are successful, they have a good feeling for when the technical capabilities sort of reach a certain point where I can do something different on the business side. 

 

And that dialogue to me is extremely valuable. But there’s also a certain set of dysfunctions there. There always is in large organisations. And that is when a new technology comes around, the business goals says, we must do something with this new technology. Gen.ai comes to mind, The cloud used to be, right? Quantum will be next, whatever. Mobile used to be. And they’re like, we need to have a mobile application. We need to have a AI assistant, right? That is not what I mean, right? 

 

This is just like, there’s some piece of technology that we must use somehow because otherwise we feel we have FOMO, right? What I mean is actually understanding how that technology enables different business models, specifically for your busines, and not just sort of ticking a box off, we have a chatbot or an agent or we are in the cloud or we have some sort of mobile app.

 

I believe the organisations that do well are the ones who make the translation in their head and the ones who do less well, they spend a lot of money having lighthouses and prototypes and they make a mobile app that does exactly the same as the website already did but is mobile. So they have a chatbot which is still no good. They end up with all these expensive tech projects that don’t add a lot of value and then they do exactly what they say.

 

They’re like, maybe the tech stuff isn’t that interesting. But to me, that’s the wrong conclusion. The tech stuff is less interesting because you didn’t make the translation to see what the tech stuff can actually do for your business.

 

Shruthi Prakash 

I mean, to sort of take off from what you said as well in terms of, let’s say, transformation innovation. So one of the points that you said earlier from you transition from a time where you were the business to now, let’s say technology being the business. 

 

And in the middle of that, there is also, you mentioned how people like constraints or boundaries and operating in structures that have, you know, been set for them.

 

And similarly, let’s say business also operates from places of, constraints. 

 

So how do you design your architecture to enable transformation while working in these, spaces of constraints and do this also while again, like creating optionality, like Simone also mentioned, let’s say the possibility of a future where there are multi products, things like that. 

 

So when your systems are power structures, et cetera, are relatively older. And then, you know, you’re sort of wrapping these new technologies around it, but that’s obviously not the most helpful direction. How do you do that? How do you enable that sort of a strategic coherence in all of this?

 

Gregor 

I think there’s a lot of points in there. The one I would latch onto is I’m a big fan of the word optionality. You guys might know one of my slogans about architecture is: “architecture is selling options”. And architecture gives you options in the way that it allows you to defer decisions into the future. So people say: “oh, our system must be scalable”. Well, that’s the option to add hardware, capacity or take hardware capacity away. Easy to do in the cloud. You have a scale-out architecture, application load balancer, elastic infrastructure, like all the techie ingredients we know very well. But the option you’re really buying is the option to add or remove capacity. And options are valuable. Well, A, that’s mathematically proven. Black and Scholes got a Nobel Prize in economics for that. So options have value, and it’s easy to understand why.

 

Because if you can defer a decision, you can generally make a better decision. Let’s just stay with the sizing example because it’s simple. I worked at Allianz, I always say we had a very sad team. And the sad team was the hardware sizing team. Like somebody has some idea about some application they’re going to build. And then somebody has to figure out, well, how much hardware capacity do need? And the reason I always say there was a sad team is because you can only be wrong.

 

You either have too much or too little because nobody can predict the future versus if you defer that decision, it becomes trivial. You need more performance. You add capacity. You’re running low traffic. You reduce capacity. So to me, options are a really nice way to express what architecture does. Now, ironically, right? 

 

Options defer decisions. They move decisions into the future versus in many cases, people misunderstand architecture as they’re the ones who make all decisions. So I think there’s both sides of it. Yes, we make some decisions like to use an elastic infrastructure and a load balancer and a scale-out architecture, whatever it may be. But the reason for that making the technical decision is so we can defer the decision of, for example, capacity planning and

sizing. So for me, options and optionality captures what architecture does very well. APIs, extension points, right? Simone mentioned building a third party, building like an ecosystem around your IT assets, right? That has a lot to do with optionality. If somebody wants to add some new module, right, or a new kind of behaviour or plug into what you have, they can actually do that. 

 

Platforms are very much related to this idea. But to me, it’s really you’re buying options. 

 

And last comment on this would be I choose the word “buying” consciously because I would say the architects “sell” options. They don’t “donate” them. They’re not free. Right. And you pay, for example, with complexity. Right. A scale out architecture, one that has APIs and is extensible, is also invariably more complex. 

 

And that might be fine for you because if you can build a giant ecosystem around your business and it flourishes then you’re very happy about this. But sometimes things are not worth the complexity. Like some people come to me and say everything must be loosely coupled. Always. I’m like well that would probably or it must be multi-cloud portable loosely coupled you name it. And I’m like well these are very abstract things – like does my customer benefit by it being multi cloud losing couple something. What’s the real driver here or am I just increasing complexity?

 

So the options are not free. They cost you in effort and they cost you in complexity. And I think finding that balance, the options that you like to have versus the cost of these options, to me that is architecture.

 

That is also something that IT cannot do in a vacuum. That’s the irony. People come to me and say, is this a good architecture or make me a good architecture? I’m like, how would I know without understanding what the business wants to do? Are we going to enter new markets? Are we going to broaden our product portfolio? Are we going to make acquisitions? Are we going to target different customer segments? Are we going to want to cross sell? 

 

I would have a million questions to the business that actually impact my architecture. So I really remind the IT architects that most decisions they make cannot be made in IT in a vacuum because you don’t know the driver. You don’t know what options are worth having and what options are not worth having. And you know exactly what happens if that’s the case.

 

If people don’t know what options are valuable, well, as a good architect, I put all the options. I make a loosey couple, scalable, portable, maintainable. But then the problem is, then the project takes 24 months and cost me 20 million. And then the business sort of wonders, well, why is everything so expensive and takes so long? And my short answer is like, well, because you guys don’t talk to each other. Coming back to my original point, right? You guys don’t talk to each other. So then you make the IT guess.

 

And because the IT wants to do a good job, it guesses on the side of inclusions. We stick all the options in. Yeah, and then we have these 20 million, two-year kind of complex projects that then the business doesn’t like. So the cure, if you wish, in my point of view, is value the options from the business side. Understand there’s a cost against it.

 

agreeing that some options may not be needed, saves you money, saves you time, but you’ve got to have that calibration from both sides of the business. Otherwise, you can’t do architecture.

 

Simone Cicero 

That’s a very interesting bit. For example, optionality and it resonates a lot with the idea of creating a language. So languages are very much ways for you to maintain optionality in a conversation, while at the same time having some sort of trade-off. So for example, a language is something that maybe you can write, you can change. So essentially, if I look at architecture as a way to let’s say reduce the number of decisions you take so that you can keep more options open in the future. 

 

So you really take the important decisions, let’s say, right? So that the other decisions you can take it in the future. It’s extremely interesting. And my feeling is that in companies, especially large ones, but more in general, would say, right? There is this conversation around technology.

 

This conversation around the customers and business, what the customers want, the products, the experiences, the UX. But there is a place in the middle, which is a little bit stranded in this type of organizations, which is what I can call, let’s say, the ontology. OK, let’s say ontology. I know it’s a very weighted word. 

 

And indeed, sometimes this space is addressed or targeted by the data people. The data ontologies and so on. But to me, especially as we move into organizations that have to increasingly speak to third parties, right? So the responsibility to create the ontology of the business, what we are, what we do, what the workflows are that we enable that translate into orchestration of services, for example, is often left there like an orphan in an organization. And at the same time, it’s the most important thing you have in the organization. So what is your feeling on that?

 

Gregor 

Oh, I very much agree. And I’m a big DDD fan. Like Eric Evans’ Domain-Driven Design book came out almost at the same time that Enterprise Integration Patterns came out that Bobby and I wrote. So we have a long friendship since late 2003, both these books, another 22 years. So again, there’s a lot of points in there that I see. So I feel that understanding and being able to articulate your domain is critically important both for the business side and the tech side right like the things that you mentioned if you want to have some sort of ecosystem, open API, extensibility is because modern organizations don’t live in a vacuum right they are successful because they they open up and allow integrations I would go as far as saying that without a good understanding of your domain you’re gonna have a very difficult time. 

 

There’s a couple of things that work against you. And this is why this is another topic that’s been with us for like two decades. we seem to, we know the problem, but the solution seems to be somewhat elusive. There’s a couple of things that work against you. And that is the one you mentioned that often the ontology and the domain sits with the data team. And that is noble but also it gives the notion that this is a sort of technology IT thing, right? They want to maintain the enterprise data model. 

 

And I find that’s making our life even harder because domain modeling, it’s kind of a soft task. It’s sort of like a right brain task. It’s about the right naming. Do I dissect two concepts? When I worked with Eric Evans, it was always about sort of the nuances, right, kind of finding things. So that’s a very right brain versus the enterprise data model is a very left brain. They’re like, do I need an index? What’s the data type for this kind of thing? So leaving it with just the data team, I think, is one reason why we struggle. 

 

And the enterprise roads are littered with dead body enterprise data models.

 

Simone Cicero 

Yeah, also because they’re not entitled to think about the ontology, right?

 

Gregor

Could, well, they kind of need the data model. So they need the output. But you’re right, they might not be entitled to do the input, right? Because basically, what is the logical model that you have? So I think this is definitely one part why we struggle. The other part is that engineers, or I wouldn’t even say just engineers, organizations who have a certain implementation of something have a very difficult time abstracting that. 

 

Basically, if you’re looking from the inside out, you’re always thinking in the pieces that you’re making and that you’re building. And I give you a couple examples. So it’s funny, we actually did a webcast with the automotive industry just this morning. And my own joke is if the engineers had named the automobile, it would be called piston crankshaft gear wheel assembly.

 

Because that’s how we look at this thing. And we are so proud of the pistons and the crankshafts and the gears and the wheels that we must have a name that has all of these things in it. And look at the cloud providers. The cloud providers talk a lot about primitives and abstractions. But in the end, what do they think in? It’s all their service names. And then they certify you on knowing all the icons and all their service names which is no different. 

 

Go to any big hyperscaler and look at the architecture of the system. What do you see? Well, piston, crankshaft, gear, wheel. They just have icons for each thing. It’s like Lambda SQS, Event Bridge, Event Arc. GCP pops up whichever color you want. And so looking from the inside out, it’s incredibly hard to find the outside in abstractions. And I think that’s the second element that hurts us in doing better with really articulating the language that we need to build these kind of layers that you’re imagining. 

 

In many cases, it takes decades. As I said, we just come off the automotive industry. Everybody kind of knows what the pieces of a car are called. We had 100 years to do that. But still, when it comes to defining APIs and ecosystems, we are still struggling to have the common language because we’re always looking from the inside out.

 

Shruthi Prakash 

I just wanted to sort of probe on this a little more, right? Let’s say, how do you change that conversation from maybe, let’s say, transactional, sometimes even maybe misleading to therein evoke, let’s say, richer conversation that supports maybe real architectural thinking, thinking of it from a coordination lens rather than from purely let’s say a technical discipline. 

 

So how does that transition happen?

 

Gregor

So, mean, again, there’s a couple of points in there. So in order to make the bridge between sort of the architecture side and the business side, and I stand behind my point, right? You cannot make architecture decisions without having business input because you don’t know what the trade-offs are. I would say the tunnel must be dig from both sides. I’m a big believer. So from a technical perspective, I find it shocking how difficult it is for lot of technical people to really articulate the trade-offs and the decisions they’re making. 

 

And I do this a lot because I write the architect elevator down into the engine room so people come to me and say I need a two-stage caching thing with a cache aside refresh something algorithm right blah blah blah blah blah blah blah blah right and then I’m like well what makes you make this decision? We need low latency. We need loose coupling. So these buzzwords kind of come and they have a very hard time looking behind these buzzwords and really articulating what they do and why. if you ask me, I’m a little bit puzzled why it’s that difficult for them. 

 

But I believe one of the reasons is that often from the vendors this comes a little bit. It’s like hey our product is loosely coupled cloud native portable scalable and then the developers kind of regurgitate what they hear. The other thing is I think the technologies somehow define themselves by being attached to a certain technology. I’m like a J2E guy or a spring guy or a whatever, GenAI is something rather person, right? And I think that is very strange to me. Basically, they latched their identity to a certain product that they see. So that is the one side of the house that definitely has room for improvement. The other one is the business needs to understand and appreciate trade-offs. And I come back to my example, executives comes, all you guys need to do is implement my grandiose vision.

 

I’m like, well, a vision that’s void of understanding complexity and effort is not very useful. Everybody can dream. It’s like, paradise looks like this, right? Everything is possible. Everything is cheap and easy and fast and whatever. That doesn’t take any skill to list all your desirable attributes. The skill is to understand the trade-offs, right to leverage the capabilities that you have. 

 

So I tend to push back pretty hard on these business people who say, I don’t care about technology. I’m like, you should, right? And the example I often give, do you think pilots care about the technology in the airplane? And the short answer is, they very much do because they go up in this thing. And if something goes wrong and they have no idea how this airplane functions, right, that’s gonna end very badly.

 

Now, luckily, we don’t crash as hard in business, but still, if something goes wrong in your tech and you have no idea what tech you’re using, your business can also have a little bit of a rough landing. So I tend to be pushing very hard is, your business life does depend on IT. You should want to understand some of IT.

 

I give a positive example where I worked with a financial services COO and we talked about making a mobile app, a classic thing. In the end, we ended up talking about load shedding and how to build scalable systems with a board member. Chief Operating Officer board member, we talked about how to design distributed scalable systems.

 

The interesting part was he really enjoyed that discussion, but why would I do that? Why would I talk with a COO about load shedding something very technical? The answer is quite simple, and that is I want to have buy-in into the trade-offs.

 

Making a successful product is not a matter of making a longer wish list. I say, wishes are cheap. Anybody can make any wishes they want. It’s about understanding the trade-offs and getting buy-in into the trade-off. So the message that I wanted to place is that any scalable system must reject work.

 

If there’s a certain capacity that you can handle, when the load exceeds that capacity, the best thing you can do is reject the extra work. Because that way you can serve the capacity that you have. You can still, let’s say you can handle a thousand transactions per second. If you get two thousand, the best thing you can do is reject one thousand and serve one thousand. If you don’t do that, your system will go down and you will serve zero.

 

So I wanted to make it clear to our sponsors that there’s trade-offs that we’re making in the design and to me that’s what real buy-in looks like. Basically the anti-pattern that I see is the business just wants to wish for everything and then somehow I see portrays a architecture that’s supposed to grant all the wishes. it’s scalable. It’s amazing. It’s portable. It’s flexible and both sides pretend that they’re not making any trade-offs that this is just a wishing contest and that in my point of view is highly dysfunctional. All architecture decisions about making a trade-off.

 

You’re getting this, you’re not getting that. You want it loosely coupled, you have more runtime overhead, more design time overhead. You want it to be extensible, you’re to spend more time designing your APIs. You want it to be scalable, you have a more complex runtime architecture. You want microservices, you need more observability. It’s everything you want. You have something else. And finding the best balance for the business, that’s the goal.

 

But if it’s just a wishing contest on both sides, you’re never really going to get there. So that’s what I do with executives. I don’t show them a long list of beautiful characteristics, but I actually show them trade-offs, decisions that we’re making. And then I discuss. And either I get buy-in into my decision or I change my decision.

 

If the business says, no, no, no, no, no, no, that trade off is going the wrong direction, then I’m like, great, let’s talk. And we come up with something else. But that way, we both understand what we are getting and what we are not getting. There’s always something that you’re not getting. 

 

I’ll tell a short anecdote. So I was invited once by Charles Simone, very nice guy. I’m also reasonably well-off guy. He invited us to his boat. Very nice boat, very large, I think 70 meters at the time. So the one question I had for Charles was, what did you want that you did not get? Because the thing cost, I don’t know, I had a million or something, right? Go for him. It’s a nice boat. I wish I had one. I said, what did you not get? And he didn’t even hesitate for one second. He knew immediately what he didn’t get.

 

He didn’t get the fireplace and he didn’t get the draft beer. And like, well, that’s interesting. And both of us, all of us went like, come on, you spent like 100 million. How difficult would it be to put a fireplace and draft beer? You can have, right, come on, right? You just add a little bit. And he said, no, no, no, no, no, no. Your fireplace is heavy. It’s big. It’s bulky. It needs fuel. It needs a chimney, right? And at some point, it’s just like, then I’m going to monkey something else up. But the fireplace has to go here.

 

The jacuzzi can’t go there, or the window can’t go here. And at some point, you’re just like, OK, just like we scratched the fireplace, even though we wanted to have a fireplace because we wanted to have everything. So lesson learned is even if you design something from ground up, all these luxury yachts that design from ground up, you can build whatever you want, but you won’t get everything you want. It can have any kind of shape, kind of trade-offs that you want to make but you’re still making the trade-offs and there still will be something that you’re not getting. 

 

And Charles is a great architect. So it was right on his mind. He knew immediately these were two things he wanted to have. And ultimately, he gave up on it because it wasn’t worth the trade-off. It wasn’t worth giving something else. And then if he made the boat bigger, it takes longer, it gets heavier, it uses more fuel, right? Then you need more fuel tank, bigger engines, like that all doesn’t work, right? So ultimately, you settle on what you have. And I think.

 

That attitude between business and IT would solve a vast majority of the problems we’re facing. Like, what are you willing to give? Like, can you accept that you will not get some things? And it’s not because IT is lazy or incompetent, but it’s just the way it is. The shipbuilders were amazing, and he still didn’t get a fireplace. And he doesn’t blame the shipbuilders. He decided ultimately, OK, fine, the fireplace is going to go out but instead I have a helipad and a jacuzzi and a bigger living room and I’m totally happy with this and it’s all good.

 

Shruthi Prakash 

So I think I really liked that this sort of deglamorizes, you know, ideal, let’s say architectures and puts it in just context aware sort of situation. So that I just wanted to point out. 

 

And the second thing was I was thinking about it from like an Indian context of let’s say tech and business being so sort of siloed from each other, even when we think of organizations, right? So when a tech dude sort of walks in, they have separate rules, they have a different work culture, their training are different, for example, and the first time they are integrated with businesses when they have to be promoted to a managerial position. That is the first interaction of, you know, let’s say, core business awareness that they have had, which is being, you know, some skill training that is happening from a MBA school outside. you know, that’s the first layer of interaction that they’ve ever had with the business. 

 

So it’s, I just wondered if this is, let’s say a gap between maybe skill and the fact that the learning process is not maybe horizontal, but more step by step and sort of linear. So I was curious about that, but I’ll also pass it on to maybe Simone, if he wants to add or, you know.

 

Gregor

So for me, I never quite had that learning experience because at school when I went to Stanford, I studied engineering management and computer science. I got two masters, so I’ve always lived on both sides. And for me, it’s been very natural. I would say so that let’s look sort of the classical Silicon Valley kind of folks. 

 

In a startup company, you have no choice but to be business oriented. Because if you don’t, you won’t be around in like six or nine months. So I see the engineers are there. Let’s put it this way. Once they have an interest in the business, I don’t see any hurdle for them to understand the business. So if anything, it’s more a lack of curiosity than a lack of skill, I think. Some people just don’t care. 

 

And I think their life is easier sort of walking up and down the cloud native tapestry and spooing out the latest open source project names that no one else can understand and it makes them feel smart kind of thing rather than really understanding the business. But I don’t see it’s a capability thing for me. It’s an attitude thing. I think what’s gotten me going is that I generally find every business domain exciting.

 

We have worked with some retailers and it’s super awesome, right? Because their logistics, their supply chain, some of them are cooperative. So the stores are owned by people, but they’re still part of this cooperative. Super interesting. Insurance, right? You could easily say that a lot of people think insurance is a little bit boring. Let me just set that straight.

 

No business is actually ever boring, including insurance. So I think what keeps me going is – I just find the business fascinating. I just talked with automotive guys this morning. Fascinating. Software defined vehicles and cloud and autonomous and left, right and center. So I think if people just have the attitude that it’s actually interesting, I don’t think they’ll have such a big problem understanding it.

 

They just need to want to. I think that’s the problem.

Simone Cicero

Yes. And yeah, mean, think technology evolution is pushing them to do it. And also they will have no much choice coming up, I guess. That’s my impression. I mean, I wanted to maybe add a last bit, but since we don’t have much time, maybe more like a reflection that you can resonate with and then we move ahead with the breadcrumbs. 

 

So I was thinking that…

 

This space we’ve been talking about, domain understanding and domain modeling, as a standard piece of organizational development that sometimes gets lost between the IT or technology and the business, and that the data teams often look into from a too technological side, I think sounds a lot like what in AI development we are starting to call context engineering. So the idea that we have to understand the context, right? And what we discovered is that AI, GenAI needs context, right? So for me, it sounds like it’s not that AI, GenAI needs context, it’s that everybody needs context. And context is very important to share decisions and trade-offs, like you said.

 

But the fascinating thing is that the emergence of these AI systems, agentic systems, or even development systems that can leverage on the context is kind of showing us that there’s a lot of biases and pride and alibis and depth that we try to protect in the organization. And then suddenly there’s this technology that needs a clear understanding of trade-offs to help us take decisions. And it’s kind of nudging us into getting our organizations much more real. 

 

So what is your impression in the work that you are doing with companies as these technologies come up? Is it something that resonates with you?

 

Gregor 

Oh yeah, big time. And I see sort of two parts. The first warning I would give is if you’re living in a silo, you say like, only do my thing and I care less about the other stuff, you make yourself a great target for GenAI replacement because it works extremely well in silos. If all you do is like, hey, give me the requirements and I code them out, well, LLMs are pretty good at that. 

 

If all you do is design beautiful user interfaces without caring about the business domain. GenAi is pretty good at that, right? So that’s my word of warning. If you live in a little box in your organization, think again, because you are the prime target for replacement, right? Where AI is not as good as strategy, collaboration, looking across the different domains, dot connecting, taking bets, placing bets for your business. That’s where it’s not nearly as good. So folks who cut across, think, will be much more in demand. 

 

It’s just like everything else in the past. GenAI raises the bar. And the bar usually goes up by understanding the domain, working across the different silos. And that’s where I think you don’t need to worry about it. It’ll be a booster for you. But if you happily live in your little silo, it might actually be the replacement. So that’s big thought number one. 

 

Big thought number two is, it’s funny how organizations always believe that the technology will solve all their problems. And you can understand why. Otherwise, it’s a little depressing. But here’s the reality is a lot of new technology doesn’t solve your problems. It actually highlights your problems more. It amplifies the problems that you already have. 

 

Let’s start with something simple, the cloud. So it’s basically, if you have this giant separation between development and operations, because it’s not like silos just exist between business and IT, the silos also exist within IT. It just keeps going. And then you go to the cloud – Companies have taken a decade and are still dealing with sorting out that nightmare. How do I get the release cadence, the agility, all the things that the cloud provider promised me didn’t really happen because of my own organizational dysfunctions? 

 

And I think the same thing is true with GenAi. 

 

So I’ll give you a couple of examples. Let’s, for argument’s sake, assume that GenAi will actually make developers five times more productive. 

 

My prediction is, everything in your organisation is going to fall apart. Because the friction you have, the decision-making processes, the release processes, basically nothing in your organisation is designed to deal with a five times more productive organisation. Or the other example is what Simona alludes to, is if GenAI can build software just on a push button, let’s say you just give your thoughts, and the software comes out, for argument’s sake.

 

Well, you need to have pretty good thoughts, right? Because everything else has now become a commodity. So you need to understand your domain, the ecosystem, the language, all the things that Simon referred to, right? That is now the real differentiators. And in many organisations, that skill is weak. IT and business interface is the business pours money and wishes in, and IT sort of spits something out which may or may not be right.

 

Simone Cicero 

You know what’s funny? What’s funny? Sorry for interrupting you, but I think it was fun. It’s funny to chime in because, you know, at Boundaryless we have been thinking about some software we wanted to develop and for some months we have been a bit frustrated by the need to raise capital and so on. But then suddenly there are these tools that can help us prototype. And now I’m even more frustrated because I don’t have enough time to work on the domain modeling. so the replete agent is there waiting for me since a few weeks and I’m so frustrated. 

 

So if anything, the frustration has grown with these new technologies.

 

Gregor 

So you know it.

 

Gregor 

Yeah, and then multiply this by sort of 1000, and then you see how this goes in large organizations. I actually love your story because it tells us that we can see the effects in the small, right? And then, you know, for organizations, we can extrapolate. But that’s what I predict a huge challenge to be. You can no longer hide between, or you can no longer hide behind the long delivery cycles and all the specifications they need to write. You need to now go understand your domain, look for business opportunities, and build ecosystems, right? And that is hard work. I can totally relate to what Simone is saying, getting the bandwidth or getting focus time to now do real critical thinking to feed your AI agent in a way is actually harder than sitting down and just cranking a few lines of code or spewing out some random design document, the bar actually goes up. 

 

And if you’re not good at this, you’re not going to be happy with GenAI. So it amplifies the dysfunctions that you already have rather than making them go away. And I would say that’s the main warning I have for organisations.

Shruthi Prakash

So very curious how all of this shapes out. And yeah, it was really nice, Gregor, having you. And before we wrap up, we always love to leave our listeners with maybe a few breadcrumbs. So if you have, let’s say any books, podcasts or thinkers you are influenced by or have shaped your perspectives lately, it would be, you know, good to go into those.

 

Gregor 

Maybe I’ll start with a sort of meta comment. One thing I learned when I attend events, which I hope many listeners will do, I highly recommend for people to attend talks from people whose point of view they don’t agree with.

 

Listen to people who have a different point of view because one of the biggest trap I see people fall into, and social media doesn’t help with that, is that people look for things that sort of reconfirm stuff that they already believe. Look, I was right. This Gregor guy says the same thing. Platforms are important and the cloud. People look for reconfirmation. Instead, you should look for a different point of view.

 

I remember well, I went to one event and somebody, was working at AWS in the serverless department, and a very smart gentleman gave a talk, was basically, serverless is outdated, it’s based on assumptions from 10 years ago, and basically, it’s a bad idea. I’m like, that’s the talk I want to go to, because I want to hear what this guy has to say. And it was very, insightful. So that would be my meta tip.

 

In terms of concrete resources, I think if anybody hasn’t realized that systems thinking is now no longer a niche but a prerequisite, then take my word for it. So anything you can read around, whether this is the fifth discipline or thinking in systems, many, many related works, I think that is now required reading. There’s the domain modeling.

 

I’m sure every audience or every listener has already understood domain modeling and domain driven design. But then there’s also the systemic thinking, the systems thinking. So I would highly encourage people to, as I said, no longer consider that a niche, but required reading. And then perhaps allowing myself to be tiny bit biased, but it fits well within our podcast as well.

 

I think platforms are also no longer something that the big hyperscalers do only, right? It is something that no matter what business you’re in, you’re gonna be a platform for something else. So that’s why I wrote Platform Strategy. Quite honestly, it wasn’t an easy book to write because it has so many nuances between marketplaces and developer platforms and cloud platforms, all these kind of things. 

 

But I would also encourage people, it’s hard to have an IT strategy today that does, or even business, business slash IT strategy, let’s put it this way, without a thought of platforming it. So this would be maybe three vectors for our audience that should be useful.

 

Simone Cicero 

And of course, if you want to add a couple of bits of where the audience can catch up with your work.

 

Gregor 

So most of my work I have at architectelevator.com. The architect elevator is about seeing architects as a connecting element across the different floors. I would say from the penthouse to the engine room and back because that’s a lot of the disconnect that we just talked about. If the business has some vision in the abstract and the techie people play with random tech stuff, that is fun, but it’s not a good way of organizing your business. 

 

So your architectelevator.com, that’s where all my blog, my books are. And the only thing that readers need to keep in mind, I write the elevator myself. So you might read one blog post about serverless asynchronous messaging architectures, and then you read another blog post about platform strategy. But my take would be that’s actually good for you, because once again, you should be reading things that don’t just reconfirm what you already know but also take you into slightly different domains.

 

Simone Cicero 

You must dig the tunnel to the truth from both sides, right?

 

Gregor

Yep, exactly. Nicely put.

 

Simone Cicero 

Good, good. mean, was an amazing conversation. I hope you enjoyed it also.

 

Gregor 

Yeah, no, very nice conversation and great insight for questions. I was only half joking when I said the first question could easily take us an hour to answer. And I think the same is true for all the other topics. 

 

Simone Cicero 

But to some extent, we have been wrangling on this conversation for the whole podcast. So I think that was effectively what happened. It took us one hour to just wrangle around it. So thank you so much again. It was a pleasure to have you. I think it was a long due conversation for your work in platforms. It’s so relevant that it’s strange that we are having it at the seventh edition of the podcast event series. 

 

But for our listeners, of course, you can head to our website. You go to boundaryless.io. If you’re listening to this podcast now, will find Gregor’s transcript with all the links, the books, the things that he mentioned in the conversation. And thank you, Shruthi, so much for joining us.

 

Shruthi Prakash 

Thank you. Thank you, Gregor. Thanks, Simone.

 

Simone Cicero 

And yeah, until we speak again to our listeners, remember to think Boundaryless.