This text is transcribed using artificial intelligence. Errors may occur.

00:00 --> 00:33

[MUSIC PLAYING] Hi, and welcome to this special episode of the Platform Pod. As you have probably noticed, this episode is in English, and that is because we have a very special guest today. Gregor Hoppe, author and speaker, now working for AWS, but he has also worked for Google and Alliance. Welcome, and nice to have you here. Thank you. The first time I came across Gregor Hoppe

00:33 --> 01:00

was when I read the Enterprise Integration Patterns book when I started working in 2004. I quoted that book many times since then, both the messaging patterns, but most frequently the chapters about different integration techniques. I still ask why whenever I see someone trying to integrate with a shared database. I can also vividly remember the article on transactions in Starbucks and the fact that they don't use two-phase commits when they serve coffee.

01:00 --> 01:23

And since then, I've talked a lot about writing the architect elevator after reading that book. And when we at Nav made our new cloud strategy, the cloud strategy was a really important part of that and the thing that all the members of the team read before we made our strategy. And now we are writing a book about platforms, which I have spent a lot of the last nine years building and thinking about.

01:23 --> 01:46

So it's fair to say that your books and articles have shaped my career a lot. So it's a great honor to have you as a guest on this podcast. So to start this off, you have two earlier books where you talk about how to be an architect in the modern world and how to navigate the cloud. What was the thinking behind making platforms the third topic? Thank you for the introduction and thank you for having me on the show.

01:46 --> 02:15

I now feel like we've been knowing each other for 20 years, going through the list of all the books. So thank you for that. Yes, so I'm writing a book on platform strategy, which is available in early access. And you're asking, so I wrote The Elevator, which kind of teaches you how to think like an architect. Then we talked about cloud strategy and how come platform strategy is the second one in the series.

02:15 --> 02:44

There's sort of a joking answer and-- well, that's actually probably the real answer and a more technical answer. So the honest answer is that writing books is tough. So what helps me is when I write one book, I generally have a procrastination project. So if I really don't want to work on that book, I collect ideas for another book. So even though I'm procrastinating, I'm still making progress.

02:44 --> 03:11

So it's a special technique of getting things done while not getting things done. So while writing cloud strategy, platform strategy was that very procrastination project. Now, that means that the scope of the book wasn't terribly well-defined, but it relates to experience at Allianz, where we started-- when we started with the cloud, we actually started on premises.

03:11 --> 03:36

We started building internal platforms originally because financial services at the time, public cloud wasn't as easy to get approvals for. So we started in-house. So there were many things we did around platforms, but they couldn't be in the cloud strategy book because that was meant to be for commercial cloud. So I had a little bit of mental backlog and the desire for procrastination. And then you put those two together,

03:36 --> 04:09

and there was the genesis of platform strategy. And I've read the early editions of the book, and you have multiple types of platforms. Can you talk a bit about the different platforms as a start that you define? Yeah, and as you hinted, I'm writing the book iteratively. That's one thing I like to do. And with e-books, that works very well. Every once in a while, people ask me, oh, so when is it done? And well, the point isn't waiting for it

04:09 --> 04:46

to be done because you can start reading right now and have a head start versus everyone else. So I always tell people, start as early as you can, and then I will tell you what changed, et cetera. The book sort of tries to go a little bit top to bottom, starting by the different kind of platforms that we see because platform is one of these words that means many things to many different people. So one is, of course, the e-commerce platforms we see. It's like the Amazons and Ubers and Airbnbs

04:46 --> 05:20

are like the platform business models, also referred to as multi-sided markets, buyers and sellers, and some organization that facilitates the transactions. And that's an enormously successful business model, and there are quite a few books about how to do that. So we cover that in my book, but only briefly because I think there's a lot that's been said. So we just do this more for context. The platforms that we are more interested in in this book are developer platforms.

05:20 --> 05:46

Right now, most people call them like IDPs, internal developer platforms, productivity platforms, those kind of titles. And many, many organizations are building those, and that's the real focus. Now, they're quite different. One is more like a business model, and the other one is something that your IT teams do internally to support your development teams. Underneath all this sits another set of platforms,

05:46 --> 06:14

and those are the cloud platforms. But I've written a whole book about that, so we don't need to repeat that in platform strategy. And lastly, a thing that I'm still thinking about are business platforms. So they would be internal to your organization, but rather than enabling your development teams, they would have business capabilities. Like if an insurance company, you could have like a core insurance system,

06:14 --> 06:41

and can that be also a kind of platform without being maybe too generous with a name? Right, so that would be a fourth category. But the book is largely about the developer platforms, which seems to be a pretty hot trend these days. So I feel that's a good scope for the book. (laughing) - Yeah, definitely a trend these days. And I was thinking about what you think about the platform engineering term

06:41 --> 07:06

as it sort of has been hyped in various mediums. - Yeah, I mean, in one hand, it's good for me because having a book on platform strategy definitely benefits from that. The dilution of the term has made it also much harder to write the book, right? In the end, I could have written four books, right? Like one about the business models, one about developer platforms, one about cloud platforms,

07:06 --> 07:40

and maybe one about business platforms, right? So it was not easy for me to scope this properly because there's so much misunderstanding. On the upshot, it's good that we have the term because at least it allows the people to find each other who are interested in this topic. So I wouldn't think so much about whether the term itself or the semantics of the term are great. For me, it's more like a unique identifier that the people can use to find each other

07:40 --> 08:06

by being interested. And then having one term that sticks like platform engineering or IDP perhaps, right? That helps because we can find each other. - So at now where me and Anil Sisan work, the platform team or the platform basically has been a tool to achieve many different things. It's been a part of our digitalization effort and it's kind of been a driver there. But it's also been a driver for us

08:06 --> 08:38

going from on-prem to the cloud and basically also helping us to use more open source technology. What do you find are the most important things people want to achieve with such an internal platform? - Yeah, let me start with a positive and a negative example. And this is what makes the topic interesting in the end. None of these platforms happen in a vacuum, right? Before we had platforms, we had IT service teams, infrastructure teams, operation teams, right?

08:38 --> 09:12

We have been having teams that help application teams for a long time, probably since the very beginning. It used to be the folks who rack and stack the servers in the very early days. So it's important to keep that context in mind. What's very different between the platform and the previous teams is that the previous teams were mostly interested in efficiency, economies of scale, and sort of division of labor, if you wish, right? If you have one place who buys servers

09:12 --> 09:34

and they install all the servers, that will be much more efficient than every development team and going doing that for themselves, because you have economies of scale. You do bulk orders, you need fewer people to do that. So it's very common for us when we have shared teams like this to think that efficiency is the main driver, right? Let's do it once, let's do it right,

09:34 --> 10:00

let's be efficient about it. Now for platforms, right? Meaning in the sense of developer platforms, which we just talked about, the main driver shouldn't be overall efficiency, it should be speed, right? It should be about enabling development teams to move faster. Now, in a way, moving faster is also kind of more efficient because you get more done,

10:00 --> 10:30

but it's sort of rather about productivity than about cost. Like when we talk about efficiency, we always think of we spend less unit costs, right? Like make it cheaper. But when I talk about development teams, maybe productivity is a better word. So it's really a productivity enhancer as opposed to a pure cost reducer. And I think that's an important distinction to make. - And our experience is also actually that you can,

10:30 --> 10:58

we, especially in the start, when we had, now we've had loads of legacy. So we have mainframes and stuff that's even worse than mainframes sometimes. But we wanted to use our platform to shape the architecture. And going back to the chapter about integration techniques, our platform makes it really easy to have one database per application and quite difficult to have two applications talking to the same database.

10:58 --> 11:25

And yeah. (laughs) And have you seen that pattern a lot that people try to make use the platform to make sure that people write better applications? - Yeah, so one of the amazing things or good things about platforms is that you can achieve more than one thing, right? You can make development teams more efficient, which ultimately will also reduce cost. You can standardize your architectures, right?

11:25 --> 11:53

Like you're referring to, like maybe we don't like shared databases all that much, right, we like message-oriented integration. You could also have compliance, right? Let's say you go into the cloud, your platform might prefer you to be in a certain region and not in other regions, especially if you have financial services or public sector. So there's many different things that you can get and often you can even get them in combination.

11:53 --> 12:22

The risky part is that I see too many platforms who promise one thing to some teams, but then promise something else to other teams and not delivering what they promised. And I actually have a cartoon in the book. I'm not a great artist, but I think the cartoon tells the story where the development teams are basically promised the super highway of software delivery, right? It's the golden path, the paved road, right?

12:22 --> 12:49

Basically no speed limit, you move as fast as possible, right? And it's all about what the road looks like. The road looks good, it's paved, it's smooth, it's like a German Autobahn, right? Like you just go. Now, another team has been promised that we will have enormous guardrails, right? So that nobody gets off this paved path. And where things get difficult is in the end,

12:49 --> 13:10

well, how much money do you spend on the pavement versus how much money do you spend on the guardrails? And my little cartoon is basically what the development team thought they're getting is the German Autobahn, right? Great pavement and yeah, a little bit guardrails, but just for real emergencies. But what they really got is a mud path, but with giant guardrails left and right. So it looks more like a cattle,

13:10 --> 13:38

like where you drive the cattle down the road because you don't want them to go left or right. And then you have a problem because what you promised is not what you delivered. So it's a delicate affair to actually balance these multiple goals to have a really good platform. - And I also find that when you try to get the teams to adopt such a platform, it's good to be clear about their autonomy.

13:38 --> 13:58

So you have this Autobahn, you can drive there if you want to. It's a really easy drive there, but you can do whatever you want. And then even though it's not an actual choice, most or even all the teams use that the paved road or the golden path. But the fact that you say it's your choice makes it easier to get adoption. - Yeah, and I have a chapter in there

13:58 --> 14:23

about characteristics of platforms. Like how do you know, 'cause it's a popular term. So we call everything a platform. We're probably running this on a podcast platform right now, right? Like everything is a platform left, right and center. So what I like to do is have a checklist to say like, "Hey, can I give you some hint whether the thing you're making here qualifies as a platform versus a traditional IT service?"

14:23 --> 14:45

Because I just mentioned that slippery slope, right? We often have existing teams who are helping developers, but in different ways. And isn't it convenient to just rename that team to be the platform team? And that of course doesn't work. Renaming rarely leads to great results. So I have this checklist. Yeah, still we do it all the time, right? So I have this checklist

14:45 --> 15:19

and one item on the checklist is quite interesting. One item is about mandatory versus voluntary. And the traditional IT services are generally mandatory. You cannot get your own server and put it in your data center. You have to use the IT service that does that. Now for a platform, I softened a tiny bit. I stated that I much prefer to be voluntary. At the same time, I recognize that in some organizations in order to get started, you might need a little nudge,

15:19 --> 15:43

right? You might need a little push or something to get a few teams on board. And you can maybe do that through great marketing, maybe through financial incentives, right? So I wanted to leave open the possibilities that sometimes in the near term, I don't like the word mandating, but strongly suggesting to people to use this platform can be helpful.

15:43 --> 16:06

There is a corollary to this. So that's another chapter in the book, which is quite curious. And that is why do developers love opinionated frameworks, which are obviously constraining, right? But they hate constraining platforms that the platform team made, right? Say, "Oh, your platform doesn't let me do this. And it doesn't let me do that." But then they love things like Rails

16:06 --> 16:29

and all the other frameworks, which also prescribe many things. And part of the answer is that if you choose to agree with somebody else's opinion, then you don't feel as constrained. You actually feel kind of cool because, "Hey, I got the same opinion as DHH, right? I'm using Rails, right? So this must be good." Versus the infrastructure team tells you

16:29 --> 17:00

what your opinion should be. The initial reaction is going to be like, "Oh, but it doesn't do whatever X, Y, Z I can come up with." So making it voluntary has a great advantage that folks will much more likely to agree with the opinions that you baked into the platform. - At least initially, we used to give all the teams that adopted the platform cake. - Library, yeah, it works. - Yeah, we basically exchanged the question,

17:00 --> 17:23

"Do I really want to rewrite this big WebSphere application into Docker and making it stateless and making it good in terms of possibility?" With the question, "Do I want cake?" And most people want cake, turns out, except a few strange people that don't like it. And that helped. And then you kind of got a start, and then you had enough feedback to make a better platform, and then it was the easy choice after a while.

17:23 --> 17:48

And then the cake budget also went down. - Nice, yeah, so that's the initial nudge, right? It comes, I guess that falls under financial incentives, I call it, or bribes in a good way. We don't like to use that term in public sector financial, but yeah, you give some incentives, at least for people to show up to the brown bag, to have a dialogue with you, right? You need a little bit of escape velocity, right? You need something to get going.

17:48 --> 18:13

Platforms thrive on scale. You cannot build a platform for one customer. And that is true for in-house platforms as well as for the multi-sided marketplaces, right? They all need a certain scale. So having a little incentive or a little nudge to get that initial scale, I think is totally fine. And it's realistic. You need to get a little jumpstart for this. - But how do we ensure that the platforms are built

18:13 --> 18:42

sort of to cater to the actual developers, the teams and applications that in my organization, because too often I've seen sort of platform teams or cloud enablement teams or cloud migration team, they go off and 12, 24 months even, they are off to their sort of building their landing zones and sort of like, I don't think they called it platform back then, and then it was totally different than what the developers envisioned.

18:42 --> 19:04

So how do we ensure that the platforms are built to cater to the teams? - Yeah, platforms are products, right? They're generally internal products for the development teams, but they're clearly products, right? And yeah, every once in a while, you can sit in your secret chamber for like 24 months and make a product in the end that everybody will love. Maybe Apple can do that,

19:04 --> 19:25

but probably your platform team is not Apple. Let's be honest, right? So that's for the lucky few, right? Most other people who make a product will advise to speak to the customers early on. Now, it's not as easy. So that's the easy advice, right? It's a product, you should have feedback. You should grow it based on the feedback. The reality though is what your customers tell you

19:25 --> 19:49

is not always what matches your roadmap or your vision for the platform, right? And that's where it gets interesting. So what I suggest that helps there is to have a clear view on the characteristics of the platform. So, and to be cool, we talked about being cool earlier. So we try to be cool. So we make them all start with C, like all the characteristics start with C.

19:49 --> 20:17

But so let's say a customer has a feature request, right? Where they say, "Hey, this would be really useful." And that might make the platform more complete. So this is one of the Cs, right? Like it's adding something that is useful and meaningful. But another C is cohesiveness, right? And sort of basically how well integrated are the different pieces. So if you add random stuff based on what the customers tell you,

20:17 --> 20:43

you might have a collection of things, but they don't integrate very well. So it's not very cohesive. And that's an equally important quality of a platform because a platform should be one thing, not 20 little things. So having this vocabulary can help you a little bit in these conversations, because if you go to the customer and say, "Yeah, I hear you, right?

20:43 --> 21:07

I find this also useful, what you're suggesting, but it doesn't fit my roadmap." They will be a little bit angry, right? They're like, "Oh, why don't you do that?" Right, so easy to do. Versus if you have a clear list of characteristics and a vocabulary behind it, and you can explain your trade-offs and your decisions, with a little luck, there'll be more understanding. So growing a platform is delicate, right?

21:07 --> 21:39

You want to learn from your users, but the users don't bring you ready-written requirements. Right, the users are not your business analysts, they're not your product managers, right? They give you input, they give you ideas, but then based on that input, you need to form a product strategy, a product roadmap. You still have a lot of work to do to translate the input from the users. And that's sometimes forgotten, maybe well-intentioned,

21:39 --> 22:05

right, we say, and I work for AWS, we're customer obsessed. It's very easy to say, "Oh, if I'm obsessed with the customers, I should do exactly what they tell me." But that is actually not how it works. It means listening to your customers and keeping them in mind, but they are not delivering you the requirements document. - And also, I think that's one of the main reasons you want your platform to be a paved road, but you shouldn't have too hard restrictions.

22:05 --> 22:28

So people should be able to go outside the platforms to use the special cloud products they need to, but that the whole company don't need to use, so you don't need to make it a part of the platform. You just make it possible for one or two teams to use that product they need. And then you can, then it's easy to say no to those teams as well. - Correct, and I call this, the platform has gentle slopes at the sides, right?

22:28 --> 22:49

If you're on top of the platform, of course, life should be very good, but what if I kind of step one foot off, right? I need something slightly different. Most traditional platforms, you drop like basically down to zero. You fell very deep. There was basically nothing we can do for you anymore. And that's not good, right? Because then the value proposition is binary.

22:49 --> 23:16

And as computer science people, we love binary things, but not when it comes to value propositions, right? It shouldn't be on or off. So having gentle slopes allows folks to go slightly outside of the platform, but still benefit. So for example, that has a lot to do with cohesiveness and granularity. So maybe they need a different thing for X, Y, Z, let's just make it up. And they might still get the CI/CD pipeline

23:16 --> 23:37

from your platform. They might still get the monitoring observability framework from your platform, right? So they don't fall all the way to zero. They might still get the automation, the templates. We talked about Kubernetes earlier, right? Maybe they make a custom resource descriptor, right? So that they can have something different, but they still get to use all the other CRDs and the other things.

23:37 --> 24:04

So I encourage platform teams to think about the shape of their platform. So how much leeway is on top, if you wish, and then sort of how gentle are the slopes and making the slopes a little bit gentle is a nice thing to do. And it makes those conversations you mentioned a lot, a lot easier also. - And when the teams goes a little bit outside the platform, then the platform team can sort of learn

24:04 --> 24:26

from their experience and also generalize sort of platform solutions for problems that they see manifest in different teams. Would that also be correct? - Yes, I like that. And when we built a developer platform for the government of Singapore, I worked for Singapore GovTech, right? That's where we, by that time, the thing had a name. So it was called Engineering Productivity Platform,

24:26 --> 24:49

Internal Developer Platform. That's exactly what we did. We basically split it into two pieces. We said, there is a certain baseline where we have a pretty good idea of what should be in there. We don't need to sit here and think about, oh, do people need continuous integration? Oh, do they need monitoring? Do they need integration? We're not starting from zero.

24:49 --> 25:12

So there's a certain set of things where we can make good assumptions based on our own experience, because we used to be application teams or by having early chats. So it's legit to make a base where basically I call this the, I know better in a cheeky way. I kind of know, I have a good guess. I assume I know better, so I go and build that. Not for 24 months though, please.

25:12 --> 25:33

Right, so you build that. And then there's the other half of the platform where you know better, right? It's like sort of little nuances, right? Maybe things you want integrated with the CI pipeline. Maybe we have certain higher level constructs we like to use. Maybe, I don't like the word so much, but kind of reference architectures or higher level components,

25:33 --> 25:58

based on the business domain that we're in, right? If we are a financial company or public sector, as opposed to manufacturing, we probably have some different vocabulary and constructs, right? And that's where you definitely know better, you being the application team. So I think splitting it into two pieces is quite a good approach. The only warning I would give is that

25:58 --> 26:29

harvesting pieces from the teams sounds really good and paper is harder in reality. We all know this. This is like the reuse, the myth of reuse. Once somebody has written something, shouldn't everybody else use the same thing? And that never quite happens. And that is because we talked about cohesion earlier. It's very hard to get new pieces to be very cohesive, to be well integrated or make a meaningful whole

26:29 --> 26:56

with the stuff that is already there. What helps a little bit is if underneath your platform, you're all on a common cloud platform. So if somebody has built something, at least they use the same cloud services underneath, maybe the same IAM, maybe the same kind of logging, monitoring, compliance kind of tools, right? And that gives you a better start than if they have a completely different stack

26:56 --> 27:23

because your platform doesn't want to be in the business of operating 50 different stacks. So the two-part sandwich is a really good approach, but don't underestimate the challenges of integrating things into your platform. You need to plan for some effort there. - But it's an interesting question to ask someone that works for AWS is, why isn't AWS enough?

27:23 --> 27:47

Why do you need to build their own internal platform as well as what the cloud provider can offer? - Oh, at first I should say it's certainly enough. (both laughing) But you can always have more, right? It has like 200 and odd services, right? So definitely the platform is large, right? AWS is large. Maybe one side comment also, I talked earlier about platforms being a meaningful whole,

27:47 --> 28:13

right, not being a random collection of pieces. So AWS is a good example. There's sort of one AWS, right? It's like one cloud thing, right? We like to say, yeah, it has over 200 services in it, but really what we're selling is the sum of all these pieces and them being well integrated, right? There's IAM and CloudWatch and all the other things that go across all these, the console. So that is a nice example of, yes,

28:13 --> 28:36

that is a very good platform. So why would you need to do anything else? And again, there's a cheeky answer, the real answer. The cheeky answer is, oh, I need to boost my resume and I found budget somewhere. So of course I'm building a platform and you'll be shocked what percentage of platform initiatives really falls under that. Under that category, we don't like it, but it's the harsh reality.

28:36 --> 28:58

So be careful there. I call this the resume driven architecture, right? RDA. So we don't want to do that, right? Kubernetes used to be in that league, now it's platforms. Now Kubernetes has labeled itself as a platform, so everybody happy. So the resume is in good shape. The more real answer is, and I say it in a kind of a cheeky way, but it's a very real answer is,

28:58 --> 29:26

we at AWS, we have to build for the whole world, right? Like we need to serve pretty much all markets, all segments, all kind of companies, right? That's what's expected from us. And quite honestly, that is also the business model, right? If you're like a FinTech startup in Australia and somebody else is a manufacturing giant in the US, like you both should be using AWS and they both do very successfully, right? That's how it works.

29:26 --> 29:50

Now, because of that, you can make more assumptions than we can make, right? So we need to accommodate everybody that sort of limits how opinionated we can be. And occasionally that's a little bit of a sort of well-meaning criticism we get. They said, "Oh, you guys could be more opinionated, right? Why aren't you more opinionated? All these open source frameworks, they are more opinionated.

29:50 --> 30:11

Why is AWS so shy to do that?" And the answer is, well, if you serve such a broad base, right, you'd got to be careful with your opinions because if people don't agree with your opinions, then they can't use your platform. If it's an open source project, they go to the next open source project, right? Maybe if you don't like Rails, right, you pick something else, you pick Spring Boot or whatever it is, right?

30:11 --> 30:40

Like you're happy either way. With a large cloud platform, status is not quite as easy. So you can make more assumptions. You can integrate more tightly. You can find higher level abstractions, those kinds of things that we can do. And those are great ways to start a platform. - And that's probably a way to increase the speed of the application teams because then they don't have to make that many choices.

30:40 --> 31:10

- So done well, it does. So let me give you another, we always hear, like I try to always show the happy path and the unhappy path because I think that's really useful for listeners. So if you can make more assumptions, then that means you should offer your internal teams something more than just like a flavor of the AWS services. And this is where a lot of platforms fail. So let's say DynamoDB, I work on serverless.

31:10 --> 31:34

I always use DynamoDB as an example, right? Great serverless database, everybody else, like NoSQL database, we know well what it does. So some platforms teams go out and say, ah, DynamoDB is great, ah, but it's kind of serverless and has all these settings. And maybe my teams shouldn't use all the features, maybe cost control, right? So what they do is they make in their platform something called NoSQL database

31:34 --> 32:00

and it's DynamoDB with many settings missing. And what I'm saying is you haven't made the development teams life easier. You've actually made it harder, right? You're giving them a 70% DynamoDB now because you took some settings away and they're like, hold on, I can have a hundred percent DynamoDB from AWS, why am I getting a 70% from you? And you can immediately see that that is a hard sell.

32:00 --> 32:23

Like if you go another way around, and this is a real example from an insurance company I worked with, they have audit requirements, right? Like financial services, right? Every time you do something in the database, they need to audit. So they made a construct called ledger database, where it's two DynamoDB databases. The one is the operational database

32:23 --> 32:50

where you keep your current data set and then they have a change data capture to lock all the changes into another database, right? And they call this whole thing a ledger database. And that makes all the difference because now I've given you a higher level construct, which is specific to my domain. I could have also made a database that is called database with customer data, right? So now that will come with some constraints

32:50 --> 33:16

as everybody would understand locality and logging and access control, right? But I didn't call it 70% DynamoDB. I said, no, this thing has a special purpose. That is a database that is allowed to have customer data. You have another database that is not allowed to have customer data and maybe has more dials you can turn. So this translation is probably the most important step of making an in-house platform.

33:16 --> 33:42

It answers sort of both of your questions, right? It answers the question, why doesn't AWS do that? And the answer is very easy. Like we don't know what a ledger database looks like for you and we don't know what a database with customer data looks like for you. So you do that, but that also makes your teams more protective. They can start using a higher level vocabulary and they don't feel that they get the same 200 AWS services

33:42 --> 34:12

just with missing settings. But that is hard, right? Because you need to understand your domain really well. You need to sort of have a higher level of abstraction, but that in my mind is what a good platform looks like. - So earlier in this podcast, we did an episode with the capital of Norway, the Oslo municipality. And they had an interesting journey because they started with a centralized platform

34:12 --> 34:41

on top of AWS. And then they found that for various reasons, that made more frictions in some ways and that they rebooted their platform initiative where they have decentralized it and then more sort of caters toward providing projects to the different teams with sort of the correct organizational rule set and some supporting tools. Could you speak a little bit to,

34:41 --> 35:01

when we have listeners out there and it's not totally obvious to them if they should sort of make one platform or they should rather sort of, oh, let's divide up our competency, put them out to the teams and sort of make the teams the best they can possibly be. Do you have any advice into that matter? - Yeah, and it's a really great insight.

35:01 --> 35:27

And what you said first, right, very much relates to what I said, right? Like if you put it on top of an existing platform and you take some things away, don't be surprised if people aren't ecstatic about it. Basically, my cheeky way of giving this advice is, as a platform team, don't second guess AWS, right? We're pretty decent at this, right? So if you're second guessing what we are doing, ah, the odds are a little bit stacked against you, right?

35:27 --> 35:53

What you should be doing instead is like thinking about things that you can do because they're good for you, but they're not good for everybody. So that's why they're not in the basic platform. Now, how do you structure this, right? Like, do you make this into many small things or is this one big thing? So it comes a little bit to the monolith question, right? The monolith platform versus the microservices platform.

35:53 --> 36:20

So I would say it's healthy for a platform to have different components, right? To not be a monolith. And that happens naturally anyway, right? Many developer platforms have things that are part of the build cycle, right? CI/CD tools, code inspections, all these things, right? They happen at build and deploy time, and then they have other tools that are runtime, right? They might have Istio or communication services.

36:20 --> 36:44

They might have observability, right? So obviously these are not one thing because they happen at very different times in the life cycle. So I think that is a given that you have some modularity and then actually like that, right? You want to have independent pieces. Yet at the same time, the value proposition of the platform is that it's not just a loose collection.

36:44 --> 37:03

So it's a balancing act. What I try to do when I do this in a book, it's really hard to tell people, "Here's what you should do," right? Because it might work for me, right? This is like, "Hey, I bought a lottery ticket. I made a million dollars. So now you should be buying lottery tickets." Yeah, it might work. It may not.

37:03 --> 37:34

So I'm very cautious about this kind of advice because the world is full of it, right? So what I rather do is give people a metaphor to think about it or like a decision model so that you still come to your decision, but you have sort of a better way to make that decision. And in this case, the metaphor is about fruit baskets and fruit salads, right? So basically if my platform is just independent pieces, that is like a basket of fruit, right?

37:34 --> 37:57

And this is how many platforms start. I have a Jenkins over here, a Jira over there, maybe a to-do-do-do this, right? Like that's how it goes. And that is not bad, right? But a fruit salad, if you look at the price per weight, always fetches a higher price because a fruit salad brings more value 'cause the fruit is cut. It's easier to eat.

37:57 --> 38:17

You can mix and match, right? You can have watermelon in it, which in the basket is very tedious because it'd be very heavy, or jackfruit if you want to be worse. I'm in Asia, right? So you can have jackfruit and watermelon in your fruit salad, but in your fruit basket, it'd be very tedious. So I give teams these kind of metaphors so they don't give you the easy answer of like,

38:17 --> 38:46

here's exactly how you do this, but it allows you to think about finding the right balance. I had one customer where I shared this metaphor and one of their platform leads changed his name to a fruit salad maker. He said, "Oh, I make fruit salad," because his view was that the initial attempts they had made at platform were too much like fruit basket, like a loose collection of stuff, right? Basically, instead of running one install,

38:46 --> 39:10

instead of running five install scripts, you run one install script. That's kind of nice, but that doesn't make a whole platform. So he adopted of saying, "Yeah, I want to make fruit salad. "I want my things to be more integrated." In reality, what I think you will find, you will zigzag a little bit on that spectrum, right? You might have some initial ideas, like we said before, like the I know better layer,

39:10 --> 39:35

and that might be very cohesive and that might be very fruit salad-y, and then you harvest something, so you have new ideas, but they might still be a little bit separate. They might be more like fruit basket. And then over time, you look for opportunities to integrate them more. I think you'll find yourself adjusting basically all the time. - I think we're closing in on the end there,

39:35 --> 40:04

but one last question. How should the organizations organize their platform teams and how do a platform team differ from another software team, for instance, in how they organize? - Yeah, we said earlier that platforms are in-house products. So platform teams are very much structured like product teams. Now, where it gets a little bit tricky or you need to pay attention is that platform teams

40:04 --> 40:26

are sort of the lower layer of application teams. Like if we make a picture, we think the platform team sort of sits underneath the development teams. And we talked earlier about that traditionally teams that follow that patterns were absolutely not product teams, right? The people doing operations, the people racking and stacking servers or building landing zones, right?

40:26 --> 40:51

They're not product teams. They don't need to discover and iterate and market and all these kinds of things. So that's where I think the biggest disconnect is. If you really think about your platform as a small company, like a product company, I think that gives you a pretty good checklist. You will need marketing, you will need PR. PR might have the cakes, right? That was a PR function that you had.

40:51 --> 41:16

You need a product manager, you need a CTO, right? You need somebody who has a technology vision. You maybe need a CEO. You might even need an internal CTO. Somebody who really helps shape the product vision. And you might even have a field CTO, which is sort of more marketing oriented and runs around and tells everybody how great this thing is. Now, not each of these roles might be a separate person 'cause it'd be a huge platform team

41:16 --> 41:42

and we haven't even talked about engineers yet. So we have no budget left to build anything that won't be very good. So many people can wear, or a fewer set of people, smaller set of people can wear multiple hats. But I think sort of going down this list, right? If I was a small business, right? What are the things that I need? And I think that's a good starting point for a platform team. People often ask me how big should this be?

41:42 --> 42:04

Like, is there a ratio? Like I have a thousand developers. How big should my platform team be? How big should my architecture team be? I always struggle with this. I always say it depends so much on what your situation is. Like, let's start with the architecture one because I used to run a lot of architecture teams and actually my architecture team ended up building the platforms, right?

42:04 --> 42:25

So that was convenient. But let's say you have nothing and everything is a giant mess and you don't even know where top and bottom is. You probably need some architects, right? You need to build that up. But then I would also say if you have 50 architects in one team, that's maybe a lot regardless of the size of the organization. Even if you have 50,000 developers,

42:25 --> 42:54

having a giant architecture team still feels odd to me. So I like to look at these kind of things about how big is the team much more over the timeline, right? Like how big the team is should vary, right? Assuming that the team is a constant size, that's a very sort of big enterprisey kind of, I have budget for 20 people and next year I get five more, right? That's very sort of old school thinking. A platform team might grow and shrink, right?

42:54 --> 43:14

And shrinking doesn't mean like everybody has to leave or lose their job. The way, for example, we shrunk our architecture team is by architects graduating into the development teams, right? So when we call them the alumni, we literally call it graduating, right? We would hire other folks and we had great friends in all the application teams. That's probably the best thing that could happen

43:14 --> 43:40

to an architecture or platform team. If your customers are full of your friends, right? Because those are the folks who used to work with you. So I highly encourage people to not think about a magic number. It's not one to 50 or one to anything, but think about over time, you know, that maybe you need more folks to get this kicked off, but then maybe, you know, you can have some of them graduate and shrink the team a little bit

43:40 --> 44:03

when there's a major technology push. So let's say like everybody else, now your platform needs to support AI. Well, maybe that's a signal that the platform team needs to beef up a little bit more, maybe recruit or borrow some folks from the application teams to tackle that. And then after that, maybe they go back. So to me, it's much more fluid. Now, maybe I'll share this as the last anecdote

44:03 --> 44:31

is what can work against you there are organizational guidelines or sometimes even labor laws, right? I just made it sound like you shuffle people between teams willy-nilly, right? Like as you see fit, you cannot always do that, right? You have works councils, you have budgets, you have managers, you have locations. So my advice there is be creative, but be creative with good intentions.

44:31 --> 44:53

So I give a very real example. In my architecture team that I used to have, everybody reported to me and not because I wanted to micromanage, actually I didn't want, but the answer was quite honestly, so if somebody shifted to another team, it wouldn't show on the org chart, right? Like I didn't need to do anything, right? They just worked on this versus on that. I say, hey, you want to go over to this team?

44:53 --> 45:13

People say, yeah, sure, fine. I'm like, I'm done, right? So I found it and this was done with best intentions and I had great friends with the work council and this was all good, but you need to be a slight bit creative so that you get the flexibility to make your platform team successful, even though you might be in a frame where it's a bit more rigid.

45:13 --> 45:42

I wrote a blog post about this once, it's called how to make organizational, how to make lemonade from organizational lemons. So you can have a read, it's all the little tricks about how to navigate organizations that have constraints, which most of them will do. - So it's been really nice talking to you and I think at least I've learned a lot, but how and when can people read this new book

45:42 --> 46:06

and also what's been your procrastination project while writing the platform strategy book? - Ah, very good question. So the publishing industry has also changed and it's become more agile and intuitive. So what I do with my books, I start on LeanPub and then from LeanPub, I usually go to Kindle Direct Publishing and then sometimes I take them to a traditional publisher like I did with the Arcade Elevator.

46:06 --> 46:33

So the book is actually on LeanPub, from leanpub.com/platformstrategy, easy enough. Most of the content is there, the pictures are sometimes good, sometimes not. You'll find some funny English probably and some typos, but that's what you get for being an early user and it's an e-book, so you can always get the updates. So that is already out. My goal is to get it into a stable version so the end of this quarter,

46:33 --> 47:02

so March, April-ish kind of thing. Regarding the procrastination project, well, I've been trying to be a good author and really focus on this thing. There is another whole series of books that I've been having in the sort of back of my brain and that is called "Drawing Like an Architect", "How to Make Pictures", that's basically sort of the add-ons to the Architect Elevator,

47:02 --> 47:31

diving much deeper into things like making pictures, writing documents, making presentations, right? Those kind of things. Now, luckily, that's a very different domain from platform strategy, so hopefully they don't interfere with each other all that much, but it's always been my ambition to make some smaller, more fun books full of real examples of, here's how I improved this architecture diagram

47:31 --> 47:58

or here's how I redid this presentation or these slides or something like that. So let's see if that comes to fruition. - Thanks for coming, Gregor, and this has been a special episode of Platform Podden and we hope you'll continue to listen and visit us anywhere you get your podcasts. - Yeah, my great pleasure to be on this podcast and it's great to have a podcast dedicated to platforms. That's excellent, thank you so much.