1 00:00:00,040 --> 00:00:03,120 When I was hired as head of Enterprise architecture, my 2 00:00:03,120 --> 00:00:05,640 first job was actually to standardize things. 3 00:00:05,880 --> 00:00:09,120 And what I also didn't know was that that is the most hated 4 00:00:09,120 --> 00:00:12,400 person in the whole organization, because the person 5 00:00:12,400 --> 00:00:15,440 who's trying to make all the standards is the one telling 6 00:00:15,440 --> 00:00:19,000 people what they cannot do. That doesn't enable anybody who 7 00:00:19,000 --> 00:00:21,800 speed anybody up. That just makes people's lives 8 00:00:21,800 --> 00:00:24,920 more difficult. So the really important question 9 00:00:24,920 --> 00:00:28,080 is where's the difference? And the difference is in the 10 00:00:28,080 --> 00:00:34,880 fact that platforms also harmonize and standardize, but 11 00:00:35,040 --> 00:00:39,760 without restricting. By standardizing they actually 12 00:00:39,840 --> 00:00:43,320 enable, they allow people to do more things. 13 00:00:43,320 --> 00:00:47,440 So they achieve the opposite of what we traditionally think 14 00:00:47,440 --> 00:00:56,680 forth as standardization. Hey everyone, my name is Henry 15 00:00:56,680 --> 00:01:01,240 Suryavirawan and you're listening to the Techni Journal 16 00:01:01,280 --> 00:01:04,440 Podcast, the show where I'll be bringing you the greatest 17 00:01:04,440 --> 00:01:07,960 technical leaders, practitioners and thought leaders in the 18 00:01:07,960 --> 00:01:12,400 industry to discuss about their journey, ideas and practices 19 00:01:12,800 --> 00:01:16,120 that we all can learn and apply to build a highly performing 20 00:01:16,120 --> 00:01:19,600 technical team and to make an impact in your personal work. 21 00:01:20,280 --> 00:01:28,640 So let's dive into our journal. Hello to all of you, my friends, 22 00:01:28,640 --> 00:01:30,600 and my listeners. You're listening to the Tech 23 00:01:30,600 --> 00:01:33,160 Lead Journal Podcast, the podcast where you can learn 24 00:01:33,160 --> 00:01:36,240 about technical leadership and excellence from my conversations 25 00:01:36,240 --> 00:01:38,400 with great thought leaders in the tech industry. 26 00:01:38,880 --> 00:01:41,960 If you haven't, please subscribe on your favorite podcast app to 27 00:01:41,960 --> 00:01:45,120 get notified for new episodes. Also subscribe to Tech Lead 28 00:01:45,120 --> 00:01:49,000 Journal's various other contents on LinkedIn X, Instagram, 29 00:01:49,120 --> 00:01:53,240 YouTube, and Tiktok and consider supporting this podcast by 30 00:01:53,320 --> 00:01:56,640 either buying me a coffee at tech legional dot dev slash tip 31 00:01:56,960 --> 00:02:00,640 or becoming a patron at tech legional dot dev slash patron. 32 00:02:01,640 --> 00:02:03,960 My guest for today's episode is Gregor. 33 00:02:03,960 --> 00:02:07,960 Hope Gregor is back again for a second episode with his latest 34 00:02:07,960 --> 00:02:12,000 book, Platform Strategy. In this episode Gregor discussed 35 00:02:12,000 --> 00:02:14,760 in depth about building platforms with a proper platform 36 00:02:14,760 --> 00:02:17,480 strategy. He began by describing what a 37 00:02:17,480 --> 00:02:20,920 platform is from a few different perspectives, the benefits it 38 00:02:20,920 --> 00:02:24,040 brings and what strategy we should think about when building 39 00:02:24,040 --> 00:02:26,800 a platform. Gregor also emphasized the 40 00:02:26,800 --> 00:02:29,720 opposite difference between platforms and IT services, with 41 00:02:29,720 --> 00:02:32,480 the key difference of how a platform thrives with more 42 00:02:32,480 --> 00:02:34,600 scale. We then had a few fun 43 00:02:34,600 --> 00:02:37,760 discussions discussing building a platform on top of a cloud 44 00:02:37,760 --> 00:02:41,360 platform, the key skill set we need to build a good platform, 45 00:02:41,560 --> 00:02:45,320 and how we should build a proper platform abstraction towards the 46 00:02:45,360 --> 00:02:47,600 end. Gregor also covered the recent 47 00:02:47,600 --> 00:02:50,080 trend of building developer platforms and business 48 00:02:50,080 --> 00:02:53,200 capability platforms. You also do not want to miss 49 00:02:53,200 --> 00:02:56,760 Gregor's fun analogy of fruit basket versus fruit salad when 50 00:02:56,760 --> 00:02:58,720 explaining a good platform strategy. 51 00:02:59,800 --> 00:03:02,320 I hope you enjoy listening to this episode and getting to 52 00:03:02,320 --> 00:03:05,160 understand what we should do differently to build proper 53 00:03:05,160 --> 00:03:08,720 platforms with great strategy. And it's always fun when having 54 00:03:08,720 --> 00:03:11,840 a conversation with Gregor, especially with his smart humor 55 00:03:11,840 --> 00:03:14,480 and analogies. If you enjoy listening to this 56 00:03:14,480 --> 00:03:17,520 episode, please do share it with your colleagues, your friends 57 00:03:17,520 --> 00:03:21,200 and communities and leave a five star rating and review on Apple 58 00:03:21,200 --> 00:03:24,760 Podcast and Spotify. Your small help will help me a 59 00:03:24,760 --> 00:03:27,960 lot in getting more people to discover and listen to this 60 00:03:27,960 --> 00:03:29,920 podcast and I really appreciate it. 61 00:03:30,400 --> 00:03:33,280 So let's now go to my conversation with Gregor after 62 00:03:33,280 --> 00:03:36,960 quick words from our sponsor. Hey, a quick message for those 63 00:03:36,960 --> 00:03:40,360 of you who are listening to this episode on Spotify, I have a 64 00:03:40,360 --> 00:03:44,360 small favor to ask. Spotify now allows mobile users 65 00:03:44,360 --> 00:03:47,400 to rate podcasts. I would really appreciate it if 66 00:03:47,400 --> 00:03:50,760 you can take a quick pause to go to the technical podcast page 67 00:03:50,880 --> 00:03:54,000 and leave your favorite show your best rating on Spotify. 68 00:03:54,520 --> 00:03:57,120 It will help me a lot to get this podcast to reach more 69 00:03:57,120 --> 00:03:59,520 people on the platform. Thanks a lot. 70 00:04:02,240 --> 00:04:04,360 Hello guys, welcome back to another new episode of the 71 00:04:04,360 --> 00:04:06,920 Technical Podcast today. I'm very excited. 72 00:04:06,920 --> 00:04:10,360 I have a repeat guest, so he appeared in episode 50. 73 00:04:10,640 --> 00:04:13,680 There was like 100 over episodes, so probably like two 74 00:04:13,680 --> 00:04:16,079 years ago. His name is Gregor Hope. 75 00:04:16,079 --> 00:04:18,880 None other than Gregor Hope. I think some of you would have 76 00:04:18,880 --> 00:04:22,160 known Gregor, seeing his post, seeing his talks and reading his 77 00:04:22,160 --> 00:04:24,560 book. Today we are going to cover his 78 00:04:24,560 --> 00:04:26,720 new book title Platform Strategy. 79 00:04:26,840 --> 00:04:29,600 So Gregor, really, really happy to have you here again. 80 00:04:30,400 --> 00:04:32,360 Yeah, I'm super excited to be back. 81 00:04:32,640 --> 00:04:35,600 I managed to be in the top ten listing I think for a little 82 00:04:35,600 --> 00:04:37,920 while. So my ambition is to make a 83 00:04:38,000 --> 00:04:41,480 second step at getting back into the top 10. 84 00:04:41,480 --> 00:04:43,880 So let's see. Right. 85 00:04:44,320 --> 00:04:45,360 Yeah. Let's, let's see. 86 00:04:45,720 --> 00:04:47,640 OK. So, Gregor, so we, we haven't 87 00:04:47,640 --> 00:04:49,360 been talking for like 2 years, right? 88 00:04:49,360 --> 00:04:51,880 So anything that you want to share, what have you been up 89 00:04:51,880 --> 00:04:55,760 lately and things like that? Yeah, so my previous book on a 90 00:04:55,760 --> 00:04:58,480 previous chat was about cloud strategy. 91 00:04:58,480 --> 00:05:02,440 So that hasn't changed in a way. So I'm still very much 92 00:05:02,440 --> 00:05:05,040 associated with building cloud solutions. 93 00:05:05,040 --> 00:05:08,920 What has changed though is so most of my work now is in 94 00:05:09,200 --> 00:05:13,520 serverless and in serverless automation particularly. 95 00:05:13,520 --> 00:05:17,120 So I do a lot of work with Lambda and CDK and serverless 96 00:05:17,120 --> 00:05:21,480 integration, and that is a lot of fun because I can use some of 97 00:05:21,480 --> 00:05:25,480 the 20 year old things from my Enterprise Integration Patterns. 98 00:05:25,760 --> 00:05:29,280 And the reason I know it's 20 years old because that book 99 00:05:29,280 --> 00:05:33,160 actually has its 20th anniversary, well, last month's 100 00:05:33,160 --> 00:05:37,240 like it had in October. So it's cool to be able to bring 101 00:05:37,240 --> 00:05:38,880 that stuff back into my daily work. 102 00:05:39,800 --> 00:05:42,800 So it seems your books have some kind of a timeline, right? 103 00:05:42,800 --> 00:05:45,440 So you started with Enterprise Integration Patterns long time 104 00:05:45,440 --> 00:05:46,400 ago, right? 20 years. 105 00:05:46,400 --> 00:05:48,880 So you also had Software Architect Elevator, right? 106 00:05:49,240 --> 00:05:52,480 Recently Cloud Strategy and this time is Platform Strategy. 107 00:05:52,720 --> 00:05:55,240 The title also have strategy. Are you thinking of creating a 108 00:05:55,240 --> 00:05:58,480 series? Yes, and the ambition was a 109 00:05:58,480 --> 00:06:01,280 little bit ahead of the reality for a while. 110 00:06:01,560 --> 00:06:06,360 So the idea was that the architect elevator, so that came 111 00:06:06,360 --> 00:06:09,360 out three years ago, like right at the beginning of the 112 00:06:09,560 --> 00:06:14,360 pandemic, right in 2020. And the idea there was to 113 00:06:14,360 --> 00:06:17,840 rethink a little bit what architects should be doing, Are 114 00:06:18,000 --> 00:06:19,880 we? There's many opinions about what 115 00:06:20,120 --> 00:06:23,400 architecture is and many opinions about what architects 116 00:06:23,400 --> 00:06:25,480 should be doing. I think last time we chatted a 117 00:06:25,520 --> 00:06:28,920 little bit about that. So the architect elevator was 118 00:06:28,920 --> 00:06:31,680 trying to take a look at. The architects aren't supposed 119 00:06:31,680 --> 00:06:34,120 to be the ones who are like the smartest people and tell 120 00:06:34,120 --> 00:06:37,800 everyone what to do and make all the decisions, but much rather 121 00:06:37,800 --> 00:06:40,680 they're supposed to fill in the gap between the grandiose 122 00:06:40,680 --> 00:06:44,040 visions and the reality. Hence the elevator. 123 00:06:44,400 --> 00:06:49,440 So the strategy books are meant to be the application of that 124 00:06:49,440 --> 00:06:53,000 principle to different domains, like the domain of cloud 125 00:06:53,000 --> 00:06:55,040 computing, right? There's a lot of technical 126 00:06:55,040 --> 00:06:58,960 resources and a lot of high level strategy stuff telling you 127 00:06:58,960 --> 00:07:01,600 all the things that you should be doing, but there's very 128 00:07:01,600 --> 00:07:04,160 little in between. Hey, like how do I get from here 129 00:07:04,280 --> 00:07:07,280 to there? And platform strategy is again 130 00:07:07,360 --> 00:07:10,760 looking to do the same thing for platforms, which has become a 131 00:07:10,760 --> 00:07:14,280 very hot buzzword. But again, you ask three 132 00:07:14,280 --> 00:07:16,560 different people, you get 4 points of view. 133 00:07:16,800 --> 00:07:20,160 So I'm trying to get a better definition of what is a 134 00:07:20,160 --> 00:07:24,240 platform, what really makes a platform, How do you go about 135 00:07:24,240 --> 00:07:27,040 building 1 and filling in that gap? 136 00:07:27,080 --> 00:07:31,640 That's indeed intended to be a serious I had a hard time 137 00:07:31,960 --> 00:07:34,840 claiming it's a series because with one book it's a little 138 00:07:35,000 --> 00:07:37,680 tough to say whether it's a one off or a series. 139 00:07:37,920 --> 00:07:41,120 So I'm super excited that with two books now, it is actually a 140 00:07:41,120 --> 00:07:43,400 proper series. Right. 141 00:07:43,400 --> 00:07:45,880 Thank you for sharing that plan. Ambitious plan, right? 142 00:07:45,880 --> 00:07:48,720 I hope to see more strategy books from you because to be 143 00:07:48,720 --> 00:07:51,480 honest, like when I read your book, I always have a good fun 144 00:07:51,680 --> 00:07:55,120 because you have a fun way and humor and metaphors that you 145 00:07:55,120 --> 00:07:57,200 introduce in your book, including in this platform 146 00:07:57,200 --> 00:08:01,000 strategy book as well. So let's start maybe in terms of 147 00:08:01,000 --> 00:08:03,000 platform, right? You mentioned just now it has 148 00:08:03,000 --> 00:08:05,280 become buzzwords. Maybe in the past, I don't know, 149 00:08:05,280 --> 00:08:08,560 five years more and more people have been mentioning about 150 00:08:08,600 --> 00:08:12,000 platform as a word these days. So hence there's a lot of 151 00:08:12,000 --> 00:08:14,400 confusion as well. Maybe from your definition if 152 00:08:14,400 --> 00:08:17,640 you can help us define what is platform in your point of view. 153 00:08:18,680 --> 00:08:23,160 It's probably good to state 1st that the whole idea isn't that 154 00:08:23,160 --> 00:08:26,440 new at all. Like one sort of thing we suffer 155 00:08:26,440 --> 00:08:29,120 from collectively is we always believe that we invent 156 00:08:29,320 --> 00:08:31,640 everything. And we mean like the software 157 00:08:31,640 --> 00:08:34,000 people, right? The computer people Like how 158 00:08:34,000 --> 00:08:36,120 sometimes I'm called by my older relatives. 159 00:08:36,480 --> 00:08:38,280 We always feel like we invent everything. 160 00:08:38,280 --> 00:08:41,240 The platform idea isn't actually that new. 161 00:08:41,240 --> 00:08:44,440 And you know, some of the popular examples are automotive 162 00:08:44,440 --> 00:08:46,800 platforms, right? The car manufacturers long time 163 00:08:46,800 --> 00:08:50,520 ago realized that making a new engine and brakes and 164 00:08:50,520 --> 00:08:54,120 transmission and everything for each car model is actually not a 165 00:08:54,120 --> 00:08:56,320 great idea. It's very expensive and in the 166 00:08:56,320 --> 00:09:00,680 end people don't really just buy the car exactly because of the 167 00:09:00,680 --> 00:09:05,040 brakes that are in that car. So they started making platforms 168 00:09:05,040 --> 00:09:09,520 and putting different car models on top of a common platform. 169 00:09:09,520 --> 00:09:12,320 So the idea has been around for a long time. 170 00:09:12,320 --> 00:09:17,120 And if we look at the IT side, operating systems are also kind 171 00:09:17,120 --> 00:09:18,960 of platform, right? They're striked away. 172 00:09:18,960 --> 00:09:21,920 In this case, it's not the engine and transmissions, but 173 00:09:21,920 --> 00:09:25,720 it's sort of the disk encoding and interfaces and all the 174 00:09:25,720 --> 00:09:27,760 hardware stuff, right? They abstract away. 175 00:09:28,080 --> 00:09:31,640 And then on top you can build many, many different things on 176 00:09:31,640 --> 00:09:34,680 common hardware without having to deal with all the details. 177 00:09:34,920 --> 00:09:39,160 So that idea has been around for quite some time where I think 178 00:09:39,160 --> 00:09:43,800 it's gotten a huge boost recently interestingly comes 179 00:09:43,800 --> 00:09:46,800 from multiple angles. And that gets back to your 180 00:09:46,800 --> 00:09:48,960 question where the confusion originates. 181 00:09:49,320 --> 00:09:53,880 The one is the platform business models like platform companies 182 00:09:53,880 --> 00:09:58,120 like the Airbnb's and the ebay's of the world where people say 183 00:09:58,120 --> 00:10:00,920 hey it's a multi sided marketplace, right. 184 00:10:00,920 --> 00:10:05,040 You have sellers and buyers and interestingly that platform 185 00:10:05,040 --> 00:10:09,680 company itself often doesn't even hold inventory like Amazon 186 00:10:09,840 --> 00:10:12,400 does for example. Now they they ship physical 187 00:10:12,400 --> 00:10:16,240 products but an Airbnb doesn't own any hotel room and that has 188 00:10:16,240 --> 00:10:21,320 become known as a platform. So that gave a huge booster and 189 00:10:21,320 --> 00:10:24,680 these are the Ubers, the Airbnb's of the world, the mega 190 00:10:24,720 --> 00:10:28,800 unicorns and now some of the most valuable yeah companies 191 00:10:28,800 --> 00:10:31,200 that we have. So that is the one world view. 192 00:10:31,640 --> 00:10:35,040 The other world view comes from a cloud platforms. 193 00:10:35,400 --> 00:10:38,200 It's actually kind of funny, like the GCP folks, the P 194 00:10:38,200 --> 00:10:40,960 obviously has the word platform in the name. 195 00:10:41,240 --> 00:10:44,400 The funny thing is on AWS we don't like to use the word 196 00:10:44,680 --> 00:10:47,240 platform. So here today I'm here as myself 197 00:10:47,240 --> 00:10:50,120 so I can joke about it. So it's kind of funny like where 198 00:10:50,120 --> 00:10:53,880 some people embrace the word and other people kind of shy away 199 00:10:53,880 --> 00:10:57,200 from it. But the reality is most clouds 200 00:10:57,280 --> 00:11:00,520 are platforms in a way, right? They give you a common layer 201 00:11:00,520 --> 00:11:04,040 that you can put many things on top of and the abstract the 202 00:11:04,040 --> 00:11:07,920 things underneath. And then so that also everybody 203 00:11:08,000 --> 00:11:10,880 is doing these days. And then if that wasn't enough, 204 00:11:11,240 --> 00:11:15,000 what everybody else also seems to be doing these days is making 205 00:11:15,000 --> 00:11:17,440 developer platforms in house platforms. 206 00:11:17,440 --> 00:11:21,080 They're called productivity platforms or ID, PS internal 207 00:11:21,080 --> 00:11:23,640 developer platforms. Again, we can't even agree on 208 00:11:23,640 --> 00:11:27,720 the acronym. And the idea is there to layer 209 00:11:27,720 --> 00:11:32,360 something on top of the base platform, like on top of the 210 00:11:32,360 --> 00:11:37,480 cloud to make it easier to use for developers or to increase 211 00:11:37,480 --> 00:11:42,600 their productivity or to have some form of governance, right? 212 00:11:42,600 --> 00:11:47,080 It can also be to restrict. Now with the three different use 213 00:11:47,080 --> 00:11:50,120 cases and as I just hinted, people having different 214 00:11:50,120 --> 00:11:51,920 objectives, right? Some people want to make 215 00:11:52,160 --> 00:11:55,360 development faster, other people want to restrict what people can 216 00:11:55,360 --> 00:11:57,680 do. You can easily imagine that it's 217 00:11:57,680 --> 00:12:02,400 no longer that easy to look at something and say, oh, is this 218 00:12:02,400 --> 00:12:06,800 now platform or is this just like an IT service or framework 219 00:12:07,080 --> 00:12:09,120 on abstraction layer or governance tool? 220 00:12:09,760 --> 00:12:12,160 Right. So even after I heard you 221 00:12:12,160 --> 00:12:15,120 explaining it right, so there are so many permutations and 222 00:12:15,120 --> 00:12:18,200 variables that could happen right to me when I always heard 223 00:12:18,200 --> 00:12:20,160 about platform, it's about reusability, right? 224 00:12:20,360 --> 00:12:23,200 It's about unification or standardization of stuff. 225 00:12:23,680 --> 00:12:25,720 Maybe if you can elaborate, maybe you have mentioned just 226 00:12:25,720 --> 00:12:29,080 now a few other benefits, right? What are some of the benefits of 227 00:12:29,080 --> 00:12:31,760 a platform truly right? Because for people to really 228 00:12:31,760 --> 00:12:34,000 understand that it is a platform, right, they need to 229 00:12:34,000 --> 00:12:36,480 understand OK, there are benefits of using the platform. 230 00:12:37,160 --> 00:12:39,040 Yes. And what I would say for the 231 00:12:39,040 --> 00:12:42,760 rest of our discussion it will help if we leave the Ubers and 232 00:12:42,760 --> 00:12:44,880 Airbnb. So if we leave the multi sided 233 00:12:44,880 --> 00:12:48,000 markets and all those aside because they share some 234 00:12:48,000 --> 00:12:51,240 commonalities, but they also very different from the 235 00:12:51,240 --> 00:12:54,840 platforms that we as engineers would normally build and use. 236 00:12:54,840 --> 00:12:58,720 So if you look inside organization, cloud platforms, 237 00:12:58,720 --> 00:13:01,400 engineering, productivity platforms, your question is a 238 00:13:01,400 --> 00:13:03,400 very good one. And I think you hinted at the 239 00:13:03,520 --> 00:13:06,560 keywords like some of the standards, standardization, 240 00:13:06,560 --> 00:13:09,400 reuse, right. Those are the things that people 241 00:13:09,400 --> 00:13:13,320 want from these platforms. But this is not the first time 242 00:13:13,320 --> 00:13:18,280 we want reuse, standardization. I worked in large enterprises 243 00:13:18,280 --> 00:13:20,360 and some people might know my joke. 244 00:13:20,360 --> 00:13:23,560 When I was hired as head of enterprise architecture, I 245 00:13:23,840 --> 00:13:26,040 didn't really know what enterprise architecture was. 246 00:13:26,040 --> 00:13:28,880 It just sounded good. And my first job was actually to 247 00:13:28,880 --> 00:13:32,240 standardize things. And what I also didn't know was 248 00:13:32,240 --> 00:13:34,600 that that is the most hated person in the whole 249 00:13:34,600 --> 00:13:37,360 organization. Because the person who's trying 250 00:13:37,360 --> 00:13:40,760 to make all the standards is the one telling people what they 251 00:13:40,760 --> 00:13:42,840 cannot do. They're like, oh, we want to 252 00:13:42,840 --> 00:13:45,760 build something on this database or use this programming language 253 00:13:45,760 --> 00:13:47,520 or this framework or this app server. 254 00:13:47,720 --> 00:13:50,320 And then the standard person comes with a Enterprise 255 00:13:50,320 --> 00:13:53,400 Architect title and says no, no, no, you cannot use that 256 00:13:53,400 --> 00:13:55,480 database. You can only use that database. 257 00:13:55,720 --> 00:13:58,360 So that is obviously not a platform, right? 258 00:13:58,360 --> 00:14:00,760 That doesn't enable anybody who speed anybody up. 259 00:14:01,040 --> 00:14:03,280 That just makes people's lives more difficult. 260 00:14:03,680 --> 00:14:06,880 So the really important question is where's the difference? 261 00:14:07,120 --> 00:14:11,880 And the difference is in the fact that platforms also 262 00:14:12,080 --> 00:14:17,480 harmonize and standardize, but without restricting. 263 00:14:17,720 --> 00:14:22,920 By standardizing they actually enable, they allow people to do 264 00:14:23,200 --> 00:14:26,480 more things. So they achieve the opposite of 265 00:14:26,480 --> 00:14:30,000 what we traditionally think for as standardization. 266 00:14:30,000 --> 00:14:33,360 Now the question is like, oh, that sounds a little magical, 267 00:14:33,360 --> 00:14:34,800 right? How can it restrict? 268 00:14:34,800 --> 00:14:38,640 Like how can it standardize but at the same time allow more 269 00:14:38,640 --> 00:14:42,840 innovation? And the key mechanism there is 270 00:14:42,840 --> 00:14:46,120 that not all standards are created equal. 271 00:14:46,360 --> 00:14:51,520 And a great example that we have that has the same property is 272 00:14:51,520 --> 00:14:54,720 HTTP, right? HTP is a standard, I mean goes 273 00:14:54,720 --> 00:14:57,400 for the different incarnations and versions, but it's a very 274 00:14:57,400 --> 00:15:01,480 well specced out, very strict standard and we all use it. 275 00:15:01,480 --> 00:15:05,720 So in a way it constrains us if you say, hey, I invented this 276 00:15:05,720 --> 00:15:09,520 other great protocol that I want to use, probably uphill battle. 277 00:15:09,520 --> 00:15:12,160 People would say hold on, why are you not using HTTP? 278 00:15:12,160 --> 00:15:16,640 It's the standard. But we can see that HTTP has 279 00:15:16,640 --> 00:15:19,000 been a huge innovation booster, right? 280 00:15:19,000 --> 00:15:21,760 Without HTTP we wouldn't have the cloud and all the other 281 00:15:21,760 --> 00:15:24,760 stuff. So that shows that you can sort 282 00:15:24,760 --> 00:15:27,440 of rewrite the laws of physics a little bit. 283 00:15:27,440 --> 00:15:31,280 Where in the past it was always that, you know if I take choice 284 00:15:31,280 --> 00:15:35,800 away, then people can't be creative, but now we have ways 285 00:15:35,800 --> 00:15:39,320 where we also take some choice away in a way, but it actually 286 00:15:39,320 --> 00:15:43,480 allows people to do more things and more creative things. 287 00:15:44,040 --> 00:15:48,440 Cloud platforms, you know, using the P bar here, the cloud 288 00:15:48,440 --> 00:15:51,680 platforms also have that property right. 289 00:15:51,680 --> 00:15:55,240 I often remind people, you know, I talk to a lot of customers at 290 00:15:55,240 --> 00:15:59,480 my day job and if the meeting is a little bit boring or I want to 291 00:15:59,480 --> 00:16:02,920 sort of poke the box a little bit, I say, listen, people, we 292 00:16:02,920 --> 00:16:05,120 have a single product basically, right? 293 00:16:05,120 --> 00:16:08,880 There's many, many services, but basically there's one AWS, 294 00:16:09,120 --> 00:16:10,760 right? There's no red, green or blue 295 00:16:11,400 --> 00:16:13,320 AWS, right. And same with GCP, Azure, right. 296 00:16:13,320 --> 00:16:17,400 It's like it's basically one thing that these companies have. 297 00:16:17,400 --> 00:16:22,400 And I say the AWS you're getting is the same AWS essentially that 298 00:16:22,600 --> 00:16:24,760 your competitor is getting like people are going like, oh, well, 299 00:16:24,760 --> 00:16:27,760 how can this be, right? So I guess it's a standardized 300 00:16:27,760 --> 00:16:31,360 platform. But what people do on top, Yeah, 301 00:16:31,360 --> 00:16:32,920 it's nothing short of magical, right? 302 00:16:32,960 --> 00:16:35,800 I mean, people do all sorts of amazing things. 303 00:16:35,800 --> 00:16:40,040 So what I'm trying to get at with the book is like, tease out 304 00:16:40,040 --> 00:16:44,360 a little bit, oh, why is the one standard thing the most hated 305 00:16:44,360 --> 00:16:46,680 activity and constraining people? 306 00:16:46,680 --> 00:16:50,760 And why is with platforms that doing the opposite? 307 00:16:50,760 --> 00:16:54,720 And how can you recreate that? What are the essential 308 00:16:54,880 --> 00:16:58,120 properties that make that magical thing happen? 309 00:16:59,160 --> 00:17:01,000 Yeah, when you explain about this, I think that's the 310 00:17:01,200 --> 00:17:03,960 insights for me, right. So people want to standardize, 311 00:17:03,960 --> 00:17:07,040 but they are more towards restricting, actually also 312 00:17:07,040 --> 00:17:09,599 restricting the kind of capability that people do with 313 00:17:09,640 --> 00:17:11,440 whatever they're building as a standard, right. 314 00:17:11,680 --> 00:17:14,599 So I think in your explanation just now, the platform, yes, 315 00:17:14,599 --> 00:17:17,720 will create some restriction, but the benefit is actually to 316 00:17:17,720 --> 00:17:20,720 enable people to do more stuffs, I mean more creative stuffs and 317 00:17:20,720 --> 00:17:23,440 even could be faster, it could be more creativity, more 318 00:17:23,440 --> 00:17:24,760 innovations and things like that. 319 00:17:25,240 --> 00:17:28,640 But it seems like a very, very tall order for many, many 320 00:17:28,640 --> 00:17:31,640 people, right? And that's why probably you have 321 00:17:31,640 --> 00:17:34,080 this thing called strategy, right platform, strategy. 322 00:17:34,440 --> 00:17:38,040 So tell us why do people need to build some kind of a platform 323 00:17:38,040 --> 00:17:41,080 strategy before they embark on building platform or using 324 00:17:41,080 --> 00:17:44,360 platform? Yeah, so the reason is that you 325 00:17:44,360 --> 00:17:47,120 need to be cautious. Is a like as we already 326 00:17:47,120 --> 00:17:50,160 discussed, right? It's kind of a subtle but 327 00:17:50,160 --> 00:17:53,400 magical property which isn't easy to create. 328 00:17:53,400 --> 00:17:58,440 So it's very tempting to set out to make a platform right? 329 00:17:58,440 --> 00:18:02,040 But if you don't really get the nuances of it, you just might be 330 00:18:02,040 --> 00:18:04,840 building another IT services layer. 331 00:18:04,840 --> 00:18:07,920 And I actually have a chapter in the book which is called 332 00:18:08,120 --> 00:18:10,840 Platform, and IT services are antonyms. 333 00:18:10,840 --> 00:18:13,200 They're like the opposite of each other. 334 00:18:13,520 --> 00:18:17,080 And what can easily happen in large organizations where I used 335 00:18:17,080 --> 00:18:21,440 to work and where many of my customers are, there's always 336 00:18:21,440 --> 00:18:26,320 the temptation to take what you have and sort of apply the new 337 00:18:26,320 --> 00:18:29,120 label to it, right? And it's understandable because 338 00:18:29,120 --> 00:18:31,480 you don't want to throw everything away and you have 339 00:18:31,480 --> 00:18:34,880 shared services or maybe even have a private cloud, some 340 00:18:34,880 --> 00:18:38,200 virtual machines, some ticketing system, maybe even some 341 00:18:38,200 --> 00:18:40,880 self-service portal, right? You have all these things and 342 00:18:40,880 --> 00:18:44,640 then you're like, oh, that's actually most of what I need for 343 00:18:44,640 --> 00:18:47,240 a platform. Let me just make that into a 344 00:18:47,240 --> 00:18:49,920 platform. And unfortunately, most of the 345 00:18:49,920 --> 00:18:54,840 time that goes completely wrong because these things were built 346 00:18:54,840 --> 00:18:59,320 for control. They were not billed for driving 347 00:18:59,320 --> 00:19:03,120 innovation and enable the diversity that you mention. 348 00:19:03,400 --> 00:19:06,360 And that's although the first important part of the strategy 349 00:19:06,360 --> 00:19:10,400 is to tell you how different this actually is and make this 350 00:19:10,400 --> 00:19:13,120 very obvious, like have these side by side comparisons. 351 00:19:13,360 --> 00:19:17,120 The stuff that you had before in a successful platform is almost 352 00:19:17,120 --> 00:19:19,720 the exact opposite. So I want people to not 353 00:19:19,760 --> 00:19:22,920 underestimate what they're signing up for. 354 00:19:23,280 --> 00:19:27,320 And I also want to give them some simple tests like you 355 00:19:27,320 --> 00:19:29,080 mentioned before, you like reading the books because 356 00:19:29,080 --> 00:19:31,520 they're sort of, you know, not entertaining. 357 00:19:31,520 --> 00:19:33,760 I would say we're not in the movie business here, but I would 358 00:19:33,760 --> 00:19:35,200 say they're engaging in a way, right? 359 00:19:35,200 --> 00:19:39,040 They're accessible, but at the same time have serious content. 360 00:19:39,040 --> 00:19:43,320 So what I'm trying to do is capture this kind of advice and 361 00:19:43,320 --> 00:19:46,360 something that's memorable and easy to understand. 362 00:19:46,360 --> 00:19:50,880 So one of the tests I'm suggesting is if you build a 363 00:19:50,880 --> 00:19:55,720 platform, people should do something on top that surprises 364 00:19:55,720 --> 00:19:58,000 you. Like if nobody does anything 365 00:19:58,000 --> 00:20:02,120 with your platform that generally surprises you, then 366 00:20:02,120 --> 00:20:04,720 you probably didn't make a platform, right? 367 00:20:04,720 --> 00:20:09,000 If you try to anticipate everything that people will do, 368 00:20:09,400 --> 00:20:13,040 it sounds very useful, because if you anticipate everything, 369 00:20:13,040 --> 00:20:16,320 you can make great reuse, right? You can provide exactly what 370 00:20:16,320 --> 00:20:19,000 everybody wanted. But you failed to make a 371 00:20:19,000 --> 00:20:22,320 platform because you didn't create this multiplier effect, 372 00:20:22,320 --> 00:20:24,560 You didn't make this innovation booster. 373 00:20:24,760 --> 00:20:29,120 So I'm trying to distill it down to these kind of tests that when 374 00:20:29,120 --> 00:20:32,680 people look at what they're proposing and saying, is this 375 00:20:32,680 --> 00:20:36,040 really allowing people to build something that we didn't even 376 00:20:36,040 --> 00:20:38,360 think of? And if the answer is, oh, not 377 00:20:38,360 --> 00:20:41,760 really, We just wanted to give them some common services, then 378 00:20:42,080 --> 00:20:44,480 probably that's an early indication that the platform 379 00:20:44,480 --> 00:20:47,080 strategy needs a little bit of revising. 380 00:20:47,920 --> 00:20:50,640 Yeah, I think the metaphor that you use is like standing on top 381 00:20:50,640 --> 00:20:54,000 of the giant's shoulder, right? If you want to reach a higher 382 00:20:54,000 --> 00:20:56,680 height, you can, you know, climb the ladder and things like that. 383 00:20:56,680 --> 00:20:59,720 But you can also stand on top of a platform, right, Or standing 384 00:20:59,720 --> 00:21:01,200 on the top of the giant's shoulder. 385 00:21:01,400 --> 00:21:04,320 And in this case here, right, your metaphor about a platform 386 00:21:04,320 --> 00:21:06,480 versus IT service. I think it's very, very 387 00:21:06,480 --> 00:21:10,200 interesting for me because some people when I see real life 388 00:21:10,200 --> 00:21:13,600 example of people building platform, right, most of them I 389 00:21:13,600 --> 00:21:16,760 see it now becoming like an IT service instead of platform. 390 00:21:17,000 --> 00:21:19,920 Maybe if you can bring up some attributes that you see are the 391 00:21:19,920 --> 00:21:22,720 antonyms between platform and IT services. 392 00:21:22,720 --> 00:21:24,720 I think that will also be useful for people. 393 00:21:25,400 --> 00:21:27,520 Yeah, yeah. And I it's interesting that you 394 00:21:27,520 --> 00:21:31,160 also see that it's a super slippery slope and we see a 395 00:21:31,160 --> 00:21:33,520 similar effect. You know, obviously I work with 396 00:21:33,520 --> 00:21:36,520 a lot of customers migrating to the cloud, adopting cloud 397 00:21:36,520 --> 00:21:38,960 service. And the failure mode 398 00:21:39,480 --> 00:21:42,920 unfortunately is always relatively similar, like people 399 00:21:42,920 --> 00:21:46,200 look at anything. That's the bottom layer of a 400 00:21:46,200 --> 00:21:47,920 picture, right? We always have this mental 401 00:21:47,920 --> 00:21:50,680 picture of on the top is application development and 402 00:21:50,680 --> 00:21:52,640 there's other stuff underneath, right? 403 00:21:52,640 --> 00:21:56,120 And underneath can be IT services, it can be the cloud or 404 00:21:56,120 --> 00:21:58,440 it can be a platform. So when we look at the 405 00:21:58,440 --> 00:22:01,560 organization we like, there's the application teams there. 406 00:22:01,720 --> 00:22:04,400 And then this stuff is with the teams that do the bottom half 407 00:22:04,800 --> 00:22:07,400 right? Now that makes some sense 408 00:22:07,400 --> 00:22:10,640 because the folks who do the bottom half, they're used to 409 00:22:10,640 --> 00:22:12,960 provisioning services, doing operations, right? 410 00:22:13,240 --> 00:22:18,120 They have some really valuable skills in this area, but they 411 00:22:18,120 --> 00:22:20,400 work in a very, very different model. 412 00:22:20,400 --> 00:22:23,440 Like, in a way they're the best guys for this, but they're also 413 00:22:23,440 --> 00:22:26,680 the worst people for this because they have the technical 414 00:22:26,680 --> 00:22:29,480 skill in many cases, but they absolutely don't have the 415 00:22:29,480 --> 00:22:33,360 mindset or the way of working. And that's where this comes from 416 00:22:33,360 --> 00:22:37,520 where both cloud initiatives or cloud transformations like we 417 00:22:37,520 --> 00:22:41,560 like to call it and platform initiatives, they struggle or 418 00:22:41,560 --> 00:22:45,680 completely fizzle out because basically the teams who are 419 00:22:45,680 --> 00:22:48,760 running them are not used to this way of working at all. 420 00:22:48,800 --> 00:22:52,600 So the the way this shows up in many cases, and this is where I 421 00:22:52,600 --> 00:22:57,760 made this, the comparison table is that IT services are often 422 00:22:57,760 --> 00:23:01,640 not full self-service right? So you fill out some ticket or 423 00:23:01,640 --> 00:23:03,120 some. I used to fill out excel 424 00:23:03,120 --> 00:23:04,920 spreadsheets to get a server right. 425 00:23:05,120 --> 00:23:09,160 That's not how platforms work. Platforms are easy to get onto. 426 00:23:09,400 --> 00:23:13,480 Platforms live from scale. You want many people to use the 427 00:23:13,480 --> 00:23:17,560 platform in a classic IT services is everybody comes and 428 00:23:17,560 --> 00:23:19,880 wants something. You probably overloaded and you 429 00:23:19,880 --> 00:23:22,400 become the bottleneck. So you can see from these 430 00:23:22,400 --> 00:23:24,440 examples it's exactly the opposite. 431 00:23:24,440 --> 00:23:27,840 One is built for control, the other one is built for ease of 432 00:23:27,840 --> 00:23:30,480 onboarding. One is for ticketing semi 433 00:23:30,480 --> 00:23:33,720 manual, the other one is complete self-service. 434 00:23:33,960 --> 00:23:39,400 The old model is based on the idea of that the IT service is 435 00:23:39,400 --> 00:23:42,120 responsible for all the non functional aspects. 436 00:23:42,120 --> 00:23:44,840 Yeah, like all the scalability and security that's supposed to 437 00:23:44,840 --> 00:23:48,280 be done on in a bottom layer. The new model, the platform 438 00:23:48,280 --> 00:23:50,600 model, is a shared responsibility model. 439 00:23:50,720 --> 00:23:53,440 If your application is super brittle and leaky and full of 440 00:23:53,440 --> 00:23:56,520 vulnerabilities, no platform is going to tell you that it's 441 00:23:56,520 --> 00:24:00,320 magically going to fix that. So the division between the two 442 00:24:00,320 --> 00:24:04,680 teams is very different. Also, maybe last example and the 443 00:24:04,680 --> 00:24:08,080 list goes on right. But last example is that the 444 00:24:08,080 --> 00:24:11,920 additional IT services like stability, because they have 445 00:24:11,920 --> 00:24:16,080 learned that through stability they get up time and those known 446 00:24:16,080 --> 00:24:19,240 functional requirements that they're responsible for. 447 00:24:19,360 --> 00:24:22,400 So they don't like to change. Well, successful platforms 448 00:24:22,400 --> 00:24:25,080 change all the time. I mean look at the cloud 449 00:24:25,080 --> 00:24:27,400 platforms, right? AWS used to have like two or 450 00:24:27,400 --> 00:24:30,600 three services, right? It was like EC2S3, SQS, right. 451 00:24:30,600 --> 00:24:33,040 And then it's like couple of 100 now, right? 452 00:24:33,040 --> 00:24:34,640 And the other one's no different, right? 453 00:24:34,840 --> 00:24:38,920 So every year there's a lot of new features, new things, open 454 00:24:38,920 --> 00:24:41,920 source projects for platforms and features all the time. 455 00:24:42,160 --> 00:24:45,560 So platforms are based on evolution and that's good 456 00:24:45,560 --> 00:24:50,400 because as the platform grows, it lifts up everything else with 457 00:24:50,400 --> 00:24:52,440 it. So you get new capabilities 458 00:24:52,760 --> 00:24:56,200 basically without doing. And again, that's the exact 459 00:24:56,440 --> 00:25:00,560 opposite of the IT services, because they always favour 460 00:25:00,560 --> 00:25:04,240 stability. So it's almost every way you 461 00:25:04,240 --> 00:25:08,920 look at it, it's the opposite or IT services are generally 462 00:25:08,920 --> 00:25:11,440 mandated, right? There's a mandate. 463 00:25:11,440 --> 00:25:14,120 Oh, you cannot do anything if you don't use our service. 464 00:25:14,600 --> 00:25:17,320 Most successful platforms are not mandated. 465 00:25:17,320 --> 00:25:20,760 It's not 100%, but in most cases it's voluntary. 466 00:25:20,760 --> 00:25:24,320 So again, it's the opposite. So what I wanted to do in the 467 00:25:24,320 --> 00:25:28,320 book is really, I don't like black and white painting because 468 00:25:28,320 --> 00:25:31,280 I always say for architects everything is a trade off. 469 00:25:31,520 --> 00:25:34,440 But in this case, I think a little bit black and white is 470 00:25:34,440 --> 00:25:38,320 helpful to really show you that it is totally the opposite of 471 00:25:38,320 --> 00:25:41,240 one another. Yeah, and I think you sum it up 472 00:25:41,240 --> 00:25:44,760 also in one statement, right? Platform tries with scale, 473 00:25:44,760 --> 00:25:47,120 right? So if you don't see some kind of 474 00:25:47,120 --> 00:25:51,360 a scale where people build more solutions, more adoptions, more 475 00:25:51,360 --> 00:25:54,640 usage and even they recommend it to other people, right. 476 00:25:54,920 --> 00:25:56,960 I think that's not like a true platform, right? 477 00:25:56,960 --> 00:25:59,720 Because that could be just some IT services that you mandate 478 00:25:59,720 --> 00:26:03,160 people to use for control, for standardization, or for whatever 479 00:26:03,160 --> 00:26:04,880 that is. Correct. 480 00:26:04,880 --> 00:26:08,400 And in some sense, that already presents a little bit of a 481 00:26:08,400 --> 00:26:10,240 challenge for in house platforms, right? 482 00:26:10,240 --> 00:26:14,200 If platforms thrive on scale, if you build something custom in 483 00:26:14,200 --> 00:26:18,120 house, you will never have the scale that, let's say, a cloud 484 00:26:18,120 --> 00:26:21,400 provider will have, right? So you need to be cautious. 485 00:26:21,680 --> 00:26:25,480 Now the good news is that you can build on top of a platform, 486 00:26:25,480 --> 00:26:27,800 so your platform doesn't have to start from scratch. 487 00:26:27,800 --> 00:26:31,240 So that helps a little bit. But you're absolutely right. 488 00:26:31,240 --> 00:26:34,960 There's a couple of important mechanisms at work here. 489 00:26:35,200 --> 00:26:39,640 The one thing is platforms are indirect value creators. 490 00:26:39,840 --> 00:26:43,160 If you build world's most beautiful platform and nobody is 491 00:26:43,160 --> 00:26:46,120 on that platform, the value creation is absolutely zero, 492 00:26:46,440 --> 00:26:48,720 right? Like the thing doesn't do 493 00:26:48,760 --> 00:26:52,680 anything on its own. It enables developers, it speeds 494 00:26:52,680 --> 00:26:55,560 them up, It helps them make fewer mistakes, build that 495 00:26:55,560 --> 00:26:57,640 application. Like there's a million ways to 496 00:26:57,640 --> 00:27:01,240 sort of position it, but the value only comes with the usage 497 00:27:01,240 --> 00:27:05,800 and that means right, the scale is where the value is versus 498 00:27:06,160 --> 00:27:09,040 traditional IT. They often suffer from their own 499 00:27:09,040 --> 00:27:11,360 success. I see this with cloud centers of 500 00:27:11,360 --> 00:27:13,640 excellence. So as a quick side note, they're 501 00:27:13,640 --> 00:27:16,280 also candidates to be relabeled as platform teams. 502 00:27:16,520 --> 00:27:19,920 As we look around, it's either the IT service teams or in a 503 00:27:19,920 --> 00:27:22,560 slightly more modern organization, the CCOE, the 504 00:27:22,560 --> 00:27:25,640 cloud center of excellence that gets relabeled as platform team. 505 00:27:25,840 --> 00:27:29,400 And if that is super popular in its scales, they usually become 506 00:27:29,760 --> 00:27:33,080 a a bottleneck, right. So it thrives on scale because 507 00:27:33,080 --> 00:27:38,440 that's the only way it can generate value and the other 508 00:27:38,600 --> 00:27:41,480 magical maneuver that platforms do. 509 00:27:41,480 --> 00:27:43,720 And this is visible with cloud platforms. 510 00:27:44,000 --> 00:27:46,440 Cloud platforms are a scale business, right? 511 00:27:46,440 --> 00:27:48,560 Building these data centers, there's like billions and 512 00:27:48,560 --> 00:27:51,120 billions of dollar data center undersea cables like this 513 00:27:51,120 --> 00:27:55,400 infrastructure that is clearly an economies of scale model, 514 00:27:55,600 --> 00:27:57,040 right? The bigger you are, right? 515 00:27:57,160 --> 00:27:59,440 Like you can make those kind of investments. 516 00:27:59,840 --> 00:28:02,280 Custom CPUs, right? Like almost every cloud 517 00:28:02,280 --> 00:28:05,480 provider, whether it's Graviton or Titan chips or whatever you 518 00:28:05,480 --> 00:28:07,480 have, right. Almost everybody has custom 519 00:28:07,480 --> 00:28:10,560 hardware these days. Those are not things you can do 520 00:28:10,560 --> 00:28:13,920 as an average enterprise. So there's a clear scale effect, 521 00:28:14,240 --> 00:28:20,080 but the magic of those platforms is that the usage of these 522 00:28:20,080 --> 00:28:24,200 platforms is not scale effect. Like, I can run one of the 523 00:28:24,200 --> 00:28:26,520 functions for like one second, right? 524 00:28:26,520 --> 00:28:28,640 And pay. I could do the math, but pay 525 00:28:28,640 --> 00:28:32,480 some ridiculously small amount, like a fraction of a penny on 526 00:28:32,480 --> 00:28:34,640 it, right? Or I can get an EC2 instance for 527 00:28:34,640 --> 00:28:37,160 one hour right, and pay like $0.50 for it. 528 00:28:37,160 --> 00:28:42,160 So the magic of the cloud platforms has been that they use 529 00:28:42,160 --> 00:28:46,680 economies of scale underneath because that's the only way to 530 00:28:46,680 --> 00:28:49,960 make these things. But they offered as what I call 531 00:28:49,960 --> 00:28:52,760 economies of speed. You can have it instantly, you 532 00:28:52,760 --> 00:28:54,680 can get as little as much as you want. 533 00:28:54,680 --> 00:28:57,840 You can shut it off. So they changed the rules of 534 00:28:57,840 --> 00:29:00,640 engagement between the usage of the platform and the 535 00:29:00,640 --> 00:29:04,600 implementation. Now for cloud platforms, we kind 536 00:29:04,600 --> 00:29:08,640 of knew that and probably if my memory was better in cloud 537 00:29:08,640 --> 00:29:12,320 strategy book, probably it says something like this about cloud 538 00:29:12,320 --> 00:29:14,920 platforms. What I'm trying to do with 539 00:29:15,160 --> 00:29:20,760 platform strategy is to take a step back and say, now is that 540 00:29:20,760 --> 00:29:24,840 just for clouds or is this for all platforms? 541 00:29:24,840 --> 00:29:29,240 And how can you as a platform team make that work for you? 542 00:29:29,240 --> 00:29:33,160 So in a way, the platform book is sort of one more level of 543 00:29:33,160 --> 00:29:36,160 abstraction over the cloud book in some sense. 544 00:29:36,960 --> 00:29:39,000 Right. You bring a topic cloud center 545 00:29:39,000 --> 00:29:41,200 of excellence. So in my experience, I've seen 546 00:29:41,200 --> 00:29:44,720 people building platforms on top of cloud platforms like you 547 00:29:44,720 --> 00:29:47,360 mentioned, we can build platform on top of base platform, right? 548 00:29:47,360 --> 00:29:49,560 In this case it's cloud platform, especially if you want 549 00:29:49,560 --> 00:29:52,680 to go hybrid, multi cloud or especially if you don't want to 550 00:29:52,680 --> 00:29:55,280 expose people to the real Cloud Console for example. 551 00:29:55,600 --> 00:29:57,840 So tell us a little bit more about this strategy. 552 00:29:58,160 --> 00:30:01,240 How do you think people should do it because so many people are 553 00:30:01,240 --> 00:30:03,400 doing it? How should they do it so that it 554 00:30:03,400 --> 00:30:06,320 becomes more successful for the organization rather than 555 00:30:06,400 --> 00:30:09,280 limiting people with options? Yeah. 556 00:30:09,560 --> 00:30:14,240 And I would say the sad reality, they are maybe more poor 557 00:30:14,240 --> 00:30:17,880 examples than good examples. I think they're slowly learning 558 00:30:17,880 --> 00:30:20,680 and there's few companies now they're basically platform 559 00:30:20,680 --> 00:30:23,760 builder tool kits to make it easier to build platforms. 560 00:30:24,040 --> 00:30:28,560 But the harsh reality is that making such a platform that you 561 00:30:28,560 --> 00:30:33,240 lay on top of the cloud is extremely difficult for a number 562 00:30:33,240 --> 00:30:35,600 of different reasons. Well, the one reason I already 563 00:30:35,600 --> 00:30:38,840 mentioned right, the platform that you're building on evolves. 564 00:30:39,120 --> 00:30:42,600 So you might be building something that in a year or so 565 00:30:42,600 --> 00:30:46,880 the base platform does that doesn't mean it's a bad thing. 566 00:30:46,880 --> 00:30:49,160 And actually this happened to me when I was in financial 567 00:30:49,160 --> 00:30:51,600 services. I built an in house platform and 568 00:30:51,600 --> 00:30:54,280 then quite a few years later somebody came like, hey, you 569 00:30:54,280 --> 00:30:57,320 know, all this stuff you built, they replaced it all with like 570 00:30:57,360 --> 00:31:00,120 AWS or something and they thought I would be very sad 571 00:31:00,120 --> 00:31:01,320 about it. It's like, oh, that's great 572 00:31:01,320 --> 00:31:04,920 because that means we were exactly on the right trajectory, 573 00:31:05,160 --> 00:31:07,120 right? We were a few years ahead with 574 00:31:07,120 --> 00:31:09,880 our specific needs and now the base platform does it. 575 00:31:10,160 --> 00:31:12,920 So I should throw away what I built and just use the base 576 00:31:12,920 --> 00:31:16,440 platform because you will always have better economics, but that 577 00:31:16,440 --> 00:31:18,720 takes a very different mindset, right? 578 00:31:18,720 --> 00:31:23,160 You must be happy when your things become obsolete, which is 579 00:31:23,160 --> 00:31:27,120 not the way normal IT works. They would always think about 580 00:31:27,440 --> 00:31:29,160 cost recovery. They're like, Oh no, no, this 581 00:31:29,160 --> 00:31:31,760 thing needs to live as long as possible because we need to get 582 00:31:31,760 --> 00:31:34,480 our money back. So this is one way in which 583 00:31:34,480 --> 00:31:38,560 these platforms struggle. The other one, and there's a 584 00:31:38,560 --> 00:31:42,600 magical word here which is I think very useful but also very 585 00:31:42,800 --> 00:31:45,320 difficult. And that's the cognitive load. 586 00:31:45,480 --> 00:31:49,040 So almost all of this thing from the team topology is right. 587 00:31:49,040 --> 00:31:51,720 You know, Matt and Manuel, you know, written the book, super 588 00:31:51,720 --> 00:31:54,040 popular, very helpful models. I'm pretty sure they weren't 589 00:31:54,040 --> 00:31:55,560 technically podcast at some point. 590 00:31:55,920 --> 00:31:59,000 So they introduced the notion of a platform team. 591 00:31:59,120 --> 00:32:02,240 Now careful platform team and platform. 592 00:32:02,240 --> 00:32:05,880 Still two different things. And there's one unfinished 593 00:32:05,880 --> 00:32:08,720 chapter in the book which is actually called platform, team 594 00:32:08,720 --> 00:32:12,320 without platform. But basically the team 595 00:32:12,320 --> 00:32:16,000 topologies really focus on the concept of cognitive flow. 596 00:32:16,040 --> 00:32:20,600 And that's important because if you look at today's development 597 00:32:20,600 --> 00:32:24,760 teams, right, there's one manoeuvre that we've executed 598 00:32:24,760 --> 00:32:27,640 over the last couple of years and that's called shift left. 599 00:32:27,840 --> 00:32:30,520 Basically, your security should be shifted left, operational 600 00:32:30,520 --> 00:32:33,080 should be shifted left. Policy and compliance should be 601 00:32:33,080 --> 00:32:36,680 shifted left policy as code. Right now we have def SEC OPS, 602 00:32:36,680 --> 00:32:39,560 def arc SEC OPS, basically you build it, you run it. 603 00:32:39,560 --> 00:32:42,440 So basically everything is piled into the development team. 604 00:32:42,640 --> 00:32:45,880 So I no longer call it shift left, I call it pile left 605 00:32:45,880 --> 00:32:49,800 because everything gets piled over and people basically going 606 00:32:50,160 --> 00:32:53,880 bananas, right. So if we don't manage to reduce 607 00:32:53,880 --> 00:32:57,240 their cognitive load, there's like no way you can have such a 608 00:32:57,240 --> 00:32:59,280 team that can do all these kind of things. 609 00:32:59,480 --> 00:33:02,880 So the idea is extremely valuable. 610 00:33:03,320 --> 00:33:07,200 Now the reason I mention it's also a bit of a dangerous word 611 00:33:07,200 --> 00:33:10,440 is that it's used to justify everything. 612 00:33:10,920 --> 00:33:15,160 So people say like, oh, we don't want you to use the native cloud 613 00:33:15,160 --> 00:33:18,440 services because we want to be portable or we don't want you to 614 00:33:18,440 --> 00:33:21,240 use this region and we want to fix this parameter. 615 00:33:21,240 --> 00:33:23,880 And they say, look, it's good for you because it reduces your 616 00:33:23,880 --> 00:33:27,160 cognitive load. And that is not true. 617 00:33:27,560 --> 00:33:29,840 So let's take a very simple example. 618 00:33:29,840 --> 00:33:33,760 Let's say you have a cloud service and it has 20 different 619 00:33:33,760 --> 00:33:37,040 parameters. And you as a platform team with 620 00:33:37,200 --> 00:33:41,840 good intentions, you say I default ten of those 20 621 00:33:41,840 --> 00:33:46,480 parameters so the developer only has to now worry about 10 622 00:33:46,480 --> 00:33:49,360 parameters. That on the surface would seem, 623 00:33:49,360 --> 00:33:51,800 hey, setting 10 parameters is easier than 20. 624 00:33:51,800 --> 00:33:54,560 Didn't the cognitive load go down by 50%? 625 00:33:54,840 --> 00:33:59,520 The reality is no, because behind these parameters sit 626 00:33:59,600 --> 00:34:02,440 concepts. So if you fix the availability 627 00:34:02,440 --> 00:34:04,520 zone, that's probably fine, right? 628 00:34:04,520 --> 00:34:07,880 People don't need to worry about it unless they need to do 629 00:34:07,880 --> 00:34:10,280 something Cross availability zones, right? 630 00:34:10,280 --> 00:34:13,760 Even then you struggle because like, oh, I never actually knew 631 00:34:13,760 --> 00:34:16,360 what an availability zone is because they were set for me. 632 00:34:16,760 --> 00:34:19,880 Now somebody says I need 4 nines or five nines, so I need to run 633 00:34:19,880 --> 00:34:22,000 across multiple ability. What is what is that? 634 00:34:22,400 --> 00:34:27,920 So it's not that easy. Also depending which parameters 635 00:34:27,920 --> 00:34:31,840 you fix, not all parameters are independent. 636 00:34:31,840 --> 00:34:35,800 You you might create some sort of intellectual minefield where 637 00:34:36,120 --> 00:34:40,120 you sort of take some concepts out of the overall construct. 638 00:34:40,520 --> 00:34:45,560 And sometimes needing to understand 1/2 a thing is harder 639 00:34:45,560 --> 00:34:46,920 than understanding the whole thing. 640 00:34:46,920 --> 00:34:49,560 Because if you see the whole thing you can understand what 641 00:34:49,560 --> 00:34:52,840 relates to what and what combinations are useful versus 642 00:34:52,840 --> 00:34:57,280 if I sort of randomly take some pieces out of the puzzle it's 643 00:34:57,280 --> 00:35:00,840 actually harder. I mean maybe a metaphor is and 644 00:35:01,000 --> 00:35:04,200 it reminds me of the funny movie The Accountant I've I blocked 645 00:35:04,360 --> 00:35:08,200 before about transformations and not hiring a hitman to fix your 646 00:35:08,200 --> 00:35:12,520 stuff, which the movie is partly about but it has a example where 647 00:35:12,520 --> 00:35:16,360 somebody tries to put together a puzzle and the kid is autistic 648 00:35:16,360 --> 00:35:20,080 so one piece is missing. So he he is very unhappy and and 649 00:35:20,080 --> 00:35:23,240 very agitated. But that metaphor just came to 650 00:35:23,240 --> 00:35:25,360 my head, right. Let's say you give somebody a 651 00:35:25,360 --> 00:35:28,680 puzzle of 1000 pieces and you say, hey, I want to make this 652 00:35:28,680 --> 00:35:31,440 easier for you. So I took away half the pieces. 653 00:35:31,880 --> 00:35:34,880 It's worse, right? Because you don't know if the 654 00:35:34,880 --> 00:35:37,200 piece is there, if it isn't, like in the end you don't know 655 00:35:37,200 --> 00:35:40,120 which ones are missing. You wouldn't need to give people 656 00:35:40,120 --> 00:35:44,800 a different puzzle with 500 pieces that fit together. 657 00:35:45,080 --> 00:35:49,440 You can't just take out half the pieces from the puzzle because 658 00:35:49,440 --> 00:35:51,160 you just make it harder for people. 659 00:35:51,640 --> 00:35:54,080 So that's where the book is trying to go. 660 00:35:54,080 --> 00:35:57,880 And it's a little bit, it sounds kind of maybe abstract, but 661 00:35:58,080 --> 00:36:01,760 that's where I see a lot of these initiatives derail. 662 00:36:01,760 --> 00:36:05,200 They say, hey, I take some things away from you, doesn't 663 00:36:05,200 --> 00:36:09,600 that make your life easier? And the short answer is no, not 664 00:36:09,600 --> 00:36:12,360 necessarily. Yeah, in your book you also 665 00:36:12,360 --> 00:36:15,240 bring up an example where for example, some of these 666 00:36:15,240 --> 00:36:18,040 parameters are hidden and they are applied in the actual 667 00:36:18,040 --> 00:36:21,000 instance for example. And then there is an issue like 668 00:36:21,200 --> 00:36:23,800 when you troubleshoot, you see an error message, but the root 669 00:36:23,800 --> 00:36:27,040 cause is mentioning something that you didn't even know that 670 00:36:27,040 --> 00:36:29,720 you tweaked before, right? So you kind of like limit people 671 00:36:29,720 --> 00:36:33,360 to understand what is going on and even troubleshoot and you 672 00:36:33,360 --> 00:36:35,920 need to file ticket support and things like that and things 673 00:36:35,920 --> 00:36:37,960 become slower. So I think this is also another 674 00:36:37,960 --> 00:36:40,280 danger zone that I read from reading your book, right? 675 00:36:40,760 --> 00:36:42,840 Yeah, so I think that that's really, really good advice for 676 00:36:42,840 --> 00:36:44,200 people who are building platforms. 677 00:36:44,480 --> 00:36:47,520 And another thing, I think when you build this in house platform 678 00:36:47,520 --> 00:36:48,880 you need to have skill set right? 679 00:36:48,880 --> 00:36:53,440 So any tips here for people how they should find skill set and 680 00:36:53,440 --> 00:36:57,000 how they should think about finding people who can build a 681 00:36:57,000 --> 00:36:59,480 truly developer friendly platform? 682 00:37:00,160 --> 00:37:03,200 Yeah, and perfect question. Ironically, this is another 683 00:37:03,200 --> 00:37:06,080 common failure mode, so I'm I'm a little bit worried that we may 684 00:37:06,080 --> 00:37:09,600 be painting the picture too darkly here about all the things 685 00:37:09,600 --> 00:37:12,840 that can go wrong. But in the end, a good strategy 686 00:37:12,840 --> 00:37:16,240 is intended to keep you on the good path and keep you out of 687 00:37:16,440 --> 00:37:18,560 trouble. So I think mentioning and 688 00:37:18,560 --> 00:37:22,040 talking about failure scenarios is is actually very common. 689 00:37:22,040 --> 00:37:25,600 So here's a failure scenario I've seen almost every large 690 00:37:25,600 --> 00:37:29,720 organization doesn't have enough fully skilled developers as they 691 00:37:29,720 --> 00:37:31,960 would like, right? And that's always going to be 692 00:37:31,960 --> 00:37:34,000 the case, right? Because there's a lot of stuff 693 00:37:34,000 --> 00:37:36,960 to do, You know, modern applications are demanding, like 694 00:37:36,960 --> 00:37:39,640 they distributed. We have fine grained deployment 695 00:37:39,640 --> 00:37:42,240 models, automation, right? We release offer like we can do 696 00:37:42,240 --> 00:37:45,760 amazingly cool stuff, but it's not exactly trivial, right? 697 00:37:45,760 --> 00:37:48,400 So there will always be a shortage of skill set. 698 00:37:48,560 --> 00:37:53,000 So what these companies they do is like, OK, if I have a lot of 699 00:37:53,000 --> 00:37:57,760 developers which are so, so can I pick good developers and make 700 00:37:57,760 --> 00:38:01,680 a platform so that the so so developers become good 701 00:38:01,680 --> 00:38:05,000 developers. And finally Martin Fowler I 702 00:38:05,000 --> 00:38:07,400 think commented on this. It must have been a decade or 703 00:38:07,400 --> 00:38:11,080 two ago because that same mistake was made with frameworks 704 00:38:11,440 --> 00:38:14,240 where it's like I was instead of a platform, I built a framework 705 00:38:14,440 --> 00:38:16,680 right where all the good developers build the framework 706 00:38:16,680 --> 00:38:19,000 and then the not so good developers become now good 707 00:38:19,000 --> 00:38:21,120 developers thanks to the framework. 708 00:38:21,120 --> 00:38:23,120 And that basically has never worked. 709 00:38:23,480 --> 00:38:27,920 So the failure scenario is that you also don't have the skills 710 00:38:27,920 --> 00:38:32,200 to build a platform because the bar for that skill is is much, 711 00:38:32,200 --> 00:38:35,120 much higher. And I'll give some example in 712 00:38:35,280 --> 00:38:37,720 different ways in which the bar is much, much higher. 713 00:38:38,120 --> 00:38:41,040 The one thing is, so let's start with what's perceived as the 714 00:38:41,040 --> 00:38:43,120 easier one, but usually the harder one. 715 00:38:43,120 --> 00:38:46,360 And that is, how does a platform team function? 716 00:38:46,800 --> 00:38:49,920 Like, how does it engage with customers, right? 717 00:38:49,920 --> 00:38:53,080 How does it take feedback? What is the rate of change? 718 00:38:53,080 --> 00:38:56,200 We said platforms must evolve, but if they change every day, 719 00:38:56,200 --> 00:38:59,000 nobody will be happy. You can go and ask your 720 00:38:59,000 --> 00:39:01,760 customers what they want, but building what their customers 721 00:39:01,760 --> 00:39:05,360 say they want is also not a great way to build a platform. 722 00:39:05,640 --> 00:39:09,600 So there's a lot of skills there in terms of it's like running a 723 00:39:09,600 --> 00:39:12,680 successful product company, a lot of trade-offs, 724 00:39:13,120 --> 00:39:16,040 prioritization, right. And that is something very 725 00:39:16,040 --> 00:39:19,640 different, especially in IT operations, right. 726 00:39:19,640 --> 00:39:22,320 We're basically, here's the three service you can have, 727 00:39:22,320 --> 00:39:25,520 please be happy, right. This is again the exact opposite 728 00:39:25,520 --> 00:39:27,840 where you need to be customer centric, do a lot of product 729 00:39:27,840 --> 00:39:30,680 management, do a lot of marketing, a lot of consulting. 730 00:39:30,680 --> 00:39:32,760 So that's skills you need to have. 731 00:39:33,240 --> 00:39:37,680 And the technical skill you need to really have is to really 732 00:39:37,680 --> 00:39:41,280 understand cognitive load and abstraction. 733 00:39:41,280 --> 00:39:45,640 So if defaulting half the parameters doesn't reduce the 734 00:39:45,640 --> 00:39:48,400 cognitive load, what actually does? 735 00:39:48,760 --> 00:39:52,200 And I see people struggle with this a lot. 736 00:39:52,200 --> 00:39:55,400 So my favorite example is. So people look at the different 737 00:39:55,400 --> 00:39:58,320 cloud providers and say, oh there's, you know, SQS, you 738 00:39:58,320 --> 00:40:01,440 know, I'm a queuing messaging guy, so I must make an example 739 00:40:01,440 --> 00:40:03,720 from message queue. So you have like SQS, right? 740 00:40:03,720 --> 00:40:06,280 You have the Azure event pass and you have Google pops up, 741 00:40:06,640 --> 00:40:09,480 right? So when they say aha, I make an 742 00:40:09,480 --> 00:40:11,840 abstraction and I call that abstraction. 743 00:40:12,120 --> 00:40:15,360 Message queue. But in the end you didn't really 744 00:40:15,360 --> 00:40:18,480 abstract much. It was already a message queue 745 00:40:18,480 --> 00:40:22,440 before you abstracted it. Maybe it had some specific 746 00:40:22,440 --> 00:40:25,360 runtime settings, but two things come into play. 747 00:40:25,360 --> 00:40:28,680 You didn't really simplify things that much because it's 748 00:40:28,680 --> 00:40:30,160 still a queue. It's asynchronous. 749 00:40:30,360 --> 00:40:32,440 You need to deal with things like back pressure and time to 750 00:40:32,440 --> 00:40:34,640 live right, like all that stuff doesn't go away. 751 00:40:35,040 --> 00:40:38,600 And to be honest, the original queues probably have some really 752 00:40:38,600 --> 00:40:43,360 important settings underneath like FIFO or not FIFO on scale 753 00:40:43,360 --> 00:40:47,160 out and many other things that if you take those away again you 754 00:40:47,160 --> 00:40:49,160 have the puzzle where half the pieces are missing. 755 00:40:49,400 --> 00:40:53,120 So I see even talented teams struggle with this. 756 00:40:53,120 --> 00:40:56,880 They say oh but I made this abstraction layer but you didn't 757 00:40:56,880 --> 00:41:00,640 actually abstract something. So what I've seen from some 758 00:41:00,640 --> 00:41:04,720 customers where they are really successful at this and have a 759 00:41:04,720 --> 00:41:08,520 much better approach is they start taking concepts from their 760 00:41:08,520 --> 00:41:11,080 business domain. It was really interesting. 761 00:41:11,080 --> 00:41:14,120 I talked to a customer like about a month ago and they 762 00:41:14,120 --> 00:41:17,720 described what they were doing. And then I was really excited 763 00:41:17,720 --> 00:41:20,760 because I liked it so much and their comment was, oh, finally 764 00:41:20,760 --> 00:41:23,880 somebody who understands what we're doing because they 765 00:41:23,880 --> 00:41:26,440 couldn't find anybody to appreciate what they had done 766 00:41:26,440 --> 00:41:30,200 because it was very subtle. But for me it was absolutely 767 00:41:30,320 --> 00:41:34,320 obvious and ingenious. So rather than trying to 768 00:41:34,360 --> 00:41:39,960 abstract SQS into a queue, they have concepts that are important 769 00:41:39,960 --> 00:41:43,640 in their what I would call business technical domain. 770 00:41:43,880 --> 00:41:45,920 So they are financial services companies. 771 00:41:45,920 --> 00:41:48,360 So they have a lot of compliance requirements. 772 00:41:48,360 --> 00:41:52,440 So they need to have ledgers. So when you have a database, you 773 00:41:52,440 --> 00:41:55,320 can make updates in the database, but every change must 774 00:41:55,320 --> 00:41:58,640 be tracked in a log or a Ledger they call, right? 775 00:41:58,640 --> 00:42:01,000 That's the way the industry functions. 776 00:42:01,000 --> 00:42:03,520 You can't just like go and change the number in the bank 777 00:42:03,520 --> 00:42:06,120 account. You add and subtract money and 778 00:42:06,120 --> 00:42:09,240 that gets all logged. So that is something that's very 779 00:42:09,240 --> 00:42:12,480 inherent to their business and their business technical domain. 780 00:42:12,800 --> 00:42:16,200 So their platform now has constructs like this. 781 00:42:16,600 --> 00:42:20,600 They have Ledger database and underneath this Dynamo DB and 782 00:42:20,600 --> 00:42:24,640 Eventbridge pipes and another Dynamo DB the way they do that. 783 00:42:24,800 --> 00:42:28,720 But they didn't call this like 2 Dynamo DBS and Eventbridge pipes 784 00:42:28,920 --> 00:42:31,720 or AQ whatever, right? They called this alleged 785 00:42:31,840 --> 00:42:34,800 database and the difference is very subtle. 786 00:42:34,800 --> 00:42:37,400 You could even make an abstraction that's called 787 00:42:37,640 --> 00:42:41,400 database with customer data and database without customer data 788 00:42:41,560 --> 00:42:44,280 or database with PII like personally identifiable 789 00:42:44,280 --> 00:42:46,960 information or without. And to most people that would 790 00:42:46,960 --> 00:42:49,240 seem very subtle. So the database. 791 00:42:49,240 --> 00:42:51,880 And again, you're probably just defaulting a few fields, right? 792 00:42:51,880 --> 00:42:55,040 Because maybe the PII database needs to be encrypted on in a 793 00:42:55,040 --> 00:42:57,320 special availability zone in a special region. 794 00:42:57,320 --> 00:42:59,280 You're like, oh, you're just defaulting fields. 795 00:42:59,480 --> 00:43:04,440 No, in this case you're not just defaulting fields, you're 796 00:43:04,520 --> 00:43:08,240 building a new domain language on top of it. 797 00:43:08,480 --> 00:43:12,600 So the second skill that you really need to have is you need 798 00:43:12,600 --> 00:43:16,680 to be able to do domain modelling, DDD really Domain 799 00:43:16,680 --> 00:43:20,560 Driven design, but for this business technical layer, right? 800 00:43:20,560 --> 00:43:23,120 It's half cloud and technical stuff. 801 00:43:23,120 --> 00:43:26,760 You talk about databases, right? That's obviously technical stuff 802 00:43:27,080 --> 00:43:29,320 but with a strong business flavor. 803 00:43:29,320 --> 00:43:32,840 Does it have PII? Doesn't need to be Ledger and I 804 00:43:32,840 --> 00:43:37,880 think that is a skill we still struggle with and the techies 805 00:43:37,960 --> 00:43:40,560 will dismiss it. As to fluffy stuff that I got 806 00:43:40,600 --> 00:43:43,200 still a database like whatever what you're talking about and 807 00:43:43,200 --> 00:43:46,560 the business people don't necessarily have the skill to 808 00:43:46,560 --> 00:43:49,960 really understand like Dynamo DB and Maven Bridge and pipes and 809 00:43:49,960 --> 00:43:52,360 all the other thing. So you're living right in that 810 00:43:52,360 --> 00:43:56,560 area, which I find super fascinating, but I've seen it 811 00:43:56,560 --> 00:43:59,600 very rarely that that is done well. 812 00:43:59,800 --> 00:44:04,560 And that touches on sort of how it can be done well, but it also 813 00:44:04,560 --> 00:44:08,520 touches on why so many things fail by just saying, hey, I 814 00:44:08,520 --> 00:44:13,120 abstract SQS into a queue or I default some fields and all that 815 00:44:13,120 --> 00:44:16,400 sounds nice, but it's not reducing cognitive load and it's 816 00:44:16,400 --> 00:44:18,480 not giving you the abstractions that you need. 817 00:44:19,280 --> 00:44:20,880 Wow. I think that's a pretty good 818 00:44:20,880 --> 00:44:23,200 insights, right? The example when you mentioned 819 00:44:23,200 --> 00:44:26,280 they created their own concept like a business technical domain 820 00:44:26,280 --> 00:44:28,480 concept, right? But I think that is really 821 00:44:28,480 --> 00:44:30,600 insightful for me. And when you mention about 822 00:44:30,600 --> 00:44:33,040 creating abstraction, right, I also love the metaphor you 823 00:44:33,040 --> 00:44:35,800 introduced in the book, right? Abstraction, not in illusion, 824 00:44:35,800 --> 00:44:37,400 right. So sometimes we create 825 00:44:37,400 --> 00:44:39,160 abstraction, but actually it's an illusion, right? 826 00:44:39,160 --> 00:44:40,840 It doesn't actually abstract away things. 827 00:44:41,080 --> 00:44:43,800 We create such that it becomes like a unified interface. 828 00:44:43,800 --> 00:44:46,840 But the implementation details can be so, so different, right? 829 00:44:46,840 --> 00:44:49,840 Between, for example, different cue mechanism from different 830 00:44:49,840 --> 00:44:51,880 clouds, right? And people will be stuck like 831 00:44:51,880 --> 00:44:55,160 because, yeah, because they think it's an abstraction, but 832 00:44:55,160 --> 00:44:57,720 the behavior is different. So I think this is also another 833 00:44:57,720 --> 00:45:00,000 danger zone. Just picking on that really 834 00:45:00,000 --> 00:45:01,560 quickly. So yeah, that happens. 835 00:45:01,560 --> 00:45:05,040 If people want to abstract too much, they say, oh, I make this 836 00:45:05,040 --> 00:45:08,320 beautiful logical abstraction. Now I have this cue, this 837 00:45:08,320 --> 00:45:11,280 generic cue. But it turns out any distributed 838 00:45:11,280 --> 00:45:14,280 system has a lot of physical properties, right? 839 00:45:14,280 --> 00:45:18,160 And no logical layer can abstract away physical 840 00:45:18,480 --> 00:45:20,960 properties, right? And Joel Spotsky, right. 841 00:45:20,960 --> 00:45:22,560 Always. Never short of an opinion, 842 00:45:22,560 --> 00:45:24,000 right? He said all abstractions are 843 00:45:24,000 --> 00:45:26,400 leaky. And that's probably true, I 844 00:45:26,400 --> 00:45:29,960 would say the leakiness isn't that horrible, right? 845 00:45:29,960 --> 00:45:33,040 So for example, I don't mind if my queues thing has an SQS 846 00:45:33,040 --> 00:45:35,400 setting on it. That's not what's making my day 847 00:45:35,400 --> 00:45:38,800 good or a bad day. But what leaks through is the 848 00:45:38,800 --> 00:45:43,360 physical aspect. Latency, failures, retries, 849 00:45:43,480 --> 00:45:46,120 queues filling up, all those kind of things. 850 00:45:46,120 --> 00:45:49,200 And an abstraction layer cannot make that go away. 851 00:45:49,440 --> 00:45:51,840 And that's where you know I work in serverless. 852 00:45:51,840 --> 00:45:55,360 As I said in the beginning, that is full of that stuff, right? 853 00:45:55,360 --> 00:45:57,800 Because serverless solutions like fine grained asynchronous 854 00:45:57,800 --> 00:46:00,440 event driven. So the physical properties are 855 00:46:00,480 --> 00:46:04,280 extremely important. And then people try to make it 856 00:46:04,280 --> 00:46:08,840 look very simple. And simple doesn't always mean 857 00:46:08,840 --> 00:46:13,040 better abstraction. So the classic example is RPCRPC 858 00:46:13,040 --> 00:46:16,320 is also beautiful abstraction, except it doesn't work. 859 00:46:16,320 --> 00:46:19,360 It it pretends to be something that it isn't because it 860 00:46:19,360 --> 00:46:21,880 pretends that there's no latency, there's no partial 861 00:46:21,880 --> 00:46:24,400 failure, pretends you have a call stack, right? 862 00:46:24,560 --> 00:46:26,160 It pretends it's always consistent. 863 00:46:26,360 --> 00:46:28,920 It pretends the infallacies of networks don't exist, right. 864 00:46:28,920 --> 00:46:31,840 Or distributed computing like basically pretends all these 865 00:46:31,840 --> 00:46:34,920 things that are not true. And that is the classic example 866 00:46:34,920 --> 00:46:39,960 of you build an illusion. So what we learn is it's not 867 00:46:39,960 --> 00:46:45,360 about taking as many things away as possible, it's about finding 868 00:46:45,360 --> 00:46:49,040 sort of the right level where you can create a new mental 869 00:46:49,040 --> 00:46:54,560 model or a new domain like a new vocabulary for people that's 870 00:46:54,800 --> 00:46:59,040 cohesive in itself, right? And that is in the end, it is 871 00:46:59,040 --> 00:47:02,680 Domain driven design And that in the end is quite challenging. 872 00:47:02,680 --> 00:47:05,200 So when people say, oh, we're going to build some platform, we 873 00:47:05,200 --> 00:47:07,440 have some servers and some cloud stuff, we're going to go build a 874 00:47:07,440 --> 00:47:11,560 platform, I kind of want them to read maybe, well, ideally read 875 00:47:11,560 --> 00:47:13,840 the book first. But whichever way you do, think 876 00:47:13,840 --> 00:47:17,280 a little bit more first about what are you really achieving 877 00:47:17,280 --> 00:47:19,200 and all those really abstractions. 878 00:47:19,200 --> 00:47:21,240 Are you really reducing cognitive load? 879 00:47:21,560 --> 00:47:24,680 We use all these words way too loosely, right? 880 00:47:24,680 --> 00:47:28,440 Like everybody talks about this stuff, but then really making it 881 00:47:28,440 --> 00:47:32,280 work is a whole different story. So yeah, hence the illusions, 882 00:47:32,840 --> 00:47:34,480 right? I'd like to bring another 883 00:47:34,480 --> 00:47:36,520 metaphor that you bring in the book, right, because we have 884 00:47:36,520 --> 00:47:39,240 been talking about, you know, building a lot of components, a 885 00:47:39,240 --> 00:47:41,080 lot of cohesion and things like that. 886 00:47:41,080 --> 00:47:44,400 You have this analogy fruit salad versus fruit basket. 887 00:47:44,600 --> 00:47:47,160 So I think this is a fun one. So if you can elaborate a little 888 00:47:47,160 --> 00:47:50,440 bit more for us to learn from. Yes, and and this fits exactly 889 00:47:50,440 --> 00:47:52,480 what I was trying to say earlier, right? 890 00:47:52,480 --> 00:47:57,000 I like to take metaphors from real life, like one of my most 891 00:47:57,000 --> 00:47:59,680 popular article is still the Starbucks does not use two phase 892 00:47:59,680 --> 00:48:01,880 commit, right? It's like it's very memorable, 893 00:48:01,880 --> 00:48:05,520 but it has a serious meaning and this one has also meaning. 894 00:48:05,880 --> 00:48:08,960 And interestingly, this was the very first chapter. 895 00:48:08,960 --> 00:48:12,640 This came out of my work at the government of Singapore when I 896 00:48:12,640 --> 00:48:15,400 worked for Govtech, where we were actually building an 897 00:48:15,400 --> 00:48:19,560 engineering productivity platform and we had to make 898 00:48:19,560 --> 00:48:23,560 design decisions. So one question was Confluence 899 00:48:23,560 --> 00:48:26,960 and Jira and a few other tools. Is that a developer platform? 900 00:48:27,080 --> 00:48:31,560 Because OK, whichever flavor you prefer, but let's say you have a 901 00:48:31,560 --> 00:48:34,800 ticketing system, a source code repository, a build pipeline, 902 00:48:34,800 --> 00:48:36,560 right? Isn't that making a great 903 00:48:36,560 --> 00:48:39,400 developer platform because it gives the developers all the 904 00:48:39,400 --> 00:48:43,080 things to be productive. And then I was saying, yes, 905 00:48:43,080 --> 00:48:49,240 that's useful, but I coined that the fruit basket, basically 906 00:48:49,520 --> 00:48:52,040 assuming the different systems, you know, like basically the 907 00:48:52,040 --> 00:48:55,960 wiki and the backlog management systems, right, And your code 908 00:48:55,960 --> 00:48:59,040 repository, your build pipeline, they're like the fruit and now 909 00:48:59,040 --> 00:49:02,720 you put this fruit into a basket and that's bundled together. 910 00:49:02,720 --> 00:49:06,720 It's convenient, but it doesn't have like it. 911 00:49:06,880 --> 00:49:10,520 The sum of the fruit is not bigger than the individual 912 00:49:10,520 --> 00:49:12,360 fruit, right? He put four fruit in the basket. 913 00:49:12,760 --> 00:49:14,520 That thing is a basket with four fruit. 914 00:49:14,520 --> 00:49:17,120 So the whole isn't greater than the sum of the parts, right? 915 00:49:17,120 --> 00:49:19,040 The whole is equal to the sum of the parts. 916 00:49:19,040 --> 00:49:22,640 It's a basket with four fruit, and in real life we know the 917 00:49:22,920 --> 00:49:25,640 counterexample. We know the counterexample of 918 00:49:25,640 --> 00:49:29,520 food salad. Now again, it seems trivial 919 00:49:29,520 --> 00:49:34,200 because it's also like fruit in it, but it opens up entirely new 920 00:49:34,320 --> 00:49:36,280 use cases. You don't need tools. 921 00:49:36,280 --> 00:49:38,360 You don't need to peel anything. You don't need a knife. 922 00:49:38,760 --> 00:49:42,600 It's easy to take to a picnic. It's easy to make a mixture that 923 00:49:42,600 --> 00:49:45,040 otherwise you cannot do. If you want to make a fruit 924 00:49:45,040 --> 00:49:48,400 basket and one of your fruit is a watermelon or a jackfruit to 925 00:49:48,400 --> 00:49:50,880 make it worse, right, you're going to struggle to balance 926 00:49:50,880 --> 00:49:53,120 that out. Well, in a fruit salad that is 927 00:49:53,120 --> 00:49:56,160 no problem because you control the mixture. 928 00:49:56,360 --> 00:50:02,240 And what I remind people is the per kilo price of fruit salad is 929 00:50:02,360 --> 00:50:06,480 routinely 2 to three times higher than the fruit because it 930 00:50:06,480 --> 00:50:10,160 has a higher value proposition. So what we learn is like, yes, 931 00:50:10,160 --> 00:50:13,040 food basket is an OK way to start. 932 00:50:13,040 --> 00:50:17,400 You bundle some things together, but don't believe everybody will 933 00:50:17,400 --> 00:50:20,720 be jumping up and down at your fantastic platform because you 934 00:50:20,720 --> 00:50:24,160 didn't really create a whole, you didn't create anything 935 00:50:24,400 --> 00:50:26,760 cohesive. You just bundled a few things. 936 00:50:27,080 --> 00:50:30,040 Maybe you share some accounts or something, but really you didn't 937 00:50:30,040 --> 00:50:32,640 put anything much on top. You just bundled. 938 00:50:33,080 --> 00:50:36,800 So you composed some things but you didn't abstract anything. 939 00:50:37,200 --> 00:50:41,480 So I always much people think about can you make a fruit 940 00:50:41,640 --> 00:50:45,400 salad? And I talked to 1 customer where 941 00:50:45,480 --> 00:50:49,080 folks told me after our meeting they changed their title to 942 00:50:49,080 --> 00:50:51,640 fruit salad maker because they're building an in house 943 00:50:51,640 --> 00:50:56,480 platform and they kept trying to explain to people that sort of, 944 00:50:56,480 --> 00:50:58,560 you know, just like GR and Confluence and a few other 945 00:50:58,560 --> 00:51:00,760 things don't make a really good platform. 946 00:51:00,760 --> 00:51:03,760 But he had a hard time articulating that so he was so 947 00:51:03,760 --> 00:51:05,360 happy. He said fruit salad. 948 00:51:05,360 --> 00:51:09,640 So wherever he goes is we need fruit salad not fruit basket. 949 00:51:09,640 --> 00:51:12,760 And that obviously makes me happy because it means these 950 00:51:12,840 --> 00:51:17,200 light hearted metaphors speak really to challenges that people 951 00:51:17,200 --> 00:51:22,040 have and help them communicate even to upper management or the 952 00:51:22,040 --> 00:51:25,800 famous non-technical people who in many cases are more technical 953 00:51:25,800 --> 00:51:28,520 than some of the developers. But it makes it easy to 954 00:51:28,520 --> 00:51:31,800 communicate the differences and the nuances, and that's what 955 00:51:31,800 --> 00:51:34,360 I'm. Always aiming for, right? 956 00:51:34,360 --> 00:51:37,600 So I think it's always a fun metaphor coming from you, right? 957 00:51:37,600 --> 00:51:40,720 Fruit salad versus fruit basket. I hope people use this whenever 958 00:51:40,720 --> 00:51:42,400 they explain about building platform. 959 00:51:42,840 --> 00:51:44,880 Another thing I think when we talk about platform right, 960 00:51:44,880 --> 00:51:48,000 there's so many probably resources, posts and things like 961 00:51:48,000 --> 00:51:50,840 that related to developer productivity, developer 962 00:51:50,840 --> 00:51:53,040 platform. So in your point of view, in 963 00:51:53,040 --> 00:51:56,440 your experience, what is a good developer platform, What kind of 964 00:51:56,440 --> 00:51:59,840 problem it should solve and what kind of strategy we should build 965 00:51:59,840 --> 00:52:02,200 for developer platform in an organization? 966 00:52:02,960 --> 00:52:06,200 So yeah, that as I mentioned, this is one of the popular use 967 00:52:06,200 --> 00:52:09,680 cases and one that I was personally involved in. 968 00:52:10,080 --> 00:52:14,560 I think there's a a couple of different angles you can take 969 00:52:14,920 --> 00:52:18,480 and we first need to understand that this is actually out of 970 00:52:18,600 --> 00:52:23,320 cloud strategy and also from work at Govtech we called it the 971 00:52:23,320 --> 00:52:26,600 four leaf Clover of application oriented cloud. 972 00:52:26,600 --> 00:52:29,920 So first you need to understand what are all the things that 973 00:52:29,920 --> 00:52:32,880 application needs in its ecosystem, because that's my 974 00:52:32,880 --> 00:52:36,080 candidates for the platform rather than The answer is, is 975 00:52:36,080 --> 00:52:39,560 not that difficult to get to. The problem is, people often 976 00:52:39,560 --> 00:52:41,600 latch onto one thing and forget the other. 977 00:52:41,600 --> 00:52:45,200 So you need a CICD pipeline, you need a build system because 978 00:52:45,200 --> 00:52:46,800 that's how your software comes to life. 979 00:52:46,800 --> 00:52:50,520 You need a runtime underneath, you need monitoring and 980 00:52:50,520 --> 00:52:54,120 observability, and you probably also need some service 981 00:52:54,120 --> 00:52:56,480 integration for things to talk to each other. 982 00:52:56,920 --> 00:53:00,440 All those are good starting points for platforms, right? 983 00:53:00,440 --> 00:53:04,240 If I make it very easy. So basically if I have complete 984 00:53:04,440 --> 00:53:06,840 development environments out-of-the-box, like, I don't 985 00:53:06,840 --> 00:53:10,040 need to do anything and just say what kind of application do I 986 00:53:10,040 --> 00:53:12,000 want to build and it builds that. 987 00:53:12,000 --> 00:53:15,880 Now that is useful. Now interestingly that is so 988 00:53:15,880 --> 00:53:18,640 useful that many base platforms do this. 989 00:53:18,640 --> 00:53:22,800 Now, like I know our things, but Coat Catalyst is basically doing 990 00:53:22,800 --> 00:53:25,120 exactly these things. It's like it's on a template to 991 00:53:25,120 --> 00:53:27,680 give you for development environment, right. 992 00:53:28,000 --> 00:53:32,960 But I think what really helps is to have clarity on the different 993 00:53:33,080 --> 00:53:35,880 parts. So I think observability and 994 00:53:35,880 --> 00:53:39,520 monitoring is often overlooked in these kind of platforms. 995 00:53:39,520 --> 00:53:43,280 And those are areas where having some commonality is extremely 996 00:53:43,280 --> 00:53:45,760 helpful because if something goes wrong, I don't want to look 997 00:53:45,760 --> 00:53:49,440 like 12 different places to find out what's actually happening. 998 00:53:49,640 --> 00:53:53,520 So I would say for teams to build these internal developer 999 00:53:53,520 --> 00:53:55,040 platforms. So there are two parts of 1000 00:53:55,040 --> 00:53:56,920 advice, a look at the whole picture. 1001 00:53:57,240 --> 00:53:59,480 Too many folks like, oh, platform equals Kubernetes, 1002 00:53:59,480 --> 00:54:00,720 right? And they always talk about the 1003 00:54:00,720 --> 00:54:02,120 runtime. Well, that's nice, it's all 1004 00:54:02,120 --> 00:54:03,640 great. But you're forgetting all the 1005 00:54:03,640 --> 00:54:06,120 other pieces. Or people think only CICD 1006 00:54:06,160 --> 00:54:09,160 pipeline and forget the other. So see the whole picture. 1007 00:54:09,600 --> 00:54:13,640 And 2nd, think carefully about how you're going to build this 1008 00:54:13,640 --> 00:54:16,640 over time. Are you going to make a sort of 1009 00:54:16,640 --> 00:54:19,920 minimal viable platform and another kind of buzzword? 1010 00:54:19,920 --> 00:54:23,800 But are you making something minimally viable for all pieces? 1011 00:54:24,080 --> 00:54:28,520 And then you enhance or you do make a really, really good CICD 1012 00:54:28,560 --> 00:54:31,680 part, which is like totally awesome, but you're lacking all 1013 00:54:31,680 --> 00:54:35,200 the other pieces, right? And both have ups and downs, 1014 00:54:35,200 --> 00:54:36,480 right? Like if you're four half 1015 00:54:36,480 --> 00:54:40,360 finished pieces, maybe it's very cohesive, but it's maybe not 1016 00:54:40,360 --> 00:54:42,440 that feature rich versus the opposite. 1017 00:54:42,440 --> 00:54:44,520 It's very feature rich, but it's incomplete. 1018 00:54:44,880 --> 00:54:49,520 So there is no easy answer. And the forward of my book has a 1019 00:54:49,560 --> 00:54:52,480 warning label like literally. Like it's not all like when you 1020 00:54:52,480 --> 00:54:55,000 buy an appliance and it says, you know, don't touch the wire. 1021 00:54:55,000 --> 00:54:57,200 So it has like a warning safety label. 1022 00:54:57,400 --> 00:55:01,920 And my safety label is the book doesn't give you answers, right. 1023 00:55:01,920 --> 00:55:04,400 There's no easy answer. One way or the other way is 1024 00:55:04,400 --> 00:55:06,840 better. The book is trying to help you 1025 00:55:06,840 --> 00:55:10,960 ask better questions and come to better answers yourself. 1026 00:55:11,240 --> 00:55:14,520 And that's the same true here. Both of those are viable routes 1027 00:55:14,920 --> 00:55:18,800 and I want to help you be aware of that decision and make that 1028 00:55:18,800 --> 00:55:21,600 decision consciously and give you some guidance. 1029 00:55:21,600 --> 00:55:25,160 But in the end I cannot tell you which one is better for your 1030 00:55:25,440 --> 00:55:29,360 situation. So there isn't a magic scorch 1031 00:55:29,360 --> 00:55:33,240 chart or recipe for these developer platform teams to be 1032 00:55:33,240 --> 00:55:36,800 successful, but it's more. It would sound a little bit 1033 00:55:36,800 --> 00:55:39,680 funny, but it's more around seeing the whole picture. 1034 00:55:39,680 --> 00:55:43,320 Decision discipline. It sounds like very fluffy in a 1035 00:55:43,320 --> 00:55:46,840 way, but that is by far the hardest part and by far the most 1036 00:55:46,840 --> 00:55:48,720 important part. Right. 1037 00:55:48,720 --> 00:55:51,720 Apart from developer platform, actually some companies also 1038 00:55:51,720 --> 00:55:54,040 think about business capability platform, right. 1039 00:55:54,040 --> 00:55:56,640 Things like for example, if you want to reuse some parts of the 1040 00:55:56,920 --> 00:55:59,400 solution in the company, right? They want to create a platform 1041 00:55:59,400 --> 00:56:02,040 so that other departments or other teams can also reuse that. 1042 00:56:02,440 --> 00:56:04,640 Do you also have some advice for people who are building this 1043 00:56:04,640 --> 00:56:07,760 kind of a business capability platform so that they avoid that 1044 00:56:07,760 --> 00:56:11,040 kind of a loophole or pitfall that people normally go into? 1045 00:56:12,080 --> 00:56:13,440 Yeah. And this is actually one of the 1046 00:56:13,440 --> 00:56:16,720 frameworks early in the book for delineating in a more fine 1047 00:56:16,720 --> 00:56:19,640 grained way. The different kind of platforms 1048 00:56:19,640 --> 00:56:23,280 is like in house, people often have technical platforms like 1049 00:56:23,280 --> 00:56:25,280 the stuff we just talked about, which is for running 1050 00:56:25,280 --> 00:56:27,080 applications and building applications. 1051 00:56:27,360 --> 00:56:29,480 And then they often have business platforms and often 1052 00:56:29,480 --> 00:56:32,520 they have ecosystem like platforms that connect with 1053 00:56:32,560 --> 00:56:34,880 other things. So this is very real and it's 1054 00:56:35,160 --> 00:56:36,720 useful. Absolutely. 1055 00:56:37,080 --> 00:56:40,520 Again, you know there is more failure modes than one might 1056 00:56:40,520 --> 00:56:42,920 think about. And here's the catch that I see 1057 00:56:43,040 --> 00:56:48,640 the business platforms, they're stuck in the model of I can 1058 00:56:48,640 --> 00:56:52,760 anticipate what everybody needs. And we said right in the 1059 00:56:52,760 --> 00:56:56,200 beginning that is dangerous and not exactly what platforms are 1060 00:56:56,200 --> 00:56:58,240 about. The picture they tend to use and 1061 00:56:58,240 --> 00:57:00,960 the architect elevator actually already makes fun of that 1062 00:57:00,960 --> 00:57:02,960 picture is the picture of a pyramid, right. 1063 00:57:02,960 --> 00:57:05,360 They say like, oh, I have all this common business 1064 00:57:05,360 --> 00:57:08,760 functionality like accounting, HR systems, right. 1065 00:57:08,960 --> 00:57:12,160 Whatever I might need that is for all my lines of business and 1066 00:57:12,160 --> 00:57:14,440 all my countries. Then I have some other things 1067 00:57:14,440 --> 00:57:17,400 that might be country specific. And then I have something like 1068 00:57:17,400 --> 00:57:20,200 the little cherry on the cake, maybe a few configuration 1069 00:57:20,200 --> 00:57:23,720 settings that just, you know, make the specific market or 1070 00:57:23,720 --> 00:57:26,040 product right. It's always that vision. 1071 00:57:26,320 --> 00:57:29,760 And on PowerPoint that vision looks amazingly good because 1072 00:57:29,960 --> 00:57:33,760 it's massive amount of reuse. And then each solution just has 1073 00:57:33,760 --> 00:57:37,120 to like put the little tiny token on top and then everything 1074 00:57:37,120 --> 00:57:39,640 is perfect. In reality, this never works and 1075 00:57:39,640 --> 00:57:42,800 it's not a platform. It's again the antithesis of a 1076 00:57:42,800 --> 00:57:47,400 platform because the platform is not trying to anticipate 1077 00:57:47,400 --> 00:57:50,560 everything and it's trying to enable people to build better 1078 00:57:50,560 --> 00:57:54,520 solutions. These business efforts, they do 1079 00:57:54,520 --> 00:57:56,400 the exact opposite. They're trying to figure out 1080 00:57:56,400 --> 00:57:58,560 what could everybody possibly need. 1081 00:57:58,800 --> 00:58:02,360 I build this in and then people just need to sort of fill in the 1082 00:58:02,360 --> 00:58:05,080 little blank. If they were right, this 1083 00:58:05,080 --> 00:58:08,520 wouldn't be so bad. But in reality, it's impossible 1084 00:58:08,520 --> 00:58:12,160 to be right on all these things because needs are changing. 1085 00:58:12,160 --> 00:58:14,440 You just cannot possibly be so smart. 1086 00:58:14,520 --> 00:58:18,920 So my worry there again would be is that the teams who now go on 1087 00:58:18,920 --> 00:58:22,920 the platform bandwagon have the same teams who did that before, 1088 00:58:22,920 --> 00:58:26,120 who built the pyramids. And my joke is always we stopped 1089 00:58:26,120 --> 00:58:29,400 building pyramids 4000 years ago for good reasons, right? 1090 00:58:29,760 --> 00:58:32,800 So let's not do this again. But it's the same story as with 1091 00:58:32,800 --> 00:58:35,480 the developer platforms. If you have the same teams with 1092 00:58:35,480 --> 00:58:40,560 the same mindset trying the new approach, the odds that they 1093 00:58:40,560 --> 00:58:46,360 fall back into the old pattern is extremely high and that will 1094 00:58:46,360 --> 00:58:51,320 void the whole latform model. And then things get worse that 1095 00:58:51,320 --> 00:58:54,320 management will see, oh, this platform stuff actually doesn't 1096 00:58:54,320 --> 00:58:55,880 work right. We failed at it. 1097 00:58:56,000 --> 00:58:58,400 Who told me that all these platform thingies, right. 1098 00:58:58,640 --> 00:59:00,520 And then they hire the consultants for a lot of money 1099 00:59:00,520 --> 00:59:04,720 to go fix it and the whole thing goes into some sort of tailspin. 1100 00:59:04,720 --> 00:59:09,080 So yes, business platforms very useful, but really you need to 1101 00:59:09,080 --> 00:59:12,400 rethink the way you go about making those. 1102 00:59:12,440 --> 00:59:14,680 Same as with the developer platforms. 1103 00:59:15,400 --> 00:59:17,200 Right. I think there are a lot of lots 1104 00:59:17,200 --> 00:59:19,600 of learnings in this conversation about platforms, 1105 00:59:19,600 --> 00:59:21,480 right. So I hope the listeners here 1106 00:59:21,480 --> 00:59:25,160 after you heard about this from Gregor, right, you rethink again 1107 00:59:25,160 --> 00:59:28,360 like the strategy for your platform or if you are actually 1108 00:59:28,360 --> 00:59:30,800 building the platform right, maybe you should label it 1109 00:59:30,800 --> 00:59:33,360 something else. So it's been a pleasure Gregor. 1110 00:59:33,360 --> 00:59:36,240 Unfortunately due to time we need to wrap up pretty soon. 1111 00:59:36,320 --> 00:59:38,840 But I have the same question that I asked you in the first 1112 00:59:38,840 --> 00:59:41,400 episode, which is I call the three technical leadership 1113 00:59:41,400 --> 00:59:43,240 wisdom. You can think of it just like an 1114 00:59:43,240 --> 00:59:45,400 advice that you want to give to the listeners here. 1115 00:59:45,480 --> 00:59:48,200 It could be related to the platform strategy or it could be 1116 00:59:48,200 --> 00:59:51,880 something else as well. Yeah, and one would hope that 1117 00:59:51,880 --> 00:59:55,320 over the years I get wiser, so there should be more wisdoms. 1118 00:59:55,640 --> 00:59:59,200 At the same time, I think my own bar also goes up. 1119 00:59:59,200 --> 01:00:03,800 So let me see what is high on my mind after working on this book. 1120 01:00:04,480 --> 01:00:07,600 I think one wisdom I've definitely run into a lot is 1121 01:00:07,600 --> 01:00:12,320 that bad architects talking extremes and good architects 1122 01:00:12,320 --> 01:00:15,560 talking trade-offs. It's really ever the case that 1123 01:00:15,560 --> 01:00:19,280 one thing is the right solution for everything and especially 1124 01:00:19,280 --> 01:00:23,400 not a technology architecture. So my wisdom is don't get 1125 01:00:23,400 --> 01:00:27,120 latched onto everything must be even driven or loosely coupled, 1126 01:00:27,120 --> 01:00:30,320 or Kubernetes or this cloud vendor or that cloud vendor, 1127 01:00:30,600 --> 01:00:33,160 right? That is really the right answer. 1128 01:00:33,680 --> 01:00:40,000 The other wisdom that I might give is that organizations tend 1129 01:00:40,000 --> 01:00:44,680 to reward specialists, right? Like if you're really good at 1130 01:00:44,680 --> 01:00:48,920 something, it's very easy to put you in a certain box and you 1131 01:00:48,920 --> 01:00:51,880 will do very well. I have friends who do database 1132 01:00:51,880 --> 01:00:55,560 tuning and they charge crazy amounts of money because they 1133 01:00:55,560 --> 01:00:57,560 are really good at this. Somebody's database doesn't 1134 01:00:57,560 --> 01:00:59,080 work. The customer's not happy. 1135 01:00:59,320 --> 01:01:02,200 They go in for like a day and charge some crazy amount of 1136 01:01:02,200 --> 01:01:04,960 money, but the customer's happy because now everything is 1137 01:01:04,960 --> 01:01:07,760 working. So it's very tempting to go this 1138 01:01:07,760 --> 01:01:11,560 route. But what I find is that the kind 1139 01:01:11,560 --> 01:01:16,320 of solutions that we build also consider being a dot connector, 1140 01:01:16,320 --> 01:01:18,000 right? We just talked earlier about, 1141 01:01:18,040 --> 01:01:20,960 oh, building this platform is highly technical, it's cloud 1142 01:01:20,960 --> 01:01:24,320 stuff, it's queues and time to live in distributed systems, but 1143 01:01:24,320 --> 01:01:27,000 it's also domain driven design, very much so. 1144 01:01:27,320 --> 01:01:32,320 So my second advice would be look over the horizon and see 1145 01:01:32,320 --> 01:01:36,400 whether you can piece different things together because I think 1146 01:01:36,400 --> 01:01:40,760 in today's world that might be as important as being a 1147 01:01:40,960 --> 01:01:46,320 specialist in some area. And my last advice that I often 1148 01:01:46,320 --> 01:01:51,360 give is thinking is the highest ROI activity you can possibly 1149 01:01:51,360 --> 01:01:53,360 do. I see too many people who say, 1150 01:01:53,360 --> 01:01:55,640 oh, we need to make a decision, oh, let's ask for expert, let's 1151 01:01:55,640 --> 01:01:57,320 get an answer, let's move forward. 1152 01:01:57,600 --> 01:02:01,040 And when you say, oh, let's think about this like we did 1153 01:02:01,040 --> 01:02:04,920 earlier, like, oh, well, the Q versus SQS versus the Ledger 1154 01:02:04,920 --> 01:02:08,280 database, right? Like we're sort of musing and 1155 01:02:08,280 --> 01:02:10,640 reflecting and it's a little bit abstract. 1156 01:02:10,960 --> 01:02:14,720 It's too easy for people to put that away as like, Oh no, we're 1157 01:02:14,720 --> 01:02:17,080 not in school here, we don't need to philosophize, we need to 1158 01:02:17,080 --> 01:02:20,000 go make a decision and I think that's short sighted. 1159 01:02:20,000 --> 01:02:24,080 So my third advice would be take time to think. 1160 01:02:24,080 --> 01:02:27,360 Play around a little bit with metaphors and words and 1161 01:02:27,360 --> 01:02:31,720 different things, because that time is extremely well spent and 1162 01:02:31,720 --> 01:02:34,400 will pay off many many times over. 1163 01:02:35,360 --> 01:02:37,640 Wow, really beautiful. I think these are all different 1164 01:02:37,640 --> 01:02:40,080 from the first episodes you gave, so I think that's really, 1165 01:02:40,080 --> 01:02:43,240 really cool advice. So Gregor, for people who love 1166 01:02:43,240 --> 01:02:46,400 to read the book, is there a place where they can find online 1167 01:02:46,400 --> 01:02:48,240 how they can reach out to you and things like that? 1168 01:02:48,960 --> 01:02:51,520 Yeah, so I'm fairly active on social media. 1169 01:02:51,520 --> 01:02:55,640 So LinkedIn is always good and some of my home base for all 1170 01:02:55,640 --> 01:02:57,240 these things. As I mentioned the very 1171 01:02:57,240 --> 01:03:01,160 beginning, all these books are essentially applications of the 1172 01:03:01,160 --> 01:03:05,640 architect elevator concept. So Architect elevator.com is 1173 01:03:05,640 --> 01:03:09,520 still the best starting point for the different books and my 1174 01:03:09,520 --> 01:03:12,400 blog and everything else. So I'm always happy for folks to 1175 01:03:12,400 --> 01:03:14,840 start from there. Thank you again for your time 1176 01:03:14,840 --> 01:03:17,120 for this second episode. So I look forward for more 1177 01:03:17,120 --> 01:03:20,000 strategy books from you. And thanks again for explaining 1178 01:03:20,000 --> 01:03:22,720 about Platform today. Yeah, I'll, I'll do my best. 1179 01:03:22,800 --> 01:03:24,640 Yeah. I look ahead for the next, the 1180 01:03:24,640 --> 01:03:26,920 next episode when the next book is done. 1181 01:03:26,920 --> 01:03:31,800 Always a pleasure. Thank you for listening to this 1182 01:03:31,800 --> 01:03:34,200 episode and for staying right until the end. 1183 01:03:34,560 --> 01:03:37,720 If you highly enjoyed it, I would appreciate if you share it 1184 01:03:37,720 --> 01:03:40,720 with your friends and colleagues who you think would also benefit 1185 01:03:40,720 --> 01:03:43,520 from listening to this episode. And if you're new to the 1186 01:03:43,520 --> 01:03:46,520 podcast, make sure to subscribe and leave me your valuable 1187 01:03:46,520 --> 01:03:49,480 review and feedback. It helps me a lot in order to 1188 01:03:49,480 --> 01:03:52,800 grow this podcast better. You can also find the full show 1189 01:03:52,800 --> 01:03:55,640 notes of this conversation on the episode page at 1190 01:03:55,640 --> 01:03:59,120 techlitjournal dot dev website, including the full transcript, 1191 01:03:59,360 --> 01:04:03,000 interesting quotes, and links to the resources mentioned from the 1192 01:04:03,000 --> 01:04:05,840 conversation. And lastly, make sure to 1193 01:04:05,840 --> 01:04:08,840 subscribe to the show's mailing list on techlitjournal dot dev 1194 01:04:09,200 --> 01:04:11,640 to get notified for any future episodes. 1195 01:04:12,240 --> 01:04:15,760 Stay tuned for the next Techly Journal episode, and until then, 1196 01:04:15,960 --> 01:04:16,480 goodbye.