1
00:00:00,000 --> 00:00:02,600
Today's episode of the 
technology on our podcast is 

2
00:00:02,600 --> 00:00:06,600
proudly sponsored by emergence. 
The Journal of business agility.

3
00:00:07,200 --> 00:00:10,200
This quarterly publication 
brings you inspiring stories 

4
00:00:10,200 --> 00:00:12,800
from the most Innovative 
companies and explores the 

5
00:00:12,800 --> 00:00:15,900
themes of the new ways of 
working reclaiming management 

6
00:00:15,900 --> 00:00:19,100
and humanizing business. 
It brings together a curated 

7
00:00:19,100 --> 00:00:22,200
selection of exclusive stories 
by great, thinkers and 

8
00:00:22,200 --> 00:00:25,200
practitioners from around the 
globe that can broaden your 

9
00:00:25,200 --> 00:00:27,400
horizons and Spark. 
Your creativity. 

10
00:00:28,000 --> 00:00:32,600
Each issue is hen Illustrated. 
And contains 100% pure content, 

11
00:00:33,000 --> 00:00:38,000
use the promo code Tech lead. 
The ECHL EAD to get a 10% 

12
00:00:38,000 --> 00:00:40,200
discount on your annual 
subscription. 

13
00:00:40,600 --> 00:00:44,000
Visit business agility, dot 
Institute, / emergence, to get 

14
00:00:44,000 --> 00:00:46,900
your addition and support the 
publication supporting your 

15
00:00:46,900 --> 00:00:49,300
podcast. 
Here's the link One More Time. 

16
00:00:49,400 --> 00:00:52,400
Business agility, dot Institute,
/ emergence. 

17
00:00:52,900 --> 00:00:56,000
What's more interesting to be 
when we talk about the cloud? 

18
00:00:56,000 --> 00:01:00,900
Is it changing operating table? 
It's really Finding the 

19
00:01:00,900 --> 00:01:03,400
interface you having with 
Europe, 80. 

20
00:01:03,700 --> 00:01:07,000
That's why I always say cloud 
instance, it procure, but it's 

21
00:01:07,000 --> 00:01:09,800
not something you buy. 
It is really on a lifestyle 

22
00:01:09,800 --> 00:01:13,600
change because if the old terms,
the way to deal with the ideas, 

23
00:01:13,600 --> 00:01:16,900
we find particular to make a 
request things, take some time 

24
00:01:17,100 --> 00:01:19,100
transparency is a little bit 
limited. 

25
00:01:19,100 --> 00:01:22,000
Once you order something usually
stuck with it for many years 

26
00:01:22,000 --> 00:01:23,600
until it's appreciated. 
Right? 

27
00:01:23,700 --> 00:01:27,000
And of course, Cloud operating 
model turns that completely on 

28
00:01:27,000 --> 00:01:29,700
its head, you can have stuff 
whatever you want it, you can 

29
00:01:29,700 --> 00:01:31,400
do. 
Dispose of it whenever you want 

30
00:01:31,400 --> 00:01:34,400
to degree create it. 
It's a highly Dynamic 

31
00:01:34,400 --> 00:01:36,700
environment. 
So in the end, it's really 

32
00:01:36,700 --> 00:01:40,000
changing the way of working. 
If you don't change the way your

33
00:01:40,000 --> 00:01:42,200
organization works, the cloud is
coming. 

34
00:01:42,200 --> 00:01:44,200
Look much more like another data
center. 

35
00:01:49,100 --> 00:01:51,900
Hey everyone. 
My name is Henry Surya, be 

36
00:01:51,900 --> 00:01:55,300
Robin. 
And you're listening to the 

37
00:01:55,300 --> 00:01:58,300
tekhelet journal. 
The show will be bringing you 

38
00:01:58,300 --> 00:02:01,700
the greatest technical leaders 
practitioners and thought 

39
00:02:01,700 --> 00:02:05,100
leaders in the industry to 
discuss about their Journey 

40
00:02:05,500 --> 00:02:09,699
ideas and practices that we all 
can learn and apply to build a 

41
00:02:09,699 --> 00:02:13,300
highly performing technical team
and to make an impact in your 

42
00:02:13,300 --> 00:02:17,000
personal work. 
So let's dive into our Journal. 

43
00:02:22,300 --> 00:02:25,200
Hello to all my listeners. 
Out there super excited to be 

44
00:02:25,200 --> 00:02:28,000
back here again with another 
episode of the taglit journal 

45
00:02:28,000 --> 00:02:30,300
podcast. 
I'm your host and research 

46
00:02:30,300 --> 00:02:32,700
everyone. 
And I'm so happy to announce 

47
00:02:32,700 --> 00:02:36,900
that technology not podcast has 
reached its 50th episode. 

48
00:02:37,100 --> 00:02:39,800
While it is personally, a great 
milestone for me. 

49
00:02:40,000 --> 00:02:42,700
And what a great one year 
Journey, it has been. 

50
00:02:43,000 --> 00:02:46,200
I'm so thankful for all of you. 
My listeners who listen, and 

51
00:02:46,200 --> 00:02:49,800
support this podcast, especially
those of you who have been there

52
00:02:49,800 --> 00:02:52,500
since the beginning, and I 
couldn't have made it without 

53
00:02:52,500 --> 00:02:55,500
any of you. 
Also a special thanks to all of 

54
00:02:55,500 --> 00:02:58,900
the amazing guests that I have 
on the show and especially for 

55
00:02:58,900 --> 00:03:02,400
sharing your story valuable 
wisdom and knowledge. 

56
00:03:02,700 --> 00:03:05,800
Last but not least. 
Thank you to all of my patrons 

57
00:03:06,000 --> 00:03:09,200
who have continuously supported 
my journey and for giving me the

58
00:03:09,200 --> 00:03:13,200
extra energy and motivation to 
produce high quality content. 

59
00:03:13,500 --> 00:03:16,700
I'm so grateful to everyone of 
you and I hope we can continue 

60
00:03:16,700 --> 00:03:20,700
this journey for more episodes 
to come special mention to those

61
00:03:20,700 --> 00:03:23,400
of you who helped me to promote 
these podcasts on the social. 

62
00:03:23,600 --> 00:03:27,200
A platform either by following 
liking and re sharing some of 

63
00:03:27,200 --> 00:03:30,300
the contents, all of you helped 
me a lot in reaching out to 

64
00:03:30,300 --> 00:03:32,800
Molly's illness. 
And I can't thank you enough for

65
00:03:32,800 --> 00:03:34,600
that. 
Speaking of which, if you 

66
00:03:34,600 --> 00:03:37,000
haven't, please subscribe to 
Tech lead journal on your 

67
00:03:37,000 --> 00:03:40,300
favorite podcast apps and also 
follow our social media channels

68
00:03:40,300 --> 00:03:43,500
on LinkedIn, Twitter and 
Instagram, you can also make 

69
00:03:43,500 --> 00:03:46,700
some contribution to the show by
subscribing as a patron at 

70
00:03:46,700 --> 00:03:49,200
technology. 
No, the death / Patron, and help

71
00:03:49,200 --> 00:03:51,900
me to continue producing. 
Great content every week. 

72
00:03:52,300 --> 00:03:56,400
To celebrate the 50th episode. 
I am extremely happy to share my

73
00:03:56,400 --> 00:04:00,100
conversation with Gregor. 
Hope Gregor is currently an 

74
00:04:00,100 --> 00:04:03,800
Enterprise strategies at AWS. 
And the author of many popular 

75
00:04:03,800 --> 00:04:07,400
books, such as Enterprise 
Integration patterns software, 

76
00:04:07,400 --> 00:04:09,500
architect elevator and Cloud 
strategy. 

77
00:04:09,500 --> 00:04:13,100
In this episode. 
We started our conversation by 

78
00:04:13,100 --> 00:04:15,000
discussing about the role of a 
software architect. 

79
00:04:15,000 --> 00:04:18,000
There are a lot of different 
opinions about software 

80
00:04:18,000 --> 00:04:20,899
architectural and Gregor. 
Explain the fundamental skills 

81
00:04:20,899 --> 00:04:24,200
required from a software. 
Architect and the reason why 

82
00:04:24,200 --> 00:04:27,500
there is the latest Resurgence 
of the role within the industry,

83
00:04:28,200 --> 00:04:30,700
he also explained about his 
software architect elevator 

84
00:04:30,700 --> 00:04:34,000
concept and then describe what a
good architecture should look 

85
00:04:34,000 --> 00:04:36,100
like. 
And how to deal with trade-offs 

86
00:04:36,100 --> 00:04:40,000
by using the analogy of 
financial options in the second 

87
00:04:40,000 --> 00:04:43,100
half of the conversation. 
We then discussed in depth about

88
00:04:43,100 --> 00:04:46,000
the cloud and the reasons why 
adopting Cloud requires a 

89
00:04:46,008 --> 00:04:48,500
lifestyle change, in order to 
benefit from it. 

90
00:04:48,500 --> 00:04:52,800
The most Gregor also describe, 
why organizations Need a good 

91
00:04:52,800 --> 00:04:56,300
viable Cloud strategy and debunk
the concern of many 

92
00:04:56,300 --> 00:04:58,900
organizations on cloud vendor 
lock-in. 

93
00:04:59,600 --> 00:05:02,800
He also gave his tips on how 
organizations should approach 

94
00:05:02,800 --> 00:05:04,800
building an in-house Cloud 
platform. 

95
00:05:05,000 --> 00:05:07,400
And how to change the 
organization structure to 

96
00:05:07,400 --> 00:05:10,200
embrace the cloud better towards
the end. 

97
00:05:10,300 --> 00:05:13,300
You do not want to miss our 
insightful discussion on the 

98
00:05:13,300 --> 00:05:15,800
Gregor's law of excessive 
complexity. 

99
00:05:16,400 --> 00:05:19,600
I really enjoy my conversation 
with Gregor learning about 

100
00:05:19,600 --> 00:05:22,400
software architecture and the 
cloud, and even though, I've 

101
00:05:22,407 --> 00:05:24,100
been working with a cloud for a 
while. 

102
00:05:24,200 --> 00:05:27,000
There are still a lot of things 
to learn from Gregor throughout 

103
00:05:27,000 --> 00:05:29,600
this conversation. 
And I'm sure that you will enjoy

104
00:05:29,600 --> 00:05:32,500
this episode as well. 
Consider helping the show by 

105
00:05:32,500 --> 00:05:35,900
leaving the rating review, a 
comment on your podcast app or 

106
00:05:35,900 --> 00:05:39,600
leave us some comments on our 
social media channels, those 

107
00:05:39,600 --> 00:05:42,300
reviews and comments are one of 
the best ways to help me get 

108
00:05:42,300 --> 00:05:46,000
this podcast to reach more 
listeners and hopefully they can

109
00:05:46,000 --> 00:05:49,000
also benefit from all the 
contents in this podcast. 

110
00:05:49,200 --> 00:05:51,500
So let's get this episode 
started right away. 

111
00:05:54,100 --> 00:05:56,400
Everyone, welcome back to 
another new episode of the 

112
00:05:56,400 --> 00:05:57,800
package. 
You know today. 

113
00:05:57,800 --> 00:05:59,800
I'm very excited to have a guest
with me. 

114
00:06:00,000 --> 00:06:03,700
He is a very famous guy in the 
tech scene all over the world. 

115
00:06:03,900 --> 00:06:05,700
He has an illustrious career as 
well. 

116
00:06:06,000 --> 00:06:09,100
So he has been a Chief Architect
at Allianz technology, technical

117
00:06:09,100 --> 00:06:12,500
director at Google, and also 
work with gastic Singapore as a 

118
00:06:12,500 --> 00:06:14,400
smart Nation fellow. 
Currently. 

119
00:06:14,400 --> 00:06:17,100
He is working at AWS as 
Enterprise strategies. 

120
00:06:17,400 --> 00:06:18,600
He is Gregor. 
Hope. 

121
00:06:18,800 --> 00:06:22,200
He also wrote a lot of books. 
Few of the popular ones. 

122
00:06:22,500 --> 00:06:25,100
Like Enterprise Integration 
patterns Cloud strategy, the 

123
00:06:25,100 --> 00:06:27,400
recent one and software 
architect elevator. 

124
00:06:27,600 --> 00:06:30,100
So today, we are going to 
discuss a lot about Cloud 

125
00:06:30,100 --> 00:06:33,000
strategy and a little bit about 
software, architect elevator. 

126
00:06:33,200 --> 00:06:36,000
So Gregor really, really pleased
to have a conversation with you 

127
00:06:36,000 --> 00:06:37,700
today. 
Looking forward to learning from

128
00:06:37,700 --> 00:06:38,800
you. 
Thank you. 

129
00:06:38,800 --> 00:06:41,100
Thank you for having me on 
looking forward to the session 

130
00:06:41,100 --> 00:06:43,200
as well. 
I know we can trying to make 

131
00:06:43,200 --> 00:06:46,400
this happen for a little while. 
So I have even more excited to 

132
00:06:46,400 --> 00:06:48,900
actually be on the show. 
Their thanks for that. 

133
00:06:49,100 --> 00:06:50,400
So maybe Gregor in the 
beginning. 

134
00:06:50,400 --> 00:06:52,200
Can you introduce yourself to 
those people? 

135
00:06:52,200 --> 00:06:54,000
People who may not be familiar 
with you. 

136
00:06:54,000 --> 00:06:56,600
Yet, maybe sharing your 
highlights turning points in 

137
00:06:56,600 --> 00:06:58,200
your career. 
Sure. 

138
00:06:58,200 --> 00:07:00,400
My name is Gregor. 
I would say. 

139
00:07:00,400 --> 00:07:04,300
I have probably seen it from 
every possible angle. 

140
00:07:04,300 --> 00:07:07,700
You could imagine the co-founded
the start of back in the old 

141
00:07:07,700 --> 00:07:09,700
days before. 
Everything was a unicorn. 

142
00:07:09,900 --> 00:07:12,100
I worked a lot of time in 
Consulting, Professional 

143
00:07:12,100 --> 00:07:15,700
Services, and I was a Silicon 
Valley software engineer. 

144
00:07:15,700 --> 00:07:18,600
I worked in a large Company ID. 
Right now. 

145
00:07:18,600 --> 00:07:21,500
I work for a cloud provider and 
I worked at public sector. 

146
00:07:21,800 --> 00:07:25,200
So, Say I've always been curious
and I always been Keen to see 

147
00:07:25,200 --> 00:07:26,900
things from different 
perspective. 

148
00:07:27,100 --> 00:07:30,900
It's also forced me to not a lot
of things and as you mentioned I

149
00:07:30,900 --> 00:07:34,200
like to write about the things I
learn solar books. 

150
00:07:34,200 --> 00:07:37,400
I will go see about the role 
Architects that are at the 

151
00:07:37,400 --> 00:07:41,400
website called architect and the
data.com and I think blutarch 

152
00:07:41,400 --> 00:07:44,900
coveted more about, but we think
an architect might be a should 

153
00:07:44,900 --> 00:07:46,600
be. 
And how than all relates to 

154
00:07:46,600 --> 00:07:50,300
Cloud architecture includes 
strategies speaking about 

155
00:07:50,300 --> 00:07:51,300
software. 
Architect. 

156
00:07:51,300 --> 00:07:54,600
I think in the last Last few 
years or so software architect 

157
00:07:54,600 --> 00:07:58,000
in terms of their name of the 
role has become one solution. 

158
00:07:58,000 --> 00:08:01,100
Whereby people will be a little 
bit skeptical so to speak, 

159
00:08:01,100 --> 00:08:02,500
right? 
When someone introduce 

160
00:08:02,500 --> 00:08:04,900
themselves as a software 
architect, we will then hesitate

161
00:08:04,900 --> 00:08:08,600
and see the person is this real 
person that will be useful to 

162
00:08:08,600 --> 00:08:11,500
deal with because of the 
connotation, of architect means 

163
00:08:11,500 --> 00:08:14,200
like a knife or a towel kind of 
architecture whereby, they will 

164
00:08:14,200 --> 00:08:16,100
document. 
And also just give orders and 

165
00:08:16,100 --> 00:08:19,000
directions without actually 
having a low-level practical 

166
00:08:19,000 --> 00:08:21,500
hands-on experience. 
So, in your point of view, then 

167
00:08:21,500 --> 00:08:24,800
what is the role Of software 
architect and this fit really 

168
00:08:24,800 --> 00:08:27,600
interesting. 
We often say that in our field 

169
00:08:27,600 --> 00:08:30,300
things swing, in a pendulum. 
It used to be like The 

170
00:08:30,300 --> 00:08:33,299
Architects, make all the 
decisions and other people just 

171
00:08:33,299 --> 00:08:35,900
fill in the blanks. 
Then there was a time where we 

172
00:08:35,900 --> 00:08:38,000
really thought we don't need 
Architects. 

173
00:08:38,299 --> 00:08:41,400
Mostly driven by the internet 
and the popular Frameworks 

174
00:08:41,400 --> 00:08:44,100
basically made. 
All the architecture. 

175
00:08:44,100 --> 00:08:46,200
Decisions for us. 
We felt for a while. 

176
00:08:46,400 --> 00:08:49,700
This has we just use Framing and
we use HTTP and there is our 

177
00:08:49,700 --> 00:08:53,600
architecture recently. 
We see the A huge Resurgence. 

178
00:08:53,800 --> 00:08:55,700
I'm an awesome. 
Sorry, would know a lot of 

179
00:08:55,700 --> 00:08:58,400
fellow officers. 
They write about architecture 

180
00:08:58,400 --> 00:09:00,600
with its microservices 
architectures, whether it's 

181
00:09:00,600 --> 00:09:02,600
event-driven architecture is, 
whether it's Cloud 

182
00:09:02,600 --> 00:09:05,000
architectures. 
We have architecture events of 

183
00:09:05,000 --> 00:09:07,600
suddenly architecture is back 
everywhere. 

184
00:09:07,900 --> 00:09:12,300
I think part of the reason is 
that the software we build is 

185
00:09:12,300 --> 00:09:16,900
enormously powerful, but it's 
also admittedly fairly complex, 

186
00:09:16,900 --> 00:09:19,800
right everything these days is 
distributed and horizontally, 

187
00:09:19,800 --> 00:09:22,000
scalable and to restart a 
bubble. 

188
00:09:22,300 --> 00:09:25,700
And resilient and anti trajan, 
whatever label you want to put 

189
00:09:25,700 --> 00:09:28,900
out there. 
It's just fantastic, but it's 

190
00:09:28,900 --> 00:09:33,100
also complex so I could take 
action helps us deal with this 

191
00:09:33,100 --> 00:09:36,600
complexity. 
What we've also come to terms 

192
00:09:36,600 --> 00:09:41,000
with I think is that having 
architecture as once named Doing

193
00:09:41,000 --> 00:09:44,900
architecture is another saying 
and having Architects itself, 

194
00:09:45,100 --> 00:09:48,200
and the simple answer is, you 
always have an architecture. 

195
00:09:48,200 --> 00:09:50,000
You can choose. 
If you write three lines of code

196
00:09:50,000 --> 00:09:51,900
listing is going to have some 
architecture. 

197
00:09:52,200 --> 00:09:55,900
So chose, most people have also 
realized that doing architecture

198
00:09:55,900 --> 00:09:58,200
consciously. 
It's a worthwhile exercise 

199
00:09:58,200 --> 00:10:01,900
because if you don't do it, 
usually end up with a big bottle

200
00:10:01,900 --> 00:10:04,900
but kind of architecture, right?
You get the giant spaghetti 

201
00:10:04,900 --> 00:10:08,300
default, but the sad part is 
like, well, do you have 

202
00:10:08,300 --> 00:10:10,700
Architects do the architecture 
or not? 

203
00:10:10,700 --> 00:10:13,200
I found that we have a much more
open mindset. 

204
00:10:13,200 --> 00:10:17,600
Some people still prefer to have
a dedicated architecture team. 

205
00:10:17,600 --> 00:10:20,700
Sometimes you have Architects 
embedded in the software teams, 

206
00:10:20,700 --> 00:10:24,300
and sometimes the I could take 
Is done by everybody and I 

207
00:10:24,300 --> 00:10:27,000
really like that. 
So I think we debunk this 

208
00:10:27,000 --> 00:10:29,200
discussion up. 
Associating do a good 

209
00:10:29,200 --> 00:10:32,600
architecture with having this 
Ivory Tower attended by 

210
00:10:32,600 --> 00:10:34,200
Architects. 
And I think that's been very 

211
00:10:34,200 --> 00:10:37,400
healthy for the dialogue. 
So in terms of software, 

212
00:10:37,400 --> 00:10:41,000
architect role, I think, one of 
the thing recently, especially 

213
00:10:41,000 --> 00:10:44,100
in the startup and all these 
Asia, they always say, do the 

214
00:10:44,100 --> 00:10:47,200
minimum as you can, but I like 
when you said that, there is 

215
00:10:47,200 --> 00:10:49,800
always an architecture in your 
system, no matter whether you 

216
00:10:49,800 --> 00:10:52,000
plan it properly, do consciously
or not. 

217
00:10:52,200 --> 00:10:53,900
Not, there will always be an 
architecture. 

218
00:10:54,100 --> 00:10:57,100
So what do you think is the 
importance of the role of 

219
00:10:57,100 --> 00:10:59,400
software architecture? 
Can you explain to us? 

220
00:10:59,400 --> 00:11:01,700
Why do you think a software 
architect will is probably still

221
00:11:01,700 --> 00:11:04,600
required? 
I often, how do you like that? 

222
00:11:04,700 --> 00:11:08,000
It's not about developers. 
Having to become Architects and 

223
00:11:08,000 --> 00:11:10,700
Architects. 
Somehow being a more senior 

224
00:11:10,700 --> 00:11:13,000
developer role. 
I see them as different roles 

225
00:11:13,000 --> 00:11:15,400
Each of which is valuable in its
own. 

226
00:11:15,700 --> 00:11:18,700
Well, I see The Architects doing
is a couple of things. 

227
00:11:18,800 --> 00:11:22,100
The one thing is that the 
Architects, generally see, the 

228
00:11:22,200 --> 00:11:25,000
System in the larger scope 
nights. 

229
00:11:25,000 --> 00:11:28,000
Coordinates on the book about 
architecting complex, real life 

230
00:11:28,000 --> 00:11:30,600
systems, like oil, drilling 
platforms, and stuff like that. 

231
00:11:30,700 --> 00:11:33,400
Where it really describes the 
role of the architect, very 

232
00:11:33,400 --> 00:11:36,700
nicely and setting. 
While in the end, you really 

233
00:11:36,800 --> 00:11:40,700
responsible for your part of the
system, but at the same time you

234
00:11:40,700 --> 00:11:44,100
accountable for the whole part 
around it for the system as a 

235
00:11:44,108 --> 00:11:46,500
whole. 
That's why Architects need to 

236
00:11:46,500 --> 00:11:50,200
look more lifted rhymed and they
can't just work based on 

237
00:11:50,200 --> 00:11:52,000
requirements. 
Architect. 

238
00:11:52,200 --> 00:11:55,400
It's 2:30. 
What I call is work based on non

239
00:11:55,400 --> 00:11:57,800
requirements, the tacit 
assumptions. 

240
00:11:57,800 --> 00:12:01,400
The things that nobody's singled
out by just things that weren't 

241
00:12:01,400 --> 00:12:04,800
actually written down anywhere 
and I think those are the key 

242
00:12:04,800 --> 00:12:07,400
inputs for a successful 
architect. 

243
00:12:07,900 --> 00:12:10,300
And you have this term called 
software architect. 

244
00:12:10,300 --> 00:12:12,900
Elevator. 
Is that somehow related to what 

245
00:12:12,900 --> 00:12:15,600
you just mentioned? 
So Architects should work based 

246
00:12:15,600 --> 00:12:18,900
on the non mention or non 
specific requirements. 

247
00:12:19,100 --> 00:12:21,400
Can you maybe share a little bit
more about the concept of 

248
00:12:21,400 --> 00:12:22,800
software? 
Elevator. 

249
00:12:23,300 --> 00:12:24,900
Yes. 
I have the name of my book and 

250
00:12:24,900 --> 00:12:28,200
my website, so it's something 
that's close to my heart. 

251
00:12:28,200 --> 00:12:31,600
Obviously, we just set the 
Architects need to have a wider 

252
00:12:31,600 --> 00:12:34,500
scope that need to see the 
system as a whole, and they need

253
00:12:34,500 --> 00:12:36,100
to watch us work on the 
requirements. 

254
00:12:36,100 --> 00:12:38,300
She but basically fill it the 
place. 

255
00:12:38,600 --> 00:12:42,600
Now, how you gonna do that? 
The way you do this is you look 

256
00:12:42,600 --> 00:12:45,500
at your system from different 
levels of abstraction. 

257
00:12:45,700 --> 00:12:48,300
You see it in the business 
context in the Strategic 

258
00:12:48,300 --> 00:12:51,700
context, or you take the 
elevator down to the engine room

259
00:12:51,700 --> 00:12:53,800
to see. 
See a system in a very technical

260
00:12:53,800 --> 00:12:56,700
contexts and what you Fareed, 
especially knowledge 

261
00:12:56,700 --> 00:12:59,300
organization cyst, these 
different layers, these 

262
00:12:59,300 --> 00:13:02,300
different context. 
They actually shockingly 

263
00:13:02,400 --> 00:13:04,700
separate from each other. 
There's some people doing the 

264
00:13:04,700 --> 00:13:07,300
financial bear witness and the 
people doing the strategy. 

265
00:13:07,600 --> 00:13:10,500
There's other people doing, 
mergers and Acquisitions, go to 

266
00:13:10,500 --> 00:13:12,700
market entry and there's 
somebody down there. 

267
00:13:12,700 --> 00:13:14,900
Configure ihum charts link 
between us. 

268
00:13:14,900 --> 00:13:16,800
That is a big giant. 
Boy. 

269
00:13:17,100 --> 00:13:20,300
That is exactly what I call the 
architect elevator. 

270
00:13:20,300 --> 00:13:24,300
Let someone who can move for, Us
these different layers and make 

271
00:13:24,300 --> 00:13:27,800
sure they're connected. 
Now in an ideal State, an 

272
00:13:27,800 --> 00:13:31,200
organization would be very 
natural, very well-connected 

273
00:13:31,200 --> 00:13:33,700
that would call those like a 
bungalow, basically, where 

274
00:13:33,700 --> 00:13:37,500
everything is easy to get to, 
when I find, even in start-up 

275
00:13:37,500 --> 00:13:40,900
companies later stage of 
mid-stage, solid different 

276
00:13:40,900 --> 00:13:42,700
people. 
Need to focus on different 

277
00:13:42,700 --> 00:13:43,800
things. 
It's inevitable. 

278
00:13:43,800 --> 00:13:46,800
Not everybody can do everything,
and then very quickly, the 

279
00:13:46,800 --> 00:13:49,100
little Bungalow chunks into 
multi-story Mo. 

280
00:13:49,200 --> 00:13:52,400
And then soon after he turns 
into stone, like, Paper? 

281
00:13:52,400 --> 00:13:54,000
Right? 
And the thing just keeps 

282
00:13:54,000 --> 00:13:56,300
growing. 
You can't just flatten it back 

283
00:13:56,300 --> 00:13:59,100
down or because the different 
functions, of course, are 

284
00:13:59,100 --> 00:14:01,500
important. 
So, the next best thing you can 

285
00:14:01,500 --> 00:14:04,200
do, is somebody ride the 
elevator between the different 

286
00:14:04,200 --> 00:14:06,500
levels and I feel the Architects
not. 

287
00:14:06,500 --> 00:14:09,700
Well, equipped to be the ones 
who write that elevator which is

288
00:14:09,700 --> 00:14:11,600
aptly called, the architect, 
everything. 

289
00:14:12,300 --> 00:14:14,200
I laughed. 
When you said that, someone is 

290
00:14:14,200 --> 00:14:17,300
tweaking Helm charts. 
Sometimes as an engineer. 

291
00:14:17,400 --> 00:14:19,400
We probably don't actually 
realize. 

292
00:14:19,400 --> 00:14:21,100
When we tweak, for example, Helm
charge. 

293
00:14:21,100 --> 00:14:23,600
What does it mean? 
Thumbs up, business impact, or 

294
00:14:23,600 --> 00:14:26,000
in terms of purpose for the 
whole organization, or the 

295
00:14:26,008 --> 00:14:28,400
system's overall. 
So I really laughed when you 

296
00:14:28,400 --> 00:14:31,400
said that, I think software 
architect, in this case is very 

297
00:14:31,400 --> 00:14:33,700
important because you will then 
have a translation. 

298
00:14:33,700 --> 00:14:36,900
And to end on the business point
of view until the engineering 

299
00:14:36,900 --> 00:14:39,200
point of view. 
You have this thing in the book,

300
00:14:39,200 --> 00:14:42,700
mentioning about an architect, 
actually stands on three legs. 

301
00:14:43,000 --> 00:14:46,500
So what are these three legs? 
Can you explain a little bit 

302
00:14:46,500 --> 00:14:49,700
further on each of the leg? 
We are connecting the different 

303
00:14:49,700 --> 00:14:51,300
levels. 
Let me just say that. 

304
00:14:51,300 --> 00:14:54,400
The reason it's so important is 
because it's the connection 

305
00:14:54,400 --> 00:14:57,200
isn't there. 
The greatest technical solution 

306
00:14:57,200 --> 00:15:00,000
in the end is not going to have 
the impact and it should have. 

307
00:15:00,100 --> 00:15:01,800
There's likely to drilling the 
two tunnels in there. 

308
00:15:01,800 --> 00:15:04,700
We'll meet each other drilling 
faster is not going to help, so 

309
00:15:04,700 --> 00:15:07,000
that's why this connection is so
important. 

310
00:15:07,200 --> 00:15:08,600
Of course. 
This place is another 

311
00:15:08,600 --> 00:15:11,400
requirements on the role of an 
architect. 

312
00:15:11,500 --> 00:15:13,500
We have to go through these 
different levels. 

313
00:15:13,500 --> 00:15:15,000
We have to connect all these 
things. 

314
00:15:15,000 --> 00:15:17,300
There's many different things 
that we need to do. 

315
00:15:17,700 --> 00:15:20,600
So, how do you come back and 
bring this into something 

316
00:15:20,600 --> 00:15:22,900
tangible? 
And I said, The end to be a 

317
00:15:22,900 --> 00:15:25,400
successful architect, you need 
to have three elements. 

318
00:15:25,700 --> 00:15:27,600
Those are the three legs that 
you stand. 

319
00:15:27,900 --> 00:15:29,600
Of course. 
You need to have the skill. 

320
00:15:29,600 --> 00:15:33,000
You need to know your sense. 
Do you find some Architects up 

321
00:15:33,000 --> 00:15:35,500
at the pet house, who just 
scored some jargon? 

322
00:15:35,500 --> 00:15:39,000
And I bid need to leverage. 
The serverless cloud iot is 

323
00:15:39,000 --> 00:15:41,800
something Edge, shredded, blah, 
blah, blah, all that doesn't 

324
00:15:41,800 --> 00:15:44,100
help anything. 
It gets Executives excited, but 

325
00:15:44,100 --> 00:15:45,500
there's who elevated and they 
are. 

326
00:15:45,900 --> 00:15:48,500
So you need to have the skill. 
You need to know what you're 

327
00:15:48,500 --> 00:15:50,300
doing. 
And what you're talking about. 

328
00:15:50,300 --> 00:15:51,900
We were just chatting before the
recording. 

329
00:15:52,100 --> 00:15:53,800
Right. 
I'm just now a tinkering with 

330
00:15:53,800 --> 00:15:57,300
some AWS products. 
So I have the anchor in the 

331
00:15:57,300 --> 00:16:00,300
inch. 
Now, the second part, of course,

332
00:16:00,300 --> 00:16:04,000
is you apply the skill to have 
an impact again. 

333
00:16:04,000 --> 00:16:06,200
Otherwise, it just saw the like 
we serve Sky. 

334
00:16:06,200 --> 00:16:09,400
Not playing around prototyping, 
that's good for very small 

335
00:16:09,400 --> 00:16:11,300
things, but that doesn't make a 
difference. 

336
00:16:11,400 --> 00:16:14,300
So you need to forge the 
connection between having the 

337
00:16:14,300 --> 00:16:17,700
technical skill and bringing 
this to have an attack. 

338
00:16:17,800 --> 00:16:20,600
This is about aligning and 
Destiny strategies. 

339
00:16:20,600 --> 00:16:23,600
Exactly like the elevator. 
But there's a third important 

340
00:16:23,600 --> 00:16:25,100
part. 
That's why the stool has three 

341
00:16:25,100 --> 00:16:26,300
legs. 
We can see, two necks is a 

342
00:16:26,308 --> 00:16:30,000
little difficult to sit on. 
And the third one is really the 

343
00:16:30,000 --> 00:16:32,700
leadership. 
I took the inspiration here for 

344
00:16:32,700 --> 00:16:35,900
other professions. 
Like, let's say only you're a 

345
00:16:35,900 --> 00:16:39,500
very highly skilled lawyer or a 
very highly skilled doctor at 

346
00:16:39,500 --> 00:16:41,400
the court staff. 
What do you become? 

347
00:16:41,600 --> 00:16:44,300
We become, like Chief doctor, 
make the cheap ploy to some 

348
00:16:44,300 --> 00:16:47,500
extent, but you really made a 
lawyer, and the doctor, and 

349
00:16:47,500 --> 00:16:50,800
also, as an architect, you read 
need an architect, but the way 

350
00:16:50,800 --> 00:16:55,300
you grow, your Impact is on the 
advancing the field to start 

351
00:16:55,300 --> 00:16:58,700
lecturing you start maybe or 
researching finding new things? 

352
00:16:58,900 --> 00:17:02,700
Describing things in February is
building more skill set and in 

353
00:17:02,700 --> 00:17:05,400
the end and leading the practice
and support. 

354
00:17:05,599 --> 00:17:07,500
And that's the leadership as the
sir. 

355
00:17:07,500 --> 00:17:09,500
Like no Goodwill. 
Nice thing about. 

356
00:17:09,500 --> 00:17:13,599
This is all of this is a two-way
street. 

357
00:17:13,599 --> 00:17:16,599
Once you have the skill. 
There's so many skills. 

358
00:17:16,599 --> 00:17:19,500
You could acquire. 
It's hard to figure out which 

359
00:17:19,500 --> 00:17:21,300
skill you should really pursue, 
right? 

360
00:17:21,300 --> 00:17:22,800
It's like a kitten. 
Candy store. 

361
00:17:23,099 --> 00:17:26,099
So I'm looking for their pack 
helps you prioritize. 

362
00:17:26,400 --> 00:17:28,300
What should I learn? 
I should learn the things that 

363
00:17:28,300 --> 00:17:31,400
have an impact and also having 
the leadership mentoring. 

364
00:17:31,400 --> 00:17:34,700
Other people gives great 
feedback because you learn 

365
00:17:34,900 --> 00:17:38,800
what's maybe most confusing or 
people ask this proverbial total

366
00:17:38,800 --> 00:17:42,300
naive questions, which really 
get you thinking so it's not 

367
00:17:42,300 --> 00:17:46,100
just your personal progression, 
but it's also a two-way street. 

368
00:17:46,100 --> 00:17:48,900
You always get things back along
this journey. 

369
00:17:49,500 --> 00:17:51,900
I really like your explanation 
that it's a two-way street. 

370
00:17:52,000 --> 00:17:53,800
Street, right? 
It's not just one thing that we 

371
00:17:53,800 --> 00:17:56,700
can just go dive, deep, study 
hard, and we become great 

372
00:17:56,700 --> 00:17:59,800
architect, but you always need 
to show impact because of all 

373
00:17:59,800 --> 00:18:01,800
and also do some kind of 
leadership thing in the 

374
00:18:01,800 --> 00:18:03,400
mentoring or advancing the 
field. 

375
00:18:03,400 --> 00:18:05,800
I really like that do research 
and talk about it. 

376
00:18:05,800 --> 00:18:08,600
So that other people can also 
adopt your ways of thinking 

377
00:18:08,800 --> 00:18:11,400
speaking about architecture. 
I think it's kind of like 

378
00:18:11,400 --> 00:18:13,800
abstract in a way. 
We all know these days about 

379
00:18:13,800 --> 00:18:15,600
microservice event driven and 
all that. 

380
00:18:15,700 --> 00:18:17,800
But what is actually a good 
architecture? 

381
00:18:17,800 --> 00:18:19,900
Because I think it's very hard 
to Define. 

382
00:18:20,200 --> 00:18:23,400
Sometimes we are clueless or I 
have a system, I've requirement.

383
00:18:23,400 --> 00:18:26,800
But what is good enough 
architecture for my requirement?

384
00:18:27,200 --> 00:18:29,500
Yes, good question. 
And the old definition is sort 

385
00:18:29,500 --> 00:18:32,600
of, you have to non-functional 
requirements from the idea would

386
00:18:32,600 --> 00:18:35,600
be that an architect just sort 
of make sure the non-functional 

387
00:18:35,600 --> 00:18:39,200
requirements are met and then 
the developers actual functional

388
00:18:39,200 --> 00:18:42,900
requirements of it, anything, 
that's a very naive definition. 

389
00:18:42,900 --> 00:18:46,700
It's a good starting point, but 
what it doesn't account for it 

390
00:18:46,700 --> 00:18:50,400
all is uncertainty like all 
these requirements taking 

391
00:18:50,500 --> 00:18:52,800
assumes, you know. 
What you need? 

392
00:18:52,800 --> 00:18:54,600
Right here is the list of 
requirements, just make it. 

393
00:18:54,600 --> 00:18:57,300
So everything would be fine. 
The dimension. 

394
00:18:57,300 --> 00:19:01,000
That's totally listening. 
Is the dimension of evolution 

395
00:19:01,000 --> 00:19:04,200
and uncertainty and anything 
that's where I'm good 

396
00:19:04,200 --> 00:19:08,300
architecture, really shines. 
You might know my famous small 

397
00:19:08,300 --> 00:19:12,800
about architecture sales 
options, options are great way 

398
00:19:12,800 --> 00:19:15,700
to deal with uncertainty. 
The analogy comes from the 

399
00:19:15,700 --> 00:19:18,600
financial markets. 
That option is the ability to 

400
00:19:18,600 --> 00:19:21,900
execute a trade, like new 
biosimilar, stock in the future.

401
00:19:22,100 --> 00:19:26,700
At defined terms so you can buy 
it option may be to buy one 

402
00:19:26,700 --> 00:19:29,700
share of Amazon stock for four 
thousand dollars, one year from 

403
00:19:29,700 --> 00:19:32,400
now. 
And then when the year comes the

404
00:19:32,400 --> 00:19:36,300
decision, whether to exercise 
the option or not becomes very 

405
00:19:36,400 --> 00:19:39,600
simple, because it that part of 
the stock is higher, you buy it 

406
00:19:39,600 --> 00:19:42,600
for 4,000 based on the option. 
You have money in the bank. 

407
00:19:42,900 --> 00:19:45,300
If the stock is nowhere on the 
market on the option, you like 

408
00:19:45,300 --> 00:19:47,100
the options expire, you don't 
take it. 

409
00:19:47,300 --> 00:19:51,100
Now, what we learned from this 
is that decisions become much 

410
00:19:51,100 --> 00:19:52,700
easier in. 
In the future. 

411
00:19:52,700 --> 00:19:55,200
It's a great way to deal with 
uncertainty if you travel into 

412
00:19:55,200 --> 00:19:56,700
the future. 
Well, there's no more 

413
00:19:56,700 --> 00:19:59,000
uncertainty. 
You can look at reality at that 

414
00:19:59,000 --> 00:20:01,200
time. 
So if you can defer the 

415
00:20:01,200 --> 00:20:03,500
decision, that is a really great
thing. 

416
00:20:03,700 --> 00:20:07,300
This is what we call options, 
probably the best technical 

417
00:20:07,300 --> 00:20:10,700
example that we have is 
horizontal scale, it back, 

418
00:20:10,700 --> 00:20:12,900
elastic, infrastructure, 
horizontal scaling, like how 

419
00:20:12,900 --> 00:20:14,800
much Hardware do you need for 
your application? 

420
00:20:15,300 --> 00:20:17,700
It's always been a guessing game
because there's a lot of 

421
00:20:17,700 --> 00:20:21,000
uncertainty and of course for 
internet facing and mobile apps 

422
00:20:21,000 --> 00:20:24,700
Etc and certain Is even higher 
and I could take, I could send 

423
00:20:24,700 --> 00:20:26,800
build option, make it my 
services architecture. 

424
00:20:26,800 --> 00:20:28,300
We make it horizontally 
scalable. 

425
00:20:28,600 --> 00:20:32,500
You run it on top of an elastic 
runtime in the future making the

426
00:20:32,500 --> 00:20:34,500
decision is very easy. 
You need a bit more Hardware 

427
00:20:34,500 --> 00:20:37,300
wanted to play with the hardware
and you need less, you actually 

428
00:20:37,300 --> 00:20:40,700
shut down some servers. 
So this is an option that as an 

429
00:20:40,700 --> 00:20:43,500
architect. 
I could give you that allows you

430
00:20:43,500 --> 00:20:46,700
to leave first a decision. 
In this case, the decision apart

431
00:20:46,700 --> 00:20:51,200
Hardware sizing, and that takes 
a lot of the uncertainty out of 

432
00:20:51,200 --> 00:20:54,100
the game. 
That is a great value, technical

433
00:20:54,100 --> 00:20:56,600
guidance, certainty out is 
highly valuable. 

434
00:20:56,600 --> 00:20:58,200
I used to work for an insurance 
company. 

435
00:20:58,400 --> 00:21:01,900
We made 11 billion euros 
operating profit a year, by 

436
00:21:01,900 --> 00:21:03,500
dealing with people's 
uncertainty. 

437
00:21:03,800 --> 00:21:06,400
So, if I get textured takes 
uncertainty out of the 

438
00:21:06,408 --> 00:21:10,400
equations, that is worth real 
money, then, how about 

439
00:21:10,400 --> 00:21:13,200
trade-offs? 
Because as we all know in IIT or

440
00:21:13,200 --> 00:21:15,600
most of the things in the world,
you can't achieve everything. 

441
00:21:15,900 --> 00:21:17,300
They will be always trade off 
either. 

442
00:21:17,300 --> 00:21:20,200
Like, for example, skill ability
versus performance security and 

443
00:21:20,200 --> 00:21:21,900
all that. 
So how does an architect? 

444
00:21:22,100 --> 00:21:24,900
Deal with these kinds of 
trade-offs at the end of the day

445
00:21:24,900 --> 00:21:27,600
with all these different options
and also trade-offs. 

446
00:21:27,600 --> 00:21:29,300
How do you actually communicate 
that? 

447
00:21:29,300 --> 00:21:32,300
So that everyone in the team, 
everyone in the company actually

448
00:21:32,300 --> 00:21:36,100
ideas to the decision and hence 
properly Implement that. 

449
00:21:36,600 --> 00:21:39,700
Yes, and recall, when I sent the
Architects with, you still 

450
00:21:39,700 --> 00:21:42,300
options, right? 
We don't donate the options and 

451
00:21:42,300 --> 00:21:45,100
there's a through the trade-offs
coming with our words or 

452
00:21:45,100 --> 00:21:47,900
thoughts, hitting example that 
option. 

453
00:21:47,900 --> 00:21:51,500
It's great. 
But it has a cause the cost is 

454
00:21:51,500 --> 00:21:53,800
slightly. 
We more complex application 

455
00:21:53,800 --> 00:21:55,900
architecture. 
We need to replicate your state 

456
00:21:55,900 --> 00:21:58,900
of extremely sister hate. 
You need out automation to 

457
00:21:58,900 --> 00:22:01,000
school onion? 
Since is not these days. 

458
00:22:01,000 --> 00:22:05,100
That's probably common to many 
developers that if you ride a 

459
00:22:05,108 --> 00:22:07,500
little hello world for yourself 
for the weekend. 

460
00:22:07,500 --> 00:22:10,200
Probably you don't make it or is
on telescope. 

461
00:22:10,200 --> 00:22:14,800
So they say cost the cost comes 
in a number of different forms, 

462
00:22:14,800 --> 00:22:16,600
right? 
This little bit of effort, but 

463
00:22:16,600 --> 00:22:18,700
it's actually relatively easy to
deal with. 

464
00:22:19,000 --> 00:22:24,300
The larger cost is complexity. 
Slingback includes more options 

465
00:22:24,300 --> 00:22:27,900
invariably is more complex. 
So we'll find out later on Flex.

466
00:22:27,900 --> 00:22:30,800
It is not a very good thing 
because complexities also doubt.

467
00:22:30,800 --> 00:22:33,400
And in the world we live in 
slowing down isn't a very good 

468
00:22:33,400 --> 00:22:37,400
thing to do the last thing. 
The way you buy these options of

469
00:22:37,400 --> 00:22:40,000
your trade. 
These options is in order to 

470
00:22:40,000 --> 00:22:43,000
gain one option. 
You need to give up other 

471
00:22:43,000 --> 00:22:44,800
options. 
So let's say, you want the 

472
00:22:44,800 --> 00:22:48,200
option that each teen programs 
in their own favorite language, 

473
00:22:48,200 --> 00:22:49,900
right? 
That's a great option to have 

474
00:22:49,900 --> 00:22:51,600
some people. 
I go the other ones to it. 

475
00:22:51,600 --> 00:22:54,300
It's got Gather around and 
people on the jvm by this is a 

476
00:22:54,300 --> 00:22:57,000
really nice option to have. 
What do you need able this 

477
00:22:57,000 --> 00:22:58,700
option by locking something 
else? 

478
00:22:58,700 --> 00:23:01,000
Now you say, okay. 
I have apis. 

479
00:23:01,000 --> 00:23:03,600
It's HTTP or https. 
It's Json. 

480
00:23:03,600 --> 00:23:05,100
Payloads. 
Look for the bus. 

481
00:23:05,100 --> 00:23:08,700
Whatever you want to be. 
You look, something's in in to 

482
00:23:08,700 --> 00:23:12,000
gate that option. 
So, it's really an options, 

483
00:23:12,000 --> 00:23:13,800
Marketplace. 
Like you're trading, you're 

484
00:23:13,800 --> 00:23:15,700
giving up some to gain other 
options. 

485
00:23:15,700 --> 00:23:19,600
Now, the question is, of course.
Well, when is it worse by the 

486
00:23:19,600 --> 00:23:21,500
new Option? 
Versus what is it? 

487
00:23:21,500 --> 00:23:23,400
Not? 
It's how big the option the 

488
00:23:23,400 --> 00:23:27,600
important part here is that the 
architect generally cannot make 

489
00:23:27,600 --> 00:23:31,100
that decision on their own. 
They can offer the option up for

490
00:23:31,100 --> 00:23:33,800
sale. 
But the value of the option, 

491
00:23:33,800 --> 00:23:37,900
depends on many factors. 
One of the key factors is the 

492
00:23:37,900 --> 00:23:40,800
amount of uncertainty. 
So if things are highly 

493
00:23:40,800 --> 00:23:42,700
uncertain, be I'm launching a 
new mobile app. 

494
00:23:42,700 --> 00:23:45,300
I don't know whether this will 
have one user or 1 million 

495
00:23:45,300 --> 00:23:47,900
users. 
I deal with a huge amount of 

496
00:23:47,900 --> 00:23:50,300
uncertainty solar. 
For example, scaling option is 

497
00:23:50,300 --> 00:23:53,300
almost a given like the value. 
It is so high because of your 

498
00:23:53,300 --> 00:23:57,300
CSR from adult, hello world or 
photo app for my own family. 

499
00:23:57,500 --> 00:23:58,600
You know, it's like three 
people. 

500
00:23:58,700 --> 00:24:00,900
I probably don't need a lot of 
option. 

501
00:24:01,200 --> 00:24:04,500
So the options Marketplace 
consists of the architect. 

502
00:24:04,600 --> 00:24:08,800
Offering things up for sale. 
They're not free, but then you 

503
00:24:08,800 --> 00:24:13,500
need to work with the bitterness
and the context to understand, 

504
00:24:13,500 --> 00:24:16,300
whether that option is actually 
worth buying not. 

505
00:24:16,500 --> 00:24:19,700
And what the cost has been. 
You said like, how we get people

506
00:24:19,700 --> 00:24:23,000
to understand that I think the 
best way is To really make these

507
00:24:23,000 --> 00:24:27,300
decisions very consciously. 
And to be very open about the 

508
00:24:27,300 --> 00:24:29,400
trade-offs. 
That doesn't help anybody. 

509
00:24:29,400 --> 00:24:31,500
He said, well, of course, it has
to be continued. 

510
00:24:31,500 --> 00:24:33,100
Of course, it has to be proven 
leaders. 

511
00:24:33,100 --> 00:24:35,300
Of course. 
It has to be x y z, of course, 

512
00:24:35,300 --> 00:24:37,100
we need to serve especially, 
because how couldn't you? 

513
00:24:37,100 --> 00:24:38,500
And of course, it has to be 
serverless. 

514
00:24:38,500 --> 00:24:41,300
It's like all the given. 
No, it's never a gif of, right. 

515
00:24:41,300 --> 00:24:43,900
These are all important 
decisions that have trade-offs 

516
00:24:44,000 --> 00:24:47,100
in case of options. 
You lose a lot of options making

517
00:24:47,100 --> 00:24:51,800
those trade-offs transparent to 
a wide audience is probably the 

518
00:24:51,900 --> 00:24:55,500
the most helpful thing you could
be and of course that looks very

519
00:24:55,500 --> 00:24:57,900
much like the other Nintendo. 
But people higher up of the 

520
00:24:57,900 --> 00:25:00,900
higher floors. 
Understand the ramifications of 

521
00:25:00,900 --> 00:25:04,400
the decisions you making 
speaking about explaining this 

522
00:25:04,400 --> 00:25:06,500
having an open conscious 
decision. 

523
00:25:06,500 --> 00:25:09,400
And also transparent reminds me 
of architect decision lock or 

524
00:25:09,408 --> 00:25:12,100
something like that. 
By you actually put down all the

525
00:25:12,100 --> 00:25:15,300
thought process that you have 
and also outlines why a certain 

526
00:25:15,300 --> 00:25:18,500
architecture is decided at that 
point in time, maybe so that 

527
00:25:18,500 --> 00:25:21,300
people also understands all 
these different options that we 

528
00:25:21,300 --> 00:25:23,600
thought about. 
And why we chose a particular 

529
00:25:23,600 --> 00:25:25,400
options versus the others. 
Yeah. 

530
00:25:25,400 --> 00:25:27,200
Mic night. 
Yeah, quite the terms of the 

531
00:25:27,200 --> 00:25:29,000
ADR. 
The architecture decision 

532
00:25:29,000 --> 00:25:30,800
record. 
I like that a lot. 

533
00:25:31,000 --> 00:25:35,200
The key thing is to express the 
decisions so that the trade-offs

534
00:25:35,200 --> 00:25:38,900
that are being made are 
meaningful for a wide audience. 

535
00:25:39,000 --> 00:25:43,300
It can be some cryptic, kind of,
we decided to flip this arcade. 

536
00:25:43,300 --> 00:25:46,100
Bit number XYZ somewhere deep in
the infrastructure. 

537
00:25:46,300 --> 00:25:48,900
That's not that ADR. 
That's gotta do a lot of good. 

538
00:25:49,100 --> 00:25:52,700
It's got to be meaningful in the
trade of are going to be 

539
00:25:52,700 --> 00:25:54,900
communicated and I like 80 yards
on. 

540
00:25:55,600 --> 00:25:58,200
The next thing that we want to 
talk about is a specific thing 

541
00:25:58,200 --> 00:26:01,500
about Cloud architecture, which 
is a big topic these days 

542
00:26:01,500 --> 00:26:04,300
because so many Cloud providers 
so many clock products and so 

543
00:26:04,300 --> 00:26:06,500
many people wanting to go into 
the cloud. 

544
00:26:06,500 --> 00:26:08,300
So, you wrote this book called 
strategy. 

545
00:26:08,600 --> 00:26:10,300
I read it. 
And I loved it a lot, because 

546
00:26:10,300 --> 00:26:12,800
there are a lot of humors as 
well inside the feeling I have 

547
00:26:12,800 --> 00:26:16,100
to say, so, when we talk about 
Cloud strategy, right, I mean, 

548
00:26:16,200 --> 00:26:18,400
almost these days. 
Everyone is familiar with the 

549
00:26:18,400 --> 00:26:21,000
cloud. 
But what is the definition of 

550
00:26:21,000 --> 00:26:22,600
cloud from? 
Point of view. 

551
00:26:23,200 --> 00:26:25,000
Yeah. 
Thanks for reading the book. 

552
00:26:25,000 --> 00:26:28,100
And, yes, I feel that books were
technical depth on have to be 

553
00:26:28,100 --> 00:26:30,000
boring. 
So, I always inject a little bit

554
00:26:30,000 --> 00:26:32,800
of humor and in Beyond reality, 
writes, the best story. 

555
00:26:32,800 --> 00:26:36,100
So I think all the funny parts 
are taken for well-disguised 

556
00:26:36,100 --> 00:26:39,400
customer conversations and 
customer engage in the book. 

557
00:26:39,400 --> 00:26:42,700
And generally, I shy away from 
having this one sentence 

558
00:26:42,700 --> 00:26:45,100
definition of won't cloud, is he
end up with these? 

559
00:26:45,100 --> 00:26:48,100
Like very academic weird things 
that try to put as many 

560
00:26:48,100 --> 00:26:52,000
passwords in a single sentence. 
When I rather try to do is His 

561
00:26:52,000 --> 00:26:55,300
show, the different aspects of 
calm than one aspect is of 

562
00:26:55,300 --> 00:26:57,900
course, where does you stuff 
run? 

563
00:26:57,900 --> 00:27:00,700
And where does he didn't? 
We say we don't need to say too 

564
00:27:00,700 --> 00:27:02,500
much about this. 
Everybody talks about 

565
00:27:02,500 --> 00:27:05,700
on-premises versus King. 
The cloud that is probably I 

566
00:27:05,700 --> 00:27:09,600
would say the overemphasized 
aspect or many recent try to 

567
00:27:09,600 --> 00:27:13,100
guess on premises often. 
Also not actually your premises.

568
00:27:13,100 --> 00:27:15,400
It's off Outsource run by a 
third party. 

569
00:27:15,400 --> 00:27:18,500
So you a lot of thoughts about 
the location, but that would be 

570
00:27:18,600 --> 00:27:21,300
the first aspect and comes to 
many people's minds. 

571
00:27:21,900 --> 00:27:24,700
More interesting to being. 
When we talk about the cloud. 

572
00:27:24,700 --> 00:27:29,600
It's a changing operating table.
It's really redefining the 

573
00:27:29,600 --> 00:27:31,800
interface you having with 
Europe. 

574
00:27:31,800 --> 00:27:35,000
It that's why I always say cloud
in sight. 

575
00:27:35,000 --> 00:27:37,000
E-procurement. 
It's not something you buy is 

576
00:27:37,000 --> 00:27:39,700
unlike a CRM kind of a system or
like a database. 

577
00:27:39,900 --> 00:27:43,700
It is really on a lifestyle 
change because the old terms, 

578
00:27:43,700 --> 00:27:47,000
the way to deal with the ideas. 
We fired, our technology, make a

579
00:27:47,000 --> 00:27:50,500
request things, take some time 
transparency, is a little bit 

580
00:27:50,500 --> 00:27:53,300
limited once you order. 
Something usually stuck with it 

581
00:27:53,300 --> 00:27:55,200
for many years until it's 
appreciated. 

582
00:27:55,200 --> 00:27:57,600
Right? 
That is what the interface into 

583
00:27:57,600 --> 00:28:00,700
your, it look like. 
And of course, Cloud operating 

584
00:28:00,700 --> 00:28:03,800
model turns that completely on 
its head, you can have stuff 

585
00:28:03,800 --> 00:28:06,400
whenever you want it. 
You can dispose of it whenever 

586
00:28:06,400 --> 00:28:08,000
you wanted. 
You can recreate it. 

587
00:28:08,200 --> 00:28:10,600
It's a highly Dynamic 
environment. 

588
00:28:10,800 --> 00:28:14,800
We talked about before zap, the 
traditional definitions of 

589
00:28:14,800 --> 00:28:17,500
architecture. 
They ignore uncertainty, right? 

590
00:28:17,500 --> 00:28:20,800
They have this idea that 
everything is clean defy nicing.

591
00:28:20,800 --> 00:28:24,000
This. 
Lates extremely well into Cloud.

592
00:28:24,100 --> 00:28:28,100
If everything is stable and 
steady and when a no, then cloud

593
00:28:28,100 --> 00:28:30,300
is probably just a little bit 
more official. 

594
00:28:30,300 --> 00:28:31,600
We need to run the 
infrastructure. 

595
00:28:31,600 --> 00:28:33,900
Yes, and you will say sub-caste 
about loudly. 

596
00:28:33,900 --> 00:28:36,500
Same old things a little bit 
better packaging, it slightly 

597
00:28:36,500 --> 00:28:39,400
more cost. 
However, once you assume that 

598
00:28:39,400 --> 00:28:42,300
you don't know everything that 
you live in an uncertain world 

599
00:28:42,300 --> 00:28:44,500
that architecture options are 
valuable to you. 

600
00:28:44,700 --> 00:28:47,000
That there's a lot of changed, a
lot of uncertainty. 

601
00:28:47,200 --> 00:28:51,200
That's when the cloud operating 
model really changes the way 

602
00:28:51,200 --> 00:28:53,200
your organization. 
Has a, she can operate and I 

603
00:28:53,208 --> 00:28:56,300
like that aspect of cloud 
computing, much better. 

604
00:28:57,000 --> 00:28:58,800
I really love your definition 
about. 

605
00:28:58,800 --> 00:29:01,600
It's really about a lifestyle 
change for your it. 

606
00:29:01,700 --> 00:29:05,300
And it's an operating model. 
Not just procuring, things like 

607
00:29:05,300 --> 00:29:07,800
buying software, buying 
Hardware, traditionally. 

608
00:29:07,800 --> 00:29:11,200
We are all accustomed to. 
So can you explain a little bit?

609
00:29:11,200 --> 00:29:14,600
Why do you think a lifestyle 
change is more proper term 

610
00:29:14,600 --> 00:29:17,700
rather than the procurement 
since I'm the first question, 

611
00:29:17,700 --> 00:29:20,800
should probably be? 
Why do you want or need a 

612
00:29:20,800 --> 00:29:22,400
lifestyle change? 
Abacus. 

613
00:29:22,400 --> 00:29:24,200
If it could be just simple 
procurement. 

614
00:29:24,200 --> 00:29:26,500
You're probably make your life a
lot easier. 

615
00:29:26,700 --> 00:29:29,500
Almost, every customer. 
I talked with the procurement 

616
00:29:29,500 --> 00:29:32,700
harder than this relatively 
easy, but then in the end, they 

617
00:29:32,700 --> 00:29:35,900
are the middle of a giant 
reservation and the translation,

618
00:29:35,900 --> 00:29:39,000
of course, is closely related to
the lifestyle change that. 

619
00:29:39,000 --> 00:29:42,300
The reason you want to have the 
lifestyle changes because he 

620
00:29:42,300 --> 00:29:46,500
environment has changed, and 
that has to do with pace, and it

621
00:29:46,500 --> 00:29:49,900
has to do with uncertainty that 
your days when things were 

622
00:29:49,900 --> 00:29:53,200
moving relatively slowly both. 
For me Isn't some by that as 

623
00:29:53,200 --> 00:29:56,100
well as for the technical Vibe 
things were just like legal by 

624
00:29:56,100 --> 00:29:59,200
three different brands of server
is so nuts about that. 

625
00:29:59,500 --> 00:30:01,200
Some Trump's a runtime 
environment. 

626
00:30:01,200 --> 00:30:03,200
It was swinging, or can you put 
it on VMware? 

627
00:30:03,200 --> 00:30:05,900
And there was up there wasn't so
much ablution. 

628
00:30:05,900 --> 00:30:08,900
There wasn't so much going on in
the business environment was 

629
00:30:08,900 --> 00:30:13,000
also much more predictable. 
Now then has changed a lot if 

630
00:30:13,000 --> 00:30:16,400
anybody needed a wake-up call, 
of course, academic do that in 

631
00:30:16,400 --> 00:30:19,400
terms of how quickly 
environments can change on the 

632
00:30:19,400 --> 00:30:24,300
business side, when I suddenly, 
Have to ship their whole custom 

633
00:30:24,300 --> 00:30:27,200
interface from physical store 
into online order. 

634
00:30:27,300 --> 00:30:30,200
Whether it's restaurants or 
whether its retail shops, 

635
00:30:30,400 --> 00:30:33,800
massive ships, which of course 
translate into the IT 

636
00:30:33,800 --> 00:30:36,200
infrastructure. 
Need customers were used to be 

637
00:30:36,200 --> 00:30:39,300
sold out 90% of supporting 
physical in Stockholm area. 

638
00:30:39,300 --> 00:30:42,600
So maybe 10% e-commerce or them 
in a matter of couple weeks that

639
00:30:42,600 --> 00:30:45,500
actually flipped. 
So talk about scaling and 

640
00:30:45,500 --> 00:30:48,600
scaling up and also scaling down
getting rid of the cost for the 

641
00:30:48,600 --> 00:30:51,600
stuff that's not needed as much 
anymore are reacting to this. 

642
00:30:51,800 --> 00:30:54,600
And I think that's why you want 
the lifestyle change. 

643
00:30:54,900 --> 00:30:58,500
I call this the transition from 
the economies of scale to the 

644
00:30:58,500 --> 00:31:01,500
economies of speed. 
The economies of scale is you 

645
00:31:01,500 --> 00:31:05,100
build something and then you get
the return on investment, right?

646
00:31:05,100 --> 00:31:07,200
The bigger you are in the lower.
You can run this thing, the 

647
00:31:07,200 --> 00:31:09,400
battery return on investment. 
So that works. 

648
00:31:09,400 --> 00:31:13,400
Well, if things are steady the 
economies of speed up much more 

649
00:31:13,400 --> 00:31:17,600
about learning quickly, having 
constant change, being able to 

650
00:31:17,600 --> 00:31:20,100
listen, being able to 
course-correct being agile. 

651
00:31:20,100 --> 00:31:23,200
If you like that word though. 
Those are the new ways that 

652
00:31:23,200 --> 00:31:26,900
business runs and the cloud is a
natural fit for that. 

653
00:31:26,900 --> 00:31:30,100
Kind of way of running business.
If you're always moving, if your

654
00:31:30,100 --> 00:31:32,700
course, correcting, if you're 
changing, that's when the 

655
00:31:32,700 --> 00:31:36,300
benefits of the cloud really 
come to bear and you coined the 

656
00:31:36,300 --> 00:31:39,700
term, as like clock things in 
first derivative, in terms of 

657
00:31:39,700 --> 00:31:42,800
economics of scale versus 
economies of speed, right? 

658
00:31:43,300 --> 00:31:45,100
Current. 
Like when the first derivative 

659
00:31:45,100 --> 00:31:46,800
is zero things on the 
steady-state. 

660
00:31:46,800 --> 00:31:49,700
Cloud is nice, but it's not 
going to really change the whole

661
00:31:49,700 --> 00:31:51,600
way. 
You think about the ID when the 

662
00:31:51,700 --> 00:31:54,800
First derivative is not 0 if 
things are changing in the 

663
00:31:54,800 --> 00:31:57,300
changing rapidly. 
That's when the climate 

664
00:31:57,400 --> 00:31:59,500
operating model Department. 
We sent of the cloud. 

665
00:31:59,500 --> 00:32:03,000
That's much more interesting. 
That's when that really comes to

666
00:32:03,000 --> 00:32:05,600
be some type of setup return on 
investment. 

667
00:32:05,600 --> 00:32:07,800
You should think about return on
agility. 

668
00:32:08,100 --> 00:32:11,300
What is my return on? 
Having the ability to react 

669
00:32:11,300 --> 00:32:14,000
quickly? 
If something changes in a, if 

670
00:32:14,000 --> 00:32:16,400
you want to look at it 
mathematically, that is really 

671
00:32:16,500 --> 00:32:20,200
the first derivative and all 
these are really interesting to 

672
00:32:20,200 --> 00:32:21,500
me. 
Because when I used to work 

673
00:32:21,500 --> 00:32:23,200
with, Love Cloud customers as 
well. 

674
00:32:23,400 --> 00:32:25,900
A lot of people in the IT 
industry is a lot of them 

675
00:32:25,900 --> 00:32:28,100
actually, their motivation or 
incentives. 

676
00:32:28,100 --> 00:32:30,500
Moving to the cloud. 
Is actually too safe. 

677
00:32:30,600 --> 00:32:34,500
So from traditionally managing 
on-prem managing fenders 

678
00:32:34,500 --> 00:32:37,500
managing, Hardware by yourself 
into moving things into the 

679
00:32:37,500 --> 00:32:39,200
cloud. 
Simply because of the cost 

680
00:32:39,200 --> 00:32:40,900
benefit. 
There will be no more what you 

681
00:32:40,900 --> 00:32:42,600
call it, capital asset and 
everything. 

682
00:32:42,600 --> 00:32:45,800
Now, become operational expense.
So it seems like from your 

683
00:32:45,800 --> 00:32:48,000
explanation. 
Just now it should not be the 

684
00:32:48,000 --> 00:32:50,300
main motivation of why you are 
going to the cop. 

685
00:32:50,300 --> 00:32:51,600
Is that correct? 
Assumption? 

686
00:32:52,100 --> 00:32:55,100
So, saving cows is always good 
to write, especially good. 

687
00:32:55,100 --> 00:32:57,900
If you have to convince upper 
management of something, right, 

688
00:32:57,900 --> 00:33:01,400
if you reduce cost, it's always 
handy to have that argument. 

689
00:33:01,400 --> 00:33:04,400
We see many customers, of 
course, reduce the cost for the 

690
00:33:04,400 --> 00:33:08,500
cloud operating model over there
so that to corollaries to that. 

691
00:33:08,800 --> 00:33:11,000
But one is the cost Centric 
model. 

692
00:33:11,000 --> 00:33:13,600
Isn't very traditional. 
It, what? 

693
00:33:13,600 --> 00:33:16,900
Which again is based on the 
Assumption of predictability is 

694
00:33:16,900 --> 00:33:17,700
D. 
Righty. 

695
00:33:17,900 --> 00:33:20,800
Here's my requirement. 
Please fulfill this requirement 

696
00:33:20,800 --> 00:33:23,700
at the lowest. 
Also the cost, what happens if 

697
00:33:23,700 --> 00:33:26,100
this requirement changes, we all
know in the old world? 

698
00:33:26,100 --> 00:33:27,700
What is called is change 
requests. 

699
00:33:27,900 --> 00:33:30,800
Now, it says change requests 
have a certain sound attached to

700
00:33:30,800 --> 00:33:32,800
them. 
It's Unicode catching because 

701
00:33:32,800 --> 00:33:36,600
the vendor rapidly makes you pay
a lot of money when you have to 

702
00:33:36,600 --> 00:33:39,200
change your mind. 
That's how old i t. 

703
00:33:39,200 --> 00:33:42,400
Answer C works. 
This is, of course, where Cloud 

704
00:33:42,400 --> 00:33:46,000
can do something very different.
So what we see customers needs 

705
00:33:46,000 --> 00:33:50,600
day is they like to reduce costs
about they just as much like the

706
00:33:50,700 --> 00:33:54,000
agility, they like to hire staff
productivity. 

707
00:33:54,000 --> 00:33:56,800
If you don't have to manage all 
the infrastructure, people can 

708
00:33:56,800 --> 00:33:59,300
actually focus on higher value. 
Things. 

709
00:33:59,600 --> 00:34:01,900
That doesn't mean you reduce 
your cost, doesn't mean you need

710
00:34:01,900 --> 00:34:04,100
to get rid of those people. 
But there are all of these 

711
00:34:04,100 --> 00:34:08,000
people can do much more valuable
sex, people arts and starting to

712
00:34:08,000 --> 00:34:10,300
fight that the cloud is much 
more reliable. 

713
00:34:10,500 --> 00:34:13,000
You can fail over easily. 
You could speed up when sensors,

714
00:34:13,300 --> 00:34:16,400
you're not going to run out of 
capacity, as easily as he do or 

715
00:34:16,400 --> 00:34:19,800
premises, you can get into 
different availability zones in 

716
00:34:19,800 --> 00:34:24,199
the end actually a higher. 
Leti and interesting lead slowly

717
00:34:24,199 --> 00:34:27,600
but steadily folks are having 
around realising that at the 

718
00:34:27,607 --> 00:34:30,600
cloud, you can run more securely
than you can run on premises. 

719
00:34:30,800 --> 00:34:33,400
I don't mean, it's probably a 
whole podcast on its own at the 

720
00:34:33,400 --> 00:34:36,000
Cyber landscape has changed 
dramatically. 

721
00:34:36,199 --> 00:34:37,900
The attack Vector is have 
changed. 

722
00:34:38,100 --> 00:34:41,199
So in the end, it is something 
that you need to have a lot of 

723
00:34:41,199 --> 00:34:44,199
resources for to manage and 
that's something that the hyper 

724
00:34:44,199 --> 00:34:47,500
scale of just simply can't do 
better than an Enterprise with 

725
00:34:47,500 --> 00:34:50,800
their data center. 
So it's a cost is still there of

726
00:34:50,800 --> 00:34:54,100
the portfolio. 
Of benefits has actually brought

727
00:34:54,100 --> 00:34:58,100
on what the one I saw in though.
And that is probably the most 

728
00:34:58,100 --> 00:35:00,000
unexpected benefit. 
At least for me. 

729
00:35:00,000 --> 00:35:02,800
It was when the first time I 
went to the club operating 

730
00:35:02,800 --> 00:35:06,700
model, there was transparency. 
We don't like to talk about it 

731
00:35:06,700 --> 00:35:09,800
so much because which CIO wants 
to admit that the ideas in 

732
00:35:09,800 --> 00:35:12,400
transparent. 
But yakult ready, it executive 

733
00:35:12,400 --> 00:35:14,300
and say wow. 
Tell me like, how many is 

734
00:35:14,300 --> 00:35:15,000
service. 
Do you have? 

735
00:35:15,000 --> 00:35:17,300
How many of those are production
versus staging box? 

736
00:35:17,300 --> 00:35:19,700
The utilization? 
What application runs on it? 

737
00:35:19,700 --> 00:35:21,600
Who's the order? 
When was the last push? 

738
00:35:21,800 --> 00:35:24,000
Often application update, what's
the patch level? 

739
00:35:24,300 --> 00:35:26,900
And basically you get a 
three-month project basically 

740
00:35:26,900 --> 00:35:29,600
see the momentum. 
So that's what it looks like. 

741
00:35:29,600 --> 00:35:33,000
There's no strain because 
everybody equally bad and that's

742
00:35:33,000 --> 00:35:36,700
why I realized Cloud actually 
gives you a much better chance. 

743
00:35:36,700 --> 00:35:39,300
Can see all these things, become
a simple report. 

744
00:35:39,400 --> 00:35:42,300
He has only workloads here to 
the patch level T as the last 

745
00:35:42,300 --> 00:35:46,000
update. 
So the transparency UPS improves

746
00:35:46,000 --> 00:35:50,200
significantly and coming back to
your Cost question, of course, 

747
00:35:50,200 --> 00:35:53,700
having improved transparency. 
Team allows you to optimize much

748
00:35:53,700 --> 00:35:55,600
better. 
And that is also a big 

749
00:35:55,600 --> 00:35:57,300
contributor to the cost 
reduction. 

750
00:35:57,300 --> 00:36:01,300
So my favorite benefit with the 
cloud is actually transparency, 

751
00:36:02,000 --> 00:36:03,900
right? 
The I again laughs when you said

752
00:36:03,900 --> 00:36:06,500
transparency because again, I 
could relate to the story 

753
00:36:06,500 --> 00:36:09,700
whereby we didn't really know. 
What is going on with our it 

754
00:36:09,700 --> 00:36:12,300
infrastructure. 
I remember one case in my 

755
00:36:12,300 --> 00:36:14,800
previous company, whereby we 
always ask this. 

756
00:36:14,900 --> 00:36:17,500
Anyone knows about this system. 
Maybe the guy already left. 

757
00:36:17,600 --> 00:36:20,000
Nobody knows about it. 
Nobody wants to touch it and 

758
00:36:20,000 --> 00:36:22,300
sometimes nobody even account. 
For it. 

759
00:36:22,400 --> 00:36:25,000
So the system just run somewhere
in a corner of a room. 

760
00:36:25,000 --> 00:36:27,300
Probably. 
And if it's down, some people 

761
00:36:27,300 --> 00:36:29,400
notice about that and we need to
support. 

762
00:36:29,400 --> 00:36:32,300
So I think with that called, at 
least, it gets more transparent.

763
00:36:32,400 --> 00:36:35,300
Even the course itself is more 
granular per minute, kind of 

764
00:36:35,300 --> 00:36:37,600
billing and we can easily figure
it out. 

765
00:36:37,600 --> 00:36:39,300
OK. 
What are the things that we have

766
00:36:39,300 --> 00:36:42,300
in our it infrastructures? 
So I really love about the 

767
00:36:42,300 --> 00:36:44,600
transparency there. 
So speaking about all these 

768
00:36:44,600 --> 00:36:47,600
different benefits that we have 
seems like moving to the cloud 

769
00:36:47,600 --> 00:36:50,100
is really beneficial. 
Also if you want to run in a 

770
00:36:50,100 --> 00:36:53,500
more agile manner, so So coming 
back to the book title itself, 

771
00:36:53,500 --> 00:36:56,100
Cloud strategy. 
Why do you think it's important 

772
00:36:56,100 --> 00:37:00,100
to have a cloud strategy? 
What is the strategy here means 

773
00:37:00,600 --> 00:37:01,400
the? 
Yeah. 

774
00:37:01,400 --> 00:37:04,400
I'm first of all, going to the 
cloud is a big deal. 

775
00:37:04,700 --> 00:37:06,800
There's many. 
Tulips are many things that help

776
00:37:06,800 --> 00:37:08,900
you get there. 
But at the same time that said, 

777
00:37:08,900 --> 00:37:12,000
it's a lifestyle change. 
It's also a major commitment 

778
00:37:12,100 --> 00:37:14,500
offer than someone on money and 
steady gets long-term 

779
00:37:14,500 --> 00:37:18,200
relationships, that build. 
So I think thinking carefully 

780
00:37:18,200 --> 00:37:21,400
about how you go to the cloud. 
It's well, advise is a good 

781
00:37:21,400 --> 00:37:23,300
idea. 
What happens what? 

782
00:37:23,300 --> 00:37:25,800
I see happen too much. 
The way is that the journey to 

783
00:37:25,800 --> 00:37:29,900
the cloud is driven by a 
specific objectives. 

784
00:37:30,000 --> 00:37:34,400
We want to be 80% of a workloads
in the cloud by anik state XYZ. 

785
00:37:34,800 --> 00:37:37,900
We want to be the market leader 
and this of that segment. 

786
00:37:38,000 --> 00:37:42,700
So basically people end up 
stating the aspirations, but 

787
00:37:42,700 --> 00:37:46,800
when it comes to actually making
tough decisions about how to get

788
00:37:46,800 --> 00:37:51,200
there things get much more quite
nessus, right? 

789
00:37:51,200 --> 00:37:53,200
Son. 
Title of the book is really 

790
00:37:53,200 --> 00:37:56,400
called a decision based approach
to successful Cloud. 

791
00:37:56,400 --> 00:37:58,500
Migration. 
Like when people show me the 

792
00:37:58,500 --> 00:38:02,200
strategy with strategy is they 
always they look like a happy 

793
00:38:02,200 --> 00:38:04,600
story book. 
So here, we migrated out first 

794
00:38:04,600 --> 00:38:07,700
workloads and then we migrate 
more workloads and then we go to

795
00:38:07,700 --> 00:38:10,700
containers and then we go to 
serverless and it's like 

796
00:38:10,700 --> 00:38:13,800
everything just becomes great 
and they lived happily ever 

797
00:38:13,800 --> 00:38:17,300
after the hit to breath is 
reality or even any meaningful 

798
00:38:17,300 --> 00:38:21,000
sized organizations. 
Reality doesn't look like this. 

799
00:38:21,000 --> 00:38:24,000
You need to Decisions. 
Are you got a bike ride 

800
00:38:24,000 --> 00:38:27,100
everything at once or you going 
to migrate in bits and pieces? 

801
00:38:27,300 --> 00:38:29,800
If you do bits and pieces, 
what's going to come first? 

802
00:38:30,000 --> 00:38:31,700
There's a million decisions, 
right? 

803
00:38:31,700 --> 00:38:34,200
Well, which Cloud, you got to go
to what kind of workloads are 

804
00:38:34,200 --> 00:38:36,500
gonna go first. 
How are you going to change your

805
00:38:36,500 --> 00:38:39,100
Operational Support? 
Do you build up your Operational

806
00:38:39,100 --> 00:38:41,100
Support before you migrate 
something? 

807
00:38:41,300 --> 00:38:43,400
Or do you do that after you 
migrate it? 

808
00:38:43,600 --> 00:38:48,500
All of these are sensible ways 
to go about it and you strategy 

809
00:38:48,500 --> 00:38:51,700
is picking your path. 
I mean, in the end you can A 

810
00:38:51,700 --> 00:38:54,900
decision tree with many nodes 
and plotting your paths. 

811
00:38:54,900 --> 00:38:58,500
With that decision tree, that is
really the strategy. 

812
00:38:58,700 --> 00:39:01,100
Proclaiming. 
The end result is relatively 

813
00:39:01,100 --> 00:39:04,200
easy navigating. 
The decision tree is much, much 

814
00:39:04,200 --> 00:39:06,300
harder. 
So that's what I'm trying to do 

815
00:39:06,300 --> 00:39:09,000
in the book. 
Not tell you what to do. 

816
00:39:09,200 --> 00:39:12,200
But to teach you how to think 
about your problems. 

817
00:39:12,200 --> 00:39:14,700
You can copy paste. 
Your Cloud migration from 

818
00:39:14,700 --> 00:39:17,000
somebody else. 
To starting point is going to be

819
00:39:17,000 --> 00:39:18,300
different. 
You constraints are going to be 

820
00:39:18,300 --> 00:39:19,400
different. 
Your needs are going to be 

821
00:39:19,408 --> 00:39:22,300
different you're competitive. 
Environment is Be different. 

822
00:39:22,500 --> 00:39:25,900
There's many factors that 
spawned you to have your own 

823
00:39:25,900 --> 00:39:28,500
strategy. 
But what I want to do is give 

824
00:39:28,500 --> 00:39:31,700
you a building kit that makes it
much easier for you to Define it

825
00:39:31,700 --> 00:39:34,200
that strategy. 
But it's not a copy-paste kind 

826
00:39:34,200 --> 00:39:38,100
of exercise and it will never be
speaking about copy paste. 

827
00:39:38,100 --> 00:39:41,900
We all want to have best 
practices or best solution to 

828
00:39:42,000 --> 00:39:43,700
certain thing. 
We can just replicate. 

829
00:39:43,900 --> 00:39:47,100
But I think migration to the 
cloud is not easy simply because

830
00:39:47,100 --> 00:39:50,500
every company has their own 
situation, their own skill sets.

831
00:39:50,700 --> 00:39:53,600
The people also me, Not be aware
about the core technology. 

832
00:39:53,600 --> 00:39:55,700
Plus, there are. 
So many Cloud providers with 

833
00:39:55,700 --> 00:39:58,000
their own. 
So many products right there, 

834
00:39:58,000 --> 00:40:00,700
just insurmountable amount of 
things that you need to learn. 

835
00:40:00,700 --> 00:40:03,500
And you need to, also be aware 
of few things that are different

836
00:40:03,500 --> 00:40:05,100
between different clouds as 
well. 

837
00:40:05,100 --> 00:40:09,000
So I think our strategy here 
makes sense, but how then should

838
00:40:09,000 --> 00:40:12,100
people start thinking about what
kind of strategy that makes 

839
00:40:12,100 --> 00:40:13,800
sense for them? 
Because these days, there are 

840
00:40:13,808 --> 00:40:17,200
many big name, card providers. 
There's also a hybrid Cloud 

841
00:40:17,200 --> 00:40:20,000
Model either on-premise and 
cloud or multi-cloud. 

842
00:40:20,000 --> 00:40:23,900
So, there's so many Options. 
How should someone start with 

843
00:40:23,900 --> 00:40:27,200
building up their strategy? 
Yeah, you're right off in the 

844
00:40:27,200 --> 00:40:29,700
strategy. 
Starts with picking the cloud 

845
00:40:29,700 --> 00:40:32,900
provider. 
This is the classic it Playbook.

846
00:40:33,100 --> 00:40:35,000
This is like, we need a 
database. 

847
00:40:35,000 --> 00:40:38,100
So I go to talk to Microsoft and
IBM and Oracle, right? 

848
00:40:38,200 --> 00:40:40,500
And I make a school child when I
pick the database. 

849
00:40:40,600 --> 00:40:43,300
Ideally, you should pick an open
source database, but eating is a

850
00:40:43,300 --> 00:40:47,000
classic it Playbook. 
And what we find time again, 

851
00:40:47,000 --> 00:40:50,400
though, is that the vendor new 
station is just one out of many 

852
00:40:50,400 --> 00:40:52,300
decisions. 
You Need to make. 

853
00:40:52,300 --> 00:40:55,000
And just recently, wrote a blog 
post, actually try to have nuts 

854
00:40:55,000 --> 00:40:59,200
to pick a cloud provider and it 
has clearly just comparing unit 

855
00:40:59,200 --> 00:41:01,100
costs. 
Tried applying the old way of 

856
00:41:01,100 --> 00:41:04,600
thinking to, the new operating 
model is almost guaranteed to 

857
00:41:04,600 --> 00:41:08,000
lead to prove himself. 
He much better starting point is

858
00:41:08,000 --> 00:41:11,500
to really think about what are 
the business metrics. 

859
00:41:11,500 --> 00:41:14,700
I want to know, why am I doing? 
This is not because, in fact, I 

860
00:41:14,700 --> 00:41:17,100
do interesting one because my 
resume needs some boosting, 

861
00:41:17,100 --> 00:41:19,000
right? 
I'm going to doing this thickens

862
00:41:19,000 --> 00:41:22,100
up, giving my business, some 
capabilities that It happened 

863
00:41:22,100 --> 00:41:25,000
before and those are 
capabilities that business very 

864
00:41:25,000 --> 00:41:27,900
much needs, like responding to 
uncertainty higher availability 

865
00:41:27,900 --> 00:41:30,200
for the systems under high rates
of change. 

866
00:41:30,200 --> 00:41:34,300
These are all things that were 
very difficult to do on premises

867
00:41:34,300 --> 00:41:38,300
that are possible in the club. 
And then I can start tracking by

868
00:41:38,300 --> 00:41:41,500
those metrics when it now, of 
course, there isn't a push 

869
00:41:41,500 --> 00:41:44,500
button, which says, improve my 
business metrics will cloud 

870
00:41:44,500 --> 00:41:47,900
provider hands that I wish. 
So now it comes to Translating 

871
00:41:47,900 --> 00:41:52,100
that into a path. 
Now, the business is Is not 

872
00:41:52,100 --> 00:41:55,200
going to be interested in each 
and every of your technical 

873
00:41:55,200 --> 00:41:58,500
decisions, but what they might 
be interested in, is the 

874
00:41:58,500 --> 00:42:01,500
principles that you apply. 
When you make the Wolves 

875
00:42:01,600 --> 00:42:03,600
decisions. 
Let me give you a classic 

876
00:42:03,600 --> 00:42:05,900
example. 
Do you want to think things 

877
00:42:05,900 --> 00:42:10,000
through very carefully and makes
it a, one shot for a specific 

878
00:42:10,000 --> 00:42:12,000
migration path. 
He figured it all out, you 

879
00:42:12,000 --> 00:42:15,200
sorted out, I'll do what a lie 
is and you're just make a club 

880
00:42:15,200 --> 00:42:18,700
it if you put it in the cloud. 
And in just beautiful, it's of a

881
00:42:18,700 --> 00:42:21,300
clot native users, everything 
into service. 

882
00:42:21,300 --> 00:42:22,800
The Do I need to be the 
operational? 

883
00:42:22,800 --> 00:42:25,100
Framework? 
It's beautiful, but it probably 

884
00:42:25,100 --> 00:42:29,800
took some time to get there or 
do you say I prefer the shortest

885
00:42:29,800 --> 00:42:32,700
paths to Value? 
So I left the chip 23 over 

886
00:42:32,700 --> 00:42:35,500
somehow, maybe make some 
changes, maybe replace the app 

887
00:42:35,500 --> 00:42:36,800
server with something open 
source. 

888
00:42:36,800 --> 00:42:40,100
Maybe we place the database but 
by and large and leave it as it 

889
00:42:40,100 --> 00:42:42,100
is, but which way you going to 
go? 

890
00:42:42,400 --> 00:42:44,700
That is a great principle to 
Define. 

891
00:42:45,000 --> 00:42:47,500
That's why I often say, do you 
want to have a principle of 

892
00:42:47,500 --> 00:42:51,400
shortest path to value and you 
need to be honest and the 

893
00:42:51,500 --> 00:42:53,800
Business will say, of course. 
Yes, we must show this pass the 

894
00:42:53,800 --> 00:42:55,300
value, because, of course, we 
want value. 

895
00:42:55,300 --> 00:42:58,400
Then as an architect. 
What you need to say is that is 

896
00:42:58,400 --> 00:43:00,700
great. 
But keep in mind that the 

897
00:43:00,700 --> 00:43:05,800
shortest character value in the 
long run is a longer path than 

898
00:43:05,800 --> 00:43:06,800
the straight shot. 
Right? 

899
00:43:06,800 --> 00:43:08,800
In the book. 
I liken this to Pythagoras. 

900
00:43:08,800 --> 00:43:11,600
If you can jump for bottom left 
to top right in from on 

901
00:43:11,600 --> 00:43:14,500
premises, traditional model is 
all the boxing's. 

902
00:43:14,500 --> 00:43:18,000
If you can jump the diagonal all
the way into Cloud Server, this 

903
00:43:18,000 --> 00:43:21,500
club made if that is the 
shortest path, but that might 

904
00:43:21,500 --> 00:43:23,600
not Be the shortest path. 
Stability of the shoulders 

905
00:43:23,600 --> 00:43:25,800
passive value skin that zigzag a
little bit. 

906
00:43:26,000 --> 00:43:29,500
So no, those are the trade-offs.
The business needs to understand

907
00:43:29,600 --> 00:43:34,400
and principles that imply those 
trade-offs on, a great way to 

908
00:43:34,400 --> 00:43:35,700
guide the cloud. 
Migration. 

909
00:43:36,300 --> 00:43:39,400
So I really like principle-based
kind of a decision approach 

910
00:43:39,400 --> 00:43:41,700
rather than which cloud provider
should we choose? 

911
00:43:41,800 --> 00:43:44,200
Because that is kind of natural 
for many people. 

912
00:43:44,400 --> 00:43:46,900
We want to go to the cloud. 
Okay, which best cloud provider,

913
00:43:46,900 --> 00:43:49,200
should we choose? 
But instead to start with the 

914
00:43:49,200 --> 00:43:51,400
principles behind, why you 
moving to the cloud? 

915
00:43:51,500 --> 00:43:53,600
Out and what kind of business 
metrics are you want to change 

916
00:43:53,600 --> 00:43:56,900
by enabling using the cloud? 
So I really love that principle 

917
00:43:56,900 --> 00:43:59,500
based approach speaking about 
these principles, right? 

918
00:43:59,500 --> 00:44:02,000
I'm sure throughout your career.
You have worked with many 

919
00:44:02,000 --> 00:44:04,200
different customers, many 
different people in the IT 

920
00:44:04,200 --> 00:44:07,200
industry. 
Do you see some common patterns 

921
00:44:07,200 --> 00:44:10,400
or empty patterns that are 
interesting for us to learn from

922
00:44:10,900 --> 00:44:12,400
you? 
I said at the beginning, you 

923
00:44:12,408 --> 00:44:15,800
know, somehow our business tends
to be defined by a pendulum 

924
00:44:15,800 --> 00:44:17,500
could, hopefully swings back and
forth. 

925
00:44:17,800 --> 00:44:21,400
So we see quite a few swinging 
pendulum hit and the one that 

926
00:44:21,600 --> 00:44:24,000
Eternal, it's always the 
multi-cloud. 

927
00:44:24,100 --> 00:44:27,700
How much do I want to be a 
single cloud and how easy do 

928
00:44:27,700 --> 00:44:30,200
when I want to make it to switch
to another Cloud? 

929
00:44:30,200 --> 00:44:33,200
It Panic on one hand. 
That is well, but why is right? 

930
00:44:33,200 --> 00:44:35,400
Because they are we talked about
uncertainty. 

931
00:44:35,600 --> 00:44:39,400
So if uncertainty forces you to 
change your vendor relationship,

932
00:44:39,400 --> 00:44:44,400
you should think about what that
implies but what we find time 

933
00:44:44,400 --> 00:44:48,800
and again is what is a very 
lengthy and architect way of 

934
00:44:48,800 --> 00:44:51,400
City, gigas people falling into 
the extreme. 

935
00:44:51,500 --> 00:44:55,000
It's the one is stream is like 
or it's just redefined I go with

936
00:44:55,000 --> 00:44:58,000
the slide provider because on a 
like their most recently than do

937
00:44:58,000 --> 00:45:00,900
they give me a nice t-shirt that
sort of the one extreme and the 

938
00:45:00,900 --> 00:45:05,500
Other Extreme is of course, we 
need the over Uber Cloud 

939
00:45:05,500 --> 00:45:07,500
abstraction something rather 
framework. 

940
00:45:07,500 --> 00:45:09,700
Basically, we're gonna build our
own cloud of other people's 

941
00:45:09,700 --> 00:45:12,300
Cloud. 
So that way we can do whatever 

942
00:45:12,300 --> 00:45:14,700
we want. 
The problem is both extreme. 

943
00:45:14,700 --> 00:45:17,800
I probably equally pad. 
That's not like attack you 

944
00:45:17,800 --> 00:45:20,500
dealing with trade-offs. 
It's always occurred throughout 

945
00:45:20,600 --> 00:45:22,900
the left and right and Point is 
never the best choice. 

946
00:45:22,900 --> 00:45:24,600
The best choice is somewhere in 
the middle. 

947
00:45:24,900 --> 00:45:27,100
We see this pendulum swinging 
back and forth. 

948
00:45:27,500 --> 00:45:31,500
What people realize is when they
walk this multi-cloud, you 

949
00:45:31,500 --> 00:45:34,700
butter, something rather than 
layer the motivation isn't 

950
00:45:34,700 --> 00:45:38,300
actually all about right there 
thinking about switching costs, 

951
00:45:38,500 --> 00:45:41,300
more believe they call this lock
hypnotism little bit of an 

952
00:45:41,300 --> 00:45:43,800
Archer for me. 
It's really just switching cost.

953
00:45:44,000 --> 00:45:45,800
If you want to switch to 
something else. 

954
00:45:46,200 --> 00:45:47,900
How much is it gonna cost you? 
How long? 

955
00:45:47,900 --> 00:45:50,400
Is it gonna take you to make 
that switch and then you can 

956
00:45:50,400 --> 00:45:53,400
calculate what is the Unlikely 
or tap the switch happens. 

957
00:45:53,700 --> 00:45:55,800
Now, you can buy yourself 
options. 

958
00:45:56,100 --> 00:45:58,800
You can abstract things away and
you can run containers. 

959
00:45:58,800 --> 00:46:01,600
We can use open source, many, 
many options. 

960
00:46:01,600 --> 00:46:05,900
You could buy to reduce that 
such angles as we set these 

961
00:46:05,900 --> 00:46:09,600
options, on all connected. 
To a cost of neck City or 

962
00:46:09,600 --> 00:46:13,400
feature under utilization, is 
probably the biggest cost that 

963
00:46:13,400 --> 00:46:15,900
you have. 
But there's one option that I 

964
00:46:15,900 --> 00:46:19,700
see Enterprises much more 
dangerously neglecting this, 

965
00:46:19,700 --> 00:46:23,700
this weird notion that It 
followed of lockean is somehow 

966
00:46:23,700 --> 00:46:26,500
set by the vendor. 
Then somehow assume like this 

967
00:46:26,500 --> 00:46:29,200
Vendome luxury because we're 
like some evil people who want 

968
00:46:29,200 --> 00:46:31,300
to take all your body of 
whatever you think it's somehow 

969
00:46:31,300 --> 00:46:33,400
assume that ended just a locking
it. 

970
00:46:33,700 --> 00:46:36,600
I don't think that is true at 
all. 

971
00:46:36,800 --> 00:46:40,900
If you defy the Locking as 
switching cost, you are 

972
00:46:40,900 --> 00:46:44,100
switching. 
Cost is dramatically determined 

973
00:46:44,300 --> 00:46:49,100
body, your organization's 
velocity and Agility like the 

974
00:46:49,100 --> 00:46:51,900
rate of change. 
You can handle it, how Quickly, 

975
00:46:51,900 --> 00:46:57,500
you can change things that is at
least as the big factor in 

976
00:46:57,500 --> 00:47:01,100
switching cost, anything that 
been vendor brings into the 

977
00:47:01,107 --> 00:47:03,000
equation. 
So let's put it this way. 

978
00:47:03,100 --> 00:47:05,700
Let's say your modern software 
delivery shot. 

979
00:47:05,700 --> 00:47:09,600
Everything is eicd automated, 
testing shift left gets a cop's 

980
00:47:09,600 --> 00:47:11,100
whatever buzzwords you on the 
tire. 

981
00:47:11,200 --> 00:47:13,800
But basically a low-friction 
sock delivery. 

982
00:47:14,000 --> 00:47:17,200
If you have an idea you need to 
do something you could Implement

983
00:47:17,200 --> 00:47:20,700
and deploy this very quickly. 
Now, whatever reason it might be

984
00:47:20,800 --> 00:47:23,800
you need to Move things into a 
different cloud provider. 

985
00:47:24,000 --> 00:47:26,800
What you take all your fully 
automated setups, right? 

986
00:47:26,800 --> 00:47:29,200
You need to make some changes, 
probably different. 

987
00:47:29,200 --> 00:47:32,400
I am different databases 
underneath some different 

988
00:47:32,400 --> 00:47:36,100
tunings yelling of making some 
changes, but you have a bell or 

989
00:47:36,100 --> 00:47:38,500
a machine that can absorb this 
changes. 

990
00:47:38,500 --> 00:47:42,200
You can test these changes. 
You can deploy these changes and

991
00:47:42,200 --> 00:47:46,500
off you go. 
Now that low lock in if you wish

992
00:47:46,500 --> 00:47:49,800
with air quotes, that low 
switching cost is because of the

993
00:47:49,800 --> 00:47:53,300
way you operate. 
The way I explain this is this 

994
00:47:53,300 --> 00:47:55,700
is the very reason that you 
fight. 

995
00:47:55,700 --> 00:47:59,800
Many startup companies not have 
the oldest tummy aches about 

996
00:47:59,800 --> 00:48:02,700
about the cloud strategy. 
The traditional business, they 

997
00:48:02,700 --> 00:48:04,800
say, oh, well, the startups 
don't need about the cloud 

998
00:48:04,800 --> 00:48:06,400
strategy because they are 
regulated. 

999
00:48:06,400 --> 00:48:09,200
Then on every anything to lose 
blah blah blah bullshit. 

1000
00:48:09,300 --> 00:48:11,500
Physically, right? 
So that companies have a lot to 

1001
00:48:11,500 --> 00:48:13,600
lose, if it takes a highly 
regulated. 

1002
00:48:13,600 --> 00:48:16,200
This is not the reason. 
They're not having tummy ache. 

1003
00:48:16,200 --> 00:48:18,700
So party Cloud strategies. 
The real reason. 

1004
00:48:18,700 --> 00:48:21,300
Is there Hannah palasa teeth a 
lower friction. 

1005
00:48:21,600 --> 00:48:23,100
They have a lower cost of 
change. 

1006
00:48:23,100 --> 00:48:26,600
So if some change comes along 
they just deal with it and 

1007
00:48:26,600 --> 00:48:28,300
they're not stuck for three 
years. 

1008
00:48:28,500 --> 00:48:31,000
They deal with it and six weeks,
they're up and running in 

1009
00:48:31,000 --> 00:48:33,800
another cloud and maybe it's 
even three weeks that off they 

1010
00:48:33,800 --> 00:48:36,500
go. 
So in this pendulum that swings 

1011
00:48:36,500 --> 00:48:39,500
between these, like, how much do
I need to be committed to what 

1012
00:48:39,500 --> 00:48:41,700
they do. 
The other the part that I find 

1013
00:48:41,700 --> 00:48:46,900
is too much neglected your your 
own velocity and that should be 

1014
00:48:46,900 --> 00:48:49,700
the biggest determinant of your 
switching costs. 

1015
00:48:49,700 --> 00:48:52,200
Not whatever the vendor brings. 
To the table. 

1016
00:48:52,800 --> 00:48:55,700
Thanks for reminding us about 
this lock-in versus switching 

1017
00:48:55,700 --> 00:48:58,500
cost because you actually wrote 
a lot about this and discuss it 

1018
00:48:58,500 --> 00:49:00,000
online. 
Few months back. 

1019
00:49:00,200 --> 00:49:02,100
What different levels of locking
are there? 

1020
00:49:02,300 --> 00:49:04,800
Is it like software lock in 
front door locking Hardware, 

1021
00:49:04,800 --> 00:49:06,800
looking and all that. 
Thanks for reminding us. 

1022
00:49:06,800 --> 00:49:08,700
Actually. 
The lock-in is simply something 

1023
00:49:08,700 --> 00:49:11,400
that you have to consider from 
your own point of view. 

1024
00:49:11,600 --> 00:49:14,600
How much velocity can you do in 
the case that if you need to 

1025
00:49:14,600 --> 00:49:16,000
change? 
Can you really do it? 

1026
00:49:16,000 --> 00:49:19,600
Fast persuasive essay? 
You don't have much it skills. 

1027
00:49:19,600 --> 00:49:21,300
For example, so locking becomes 
more. 

1028
00:49:21,500 --> 00:49:23,800
Probably not even though 
probably the software vendor 

1029
00:49:23,800 --> 00:49:26,800
heart is not so difficult to 
move out from. 

1030
00:49:27,000 --> 00:49:29,100
So I think this is a good 
reminder for all of us. 

1031
00:49:29,400 --> 00:49:32,500
Another thing that you wrote In 
the book about common and the 

1032
00:49:32,500 --> 00:49:35,700
pattern or mindset difference is
that cloud should not be an 

1033
00:49:35,700 --> 00:49:38,700
infrastructure topic, but all 
these days people talk about 

1034
00:49:38,700 --> 00:49:41,900
cloud is more about moving their
infrastructure live friendship, 

1035
00:49:41,900 --> 00:49:45,200
like from on-prem two, VMS or 
communities container and all 

1036
00:49:45,200 --> 00:49:47,400
that. 
Why do you think that it's not 

1037
00:49:47,400 --> 00:49:51,200
an infrastructure topic then you
send it off in it? 

1038
00:49:51,400 --> 00:49:54,500
Starts with infrastructure 
because Lance the classic ID 

1039
00:49:54,500 --> 00:49:57,200
moderate, you found the ticket, 
you get a server or VM but 

1040
00:49:57,200 --> 00:49:59,700
mainly the rest is with the 
application teams. 

1041
00:50:00,100 --> 00:50:05,200
The reasons that is no longer so
is because we work in different 

1042
00:50:05,200 --> 00:50:07,200
ways. 
Reason we work in different ways

1043
00:50:07,200 --> 00:50:09,500
is because the market has 
different demands for 

1044
00:50:09,500 --> 00:50:12,300
applications. 
We need applications that can 

1045
00:50:12,300 --> 00:50:15,900
undergo a high rate of change 
while maintaining High 

1046
00:50:16,000 --> 00:50:18,600
reliability. 
Many people, Texas, still back 

1047
00:50:18,600 --> 00:50:21,100
then baked in. 
We do something quick and dirty,

1048
00:50:21,100 --> 00:50:22,700
right? 
It's always this per seat 

1049
00:50:22,700 --> 00:50:27,200
dichotomy that we do either, I'm
moving fast or I do something 

1050
00:50:27,200 --> 00:50:29,400
high quality. 
The couple of years ago is the 

1051
00:50:29,400 --> 00:50:32,400
analyst even tried to make this 
a lot of official with these 

1052
00:50:32,400 --> 00:50:34,100
ill-advised to speed 
architectures. 

1053
00:50:34,100 --> 00:50:36,400
They said, oh, on the front 
there and you can people be 

1054
00:50:36,400 --> 00:50:39,100
quickly, because if you break 
something, it's not so bad, but 

1055
00:50:39,100 --> 00:50:40,900
your back end, has to move very 
slowly. 

1056
00:50:40,900 --> 00:50:42,900
They can see have to be going 
careful. 

1057
00:50:43,100 --> 00:50:45,700
I will side one chapter from the
new software, architect 

1058
00:50:45,700 --> 00:50:49,300
elevator, and it's called snow 
chaos, is not order. 

1059
00:50:49,500 --> 00:50:52,200
Just moving slow leak. 
Doesn't Makes things actually 

1060
00:50:52,200 --> 00:50:56,300
better and we've actually found 
that moving faster often 

1061
00:50:56,300 --> 00:50:58,800
increases quality. 
That's where all the automation,

1062
00:50:58,800 --> 00:51:02,500
see ICD all these kind of things
happen to play in the idea of 

1063
00:51:02,500 --> 00:51:05,400
higher quality, High 
operational, reliability at the 

1064
00:51:05,400 --> 00:51:09,000
height and weight of change. 
Now, the reason that relates to 

1065
00:51:09,000 --> 00:51:12,400
infrastructure is because that 
way of working is no longer 

1066
00:51:12,400 --> 00:51:14,200
infrastructure. 
Centre point of view. 

1067
00:51:14,500 --> 00:51:16,700
I already said, right. 
It's about see ICD about 

1068
00:51:16,700 --> 00:51:20,100
desktops, but delivery pipeline 
about software on Terminal. 

1069
00:51:20,100 --> 00:51:22,800
It's probably also about you. 
Medications infrastructure, your

1070
00:51:22,800 --> 00:51:25,900
service measures. 
There's a lot of stuff around if

1071
00:51:25,900 --> 00:51:30,300
that makes this whale working 
possible and that stuff isn't 

1072
00:51:30,300 --> 00:51:32,800
infrastructure. 
So, if you want the cloud 

1073
00:51:32,800 --> 00:51:35,600
operating model, you don't want 
to look just at the 

1074
00:51:35,607 --> 00:51:38,400
infrastructure you want to look 
at what I cleaning or what. 

1075
00:51:38,400 --> 00:51:42,000
I call the be more often and 
application-centric law because 

1076
00:51:42,000 --> 00:51:44,400
that's where you get the 
velocity of the agility. 

1077
00:51:44,700 --> 00:51:46,200
That's where you get to move 
quickly. 

1078
00:51:46,500 --> 00:51:49,200
That is also how we reduce the 
switching cost. 

1079
00:51:49,200 --> 00:51:51,200
That's how you reduce type. 
Did you feature? 

1080
00:51:51,300 --> 00:51:53,100
Release. 
That's how you recover more 

1081
00:51:53,100 --> 00:51:54,700
quickly, in case something goes 
wrong. 

1082
00:51:55,000 --> 00:51:57,900
So all of these benefits cannot 
come from the infrastructure 

1083
00:51:57,900 --> 00:52:01,100
alone. 
They come from a nice, interplay

1084
00:52:01,100 --> 00:52:04,200
between application delivery and
infrastructure. 

1085
00:52:04,500 --> 00:52:06,800
This is probably one of the 
biggest ships. 

1086
00:52:06,800 --> 00:52:09,100
I have a chapter in the book. 
It's called the cloud turns, the

1087
00:52:09,100 --> 00:52:12,300
organization sideways. 
This place exactly on this. 

1088
00:52:12,300 --> 00:52:14,900
It used to be at this nice 
infrastructure layer. 

1089
00:52:14,900 --> 00:52:17,600
Then you have the middleware 
layer and the application layer 

1090
00:52:17,600 --> 00:52:19,200
and their own in their own 
layer. 

1091
00:52:19,400 --> 00:52:22,400
And it turns out to actually 
operate The modern operating 

1092
00:52:22,400 --> 00:52:25,300
model in a high Pace model. 
You basically need to turn this 

1093
00:52:25,300 --> 00:52:28,900
sideways 90 degrees, where you 
work across the different 

1094
00:52:28,900 --> 00:52:31,300
layers. 
Well, folks who managed to do 

1095
00:52:31,300 --> 00:52:33,800
that. 
Those are in the end, the ones 

1096
00:52:33,800 --> 00:52:35,500
who lead the benefits from the 
cloud. 

1097
00:52:35,500 --> 00:52:39,500
Migration, that's we see time. 
And again, and another quite 

1098
00:52:39,500 --> 00:52:42,600
common that I see along with 
this Cloud Journey, or since 

1099
00:52:42,600 --> 00:52:45,500
there are multiple clouds, since
they have different options, 

1100
00:52:45,500 --> 00:52:47,800
that people can choose in terms 
of products services, and 

1101
00:52:47,800 --> 00:52:49,400
different ways of securing 
things. 

1102
00:52:49,400 --> 00:52:52,300
A lot of customers actually 
thinking about About building 

1103
00:52:52,300 --> 00:52:54,800
in-house platform, or in-house 
Cloud platform. 

1104
00:52:54,800 --> 00:52:57,900
So, to speak in what kind of 
abstraction layer to deal with 

1105
00:52:57,900 --> 00:53:00,600
different complexities? 
For example, different apis, 

1106
00:53:00,600 --> 00:53:03,300
different products, different 
services and you mentioned this 

1107
00:53:03,300 --> 00:53:05,100
in one of the chapters of the 
book as well. 

1108
00:53:05,300 --> 00:53:08,600
What do you think about this 
strategy of building in-house 

1109
00:53:08,600 --> 00:53:12,000
Cloud platform? 
So, I like platforms unlocked 

1110
00:53:12,000 --> 00:53:16,400
and then riding a sheep book on 
platform strategy because 

1111
00:53:16,400 --> 00:53:18,900
something black forms and 
something very powerful. 

1112
00:53:18,900 --> 00:53:21,200
And I'm also a pretty big fan of
the team too. 

1113
00:53:21,400 --> 00:53:24,000
Achieves, full crunch, which 
talks about platform teams. 

1114
00:53:24,300 --> 00:53:27,800
The reason platforms are such a 
powerful concept diabetic, 

1115
00:53:27,800 --> 00:53:29,500
loudest, perfect. 
Peace out. 

1116
00:53:29,500 --> 00:53:33,300
Police that platforms are 
something relatively stable and 

1117
00:53:33,700 --> 00:53:38,800
harmonized, but at the same time
they and nabal at high rate of 

1118
00:53:38,800 --> 00:53:40,800
change and a high rate of 
innovation. 

1119
00:53:41,100 --> 00:53:43,600
Sometimes if I want to wake up 
our customers a little bit. 

1120
00:53:43,800 --> 00:53:47,400
I tell that that the cloud you 
body is the same Cloud your 

1121
00:53:47,400 --> 00:53:49,800
competitors by the books of a 
slightly shocked. 

1122
00:53:49,800 --> 00:53:52,900
This like, yes, the prince Apple
off a cloud platform is 

1123
00:53:52,900 --> 00:53:54,900
standardization and 
harmonization. 

1124
00:53:54,900 --> 00:53:58,200
Otherwise the think and it's 
gay, but God Computing has 

1125
00:53:58,200 --> 00:54:00,400
surely been the biggest 
Innovation driver at the last 

1126
00:54:00,400 --> 00:54:03,500
decade in Acts on this Something
Magic about platforms. 

1127
00:54:03,800 --> 00:54:07,400
Now, the question is, how should
you deal with that in house? 

1128
00:54:07,700 --> 00:54:11,600
But big fan of platform teams in
house, they actually had cafta 

1129
00:54:11,600 --> 00:54:14,200
Kapoor. 
I was working closely originally

1130
00:54:14,200 --> 00:54:17,000
were called with application 
infrastructure team, then we did

1131
00:54:17,000 --> 00:54:19,500
like the infrastructure of term 
so much for the reasons. 

1132
00:54:19,500 --> 00:54:21,600
We just mentioned. 
So we became the Rick 

1133
00:54:21,600 --> 00:54:26,000
productivity team and that was 
clearly a platform t, a couple 

1134
00:54:26,000 --> 00:54:29,900
of important things for such a 
platform team to 60 a. 

1135
00:54:30,500 --> 00:54:35,300
Make sure you enable the lot of 
traditional it when they want to

1136
00:54:35,300 --> 00:54:38,700
harmonize something I had for 
that D of the ligand platform. 

1137
00:54:38,900 --> 00:54:42,600
They thinking about constraining
the thinking part standards. 

1138
00:54:42,600 --> 00:54:45,300
You can't use this database, but
you can only use that word. 

1139
00:54:45,300 --> 00:54:47,800
And here's the 70 quality Gates.
You have to go through there. 

1140
00:54:47,800 --> 00:54:51,200
Always think about constraint 
that's sort of the classic. 

1141
00:54:51,300 --> 00:54:54,300
It idea of application delivery,
because Wild West and 

1142
00:54:54,300 --> 00:54:56,500
infrastructure. 
Some of having to come in and 

1143
00:54:56,500 --> 00:55:00,300
restore Law and Order that model
makes for great continuity. 

1144
00:55:00,300 --> 00:55:03,300
Doesn't make for very great and 
it t, so platforms. 

1145
00:55:03,300 --> 00:55:05,600
Need to enable. 
That's the first thing. 

1146
00:55:06,000 --> 00:55:09,500
The second thing is the 
platform's, your bill can be 

1147
00:55:09,500 --> 00:55:13,600
cast in store, like successful 
platforms, aren't they Envision 

1148
00:55:13,600 --> 00:55:16,900
the future in five years that 
you go to build that and that 

1149
00:55:16,900 --> 00:55:20,400
for the half years low that 
future essentially in place. 

1150
00:55:20,600 --> 00:55:23,700
This is not Works. 
If you look at AWS via great 

1151
00:55:23,700 --> 00:55:25,800
example, right is constantly 
evolving. 

1152
00:55:25,800 --> 00:55:28,000
It's always taking feedback from
customers. 

1153
00:55:28,400 --> 00:55:32,000
So an in-house platform also 
needs to take feedback. 

1154
00:55:32,200 --> 00:55:34,600
You can't assume you're smarter 
than everybody else. 

1155
00:55:35,100 --> 00:55:37,200
The third advice. 
I would give for in-house 

1156
00:55:37,200 --> 00:55:39,500
platforms. 
Don't rebuild. 

1157
00:55:39,500 --> 00:55:41,800
What other platforms have 
already done. 

1158
00:55:42,100 --> 00:55:44,600
There's at least three major 
Cloud providers, maybe four or 

1159
00:55:44,600 --> 00:55:46,300
five, depending on how you 
count. 

1160
00:55:46,400 --> 00:55:49,400
I haven't checked our combined 
market cap, but it's like 

1161
00:55:49,400 --> 00:55:52,900
somewhere five trillion plus 
There's a lot of smarts and a 

1162
00:55:52,900 --> 00:55:55,600
lot of innovation and a lot of 
things going in there. 

1163
00:55:55,800 --> 00:55:58,000
And that is a huge value for 
you. 

1164
00:55:58,000 --> 00:56:00,800
Because all that Innovation 
comes to you for like ten. 

1165
00:56:00,800 --> 00:56:03,900
He's an hour or micro candy 
store API request. 

1166
00:56:04,000 --> 00:56:07,000
It's basically, they're cheap 
the way you get to consume that 

1167
00:56:07,000 --> 00:56:09,900
Innovation. 
Don't sing that with a small 

1168
00:56:09,900 --> 00:56:13,200
in-house platform team. 
You are not able to compete with

1169
00:56:13,200 --> 00:56:16,000
that and build some sort of 
abstraction layer, then somehow 

1170
00:56:16,000 --> 00:56:19,900
magically keeps up with all the 
stuff that isn't that neat. 

1171
00:56:20,200 --> 00:56:24,200
So if you follow Those three 
points of administrative nabel 

1172
00:56:24,200 --> 00:56:27,300
crowd with a disabled that you 
take feedback, rather than 

1173
00:56:27,300 --> 00:56:29,200
thinking you're smarter than 
anybody else. 

1174
00:56:29,500 --> 00:56:32,700
And if you don't replicate 
everything and it's all these 

1175
00:56:32,700 --> 00:56:37,000
layer, I think you can have a 
very productive and very happy 

1176
00:56:37,100 --> 00:56:41,000
in-house platform T because you 
can make assumptions that are 

1177
00:56:41,000 --> 00:56:43,600
true in new organization that 
might not be true. 

1178
00:56:43,600 --> 00:56:46,600
In all organizations the 
platform, like AWS need to 

1179
00:56:46,600 --> 00:56:49,000
support many different 
Enterprises and digital native 

1180
00:56:49,000 --> 00:56:51,300
businesses. 
So maybe you can narrow Oh 

1181
00:56:51,308 --> 00:56:54,200
things down a little bit that is
totally fine. 

1182
00:56:54,200 --> 00:56:57,900
You can make smart default. 
You can defy processes that are 

1183
00:56:57,900 --> 00:57:00,800
related to eat Industries. 
There's many great things in 

1184
00:57:00,800 --> 00:57:03,100
there. 
But I highly advise you to 

1185
00:57:03,100 --> 00:57:06,000
follow the three ground rules of
making it in halves platform 

1186
00:57:06,000 --> 00:57:09,700
team and also that each of the 
cloud provider itself evolves, 

1187
00:57:09,700 --> 00:57:11,900
right? 
So, their products change their 

1188
00:57:11,900 --> 00:57:15,200
new products coming out as well,
how they interplay each other. 

1189
00:57:15,200 --> 00:57:17,700
I think it's also something that
sometimes the platform team 

1190
00:57:17,700 --> 00:57:20,300
didn't foresee in the beginning 
when they wanted to build a 

1191
00:57:20,308 --> 00:57:21,900
platform. 
They I'll be see. 

1192
00:57:21,900 --> 00:57:24,400
Okay, this card provider 
provides, this kind of 

1193
00:57:24,400 --> 00:57:27,400
capabilities now, but actually 
maybe one year after that all 

1194
00:57:27,400 --> 00:57:30,100
things will change. 
You also have to maintain or 

1195
00:57:30,100 --> 00:57:33,200
even change a refactor, the kind
of platform that you have built 

1196
00:57:33,200 --> 00:57:35,800
over the time in order to keep 
up with the changes from the 

1197
00:57:35,800 --> 00:57:38,000
cloud providers. 
I think it's also something that

1198
00:57:38,000 --> 00:57:40,700
is very tricky to deal with. 
And another thing that it's 

1199
00:57:40,700 --> 00:57:43,300
quite common, speaking about it 
industry, these days is about 

1200
00:57:43,300 --> 00:57:45,300
shiny object syndrome or 
passwords. 

1201
00:57:45,500 --> 00:57:48,900
Then you have this long, which 
you call a Gregor's log, 

1202
00:57:48,900 --> 00:57:51,100
excessive complexity. 
So what? 

1203
00:57:51,200 --> 00:57:54,200
Is the relation of complexity 
here and you know, like password

1204
00:57:54,200 --> 00:57:56,400
driven, kind of development. 
You have to. 

1205
00:57:56,500 --> 00:57:58,500
We talked about complexity a few
times. 

1206
00:57:58,600 --> 00:58:02,500
I think if this whole exercise 
complexity is your biggest enemy

1207
00:58:02,700 --> 00:58:05,000
because complexity slows you 
down complexity. 

1208
00:58:05,000 --> 00:58:08,200
It reduces errors complexity 
hurts your operational 

1209
00:58:08,200 --> 00:58:10,500
abilities. 
In the end complexity is really 

1210
00:58:10,500 --> 00:58:13,400
the root of much evil that we 
say, like, if you go back to the

1211
00:58:13,400 --> 00:58:16,400
beginning, that's really the 
options Marketplace, having 

1212
00:58:16,400 --> 00:58:18,300
options. 
That's great options, cost. 

1213
00:58:18,300 --> 00:58:21,000
You the cost is usually 
complexity in finding a good 

1214
00:58:21,000 --> 00:58:22,900
path. 
Once the hair is probably, when 

1215
00:58:22,900 --> 00:58:26,400
I get x to the reason I relate 
this to shiny objects, and 

1216
00:58:26,400 --> 00:58:28,600
passwords is because being a 
knight TD. 

1217
00:58:28,600 --> 00:58:31,100
Sting is, can be like the kid in
the candy store. 

1218
00:58:31,200 --> 00:58:33,600
All the stuff. 
You have, all the different open

1219
00:58:33,600 --> 00:58:36,700
source projects with like, 
ridiculous names and we are 200 

1220
00:58:36,700 --> 00:58:38,200
service in San. 
Aw us as well. 

1221
00:58:38,200 --> 00:58:40,900
Like you add the other services 
from the other Cloud providers. 

1222
00:58:41,100 --> 00:58:44,900
You just have stuff to know it 
and when you keep spewing out, 

1223
00:58:44,900 --> 00:58:48,300
these kind of bus routes, a 
couple of dogs things actually 

1224
00:58:48,400 --> 00:58:51,100
happen, a it doesn't make a 
viable strategy. 

1225
00:58:51,200 --> 00:58:54,400
It's just like a mishmash of 
like random stuff. 

1226
00:58:54,700 --> 00:58:58,100
And the other thing that it will
also do is it will cause 

1227
00:58:58,100 --> 00:59:01,700
enormous complexity, big 
kitchens like a pile of random 

1228
00:59:01,700 --> 00:59:05,800
Singh said, you think you'd need
to have it's like going to the 

1229
00:59:05,800 --> 00:59:08,800
supermarket and there's all 
these great fantastic foods. 

1230
00:59:08,800 --> 00:59:10,700
You can happen. 
You like all of them. 

1231
00:59:11,000 --> 00:59:13,900
So you pick them pop Corning, 
you pick the Pasta sauce and he 

1232
00:59:13,900 --> 00:59:16,200
took the steak and you pick all 
this kind of stuff because he 

1233
00:59:16,200 --> 00:59:18,500
liked all of them, you put it in
one big pot. 

1234
00:59:18,500 --> 00:59:21,100
Then you cook this and nobody's 
going to eat. 

1235
00:59:21,400 --> 00:59:25,500
Instantly like it edible. 
So, ideal strategy. 

1236
00:59:25,500 --> 00:59:28,300
It's like this. 
You can't fall victim to the bus

1237
00:59:28,300 --> 00:59:30,100
words. 
You need to have in mind. 

1238
00:59:30,100 --> 00:59:33,000
What am I going to cook? 
Get the right ingredient to? 

1239
00:59:33,000 --> 00:59:35,200
What are you going to cook? 
And put the right pieces 

1240
00:59:35,200 --> 00:59:37,000
together? 
You can just randomly 

1241
00:59:37,000 --> 00:59:40,400
mix-and-match, other words. 
The reason that relates to 

1242
00:59:40,400 --> 00:59:44,100
Gregor's law, is it comes back 
to having the options. 

1243
00:59:44,300 --> 00:59:48,900
Having options is nice. 
But in the extreme caves, you 

1244
00:59:48,900 --> 00:59:52,300
will find folks who want all of 
the Objects or what if this 

1245
00:59:52,300 --> 00:59:53,900
happens? 
What if I need to go in another 

1246
00:59:53,900 --> 00:59:55,400
industry, or what? 
If I need to change my 

1247
00:59:55,408 --> 00:59:58,100
technology, what if I need to 
operate on Mars? 

1248
00:59:58,100 --> 01:00:00,900
What if the aliens invaded, I 
need to be prepared with my idea

1249
01:00:00,900 --> 01:00:02,900
of structure. 
I just need to have all the 

1250
01:00:02,900 --> 01:00:05,300
options. 
These are the people who never 

1251
01:00:05,300 --> 01:00:08,500
want to make a decision. 
The decision is to just have all

1252
01:00:08,500 --> 01:00:10,100
options available at all. 
Time. 

1253
01:00:10,400 --> 01:00:14,400
I'm seeing this and I can't this
Gregor's law and and then it 

1254
01:00:14,400 --> 01:00:18,400
goes as follows. 
Excessive complexity is Nature's

1255
01:00:18,400 --> 01:00:21,100
punishment for organizations who
are unable. 

1256
01:00:21,200 --> 01:00:24,100
To make decisions somebody who 
wants everything. 

1257
01:00:24,100 --> 01:00:26,600
It was just like blinded by all 
the passwords. 

1258
01:00:26,900 --> 01:00:29,100
It has to be this. 
There has to be that and it has 

1259
01:00:29,100 --> 01:00:32,300
to be able to do this. 
They suffer from excessive 

1260
01:00:32,300 --> 01:00:36,000
complexity and that in the end 
is what slows them down. 

1261
01:00:36,300 --> 01:00:40,200
The weird part of it is the 
ironic part is often. 

1262
01:00:40,200 --> 01:00:44,800
They took this route under the 
idea that somehow it would 

1263
01:00:44,800 --> 01:00:47,400
reduce Market because they want 
to have all the options I do. 

1264
01:00:47,400 --> 01:00:49,500
If I have all the options that 
never really knocked it to 

1265
01:00:49,508 --> 01:00:52,700
anything but in the end. 
Then locked into their own 

1266
01:00:52,700 --> 01:00:55,000
complexity, more than anything 
else. 

1267
01:00:55,200 --> 01:00:57,000
And that is Nature's 
punishments, right? 

1268
01:00:57,000 --> 01:00:58,900
That is the essence of Gregor's 
law. 

1269
01:00:59,100 --> 01:01:04,100
So go make some decisions, make 
conscious decisions, take some 

1270
01:01:04,100 --> 01:01:07,600
options, but also makes some 
conscious decisions that were 

1271
01:01:07,600 --> 01:01:10,700
you get the complexity doubted, 
your life would be much happier.

1272
01:01:11,500 --> 01:01:14,500
I really love that love. 
So excessive complexity is 

1273
01:01:14,500 --> 01:01:17,500
Nature's punishment. 
If you are unable to make any 

1274
01:01:17,500 --> 01:01:21,000
decision, thanks for reminding 
that and I think I could relate 

1275
01:01:21,000 --> 01:01:23,500
to These as well, sometimes we 
just want all the options 

1276
01:01:23,500 --> 01:01:25,300
available, all the cool 
Technologies out there. 

1277
01:01:25,300 --> 01:01:28,700
But actually, we are like stuck 
in all the complexities by first

1278
01:01:28,700 --> 01:01:31,500
of all having to learn each of 
the technology and also how they

1279
01:01:31,500 --> 01:01:33,000
interplay with each other. 
Right? 

1280
01:01:33,100 --> 01:01:36,200
And the second thing is that 
what are the available people to

1281
01:01:36,200 --> 01:01:39,100
support all this complexity? 
Maybe last question on this 

1282
01:01:39,100 --> 01:01:41,700
Cloud strategy. 
How should an organization 

1283
01:01:41,700 --> 01:01:45,200
actually embark on this journey.
So, how do you structure your 

1284
01:01:45,200 --> 01:01:47,300
team? 
How do you obscure your people? 

1285
01:01:47,600 --> 01:01:50,500
How do you actually go about it 
in terms of organizational 

1286
01:01:50,500 --> 01:01:54,100
level? 
Yes, it's always a people topic,

1287
01:01:54,100 --> 01:01:57,100
but transformation. 
The a tech is all available more

1288
01:01:57,100 --> 01:01:58,600
than you probably will ever 
need. 

1289
01:01:58,700 --> 01:02:02,100
So in the end, it's really 
changing the way of working. 

1290
01:02:02,300 --> 01:02:05,400
If you don't change the way your
organization works, the cloud is

1291
01:02:05,400 --> 01:02:06,300
coming. 
Look much more. 

1292
01:02:06,300 --> 01:02:09,300
Like another data center. 
We have very nice data centers, 

1293
01:02:09,300 --> 01:02:11,700
but no it executive. 
I've met ever needed another 

1294
01:02:11,700 --> 01:02:15,700
data set so you should change 
the way your folks operate and 

1295
01:02:15,700 --> 01:02:17,400
think about it. 
I should have a chapter in the 

1296
01:02:17,408 --> 01:02:18,900
book, right? 
Because we always talk about 

1297
01:02:18,900 --> 01:02:22,200
that, five six or seven hours 
off my Ready applications. 

1298
01:02:22,500 --> 01:02:24,900
So should you find the Mrs of my
grading? 

1299
01:02:25,000 --> 01:02:28,600
Your work force because you also
need to re-skill sometimes 

1300
01:02:28,600 --> 01:02:31,200
replaced. 
Sometimes retire your Workforce,

1301
01:02:31,500 --> 01:02:34,900
couple of things. 
I always say up from the most 

1302
01:02:34,900 --> 01:02:37,400
common concern is are the 
executives come to these? 

1303
01:02:37,400 --> 01:02:39,900
Like I get all this Cloud 
software really want to do it, 

1304
01:02:40,200 --> 01:02:42,800
but I don't have to like people 
so it's like I don't have any 

1305
01:02:42,800 --> 01:02:45,200
people that I can't hire the 
right people because I'm a 

1306
01:02:45,200 --> 01:02:48,100
boring exercise that Cuppa tea. 
I'm not a Silicon Valley 

1307
01:02:48,100 --> 01:02:50,200
Hotshot. 
I usually pause the 

1308
01:02:50,200 --> 01:02:52,800
conversation. 
Right there and I make people 

1309
01:02:52,800 --> 01:02:55,400
take two very important factors.
It took hell. 

1310
01:02:55,800 --> 01:02:58,400
Did he? 
If you think your people are 

1311
01:02:58,500 --> 01:03:02,000
risk, averse, or they don't want
to change or they're not like to

1312
01:03:02,000 --> 01:03:03,900
sort of work in this new 
environment. 

1313
01:03:04,100 --> 01:03:07,600
You late the behave, that way 
when I was in kindergarten, 

1314
01:03:07,600 --> 01:03:10,200
nobody was thinking about 
locking in and being risk 

1315
01:03:10,200 --> 01:03:12,100
averse. 
And not trying things out. 

1316
01:03:12,300 --> 01:03:16,200
You organization, tall people 
that taking risks is not a 

1317
01:03:16,200 --> 01:03:18,200
rewarded, but it might be 
punished. 

1318
01:03:18,200 --> 01:03:20,900
Then there's no support for 
experimentation trying new 

1319
01:03:20,900 --> 01:03:23,800
things. 
You organization talked about, 

1320
01:03:24,200 --> 01:03:27,000
so now you're liable to and 
teach them that. 

1321
01:03:27,000 --> 01:03:29,400
Because if you've been teaching 
that to them for 20 years, you 

1322
01:03:29,400 --> 01:03:31,100
can say you have the wrong 
people. 

1323
01:03:31,400 --> 01:03:34,000
You have exactly the people that
you taught them to be. 

1324
01:03:34,300 --> 01:03:37,100
So don't come to me now and say,
oh, I need different kind of P. 

1325
01:03:37,500 --> 01:03:40,900
You taught them you and teach 
them that's fundamental. 

1326
01:03:40,900 --> 01:03:44,700
Number one. 
Fundamental number two is most 

1327
01:03:44,700 --> 01:03:47,600
of the time you actually have 
the right people. 

1328
01:03:47,800 --> 01:03:50,400
The favorite story. 
There is an old interview with 

1329
01:03:50,400 --> 01:03:52,500
agent copy. 
Laughter also works at animals 

1330
01:03:52,500 --> 01:03:54,800
out where somebody says. 
Well, he was a Netflix at the 

1331
01:03:54,800 --> 01:03:57,100
time because super sexy super 
hot company. 

1332
01:03:57,200 --> 01:04:00,200
He says you can do all these 
things because he like Netflix. 

1333
01:04:00,200 --> 01:04:03,000
You have all these great people 
and enduring. 

1334
01:04:03,000 --> 01:04:05,700
And certainly said, well, you 
know, where we hired from, we 

1335
01:04:05,700 --> 01:04:09,300
hired a lot from your company. 
All right, and people of course,

1336
01:04:09,300 --> 01:04:13,200
have the Blank Stare, so you 
probably have the people, 

1337
01:04:13,600 --> 01:04:17,300
they're just being held back by 
interested, friction inside. 

1338
01:04:17,600 --> 01:04:21,000
And we think takes forever, you 
try the approval processes. 

1339
01:04:21,400 --> 01:04:24,900
You can't get anything done. 
People are being slow, down. 

1340
01:04:24,900 --> 01:04:28,000
Salt for me. 
The people transformation story.

1341
01:04:28,000 --> 01:04:31,300
Always starts with you taught 
them, you are ditch them and the

1342
01:04:31,300 --> 01:04:34,300
obvious assumption should be. 
You have the right, people 

1343
01:04:34,600 --> 01:04:38,700
unleash that potential and you 
might be positively surprised. 

1344
01:04:38,700 --> 01:04:41,100
What actually can happen in your
organization. 

1345
01:04:41,900 --> 01:04:44,100
Wow. 
So thanks again for reminding us

1346
01:04:44,100 --> 01:04:48,200
because sometimes we think that 
oh to be called a verse, we have

1347
01:04:48,200 --> 01:04:50,600
to have the great enough people 
Talent. 

1348
01:04:51,100 --> 01:04:52,600
And we can't hire them because 
they are. 

1349
01:04:52,600 --> 01:04:55,800
First of all, maybe not many are
available out there in the 

1350
01:04:55,800 --> 01:04:58,400
market because a lot of 
companies are trying to recruit 

1351
01:04:58,400 --> 01:05:00,000
all of them. 
Speaking about getting the 

1352
01:05:00,000 --> 01:05:01,800
talents. 
Maybe you should look inwards, 

1353
01:05:01,800 --> 01:05:05,700
try to upskill or maybe, remove 
all the constraints or what you 

1354
01:05:05,700 --> 01:05:08,300
said is unteach them. 
The constraints that they know 

1355
01:05:08,600 --> 01:05:12,600
and start to, let them play the 
experiments in order to learn 

1356
01:05:12,600 --> 01:05:15,500
and also gain the benefits of 
learning along the way. 

1357
01:05:15,500 --> 01:05:18,300
So really love that. 
So, Gregor is been a really 

1358
01:05:18,300 --> 01:05:20,800
Pleasant conversation. 
I really love this a lot. 

1359
01:05:21,300 --> 01:05:24,900
Since we are out of time, I only
have one last question that I 

1360
01:05:24,900 --> 01:05:28,300
normally ask to all my guests, 
which is about three technical 

1361
01:05:28,300 --> 01:05:30,900
leadership wisdom for you to 
share with all of us here so 

1362
01:05:30,900 --> 01:05:32,900
that we can learn from your 
wisdom. 

1363
01:05:33,400 --> 01:05:35,300
If it's a great topic. 
Thanks for the chair. 

1364
01:05:35,600 --> 01:05:37,400
We could talk a lot more. 
Yes. 

1365
01:05:37,400 --> 01:05:39,200
So I think there's more than 
three wisdoms. 

1366
01:05:39,200 --> 01:05:42,900
But if I had to pick three, the 
first one that comes to my mind 

1367
01:05:42,900 --> 01:05:46,300
is and recently saw blog post, 
is actually from chloroquine. 

1368
01:05:46,300 --> 01:05:49,400
We post a lot about cloud and a 
double years, and he said, 

1369
01:05:49,600 --> 01:05:51,800
you're not the technology. 
E you work out. 

1370
01:05:52,000 --> 01:05:53,900
You're not a survivalist 
developer. 

1371
01:05:53,900 --> 01:05:55,200
You're not agglomerated to the 
number. 

1372
01:05:55,200 --> 01:05:56,700
You're not in need of being 
single opinion. 

1373
01:05:56,700 --> 01:06:00,100
Are the gcp that I'm going for. 
This is just Tech stuff that 

1374
01:06:00,100 --> 01:06:03,500
comes and go. 
What you create is much beyond 

1375
01:06:03,500 --> 01:06:07,000
that and I think being an 
architect is at the very essence

1376
01:06:07,000 --> 01:06:09,300
of that. 
Don't lock yourself in with the 

1377
01:06:09,300 --> 01:06:11,600
technology the second one 
relates closely. 

1378
01:06:11,600 --> 01:06:13,800
What we said about Bus words, 
right out of a lot of 

1379
01:06:13,800 --> 01:06:16,000
frustration with people who 
screw out buzzwords. 

1380
01:06:16,300 --> 01:06:18,700
So this is sort of like the 
corner of Richard Fineman. 

1381
01:06:19,100 --> 01:06:21,800
I always say if you can't 
explain What you're doing and 

1382
01:06:21,800 --> 01:06:23,800
what you're proposing to do it. 
Plain English. 

1383
01:06:24,000 --> 01:06:25,700
You just simply don't 
understand. 

1384
01:06:26,100 --> 01:06:30,600
There's no excuse for confusing.
People always say, uit shouldn't

1385
01:06:30,600 --> 01:06:33,900
look like an episode of the old 
Battlestar Galactica where the 

1386
01:06:33,900 --> 01:06:36,800
right all we need to go. 
Seven qualms to reach the 

1387
01:06:36,800 --> 01:06:39,900
proton, something rather. 
They speak descriptive language 

1388
01:06:39,900 --> 01:06:43,500
that, nobody knows technology, 
shouldn't be like that. 

1389
01:06:43,500 --> 01:06:45,900
You need to bake yourself. 
Aren't stuck. 

1390
01:06:46,200 --> 01:06:50,000
That way, you get buy-in for the
decisions and you best do late 

1391
01:06:50,000 --> 01:06:53,700
functioning or All the passwords
and the last one inspect a 

1392
01:06:53,700 --> 01:06:56,300
regular slaw complexity is a 
punishment. 

1393
01:06:56,400 --> 01:06:59,400
Complexity isn't biggest. 
Any be so gold. 

1394
01:06:59,400 --> 01:07:03,700
Don't be afraid to make some 
decisions reduce the complexity.

1395
01:07:03,700 --> 01:07:05,900
So you don't fall victim to 
Gregor's law. 

1396
01:07:06,400 --> 01:07:09,200
I really love when you said 
that, if you can explain it in 

1397
01:07:09,200 --> 01:07:11,600
plain English, most likely, you 
don't understand it. 

1398
01:07:11,700 --> 01:07:14,300
So, I think it's also something 
that we need to ponder. 

1399
01:07:14,500 --> 01:07:17,200
For example, if you want to 
propose that use kubernetes, can

1400
01:07:17,200 --> 01:07:20,500
you explain it in plain English 
with all this jargons and terms 

1401
01:07:20,500 --> 01:07:23,500
like, There's orchestration 
schedule and whatever. 

1402
01:07:23,700 --> 01:07:25,700
I think it's really great, 
reminder for all of us. 

1403
01:07:25,700 --> 01:07:28,400
Before we propose something, we 
probably should be able to 

1404
01:07:28,400 --> 01:07:31,300
explain it in a simplified 
manner or cleaning list, so to 

1405
01:07:31,300 --> 01:07:33,700
speak. 
So Greg up, if people want to 

1406
01:07:33,700 --> 01:07:36,200
have more conversation with you 
or find your work. 

1407
01:07:36,200 --> 01:07:38,200
Is there a place for them to 
find it online? 

1408
01:07:38,800 --> 01:07:40,800
Yeah. 
So my home is architect, 

1409
01:07:40,800 --> 01:07:44,100
elevator know.com. 
There's also Cloud strategy, 

1410
01:07:44,100 --> 01:07:48,600
books.com, some relatively 
easily found and corrected for 

1411
01:07:48,800 --> 01:07:50,900
LinkedIn. 
So, that's also a good place. 

1412
01:07:51,000 --> 01:07:54,400
To interact and unbolt equally 
active on Twitter. 

1413
01:07:54,400 --> 01:07:58,200
It's g, h, or h v is my handle. 
Their Twitter is more mix of 

1414
01:07:58,200 --> 01:08:00,600
opinions and random stuff, but I
diode. 

1415
01:08:00,600 --> 01:08:03,000
So look out for other people for
advice on Twitter. 

1416
01:08:03,000 --> 01:08:06,300
So, truly a community, may 
actually like quite a bit and 

1417
01:08:06,300 --> 01:08:08,600
always look forward to hearing 
back to your feedback. 

1418
01:08:08,600 --> 01:08:11,600
So please don't be shy to post 
anything online. 

1419
01:08:12,000 --> 01:08:13,700
I'll be happy to see them 
respond to that. 

1420
01:08:14,100 --> 01:08:16,000
Then I highly recommend the book
as well. 

1421
01:08:16,000 --> 01:08:18,899
Cloud strategy including also 
the software architect elevator,

1422
01:08:18,899 --> 01:08:22,300
which is also quite insightful 
in terms of How do you become a 

1423
01:08:22,300 --> 01:08:24,700
great software architect? 
So make sure to check those 

1424
01:08:24,700 --> 01:08:27,399
books and support regular in all
his writing. 

1425
01:08:27,700 --> 01:08:30,500
So thanks Gregor for your time. 
Today is really a wonderful 

1426
01:08:30,500 --> 01:08:33,100
conversations. 
So hope you good luck for 

1427
01:08:33,100 --> 01:08:35,200
whatever that you do next. 
Yep. 

1428
01:08:35,200 --> 01:08:37,200
Thank you so much. 
And I know what I'll do next 

1429
01:08:37,200 --> 01:08:39,300
Saturday right of the platform 
strategy book. 

1430
01:08:39,300 --> 01:08:42,000
So maybe we'll talk again in a 
few months. 

1431
01:08:42,000 --> 01:08:43,800
So here about what that came out
to be. 

1432
01:08:44,000 --> 01:08:46,600
Thank you for the time. 
Thanks to all the listeners for 

1433
01:08:46,600 --> 01:08:49,500
listening to the podcast, right?
Looking forward to that. 

1434
01:08:52,000 --> 01:08:55,399
Thank you for listening to this 
episode and for staying right 

1435
01:08:55,399 --> 01:08:58,300
till the end. 
If you highly enjoyed, please 

1436
01:08:58,300 --> 01:09:01,000
share it with your friends and 
colleagues who you think would 

1437
01:09:01,000 --> 01:09:03,800
also benefit from listening to 
this episode. 

1438
01:09:04,100 --> 01:09:07,000
And if you're new to the 
podcast, make sure to subscribe 

1439
01:09:07,000 --> 01:09:09,899
and leave me your valuable 
review and feedback. 

1440
01:09:10,000 --> 01:09:13,700
It really, really helps me a lot
in order to grow these podcasts 

1441
01:09:13,700 --> 01:09:16,300
better. 
You can also find the full show 

1442
01:09:16,300 --> 01:09:19,899
notes of this conversation on 
the episode page at technology. 

1443
01:09:19,899 --> 01:09:23,200
No, the death website. 
Adding the full transcript, 

1444
01:09:23,200 --> 01:09:26,800
interesting quotes, and links to
the resources and mentions from 

1445
01:09:26,800 --> 01:09:29,600
the conversation. 
And lastly make sure to 

1446
01:09:29,600 --> 01:09:32,100
subscribe to the show's mailing 
list on technology. 

1447
01:09:32,100 --> 01:09:35,600
No, the deaf to get notified for
any future episodes. 

1448
01:09:35,899 --> 01:09:38,600
Stay tuned for the next 
technique Journal episode. 

1449
01:09:38,700 --> 01:09:40,399
And until then. 
Goodbye.