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.