Today's episode of the technology on our podcast is proudly sponsored by emergence. The Journal of business agility. This quarterly publication brings you inspiring stories from the most Innovative companies and explores the themes of the new ways of working reclaiming management and humanizing business. It brings together a curated selection of exclusive stories by great, thinkers and practitioners from around the globe that can broaden your horizons and Spark. Your creativity.
Each issue is hen Illustrated. And contains 100% pure content, use the promo code Tech lead. The ECHL EAD to get a 10% discount on your annual subscription. Visit business agility, dot Institute, / emergence, to get your addition and support the publication supporting your podcast. Here's the link One More Time. Business agility, dot Institute, / emergence. What's more interesting to be when we talk about the cloud?
Is it changing operating table? It's really Finding the interface you having with Europe, 80. That's why I always say cloud instance, it procure, but it's not something you buy. It is really on a lifestyle change because if the old terms, the way to deal with the ideas, we find particular to make a request things, take some time transparency is a little bit limited. Once you order something usually stuck with it for many years until it's appreciated. Right?
And of course, Cloud operating model turns that completely on its head, you can have stuff whatever you want it, you can do. Dispose of it whenever you want to degree create it. It's a highly Dynamic environment. So in the end, it's really changing the way of working. If you don't change the way your organization works, the cloud is coming. Look much more like another data center. Hey everyone. My name is Henry Surya, be Robin. And you're listening to the
tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello to all my listeners. Out there super excited to be back here again with another episode of the taglit journal podcast. I'm your host and research
everyone. And I'm so happy to announce that technology not podcast has reached its 50th episode. While it is personally, a great milestone for me. And what a great one year Journey, it has been. I'm so thankful for all of you. My listeners who listen, and support this podcast, especially those of you who have been there since the beginning, and I couldn't have made it without
any of you. Also a special thanks to all of the amazing guests that I have on the show and especially for sharing your story valuable wisdom and knowledge. Last but not least. Thank you to all of my patrons who have continuously supported my journey and for giving me the extra energy and motivation to produce high quality content.
I'm so grateful to everyone of you and I hope we can continue this journey for more episodes to come special mention to those of you who helped me to promote these podcasts on the social. A platform either by following liking and re sharing some of the contents, all of you helped me a lot in reaching out to Molly's illness. And I can't thank you enough for
that. Speaking of which, if you haven't, please subscribe to Tech lead journal on your favorite podcast apps and also follow our social media channels on LinkedIn, Twitter and Instagram, you can also make some contribution to the show by subscribing as a patron at technology. No, the death / Patron, and help me to continue producing. Great content every week. To celebrate the 50th episode. I am extremely happy to share my conversation with Gregor. Hope Gregor is currently an
Enterprise strategies at AWS. And the author of many popular books, such as Enterprise Integration patterns software, architect elevator and Cloud strategy. In this episode. We started our conversation by discussing about the role of a software architect. There are a lot of different opinions about software architectural and Gregor. Explain the fundamental skills
required from a software. Architect and the reason why there is the latest Resurgence of the role within the industry, he also explained about his software architect elevator concept and then describe what a good architecture should look like. And how to deal with trade-offs by using the analogy of financial options in the second
half of the conversation. We then discussed in depth about the cloud and the reasons why adopting Cloud requires a lifestyle change, in order to benefit from it. The most Gregor also describe, why organizations Need a good viable Cloud strategy and debunk the concern of many organizations on cloud vendor lock-in. He also gave his tips on how organizations should approach building an in-house Cloud platform.
And how to change the organization structure to embrace the cloud better towards the end. You do not want to miss our insightful discussion on the Gregor's law of excessive complexity. I really enjoy my conversation with Gregor learning about software architecture and the cloud, and even though, I've been working with a cloud for a while. There are still a lot of things to learn from Gregor throughout this conversation. And I'm sure that you will enjoy
this episode as well. Consider helping the show by leaving the rating review, a comment on your podcast app or leave us some comments on our social media channels, those reviews and comments are one of the best ways to help me get this podcast to reach more listeners and hopefully they can also benefit from all the contents in this podcast. So let's get this episode started right away. Everyone, welcome back to another new episode of the package. You know today.
I'm very excited to have a guest with me. He is a very famous guy in the tech scene all over the world. He has an illustrious career as well. So he has been a Chief Architect at Allianz technology, technical director at Google, and also work with gastic Singapore as a smart Nation fellow. Currently. He is working at AWS as Enterprise strategies. He is Gregor. Hope. He also wrote a lot of books. Few of the popular ones.
Like Enterprise Integration patterns Cloud strategy, the recent one and software architect elevator. So today, we are going to discuss a lot about Cloud strategy and a little bit about software, architect elevator. So Gregor really, really pleased to have a conversation with you today. Looking forward to learning from you. Thank you. Thank you for having me on looking forward to the session as well. I know we can trying to make
this happen for a little while. So I have even more excited to actually be on the show. Their thanks for that. So maybe Gregor in the beginning. Can you introduce yourself to those people? People who may not be familiar with you. Yet, maybe sharing your highlights turning points in your career. Sure. My name is Gregor. I would say. I have probably seen it from every possible angle. You could imagine the co-founded the start of back in the old days before. Everything was a unicorn.
I worked a lot of time in Consulting, Professional Services, and I was a Silicon Valley software engineer. I worked in a large Company ID. Right now. I work for a cloud provider and I worked at public sector. So, Say I've always been curious and I always been Keen to see things from different perspective. It's also forced me to not a lot of things and as you mentioned I like to write about the things I learn solar books.
I will go see about the role Architects that are at the website called architect and the data.com and I think blutarch coveted more about, but we think an architect might be a should be. And how than all relates to Cloud architecture includes strategies speaking about software. Architect. I think in the last Last few years or so software architect in terms of their name of the role has become one solution. Whereby people will be a little bit skeptical so to speak,
right? When someone introduce themselves as a software architect, we will then hesitate and see the person is this real person that will be useful to deal with because of the connotation, of architect means like a knife or a towel kind of architecture whereby, they will document. And also just give orders and directions without actually having a low-level practical hands-on experience. So, in your point of view, then what is the role Of software architect and this fit really
interesting. We often say that in our field things swing, in a pendulum. It used to be like The Architects, make all the decisions and other people just fill in the blanks. Then there was a time where we really thought we don't need Architects. Mostly driven by the internet and the popular Frameworks basically made. All the architecture. Decisions for us. We felt for a while. This has we just use Framing and we use HTTP and there is our
architecture recently. We see the A huge Resurgence. I'm an awesome. Sorry, would know a lot of fellow officers. They write about architecture with its microservices architectures, whether it's event-driven architecture is, whether it's Cloud architectures. We have architecture events of suddenly architecture is back everywhere.
I think part of the reason is that the software we build is enormously powerful, but it's also admittedly fairly complex, right everything these days is distributed and horizontally, scalable and to restart a bubble. And resilient and anti trajan, whatever label you want to put out there. It's just fantastic, but it's also complex so I could take action helps us deal with this
complexity. What we've also come to terms with I think is that having architecture as once named Doing architecture is another saying and having Architects itself, and the simple answer is, you always have an architecture. You can choose. If you write three lines of code listing is going to have some architecture. So chose, most people have also realized that doing architecture consciously. It's a worthwhile exercise because if you don't do it, usually end up with a big bottle
but kind of architecture, right? You get the giant spaghetti default, but the sad part is like, well, do you have Architects do the architecture or not? I found that we have a much more open mindset. Some people still prefer to have a dedicated architecture team. Sometimes you have Architects embedded in the software teams, and sometimes the I could take Is done by everybody and I
really like that. So I think we debunk this discussion up. Associating do a good architecture with having this Ivory Tower attended by Architects. And I think that's been very
healthy for the dialogue. So in terms of software, architect role, I think, one of the thing recently, especially in the startup and all these Asia, they always say, do the minimum as you can, but I like when you said that, there is always an architecture in your system, no matter whether you plan it properly, do consciously or not. Not, there will always be an architecture. So what do you think is the importance of the role of software architecture? Can you explain to us?
Why do you think a software architect will is probably still required? I often, how do you like that? It's not about developers. Having to become Architects and Architects. Somehow being a more senior developer role. I see them as different roles Each of which is valuable in its own. Well, I see The Architects doing is a couple of things. The one thing is that the Architects, generally see, the System in the larger scope nights.
Coordinates on the book about architecting complex, real life systems, like oil, drilling platforms, and stuff like that. Where it really describes the role of the architect, very nicely and setting. While in the end, you really responsible for your part of the system, but at the same time you accountable for the whole part around it for the system as a whole. That's why Architects need to look more lifted rhymed and they can't just work based on requirements. Architect.
It's 2:30. What I call is work based on non requirements, the tacit assumptions. The things that nobody's singled out by just things that weren't actually written down anywhere and I think those are the key inputs for a successful architect. And you have this term called software architect. Elevator. Is that somehow related to what you just mentioned? So Architects should work based on the non mention or non specific requirements.
Can you maybe share a little bit more about the concept of software? Elevator. Yes. I have the name of my book and my website, so it's something that's close to my heart. Obviously, we just set the Architects need to have a wider scope that need to see the system as a whole, and they need to watch us work on the requirements. She but basically fill it the place. Now, how you gonna do that? The way you do this is you look at your system from different levels of abstraction.
You see it in the business context in the Strategic context, or you take the elevator down to the engine room to see. See a system in a very technical contexts and what you Fareed, especially knowledge organization cyst, these different layers, these different context. They actually shockingly separate from each other. There's some people doing the financial bear witness and the people doing the strategy.
There's other people doing, mergers and Acquisitions, go to market entry and there's somebody down there. Configure ihum charts link between us. That is a big giant. Boy. That is exactly what I call the architect elevator. Let someone who can move for, Us these different layers and make
sure they're connected. Now in an ideal State, an organization would be very natural, very well-connected that would call those like a bungalow, basically, where everything is easy to get to, when I find, even in start-up companies later stage of mid-stage, solid different people. Need to focus on different things. It's inevitable. Not everybody can do everything, and then very quickly, the little Bungalow chunks into multi-story Mo. And then soon after he turns into stone, like, Paper?
Right? And the thing just keeps growing. You can't just flatten it back down or because the different functions, of course, are important. So, the next best thing you can do, is somebody ride the elevator between the different levels and I feel the Architects not. Well, equipped to be the ones who write that elevator which is aptly called, the architect, everything. I laughed. When you said that, someone is tweaking Helm charts. Sometimes as an engineer.
We probably don't actually realize. When we tweak, for example, Helm charge. What does it mean? Thumbs up, business impact, or in terms of purpose for the whole organization, or the system's overall. So I really laughed when you said that, I think software architect, in this case is very important because you will then have a translation. And to end on the business point of view until the engineering
point of view. You have this thing in the book, mentioning about an architect, actually stands on three legs. So what are these three legs? Can you explain a little bit further on each of the leg? We are connecting the different levels. Let me just say that. The reason it's so important is because it's the connection isn't there. The greatest technical solution in the end is not going to have the impact and it should have. There's likely to drilling the two tunnels in there.
We'll meet each other drilling faster is not going to help, so that's why this connection is so important. Of course. This place is another requirements on the role of an architect. We have to go through these different levels. We have to connect all these things. There's many different things that we need to do. So, how do you come back and bring this into something tangible? And I said, The end to be a successful architect, you need to have three elements.
Those are the three legs that you stand. Of course. You need to have the skill. You need to know your sense. Do you find some Architects up at the pet house, who just scored some jargon? And I bid need to leverage. The serverless cloud iot is something Edge, shredded, blah, blah, blah, all that doesn't help anything. It gets Executives excited, but there's who elevated and they are. So you need to have the skill. You need to know what you're doing. And what you're talking about.
We were just chatting before the recording. Right. I'm just now a tinkering with some AWS products. So I have the anchor in the inch. Now, the second part, of course, is you apply the skill to have an impact again. Otherwise, it just saw the like we serve Sky. Not playing around prototyping, that's good for very small things, but that doesn't make a difference. So you need to forge the connection between having the technical skill and bringing this to have an attack.
This is about aligning and Destiny strategies. Exactly like the elevator. But there's a third important part. That's why the stool has three legs. We can see, two necks is a little difficult to sit on. And the third one is really the leadership. I took the inspiration here for other professions. Like, let's say only you're a very highly skilled lawyer or a very highly skilled doctor at the court staff. What do you become?
We become, like Chief doctor, make the cheap ploy to some extent, but you really made a lawyer, and the doctor, and also, as an architect, you read need an architect, but the way you grow, your Impact is on the advancing the field to start lecturing you start maybe or researching finding new things? Describing things in February is building more skill set and in the end and leading the practice and support. And that's the leadership as the sir. Like no Goodwill. Nice thing about.
This is all of this is a two-way street. Once you have the skill. There's so many skills. You could acquire. It's hard to figure out which skill you should really pursue, right? It's like a kitten. Candy store. So I'm looking for their pack helps you prioritize. What should I learn? I should learn the things that have an impact and also having the leadership mentoring.
Other people gives great feedback because you learn what's maybe most confusing or people ask this proverbial total naive questions, which really get you thinking so it's not just your personal progression, but it's also a two-way street. You always get things back along this journey. I really like your explanation that it's a two-way street.
Street, right? It's not just one thing that we can just go dive, deep, study hard, and we become great architect, but you always need to show impact because of all and also do some kind of leadership thing in the mentoring or advancing the field. I really like that do research and talk about it. So that other people can also adopt your ways of thinking speaking about architecture. I think it's kind of like
abstract in a way. We all know these days about microservice event driven and all that. But what is actually a good architecture? Because I think it's very hard to Define. Sometimes we are clueless or I have a system, I've requirement. But what is good enough architecture for my requirement?
Yes, good question. And the old definition is sort of, you have to non-functional requirements from the idea would be that an architect just sort of make sure the non-functional requirements are met and then the developers actual functional requirements of it, anything, that's a very naive definition. It's a good starting point, but what it doesn't account for it all is uncertainty like all these requirements taking assumes, you know. What you need?
Right here is the list of requirements, just make it. So everything would be fine. The dimension. That's totally listening. Is the dimension of evolution and uncertainty and anything that's where I'm good architecture, really shines. You might know my famous small about architecture sales options, options are great way to deal with uncertainty. The analogy comes from the financial markets. That option is the ability to execute a trade, like new biosimilar, stock in the future.
At defined terms so you can buy it option may be to buy one share of Amazon stock for four thousand dollars, one year from now. And then when the year comes the decision, whether to exercise the option or not becomes very simple, because it that part of the stock is higher, you buy it for 4,000 based on the option. You have money in the bank. If the stock is nowhere on the market on the option, you like the options expire, you don't take it.
Now, what we learned from this is that decisions become much easier in. In the future. It's a great way to deal with uncertainty if you travel into the future. Well, there's no more uncertainty. You can look at reality at that time. So if you can defer the decision, that is a really great thing.
This is what we call options, probably the best technical example that we have is horizontal scale, it back, elastic, infrastructure, horizontal scaling, like how much Hardware do you need for your application? It's always been a guessing game because there's a lot of uncertainty and of course for internet facing and mobile apps Etc and certain Is even higher and I could take, I could send build option, make it my services architecture. We make it horizontally scalable.
You run it on top of an elastic runtime in the future making the decision is very easy. You need a bit more Hardware wanted to play with the hardware and you need less, you actually shut down some servers. So this is an option that as an architect. I could give you that allows you to leave first a decision. In this case, the decision apart Hardware sizing, and that takes a lot of the uncertainty out of the game. That is a great value, technical guidance, certainty out is highly valuable.
I used to work for an insurance company. We made 11 billion euros operating profit a year, by dealing with people's uncertainty. So, if I get textured takes uncertainty out of the equations, that is worth real money, then, how about trade-offs? Because as we all know in IIT or most of the things in the world, you can't achieve everything. They will be always trade off either. Like, for example, skill ability versus performance security and all that. So how does an architect?
Deal with these kinds of trade-offs at the end of the day with all these different options and also trade-offs. How do you actually communicate that? So that everyone in the team, everyone in the company actually ideas to the decision and hence properly Implement that. Yes, and recall, when I sent the Architects with, you still options, right? We don't donate the options and there's a through the trade-offs coming with our words or thoughts, hitting example that option.
It's great. But it has a cause the cost is slightly. We more complex application architecture. We need to replicate your state of extremely sister hate. You need out automation to school onion? Since is not these days. That's probably common to many developers that if you ride a little hello world for yourself for the weekend. Probably you don't make it or is on telescope. So they say cost the cost comes in a number of different forms,
right? This little bit of effort, but it's actually relatively easy to deal with. The larger cost is complexity. Slingback includes more options invariably is more complex. So we'll find out later on Flex. It is not a very good thing because complexities also doubt. And in the world we live in slowing down isn't a very good thing to do the last thing. The way you buy these options of your trade. These options is in order to gain one option. You need to give up other
options. So let's say, you want the option that each teen programs in their own favorite language, right? That's a great option to have some people. I go the other ones to it. It's got Gather around and people on the jvm by this is a really nice option to have. What do you need able this option by locking something else? Now you say, okay. I have apis. It's HTTP or https. It's Json. Payloads. Look for the bus. Whatever you want to be. You look, something's in in to
gate that option. So, it's really an options, Marketplace. Like you're trading, you're giving up some to gain other options. Now, the question is, of course. Well, when is it worse by the new Option? Versus what is it? Not? It's how big the option the important part here is that the architect generally cannot make that decision on their own. They can offer the option up for sale. But the value of the option, depends on many factors. One of the key factors is the
amount of uncertainty. So if things are highly uncertain, be I'm launching a new mobile app. I don't know whether this will have one user or 1 million users. I deal with a huge amount of uncertainty solar. For example, scaling option is almost a given like the value. It is so high because of your CSR from adult, hello world or photo app for my own family. You know, it's like three people. I probably don't need a lot of option. So the options Marketplace consists of the architect.
Offering things up for sale. They're not free, but then you need to work with the bitterness and the context to understand, whether that option is actually worth buying not. And what the cost has been. You said like, how we get people to understand that I think the best way is To really make these decisions very consciously. And to be very open about the trade-offs. That doesn't help anybody. He said, well, of course, it has to be continued. Of course, it has to be proven leaders.
Of course. It has to be x y z, of course, we need to serve especially, because how couldn't you? And of course, it has to be serverless. It's like all the given. No, it's never a gif of, right. These are all important decisions that have trade-offs in case of options. You lose a lot of options making those trade-offs transparent to a wide audience is probably the the most helpful thing you could be and of course that looks very much like the other Nintendo. But people higher up of the
higher floors. Understand the ramifications of the decisions you making speaking about explaining this having an open conscious decision. And also transparent reminds me of architect decision lock or something like that. By you actually put down all the thought process that you have and also outlines why a certain architecture is decided at that point in time, maybe so that people also understands all these different options that we thought about. And why we chose a particular
options versus the others. Yeah. Mic night. Yeah, quite the terms of the ADR. The architecture decision record. I like that a lot. The key thing is to express the decisions so that the trade-offs that are being made are meaningful for a wide audience. It can be some cryptic, kind of, we decided to flip this arcade. Bit number XYZ somewhere deep in the infrastructure. That's not that ADR. That's gotta do a lot of good.
It's got to be meaningful in the trade of are going to be communicated and I like 80 yards on. The next thing that we want to talk about is a specific thing about Cloud architecture, which is a big topic these days because so many Cloud providers so many clock products and so many people wanting to go into the cloud. So, you wrote this book called strategy.
I read it. And I loved it a lot, because there are a lot of humors as well inside the feeling I have to say, so, when we talk about Cloud strategy, right, I mean, almost these days. Everyone is familiar with the cloud. But what is the definition of cloud from? Point of view. Yeah. Thanks for reading the book. And, yes, I feel that books were technical depth on have to be boring. So, I always inject a little bit of humor and in Beyond reality, writes, the best story.
So I think all the funny parts are taken for well-disguised customer conversations and customer engage in the book. And generally, I shy away from having this one sentence definition of won't cloud, is he end up with these? Like very academic weird things that try to put as many passwords in a single sentence. When I rather try to do is His show, the different aspects of calm than one aspect is of course, where does you stuff run? And where does he didn't? We say we don't need to say too
much about this. Everybody talks about on-premises versus King. The cloud that is probably I would say the overemphasized aspect or many recent try to guess on premises often. Also not actually your premises. It's off Outsource run by a third party. So you a lot of thoughts about the location, but that would be the first aspect and comes to many people's minds. More interesting to being. When we talk about the cloud.
It's a changing operating table. It's really redefining the interface you having with Europe. It that's why I always say cloud in sight. E-procurement. It's not something you buy is unlike a CRM kind of a system or like a database. It is really on a lifestyle change because the old terms, the way to deal with the ideas. We fired, our technology, make a request things, take some time transparency, is a little bit
limited once you order. Something usually stuck with it for many years until it's appreciated. Right? That is what the interface into your, it look like. And of course, Cloud operating model turns that completely on its head, you can have stuff whenever you want it. You can dispose of it whenever you wanted. You can recreate it. It's a highly Dynamic environment. We talked about before zap, the traditional definitions of architecture. They ignore uncertainty, right?
They have this idea that everything is clean defy nicing. This. Lates extremely well into Cloud. If everything is stable and steady and when a no, then cloud is probably just a little bit more official. We need to run the infrastructure. Yes, and you will say sub-caste about loudly. Same old things a little bit better packaging, it slightly
more cost. However, once you assume that you don't know everything that you live in an uncertain world that architecture options are valuable to you. That there's a lot of changed, a lot of uncertainty. That's when the cloud operating model really changes the way your organization. Has a, she can operate and I like that aspect of cloud computing, much better. I really love your definition about. It's really about a lifestyle change for your it.
And it's an operating model. Not just procuring, things like buying software, buying Hardware, traditionally. We are all accustomed to. So can you explain a little bit? Why do you think a lifestyle change is more proper term rather than the procurement since I'm the first question, should probably be? Why do you want or need a lifestyle change? Abacus. If it could be just simple procurement. You're probably make your life a lot easier.
Almost, every customer. I talked with the procurement harder than this relatively easy, but then in the end, they are the middle of a giant reservation and the translation, of course, is closely related to the lifestyle change that. The reason you want to have the lifestyle changes because he environment has changed, and that has to do with pace, and it has to do with uncertainty that your days when things were
moving relatively slowly both. For me Isn't some by that as well as for the technical Vibe things were just like legal by three different brands of server is so nuts about that. Some Trump's a runtime environment. It was swinging, or can you put it on VMware? And there was up there wasn't so much ablution. There wasn't so much going on in the business environment was
also much more predictable. Now then has changed a lot if anybody needed a wake-up call, of course, academic do that in terms of how quickly environments can change on the business side, when I suddenly, Have to ship their whole custom interface from physical store into online order. Whether it's restaurants or whether its retail shops, massive ships, which of course translate into the IT
infrastructure. Need customers were used to be sold out 90% of supporting physical in Stockholm area. So maybe 10% e-commerce or them in a matter of couple weeks that actually flipped. So talk about scaling and scaling up and also scaling down getting rid of the cost for the stuff that's not needed as much anymore are reacting to this. And I think that's why you want the lifestyle change. I call this the transition from the economies of scale to the
economies of speed. The economies of scale is you build something and then you get the return on investment, right? The bigger you are in the lower. You can run this thing, the battery return on investment. So that works. Well, if things are steady the economies of speed up much more about learning quickly, having constant change, being able to listen, being able to course-correct being agile.
If you like that word though. Those are the new ways that business runs and the cloud is a natural fit for that. Kind of way of running business. If you're always moving, if your course, correcting, if you're changing, that's when the benefits of the cloud really come to bear and you coined the term, as like clock things in first derivative, in terms of economics of scale versus economies of speed, right? Current. Like when the first derivative is zero things on the steady-state.
Cloud is nice, but it's not going to really change the whole way. You think about the ID when the First derivative is not 0 if things are changing in the changing rapidly. That's when the climate operating model Department. We sent of the cloud. That's much more interesting. That's when that really comes to be some type of setup return on investment. You should think about return on agility. What is my return on? Having the ability to react
quickly? If something changes in a, if you want to look at it mathematically, that is really the first derivative and all these are really interesting to me. Because when I used to work with, Love Cloud customers as well. A lot of people in the IT industry is a lot of them actually, their motivation or incentives. Moving to the cloud. Is actually too safe. So from traditionally managing on-prem managing fenders managing, Hardware by yourself into moving things into the
cloud. Simply because of the cost benefit. There will be no more what you call it, capital asset and everything. Now, become operational expense. So it seems like from your explanation. Just now it should not be the main motivation of why you are going to the cop. Is that correct? Assumption? So, saving cows is always good to write, especially good. If you have to convince upper management of something, right, if you reduce cost, it's always handy to have that argument.
We see many customers, of course, reduce the cost for the cloud operating model over there so that to corollaries to that. But one is the cost Centric model. Isn't very traditional. It, what? Which again is based on the Assumption of predictability is D. Righty. Here's my requirement. Please fulfill this requirement at the lowest. Also the cost, what happens if this requirement changes, we all know in the old world? What is called is change requests.
Now, it says change requests have a certain sound attached to them. It's Unicode catching because the vendor rapidly makes you pay a lot of money when you have to change your mind. That's how old i t. Answer C works. This is, of course, where Cloud can do something very different. So what we see customers needs day is they like to reduce costs about they just as much like the agility, they like to hire staff productivity. If you don't have to manage all the infrastructure, people can
actually focus on higher value. Things. That doesn't mean you reduce your cost, doesn't mean you need to get rid of those people. But there are all of these people can do much more valuable sex, people arts and starting to fight that the cloud is much more reliable. You can fail over easily. You could speed up when sensors, you're not going to run out of capacity, as easily as he do or premises, you can get into different availability zones in
the end actually a higher. Leti and interesting lead slowly but steadily folks are having around realising that at the cloud, you can run more securely than you can run on premises. I don't mean, it's probably a whole podcast on its own at the Cyber landscape has changed dramatically. The attack Vector is have changed.
So in the end, it is something that you need to have a lot of resources for to manage and that's something that the hyper scale of just simply can't do better than an Enterprise with their data center. So it's a cost is still there of the portfolio. Of benefits has actually brought on what the one I saw in though. And that is probably the most unexpected benefit. At least for me. It was when the first time I went to the club operating
model, there was transparency. We don't like to talk about it so much because which CIO wants to admit that the ideas in transparent. But yakult ready, it executive and say wow. Tell me like, how many is service. Do you have? How many of those are production versus staging box? The utilization? What application runs on it? Who's the order? When was the last push? Often application update, what's the patch level? And basically you get a three-month project basically
see the momentum. So that's what it looks like. There's no strain because everybody equally bad and that's why I realized Cloud actually gives you a much better chance. Can see all these things, become a simple report. He has only workloads here to the patch level T as the last update. So the transparency UPS improves significantly and coming back to your Cost question, of course, having improved transparency. Team allows you to optimize much
better. And that is also a big contributor to the cost reduction. So my favorite benefit with the cloud is actually transparency, right? The I again laughs when you said transparency because again, I could relate to the story whereby we didn't really know. What is going on with our it infrastructure. I remember one case in my previous company, whereby we always ask this. Anyone knows about this system. Maybe the guy already left. Nobody knows about it. Nobody wants to touch it and
sometimes nobody even account. For it. So the system just run somewhere in a corner of a room. Probably. And if it's down, some people notice about that and we need to support. So I think with that called, at least, it gets more transparent. Even the course itself is more granular per minute, kind of billing and we can easily figure it out. OK. What are the things that we have in our it infrastructures? So I really love about the
transparency there. So speaking about all these different benefits that we have seems like moving to the cloud is really beneficial. Also if you want to run in a more agile manner, so So coming back to the book title itself, Cloud strategy. Why do you think it's important to have a cloud strategy? What is the strategy here means the? Yeah. I'm first of all, going to the cloud is a big deal. There's many. Tulips are many things that help you get there. But at the same time that said,
it's a lifestyle change. It's also a major commitment offer than someone on money and steady gets long-term relationships, that build. So I think thinking carefully about how you go to the cloud. It's well, advise is a good idea. What happens what? I see happen too much. The way is that the journey to the cloud is driven by a specific objectives. We want to be 80% of a workloads in the cloud by anik state XYZ. We want to be the market leader and this of that segment.
So basically people end up stating the aspirations, but when it comes to actually making tough decisions about how to get there things get much more quite nessus, right? Son. Title of the book is really called a decision based approach to successful Cloud. Migration. Like when people show me the strategy with strategy is they always they look like a happy
story book. So here, we migrated out first workloads and then we migrate more workloads and then we go to containers and then we go to serverless and it's like everything just becomes great and they lived happily ever after the hit to breath is reality or even any meaningful sized organizations. Reality doesn't look like this. You need to Decisions. Are you got a bike ride everything at once or you going to migrate in bits and pieces?
If you do bits and pieces, what's going to come first? There's a million decisions, right? Well, which Cloud, you got to go to what kind of workloads are gonna go first. How are you going to change your Operational Support? Do you build up your Operational Support before you migrate something? Or do you do that after you migrate it? All of these are sensible ways to go about it and you strategy
is picking your path. I mean, in the end you can A decision tree with many nodes and plotting your paths. With that decision tree, that is really the strategy. Proclaiming. The end result is relatively easy navigating. The decision tree is much, much harder. So that's what I'm trying to do in the book. Not tell you what to do. But to teach you how to think about your problems. You can copy paste. Your Cloud migration from somebody else. To starting point is going to be
different. You constraints are going to be different. Your needs are going to be different you're competitive. Environment is Be different. There's many factors that spawned you to have your own strategy. But what I want to do is give you a building kit that makes it much easier for you to Define it that strategy. But it's not a copy-paste kind of exercise and it will never be speaking about copy paste. We all want to have best practices or best solution to
certain thing. We can just replicate. But I think migration to the cloud is not easy simply because every company has their own situation, their own skill sets. The people also me, Not be aware about the core technology. Plus, there are. So many Cloud providers with their own. So many products right there, just insurmountable amount of things that you need to learn. And you need to, also be aware of few things that are different between different clouds as well.
So I think our strategy here makes sense, but how then should people start thinking about what kind of strategy that makes sense for them? Because these days, there are many big name, card providers. There's also a hybrid Cloud Model either on-premise and cloud or multi-cloud. So, there's so many Options. How should someone start with building up their strategy? Yeah, you're right off in the strategy. Starts with picking the cloud provider. This is the classic it Playbook.
This is like, we need a database. So I go to talk to Microsoft and IBM and Oracle, right? And I make a school child when I pick the database. Ideally, you should pick an open source database, but eating is a classic it Playbook. And what we find time again, though, is that the vendor new station is just one out of many decisions. You Need to make. And just recently, wrote a blog post, actually try to have nuts to pick a cloud provider and it has clearly just comparing unit
costs. Tried applying the old way of thinking to, the new operating model is almost guaranteed to lead to prove himself. He much better starting point is to really think about what are the business metrics. I want to know, why am I doing? This is not because, in fact, I do interesting one because my resume needs some boosting,
right? I'm going to doing this thickens up, giving my business, some capabilities that It happened before and those are capabilities that business very much needs, like responding to uncertainty higher availability for the systems under high rates of change. These are all things that were very difficult to do on premises
that are possible in the club. And then I can start tracking by those metrics when it now, of course, there isn't a push button, which says, improve my business metrics will cloud provider hands that I wish. So now it comes to Translating that into a path. Now, the business is Is not going to be interested in each and every of your technical decisions, but what they might be interested in, is the principles that you apply. When you make the Wolves decisions. Let me give you a classic
example. Do you want to think things through very carefully and makes it a, one shot for a specific migration path. He figured it all out, you sorted out, I'll do what a lie is and you're just make a club it if you put it in the cloud. And in just beautiful, it's of a clot native users, everything into service. The Do I need to be the operational? Framework? It's beautiful, but it probably took some time to get there or do you say I prefer the shortest
paths to Value? So I left the chip 23 over somehow, maybe make some changes, maybe replace the app server with something open source. Maybe we place the database but by and large and leave it as it is, but which way you going to go? That is a great principle to Define. That's why I often say, do you want to have a principle of shortest path to value and you need to be honest and the Business will say, of course. Yes, we must show this pass the value, because, of course, we want value.
Then as an architect. What you need to say is that is great. But keep in mind that the shortest character value in the long run is a longer path than the straight shot. Right? In the book. I liken this to Pythagoras. If you can jump for bottom left to top right in from on premises, traditional model is all the boxing's. If you can jump the diagonal all the way into Cloud Server, this club made if that is the shortest path, but that might
not Be the shortest path. Stability of the shoulders passive value skin that zigzag a little bit. So no, those are the trade-offs. The business needs to understand and principles that imply those trade-offs on, a great way to guide the cloud. Migration. So I really like principle-based kind of a decision approach rather than which cloud provider should we choose? Because that is kind of natural for many people. We want to go to the cloud. Okay, which best cloud provider,
should we choose? But instead to start with the principles behind, why you moving to the cloud? Out and what kind of business metrics are you want to change by enabling using the cloud? So I really love that principle based approach speaking about these principles, right? I'm sure throughout your career. You have worked with many different customers, many different people in the IT industry. Do you see some common patterns or empty patterns that are interesting for us to learn from
you? I said at the beginning, you know, somehow our business tends to be defined by a pendulum could, hopefully swings back and forth. So we see quite a few swinging pendulum hit and the one that Eternal, it's always the multi-cloud. How much do I want to be a single cloud and how easy do when I want to make it to switch to another Cloud? It Panic on one hand. That is well, but why is right? Because they are we talked about uncertainty.
So if uncertainty forces you to change your vendor relationship, you should think about what that implies but what we find time and again is what is a very lengthy and architect way of City, gigas people falling into the extreme.
It's the one is stream is like or it's just redefined I go with the slide provider because on a like their most recently than do they give me a nice t-shirt that sort of the one extreme and the Other Extreme is of course, we need the over Uber Cloud abstraction something rather framework. Basically, we're gonna build our own cloud of other people's Cloud. So that way we can do whatever we want. The problem is both extreme. I probably equally pad. That's not like attack you
dealing with trade-offs. It's always occurred throughout the left and right and Point is never the best choice. The best choice is somewhere in the middle. We see this pendulum swinging back and forth. What people realize is when they walk this multi-cloud, you butter, something rather than layer the motivation isn't actually all about right there thinking about switching costs, more believe they call this lock hypnotism little bit of an Archer for me. It's really just switching cost.
If you want to switch to something else. How much is it gonna cost you? How long? Is it gonna take you to make that switch and then you can calculate what is the Unlikely or tap the switch happens. Now, you can buy yourself options. You can abstract things away and you can run containers. We can use open source, many, many options. You could buy to reduce that such angles as we set these
options, on all connected. To a cost of neck City or feature under utilization, is probably the biggest cost that you have. But there's one option that I see Enterprises much more dangerously neglecting this, this weird notion that It followed of lockean is somehow set by the vendor. Then somehow assume like this Vendome luxury because we're like some evil people who want to take all your body of whatever you think it's somehow assume that ended just a locking it.
I don't think that is true at all. If you defy the Locking as switching cost, you are switching. Cost is dramatically determined body, your organization's velocity and Agility like the rate of change. You can handle it, how Quickly, you can change things that is at least as the big factor in switching cost, anything that been vendor brings into the equation. So let's put it this way. Let's say your modern software delivery shot.
Everything is eicd automated, testing shift left gets a cop's whatever buzzwords you on the tire. But basically a low-friction sock delivery. If you have an idea you need to do something you could Implement and deploy this very quickly. Now, whatever reason it might be you need to Move things into a different cloud provider. What you take all your fully automated setups, right? You need to make some changes, probably different.
I am different databases underneath some different tunings yelling of making some changes, but you have a bell or a machine that can absorb this changes. You can test these changes. You can deploy these changes and off you go. Now that low lock in if you wish with air quotes, that low switching cost is because of the way you operate. The way I explain this is this is the very reason that you fight. Many startup companies not have the oldest tummy aches about
about the cloud strategy. The traditional business, they say, oh, well, the startups don't need about the cloud strategy because they are regulated. Then on every anything to lose blah blah blah bullshit. Physically, right? So that companies have a lot to lose, if it takes a highly regulated. This is not the reason. They're not having tummy ache. So party Cloud strategies. The real reason. Is there Hannah palasa teeth a lower friction. They have a lower cost of change.
So if some change comes along they just deal with it and they're not stuck for three years. They deal with it and six weeks, they're up and running in another cloud and maybe it's even three weeks that off they go. So in this pendulum that swings between these, like, how much do I need to be committed to what they do. The other the part that I find is too much neglected your your own velocity and that should be the biggest determinant of your switching costs.
Not whatever the vendor brings. To the table. Thanks for reminding us about this lock-in versus switching cost because you actually wrote a lot about this and discuss it online. Few months back. What different levels of locking are there? Is it like software lock in front door locking Hardware, looking and all that. Thanks for reminding us. Actually. The lock-in is simply something that you have to consider from your own point of view.
How much velocity can you do in the case that if you need to change? Can you really do it? Fast persuasive essay? You don't have much it skills. For example, so locking becomes more. Probably not even though probably the software vendor heart is not so difficult to move out from. So I think this is a good reminder for all of us.
Another thing that you wrote In the book about common and the pattern or mindset difference is that cloud should not be an infrastructure topic, but all these days people talk about cloud is more about moving their infrastructure live friendship, like from on-prem two, VMS or communities container and all that. Why do you think that it's not an infrastructure topic then you send it off in it?
Starts with infrastructure because Lance the classic ID moderate, you found the ticket, you get a server or VM but mainly the rest is with the application teams. The reasons that is no longer so is because we work in different ways. Reason we work in different ways is because the market has different demands for applications. We need applications that can undergo a high rate of change while maintaining High
reliability. Many people, Texas, still back then baked in. We do something quick and dirty, right? It's always this per seat dichotomy that we do either, I'm moving fast or I do something high quality. The couple of years ago is the analyst even tried to make this a lot of official with these ill-advised to speed architectures. They said, oh, on the front there and you can people be quickly, because if you break something, it's not so bad, but your back end, has to move very slowly.
They can see have to be going careful. I will side one chapter from the new software, architect elevator, and it's called snow chaos, is not order. Just moving slow leak. Doesn't Makes things actually better and we've actually found that moving faster often increases quality. That's where all the automation, see ICD all these kind of things happen to play in the idea of higher quality, High operational, reliability at the
height and weight of change. Now, the reason that relates to infrastructure is because that way of working is no longer infrastructure. Centre point of view. I already said, right. It's about see ICD about desktops, but delivery pipeline about software on Terminal. It's probably also about you. Medications infrastructure, your service measures. There's a lot of stuff around if that makes this whale working possible and that stuff isn't
infrastructure. So, if you want the cloud operating model, you don't want to look just at the infrastructure you want to look at what I cleaning or what. I call the be more often and application-centric law because that's where you get the velocity of the agility. That's where you get to move quickly. That is also how we reduce the switching cost. That's how you reduce type. Did you feature? Release. That's how you recover more quickly, in case something goes wrong.
So all of these benefits cannot come from the infrastructure alone. They come from a nice, interplay between application delivery and infrastructure. This is probably one of the biggest ships. I have a chapter in the book. It's called the cloud turns, the organization sideways. This place exactly on this. It used to be at this nice infrastructure layer. Then you have the middleware layer and the application layer and their own in their own layer.
And it turns out to actually operate The modern operating model in a high Pace model. You basically need to turn this sideways 90 degrees, where you work across the different layers. Well, folks who managed to do that. Those are in the end, the ones who lead the benefits from the cloud.
Migration, that's we see time. And again, and another quite common that I see along with this Cloud Journey, or since there are multiple clouds, since they have different options, that people can choose in terms of products services, and different ways of securing things. A lot of customers actually thinking about About building in-house platform, or in-house Cloud platform. So, to speak in what kind of abstraction layer to deal with
different complexities? For example, different apis, different products, different services and you mentioned this in one of the chapters of the book as well. What do you think about this strategy of building in-house Cloud platform? So, I like platforms unlocked and then riding a sheep book on platform strategy because something black forms and something very powerful. And I'm also a pretty big fan of the team too. Achieves, full crunch, which talks about platform teams.
The reason platforms are such a powerful concept diabetic, loudest, perfect. Peace out. Police that platforms are something relatively stable and harmonized, but at the same time they and nabal at high rate of change and a high rate of innovation. Sometimes if I want to wake up our customers a little bit. I tell that that the cloud you body is the same Cloud your competitors by the books of a slightly shocked.
This like, yes, the prince Apple off a cloud platform is standardization and harmonization. Otherwise the think and it's gay, but God Computing has surely been the biggest Innovation driver at the last decade in Acts on this Something Magic about platforms. Now, the question is, how should you deal with that in house?
But big fan of platform teams in house, they actually had cafta Kapoor. I was working closely originally were called with application infrastructure team, then we did like the infrastructure of term so much for the reasons.
We just mentioned. So we became the Rick productivity team and that was clearly a platform t, a couple of important things for such a platform team to 60 a. Make sure you enable the lot of traditional it when they want to harmonize something I had for that D of the ligand platform. They thinking about constraining the thinking part standards. You can't use this database, but you can only use that word. And here's the 70 quality Gates. You have to go through there.
Always think about constraint that's sort of the classic. It idea of application delivery, because Wild West and infrastructure. Some of having to come in and restore Law and Order that model makes for great continuity. Doesn't make for very great and it t, so platforms. Need to enable. That's the first thing.
The second thing is the platform's, your bill can be cast in store, like successful platforms, aren't they Envision the future in five years that you go to build that and that for the half years low that future essentially in place. This is not Works. If you look at AWS via great example, right is constantly evolving. It's always taking feedback from customers. So an in-house platform also needs to take feedback. You can't assume you're smarter than everybody else.
The third advice. I would give for in-house platforms. Don't rebuild. What other platforms have already done. There's at least three major Cloud providers, maybe four or five, depending on how you count. I haven't checked our combined market cap, but it's like somewhere five trillion plus There's a lot of smarts and a lot of innovation and a lot of things going in there. And that is a huge value for you. Because all that Innovation comes to you for like ten.
He's an hour or micro candy store API request. It's basically, they're cheap the way you get to consume that Innovation. Don't sing that with a small in-house platform team. You are not able to compete with that and build some sort of abstraction layer, then somehow magically keeps up with all the stuff that isn't that neat. So if you follow Those three points of administrative nabel crowd with a disabled that you take feedback, rather than thinking you're smarter than anybody else.
And if you don't replicate everything and it's all these layer, I think you can have a very productive and very happy in-house platform T because you can make assumptions that are true in new organization that might not be true. In all organizations the platform, like AWS need to support many different Enterprises and digital native businesses. So maybe you can narrow Oh things down a little bit that is totally fine.
You can make smart default. You can defy processes that are related to eat Industries. There's many great things in there. But I highly advise you to follow the three ground rules of making it in halves platform team and also that each of the cloud provider itself evolves, right? So, their products change their new products coming out as well, how they interplay each other.
I think it's also something that sometimes the platform team didn't foresee in the beginning when they wanted to build a platform. They I'll be see. Okay, this card provider provides, this kind of capabilities now, but actually maybe one year after that all things will change. You also have to maintain or even change a refactor, the kind of platform that you have built over the time in order to keep up with the changes from the cloud providers. I think it's also something that
is very tricky to deal with. And another thing that it's quite common, speaking about it industry, these days is about shiny object syndrome or passwords. Then you have this long, which you call a Gregor's log, excessive complexity. So what? Is the relation of complexity here and you know, like password driven, kind of development. You have to. We talked about complexity a few times.
I think if this whole exercise complexity is your biggest enemy because complexity slows you down complexity. It reduces errors complexity hurts your operational abilities. In the end complexity is really the root of much evil that we say, like, if you go back to the beginning, that's really the options Marketplace, having options. That's great options, cost. You the cost is usually complexity in finding a good
path. Once the hair is probably, when I get x to the reason I relate this to shiny objects, and passwords is because being a knight TD. Sting is, can be like the kid in the candy store. All the stuff. You have, all the different open source projects with like, ridiculous names and we are 200 service in San. Aw us as well. Like you add the other services from the other Cloud providers.
You just have stuff to know it and when you keep spewing out, these kind of bus routes, a couple of dogs things actually happen, a it doesn't make a viable strategy. It's just like a mishmash of like random stuff. And the other thing that it will also do is it will cause enormous complexity, big kitchens like a pile of random Singh said, you think you'd need to have it's like going to the supermarket and there's all these great fantastic foods. You can happen. You like all of them.
So you pick them pop Corning, you pick the Pasta sauce and he took the steak and you pick all this kind of stuff because he liked all of them, you put it in one big pot. Then you cook this and nobody's going to eat. Instantly like it edible. So, ideal strategy. It's like this. You can't fall victim to the bus words. You need to have in mind. What am I going to cook? Get the right ingredient to? What are you going to cook? And put the right pieces together? You can just randomly
mix-and-match, other words. The reason that relates to Gregor's law, is it comes back to having the options. Having options is nice. But in the extreme caves, you will find folks who want all of the Objects or what if this happens? What if I need to go in another industry, or what? If I need to change my technology, what if I need to operate on Mars? What if the aliens invaded, I need to be prepared with my idea of structure. I just need to have all the
options. These are the people who never want to make a decision. The decision is to just have all options available at all. Time. I'm seeing this and I can't this Gregor's law and and then it goes as follows. Excessive complexity is Nature's punishment for organizations who are unable. To make decisions somebody who wants everything. It was just like blinded by all the passwords. It has to be this. There has to be that and it has
to be able to do this. They suffer from excessive complexity and that in the end is what slows them down. The weird part of it is the ironic part is often. They took this route under the idea that somehow it would reduce Market because they want to have all the options I do. If I have all the options that never really knocked it to anything but in the end. Then locked into their own complexity, more than anything else. And that is Nature's punishments, right?
That is the essence of Gregor's law. So go make some decisions, make conscious decisions, take some options, but also makes some conscious decisions that were you get the complexity doubted, your life would be much happier. I really love that love. So excessive complexity is
Nature's punishment. If you are unable to make any decision, thanks for reminding that and I think I could relate to These as well, sometimes we just want all the options available, all the cool Technologies out there. But actually, we are like stuck in all the complexities by first of all having to learn each of the technology and also how they interplay with each other. Right? And the second thing is that what are the available people to
support all this complexity? Maybe last question on this Cloud strategy. How should an organization actually embark on this journey. So, how do you structure your team? How do you obscure your people? How do you actually go about it in terms of organizational level? Yes, it's always a people topic, but transformation. The a tech is all available more than you probably will ever need. So in the end, it's really changing the way of working.
If you don't change the way your organization works, the cloud is coming. Look much more. Like another data center. We have very nice data centers, but no it executive. I've met ever needed another data set so you should change the way your folks operate and think about it. I should have a chapter in the book, right? Because we always talk about that, five six or seven hours off my Ready applications. So should you find the Mrs of my grading?
Your work force because you also need to re-skill sometimes replaced. Sometimes retire your Workforce, couple of things. I always say up from the most common concern is are the executives come to these? Like I get all this Cloud software really want to do it, but I don't have to like people so it's like I don't have any people that I can't hire the right people because I'm a boring exercise that Cuppa tea. I'm not a Silicon Valley Hotshot. I usually pause the
conversation. Right there and I make people take two very important factors. It took hell. Did he? If you think your people are risk, averse, or they don't want to change or they're not like to sort of work in this new environment. You late the behave, that way when I was in kindergarten, nobody was thinking about locking in and being risk averse. And not trying things out. You organization, tall people that taking risks is not a rewarded, but it might be punished.
Then there's no support for experimentation trying new things. You organization talked about, so now you're liable to and teach them that. Because if you've been teaching that to them for 20 years, you can say you have the wrong people. You have exactly the people that you taught them to be. So don't come to me now and say, oh, I need different kind of P. You taught them you and teach them that's fundamental.
Number one. Fundamental number two is most of the time you actually have the right people. The favorite story. There is an old interview with agent copy. Laughter also works at animals out where somebody says. Well, he was a Netflix at the time because super sexy super hot company. He says you can do all these things because he like Netflix. You have all these great people and enduring. And certainly said, well, you know, where we hired from, we
hired a lot from your company. All right, and people of course, have the Blank Stare, so you probably have the people, they're just being held back by interested, friction inside. And we think takes forever, you try the approval processes. You can't get anything done. People are being slow, down. Salt for me. The people transformation story.
Always starts with you taught them, you are ditch them and the obvious assumption should be. You have the right, people unleash that potential and you might be positively surprised. What actually can happen in your organization. Wow. So thanks again for reminding us because sometimes we think that oh to be called a verse, we have to have the great enough people Talent. And we can't hire them because they are.
First of all, maybe not many are available out there in the market because a lot of companies are trying to recruit all of them. Speaking about getting the talents. Maybe you should look inwards, try to upskill or maybe, remove all the constraints or what you said is unteach them. The constraints that they know and start to, let them play the experiments in order to learn and also gain the benefits of learning along the way. So really love that. So, Gregor is been a really
Pleasant conversation. I really love this a lot. Since we are out of time, I only have one last question that I normally ask to all my guests, which is about three technical leadership wisdom for you to share with all of us here so that we can learn from your wisdom. If it's a great topic. Thanks for the chair. We could talk a lot more. Yes. So I think there's more than three wisdoms.
But if I had to pick three, the first one that comes to my mind is and recently saw blog post, is actually from chloroquine. We post a lot about cloud and a double years, and he said, you're not the technology. E you work out. You're not a survivalist developer. You're not agglomerated to the number. You're not in need of being single opinion.
Are the gcp that I'm going for. This is just Tech stuff that comes and go. What you create is much beyond that and I think being an architect is at the very essence of that. Don't lock yourself in with the technology the second one relates closely. What we said about Bus words, right out of a lot of frustration with people who screw out buzzwords. So this is sort of like the corner of Richard Fineman.
I always say if you can't explain What you're doing and what you're proposing to do it. Plain English. You just simply don't understand. There's no excuse for confusing. People always say, uit shouldn't look like an episode of the old Battlestar Galactica where the right all we need to go. Seven qualms to reach the proton, something rather. They speak descriptive language that, nobody knows technology, shouldn't be like that. You need to bake yourself. Aren't stuck.
That way, you get buy-in for the decisions and you best do late functioning or All the passwords and the last one inspect a regular slaw complexity is a punishment. Complexity isn't biggest. Any be so gold. Don't be afraid to make some decisions reduce the complexity. So you don't fall victim to Gregor's law. I really love when you said that, if you can explain it in plain English, most likely, you don't understand it. So, I think it's also something that we need to ponder.
For example, if you want to propose that use kubernetes, can you explain it in plain English with all this jargons and terms like, There's orchestration schedule and whatever. I think it's really great, reminder for all of us. Before we propose something, we probably should be able to explain it in a simplified manner or cleaning list, so to speak. So Greg up, if people want to have more conversation with you or find your work. Is there a place for them to find it online?
Yeah. So my home is architect, elevator know.com. There's also Cloud strategy, books.com, some relatively easily found and corrected for LinkedIn. So, that's also a good place. To interact and unbolt equally active on Twitter. It's g, h, or h v is my handle. Their Twitter is more mix of opinions and random stuff, but I diode. So look out for other people for advice on Twitter. So, truly a community, may actually like quite a bit and always look forward to hearing back to your feedback.
So please don't be shy to post anything online. I'll be happy to see them respond to that. Then I highly recommend the book as well. Cloud strategy including also the software architect elevator, which is also quite insightful in terms of How do you become a great software architect? So make sure to check those books and support regular in all his writing. So thanks Gregor for your time. Today is really a wonderful conversations. So hope you good luck for whatever that you do next. Yep.
Thank you so much. And I know what I'll do next Saturday right of the platform strategy book. So maybe we'll talk again in a few months. So here about what that came out to be. Thank you for the time. Thanks to all the listeners for listening to the podcast, right? Looking forward to that. Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better. You can also find the full show notes of this conversation on the episode page at technology.
No, the death website. Adding the full transcript, interesting quotes, and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the show's mailing list on technology. No, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.