When I was hired as head of Enterprise architecture, my
first job was actually to standardize things.
And what I also didn't know was that that is the most hated
person in the whole organization, because the person
who's trying to make all the standards is the one telling
people what they cannot do. That doesn't enable anybody who
speed anybody up. That just makes people's lives
more difficult. So the really important question
is where's the difference? And the difference is in the
fact that platforms also harmonize and standardize, but
without restricting. By standardizing they actually
enable, they allow people to do more things.
So they achieve the opposite of what we traditionally think
forth as standardization. Hey everyone, my name is Henry
Suryavirawan and you're listening to the Techni Journal
Podcast, the show where I'll be bringing you the greatest
technical leaders, practitioners and thought leaders in the
industry to discuss about their journey, ideas and practices
that we all can learn and apply to build a highly performing
technical team and to make an impact in your personal work.
So let's dive into our journal. Hello to all of you, my friends,
and my listeners. You're listening to the Tech
Lead Journal Podcast, the podcast where you can learn
about technical leadership and excellence from my conversations
with great thought leaders in the tech industry.
If you haven't, please subscribe on your favorite podcast app to
get notified for new episodes. Also subscribe to Tech Lead
Journal's various other contents on LinkedIn X, Instagram,
YouTube, and Tiktok and consider supporting this podcast by
either buying me a coffee at tech legional dot dev slash tip
or becoming a patron at tech legional dot dev slash patron.
My guest for today's episode is Gregor.
Hope Gregor is back again for a second episode with his latest
book, Platform Strategy. In this episode Gregor discussed
in depth about building platforms with a proper platform
strategy. He began by describing what a
platform is from a few different perspectives, the benefits it
brings and what strategy we should think about when building
a platform. Gregor also emphasized the
opposite difference between platforms and IT services, with
the key difference of how a platform thrives with more
scale. We then had a few fun
discussions discussing building a platform on top of a cloud
platform, the key skill set we need to build a good platform,
and how we should build a proper platform abstraction towards the
end. Gregor also covered the recent
trend of building developer platforms and business
capability platforms. You also do not want to miss
Gregor's fun analogy of fruit basket versus fruit salad when
explaining a good platform strategy.
I hope you enjoy listening to this episode and getting to
understand what we should do differently to build proper
platforms with great strategy. And it's always fun when having
a conversation with Gregor, especially with his smart humor
and analogies. If you enjoy listening to this
episode, please do share it with your colleagues, your friends
and communities and leave a five star rating and review on Apple
Podcast and Spotify. Your small help will help me a
lot in getting more people to discover and listen to this
podcast and I really appreciate it.
So let's now go to my conversation with Gregor after
quick words from our sponsor. Hey, a quick message for those
of you who are listening to this episode on Spotify, I have a
small favor to ask. Spotify now allows mobile users
to rate podcasts. I would really appreciate it if
you can take a quick pause to go to the technical podcast page
and leave your favorite show your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot.
Hello guys, welcome back to another new episode of the
Technical Podcast today. I'm very excited.
I have a repeat guest, so he appeared in episode 50.
There was like 100 over episodes, so probably like two
years ago. His name is Gregor Hope.
None other than Gregor Hope. I think some of you would have
known Gregor, seeing his post, seeing his talks and reading his
book. Today we are going to cover his
new book title Platform Strategy.
So Gregor, really, really happy to have you here again.
Yeah, I'm super excited to be back.
I managed to be in the top ten listing I think for a little
while. So my ambition is to make a
second step at getting back into the top 10.
So let's see. Right.
Yeah. Let's, let's see.
OK. So, Gregor, so we, we haven't
been talking for like 2 years, right?
So anything that you want to share, what have you been up
lately and things like that? Yeah, so my previous book on a
previous chat was about cloud strategy.
So that hasn't changed in a way. So I'm still very much
associated with building cloud solutions.
What has changed though is so most of my work now is in
serverless and in serverless automation particularly.
So I do a lot of work with Lambda and CDK and serverless
integration, and that is a lot of fun because I can use some of
the 20 year old things from my Enterprise Integration Patterns.
And the reason I know it's 20 years old because that book
actually has its 20th anniversary, well, last month's
like it had in October. So it's cool to be able to bring
that stuff back into my daily work.
So it seems your books have some kind of a timeline, right?
So you started with Enterprise Integration Patterns long time
ago, right? 20 years.
So you also had Software Architect Elevator, right?
Recently Cloud Strategy and this time is Platform Strategy.
The title also have strategy. Are you thinking of creating a
series? Yes, and the ambition was a
little bit ahead of the reality for a while.
So the idea was that the architect elevator, so that came
out three years ago, like right at the beginning of the
pandemic, right in 2020. And the idea there was to
rethink a little bit what architects should be doing, Are
we? There's many opinions about what
architecture is and many opinions about what architects
should be doing. I think last time we chatted a
little bit about that. So the architect elevator was
trying to take a look at. The architects aren't supposed
to be the ones who are like the smartest people and tell
everyone what to do and make all the decisions, but much rather
they're supposed to fill in the gap between the grandiose
visions and the reality. Hence the elevator.
So the strategy books are meant to be the application of that
principle to different domains, like the domain of cloud
computing, right? There's a lot of technical
resources and a lot of high level strategy stuff telling you
all the things that you should be doing, but there's very
little in between. Hey, like how do I get from here
to there? And platform strategy is again
looking to do the same thing for platforms, which has become a
very hot buzzword. But again, you ask three
different people, you get 4 points of view.
So I'm trying to get a better definition of what is a
platform, what really makes a platform, How do you go about
building 1 and filling in that gap?
That's indeed intended to be a serious I had a hard time
claiming it's a series because with one book it's a little
tough to say whether it's a one off or a series.
So I'm super excited that with two books now, it is actually a
proper series. Right.
Thank you for sharing that plan. Ambitious plan, right?
I hope to see more strategy books from you because to be
honest, like when I read your book, I always have a good fun
because you have a fun way and humor and metaphors that you
introduce in your book, including in this platform
strategy book as well. So let's start maybe in terms of
platform, right? You mentioned just now it has
become buzzwords. Maybe in the past, I don't know,
five years more and more people have been mentioning about
platform as a word these days. So hence there's a lot of
confusion as well. Maybe from your definition if
you can help us define what is platform in your point of view.
It's probably good to state 1st that the whole idea isn't that
new at all. Like one sort of thing we suffer
from collectively is we always believe that we invent
everything. And we mean like the software
people, right? The computer people Like how
sometimes I'm called by my older relatives.
We always feel like we invent everything.
The platform idea isn't actually that new.
And you know, some of the popular examples are automotive
platforms, right? The car manufacturers long time
ago realized that making a new engine and brakes and
transmission and everything for each car model is actually not a
great idea. It's very expensive and in the
end people don't really just buy the car exactly because of the
brakes that are in that car. So they started making platforms
and putting different car models on top of a common platform.
So the idea has been around for a long time.
And if we look at the IT side, operating systems are also kind
of platform, right? They're striked away.
In this case, it's not the engine and transmissions, but
it's sort of the disk encoding and interfaces and all the
hardware stuff, right? They abstract away.
And then on top you can build many, many different things on
common hardware without having to deal with all the details.
So that idea has been around for quite some time where I think
it's gotten a huge boost recently interestingly comes
from multiple angles. And that gets back to your
question where the confusion originates.
The one is the platform business models like platform companies
like the Airbnb's and the ebay's of the world where people say
hey it's a multi sided marketplace, right.
You have sellers and buyers and interestingly that platform
company itself often doesn't even hold inventory like Amazon
does for example. Now they they ship physical
products but an Airbnb doesn't own any hotel room and that has
become known as a platform. So that gave a huge booster and
these are the Ubers, the Airbnb's of the world, the mega
unicorns and now some of the most valuable yeah companies
that we have. So that is the one world view.
The other world view comes from a cloud platforms.
It's actually kind of funny, like the GCP folks, the P
obviously has the word platform in the name.
The funny thing is on AWS we don't like to use the word
platform. So here today I'm here as myself
so I can joke about it. So it's kind of funny like where
some people embrace the word and other people kind of shy away
from it. But the reality is most clouds
are platforms in a way, right? They give you a common layer
that you can put many things on top of and the abstract the
things underneath. And then so that also everybody
is doing these days. And then if that wasn't enough,
what everybody else also seems to be doing these days is making
developer platforms in house platforms.
They're called productivity platforms or ID, PS internal
developer platforms. Again, we can't even agree on
the acronym. And the idea is there to layer
something on top of the base platform, like on top of the
cloud to make it easier to use for developers or to increase
their productivity or to have some form of governance, right?
It can also be to restrict. Now with the three different use
cases and as I just hinted, people having different
objectives, right? Some people want to make
development faster, other people want to restrict what people can
do. You can easily imagine that it's
no longer that easy to look at something and say, oh, is this
now platform or is this just like an IT service or framework
on abstraction layer or governance tool?
Right. So even after I heard you
explaining it right, so there are so many permutations and
variables that could happen right to me when I always heard
about platform, it's about reusability, right?
It's about unification or standardization of stuff.
Maybe if you can elaborate, maybe you have mentioned just
now a few other benefits, right? What are some of the benefits of
a platform truly right? Because for people to really
understand that it is a platform, right, they need to
understand OK, there are benefits of using the platform.
Yes. And what I would say for the
rest of our discussion it will help if we leave the Ubers and
Airbnb. So if we leave the multi sided
markets and all those aside because they share some
commonalities, but they also very different from the
platforms that we as engineers would normally build and use.
So if you look inside organization, cloud platforms,
engineering, productivity platforms, your question is a
very good one. And I think you hinted at the
keywords like some of the standards, standardization,
reuse, right. Those are the things that people
want from these platforms. But this is not the first time
we want reuse, standardization. I worked in large enterprises
and some people might know my joke.
When I was hired as head of enterprise architecture, I
didn't really know what enterprise architecture was.
It just sounded good. And my first job was actually to
standardize things. And what I also didn't know was
that that is the most hated person in the whole
organization. Because the person who's trying
to make all the standards is the one telling people what they
cannot do. They're like, oh, we want to
build something on this database or use this programming language
or this framework or this app server.
And then the standard person comes with a Enterprise
Architect title and says no, no, no, you cannot use that
database. You can only use that database.
So that is obviously not a platform, right?
That doesn't enable anybody who speed anybody up.
That just makes people's lives more difficult.
So the really important question is where's the difference?
And the difference is in the fact that platforms also
harmonize and standardize, but without restricting.
By standardizing they actually enable, they allow people to do
more things. So they achieve the opposite of
what we traditionally think for as standardization.
Now the question is like, oh, that sounds a little magical,
right? How can it restrict?
Like how can it standardize but at the same time allow more
innovation? And the key mechanism there is
that not all standards are created equal.
And a great example that we have that has the same property is
HTTP, right? HTP is a standard, I mean goes
for the different incarnations and versions, but it's a very
well specced out, very strict standard and we all use it.
So in a way it constrains us if you say, hey, I invented this
other great protocol that I want to use, probably uphill battle.
People would say hold on, why are you not using HTTP?
It's the standard. But we can see that HTTP has
been a huge innovation booster, right?
Without HTTP we wouldn't have the cloud and all the other
stuff. So that shows that you can sort
of rewrite the laws of physics a little bit.
Where in the past it was always that, you know if I take choice
away, then people can't be creative, but now we have ways
where we also take some choice away in a way, but it actually
allows people to do more things and more creative things.
Cloud platforms, you know, using the P bar here, the cloud
platforms also have that property right.
I often remind people, you know, I talk to a lot of customers at
my day job and if the meeting is a little bit boring or I want to
sort of poke the box a little bit, I say, listen, people, we
have a single product basically, right?
There's many, many services, but basically there's one AWS,
right? There's no red, green or blue
AWS, right. And same with GCP, Azure, right.
It's like it's basically one thing that these companies have.
And I say the AWS you're getting is the same AWS essentially that
your competitor is getting like people are going like, oh, well,
how can this be, right? So I guess it's a standardized
platform. But what people do on top, Yeah,
it's nothing short of magical, right?
I mean, people do all sorts of amazing things.
So what I'm trying to get at with the book is like, tease out
a little bit, oh, why is the one standard thing the most hated
activity and constraining people?
And why is with platforms that doing the opposite?
And how can you recreate that? What are the essential
properties that make that magical thing happen?
Yeah, when you explain about this, I think that's the
insights for me, right. So people want to standardize,
but they are more towards restricting, actually also
restricting the kind of capability that people do with
whatever they're building as a standard, right.
So I think in your explanation just now, the platform, yes,
will create some restriction, but the benefit is actually to
enable people to do more stuffs, I mean more creative stuffs and
even could be faster, it could be more creativity, more
innovations and things like that.
But it seems like a very, very tall order for many, many
people, right? And that's why probably you have
this thing called strategy, right platform, strategy.
So tell us why do people need to build some kind of a platform
strategy before they embark on building platform or using
platform? Yeah, so the reason is that you
need to be cautious. Is a like as we already
discussed, right? It's kind of a subtle but
magical property which isn't easy to create.
So it's very tempting to set out to make a platform right?
But if you don't really get the nuances of it, you just might be
building another IT services layer.
And I actually have a chapter in the book which is called
Platform, and IT services are antonyms.
They're like the opposite of each other.
And what can easily happen in large organizations where I used
to work and where many of my customers are, there's always
the temptation to take what you have and sort of apply the new
label to it, right? And it's understandable because
you don't want to throw everything away and you have
shared services or maybe even have a private cloud, some
virtual machines, some ticketing system, maybe even some
self-service portal, right? You have all these things and
then you're like, oh, that's actually most of what I need for
a platform. Let me just make that into a
platform. And unfortunately, most of the
time that goes completely wrong because these things were built
for control. They were not billed for driving
innovation and enable the diversity that you mention.
And that's although the first important part of the strategy
is to tell you how different this actually is and make this
very obvious, like have these side by side comparisons.
The stuff that you had before in a successful platform is almost
the exact opposite. So I want people to not
underestimate what they're signing up for.
And I also want to give them some simple tests like you
mentioned before, you like reading the books because
they're sort of, you know, not entertaining.
I would say we're not in the movie business here, but I would
say they're engaging in a way, right?
They're accessible, but at the same time have serious content.
So what I'm trying to do is capture this kind of advice and
something that's memorable and easy to understand.
So one of the tests I'm suggesting is if you build a
platform, people should do something on top that surprises
you. Like if nobody does anything
with your platform that generally surprises you, then
you probably didn't make a platform, right?
If you try to anticipate everything that people will do,
it sounds very useful, because if you anticipate everything,
you can make great reuse, right? You can provide exactly what
everybody wanted. But you failed to make a
platform because you didn't create this multiplier effect,
You didn't make this innovation booster.
So I'm trying to distill it down to these kind of tests that when
people look at what they're proposing and saying, is this
really allowing people to build something that we didn't even
think of? And if the answer is, oh, not
really, We just wanted to give them some common services, then
probably that's an early indication that the platform
strategy needs a little bit of revising.
Yeah, I think the metaphor that you use is like standing on top
of the giant's shoulder, right? If you want to reach a higher
height, you can, you know, climb the ladder and things like that.
But you can also stand on top of a platform, right, Or standing
on the top of the giant's shoulder.
And in this case here, right, your metaphor about a platform
versus IT service. I think it's very, very
interesting for me because some people when I see real life
example of people building platform, right, most of them I
see it now becoming like an IT service instead of platform.
Maybe if you can bring up some attributes that you see are the
antonyms between platform and IT services.
I think that will also be useful for people.
Yeah, yeah. And I it's interesting that you
also see that it's a super slippery slope and we see a
similar effect. You know, obviously I work with
a lot of customers migrating to the cloud, adopting cloud
service. And the failure mode
unfortunately is always relatively similar, like people
look at anything. That's the bottom layer of a
picture, right? We always have this mental
picture of on the top is application development and
there's other stuff underneath, right?
And underneath can be IT services, it can be the cloud or
it can be a platform. So when we look at the
organization we like, there's the application teams there.
And then this stuff is with the teams that do the bottom half
right? Now that makes some sense
because the folks who do the bottom half, they're used to
provisioning services, doing operations, right?
They have some really valuable skills in this area, but they
work in a very, very different model.
Like, in a way they're the best guys for this, but they're also
the worst people for this because they have the technical
skill in many cases, but they absolutely don't have the
mindset or the way of working. And that's where this comes from
where both cloud initiatives or cloud transformations like we
like to call it and platform initiatives, they struggle or
completely fizzle out because basically the teams who are
running them are not used to this way of working at all.
So the the way this shows up in many cases, and this is where I
made this, the comparison table is that IT services are often
not full self-service right? So you fill out some ticket or
some. I used to fill out excel
spreadsheets to get a server right.
That's not how platforms work. Platforms are easy to get onto.
Platforms live from scale. You want many people to use the
platform in a classic IT services is everybody comes and
wants something. You probably overloaded and you
become the bottleneck. So you can see from these
examples it's exactly the opposite.
One is built for control, the other one is built for ease of
onboarding. One is for ticketing semi
manual, the other one is complete self-service.
The old model is based on the idea of that the IT service is
responsible for all the non functional aspects.
Yeah, like all the scalability and security that's supposed to
be done on in a bottom layer. The new model, the platform
model, is a shared responsibility model.
If your application is super brittle and leaky and full of
vulnerabilities, no platform is going to tell you that it's
magically going to fix that. So the division between the two
teams is very different. Also, maybe last example and the
list goes on right. But last example is that the
additional IT services like stability, because they have
learned that through stability they get up time and those known
functional requirements that they're responsible for.
So they don't like to change. Well, successful platforms
change all the time. I mean look at the cloud
platforms, right? AWS used to have like two or
three services, right? It was like EC2S3, SQS, right.
And then it's like couple of 100 now, right?
And the other one's no different, right?
So every year there's a lot of new features, new things, open
source projects for platforms and features all the time.
So platforms are based on evolution and that's good
because as the platform grows, it lifts up everything else with
it. So you get new capabilities
basically without doing. And again, that's the exact
opposite of the IT services, because they always favour
stability. So it's almost every way you
look at it, it's the opposite or IT services are generally
mandated, right? There's a mandate.
Oh, you cannot do anything if you don't use our service.
Most successful platforms are not mandated.
It's not 100%, but in most cases it's voluntary.
So again, it's the opposite. So what I wanted to do in the
book is really, I don't like black and white painting because
I always say for architects everything is a trade off.
But in this case, I think a little bit black and white is
helpful to really show you that it is totally the opposite of
one another. Yeah, and I think you sum it up
also in one statement, right? Platform tries with scale,
right? So if you don't see some kind of
a scale where people build more solutions, more adoptions, more
usage and even they recommend it to other people, right.
I think that's not like a true platform, right?
Because that could be just some IT services that you mandate
people to use for control, for standardization, or for whatever
that is. Correct.
And in some sense, that already presents a little bit of a
challenge for in house platforms, right?
If platforms thrive on scale, if you build something custom in
house, you will never have the scale that, let's say, a cloud
provider will have, right? So you need to be cautious.
Now the good news is that you can build on top of a platform,
so your platform doesn't have to start from scratch.
So that helps a little bit. But you're absolutely right.
There's a couple of important mechanisms at work here.
The one thing is platforms are indirect value creators.
If you build world's most beautiful platform and nobody is
on that platform, the value creation is absolutely zero,
right? Like the thing doesn't do
anything on its own. It enables developers, it speeds
them up, It helps them make fewer mistakes, build that
application. Like there's a million ways to
sort of position it, but the value only comes with the usage
and that means right, the scale is where the value is versus
traditional IT. They often suffer from their own
success. I see this with cloud centers of
excellence. So as a quick side note, they're
also candidates to be relabeled as platform teams.
As we look around, it's either the IT service teams or in a
slightly more modern organization, the CCOE, the
cloud center of excellence that gets relabeled as platform team.
And if that is super popular in its scales, they usually become
a a bottleneck, right. So it thrives on scale because
that's the only way it can generate value and the other
magical maneuver that platforms do.
And this is visible with cloud platforms.
Cloud platforms are a scale business, right?
Building these data centers, there's like billions and
billions of dollar data center undersea cables like this
infrastructure that is clearly an economies of scale model,
right? The bigger you are, right?
Like you can make those kind of investments.
Custom CPUs, right? Like almost every cloud
provider, whether it's Graviton or Titan chips or whatever you
have, right. Almost everybody has custom
hardware these days. Those are not things you can do
as an average enterprise. So there's a clear scale effect,
but the magic of those platforms is that the usage of these
platforms is not scale effect. Like, I can run one of the
functions for like one second, right?
And pay. I could do the math, but pay
some ridiculously small amount, like a fraction of a penny on
it, right? Or I can get an EC2 instance for
one hour right, and pay like $0.50 for it.
So the magic of the cloud platforms has been that they use
economies of scale underneath because that's the only way to
make these things. But they offered as what I call
economies of speed. You can have it instantly, you
can get as little as much as you want.
You can shut it off. So they changed the rules of
engagement between the usage of the platform and the
implementation. Now for cloud platforms, we kind
of knew that and probably if my memory was better in cloud
strategy book, probably it says something like this about cloud
platforms. What I'm trying to do with
platform strategy is to take a step back and say, now is that
just for clouds or is this for all platforms?
And how can you as a platform team make that work for you?
So in a way, the platform book is sort of one more level of
abstraction over the cloud book in some sense.
Right. You bring a topic cloud center
of excellence. So in my experience, I've seen
people building platforms on top of cloud platforms like you
mentioned, we can build platform on top of base platform, right?
In this case it's cloud platform, especially if you want
to go hybrid, multi cloud or especially if you don't want to
expose people to the real Cloud Console for example.
So tell us a little bit more about this strategy.
How do you think people should do it because so many people are
doing it? How should they do it so that it
becomes more successful for the organization rather than
limiting people with options? Yeah.
And I would say the sad reality, they are maybe more poor
examples than good examples. I think they're slowly learning
and there's few companies now they're basically platform
builder tool kits to make it easier to build platforms.
But the harsh reality is that making such a platform that you
lay on top of the cloud is extremely difficult for a number
of different reasons. Well, the one reason I already
mentioned right, the platform that you're building on evolves.
So you might be building something that in a year or so
the base platform does that doesn't mean it's a bad thing.
And actually this happened to me when I was in financial
services. I built an in house platform and
then quite a few years later somebody came like, hey, you
know, all this stuff you built, they replaced it all with like
AWS or something and they thought I would be very sad
about it. It's like, oh, that's great
because that means we were exactly on the right trajectory,
right? We were a few years ahead with
our specific needs and now the base platform does it.
So I should throw away what I built and just use the base
platform because you will always have better economics, but that
takes a very different mindset, right?
You must be happy when your things become obsolete, which is
not the way normal IT works. They would always think about
cost recovery. They're like, Oh no, no, this
thing needs to live as long as possible because we need to get
our money back. So this is one way in which
these platforms struggle. The other one, and there's a
magical word here which is I think very useful but also very
difficult. And that's the cognitive load.
So almost all of this thing from the team topology is right.
You know, Matt and Manuel, you know, written the book, super
popular, very helpful models. I'm pretty sure they weren't
technically podcast at some point.
So they introduced the notion of a platform team.
Now careful platform team and platform.
Still two different things. And there's one unfinished
chapter in the book which is actually called platform, team
without platform. But basically the team
topologies really focus on the concept of cognitive flow.
And that's important because if you look at today's development
teams, right, there's one manoeuvre that we've executed
over the last couple of years and that's called shift left.
Basically, your security should be shifted left, operational
should be shifted left. Policy and compliance should be
shifted left policy as code. Right now we have def SEC OPS,
def arc SEC OPS, basically you build it, you run it.
So basically everything is piled into the development team.
So I no longer call it shift left, I call it pile left
because everything gets piled over and people basically going
bananas, right. So if we don't manage to reduce
their cognitive load, there's like no way you can have such a
team that can do all these kind of things.
So the idea is extremely valuable.
Now the reason I mention it's also a bit of a dangerous word
is that it's used to justify everything.
So people say like, oh, we don't want you to use the native cloud
services because we want to be portable or we don't want you to
use this region and we want to fix this parameter.
And they say, look, it's good for you because it reduces your
cognitive load. And that is not true.
So let's take a very simple example.
Let's say you have a cloud service and it has 20 different
parameters. And you as a platform team with
good intentions, you say I default ten of those 20
parameters so the developer only has to now worry about 10
parameters. That on the surface would seem,
hey, setting 10 parameters is easier than 20.
Didn't the cognitive load go down by 50%?
The reality is no, because behind these parameters sit
concepts. So if you fix the availability
zone, that's probably fine, right?
People don't need to worry about it unless they need to do
something Cross availability zones, right?
Even then you struggle because like, oh, I never actually knew
what an availability zone is because they were set for me.
Now somebody says I need 4 nines or five nines, so I need to run
across multiple ability. What is what is that?
So it's not that easy. Also depending which parameters
you fix, not all parameters are independent.
You you might create some sort of intellectual minefield where
you sort of take some concepts out of the overall construct.
And sometimes needing to understand 1/2 a thing is harder
than understanding the whole thing.
Because if you see the whole thing you can understand what
relates to what and what combinations are useful versus
if I sort of randomly take some pieces out of the puzzle it's
actually harder. I mean maybe a metaphor is and
it reminds me of the funny movie The Accountant I've I blocked
before about transformations and not hiring a hitman to fix your
stuff, which the movie is partly about but it has a example where
somebody tries to put together a puzzle and the kid is autistic
so one piece is missing. So he he is very unhappy and and
very agitated. But that metaphor just came to
my head, right. Let's say you give somebody a
puzzle of 1000 pieces and you say, hey, I want to make this
easier for you. So I took away half the pieces.
It's worse, right? Because you don't know if the
piece is there, if it isn't, like in the end you don't know
which ones are missing. You wouldn't need to give people
a different puzzle with 500 pieces that fit together.
You can't just take out half the pieces from the puzzle because
you just make it harder for people.
So that's where the book is trying to go.
And it's a little bit, it sounds kind of maybe abstract, but
that's where I see a lot of these initiatives derail.
They say, hey, I take some things away from you, doesn't
that make your life easier? And the short answer is no, not
necessarily. Yeah, in your book you also
bring up an example where for example, some of these
parameters are hidden and they are applied in the actual
instance for example. And then there is an issue like
when you troubleshoot, you see an error message, but the root
cause is mentioning something that you didn't even know that
you tweaked before, right? So you kind of like limit people
to understand what is going on and even troubleshoot and you
need to file ticket support and things like that and things
become slower. So I think this is also another
danger zone that I read from reading your book, right?
Yeah, so I think that that's really, really good advice for
people who are building platforms.
And another thing, I think when you build this in house platform
you need to have skill set right?
So any tips here for people how they should find skill set and
how they should think about finding people who can build a
truly developer friendly platform?
Yeah, and perfect question. Ironically, this is another
common failure mode, so I'm I'm a little bit worried that we may
be painting the picture too darkly here about all the things
that can go wrong. But in the end, a good strategy
is intended to keep you on the good path and keep you out of
trouble. So I think mentioning and
talking about failure scenarios is is actually very common.
So here's a failure scenario I've seen almost every large
organization doesn't have enough fully skilled developers as they
would like, right? And that's always going to be
the case, right? Because there's a lot of stuff
to do, You know, modern applications are demanding, like
they distributed. We have fine grained deployment
models, automation, right? We release offer like we can do
amazingly cool stuff, but it's not exactly trivial, right?
So there will always be a shortage of skill set.
So what these companies they do is like, OK, if I have a lot of
developers which are so, so can I pick good developers and make
a platform so that the so so developers become good
developers. And finally Martin Fowler I
think commented on this. It must have been a decade or
two ago because that same mistake was made with frameworks
where it's like I was instead of a platform, I built a framework
right where all the good developers build the framework
and then the not so good developers become now good
developers thanks to the framework.
And that basically has never worked.
So the failure scenario is that you also don't have the skills
to build a platform because the bar for that skill is is much,
much higher. And I'll give some example in
different ways in which the bar is much, much higher.
The one thing is, so let's start with what's perceived as the
easier one, but usually the harder one.
And that is, how does a platform team function?
Like, how does it engage with customers, right?
How does it take feedback? What is the rate of change?
We said platforms must evolve, but if they change every day,
nobody will be happy. You can go and ask your
customers what they want, but building what their customers
say they want is also not a great way to build a platform.
So there's a lot of skills there in terms of it's like running a
successful product company, a lot of trade-offs,
prioritization, right. And that is something very
different, especially in IT operations, right.
We're basically, here's the three service you can have,
please be happy, right. This is again the exact opposite
where you need to be customer centric, do a lot of product
management, do a lot of marketing, a lot of consulting.
So that's skills you need to have.
And the technical skill you need to really have is to really
understand cognitive load and abstraction.
So if defaulting half the parameters doesn't reduce the
cognitive load, what actually does?
And I see people struggle with this a lot.
So my favorite example is. So people look at the different
cloud providers and say, oh there's, you know, SQS, you
know, I'm a queuing messaging guy, so I must make an example
from message queue. So you have like SQS, right?
You have the Azure event pass and you have Google pops up,
right? So when they say aha, I make an
abstraction and I call that abstraction.
Message queue. But in the end you didn't really
abstract much. It was already a message queue
before you abstracted it. Maybe it had some specific
runtime settings, but two things come into play.
You didn't really simplify things that much because it's
still a queue. It's asynchronous.
You need to deal with things like back pressure and time to
live right, like all that stuff doesn't go away.
And to be honest, the original queues probably have some really
important settings underneath like FIFO or not FIFO on scale
out and many other things that if you take those away again you
have the puzzle where half the pieces are missing.
So I see even talented teams struggle with this.
They say oh but I made this abstraction layer but you didn't
actually abstract something. So what I've seen from some
customers where they are really successful at this and have a
much better approach is they start taking concepts from their
business domain. It was really interesting.
I talked to a customer like about a month ago and they
described what they were doing. And then I was really excited
because I liked it so much and their comment was, oh, finally
somebody who understands what we're doing because they
couldn't find anybody to appreciate what they had done
because it was very subtle. But for me it was absolutely
obvious and ingenious. So rather than trying to
abstract SQS into a queue, they have concepts that are important
in their what I would call business technical domain.
So they are financial services companies.
So they have a lot of compliance requirements.
So they need to have ledgers. So when you have a database, you
can make updates in the database, but every change must
be tracked in a log or a Ledger they call, right?
That's the way the industry functions.
You can't just like go and change the number in the bank
account. You add and subtract money and
that gets all logged. So that is something that's very
inherent to their business and their business technical domain.
So their platform now has constructs like this.
They have Ledger database and underneath this Dynamo DB and
Eventbridge pipes and another Dynamo DB the way they do that.
But they didn't call this like 2 Dynamo DBS and Eventbridge pipes
or AQ whatever, right? They called this alleged
database and the difference is very subtle.
You could even make an abstraction that's called
database with customer data and database without customer data
or database with PII like personally identifiable
information or without. And to most people that would
seem very subtle. So the database.
And again, you're probably just defaulting a few fields, right?
Because maybe the PII database needs to be encrypted on in a
special availability zone in a special region.
You're like, oh, you're just defaulting fields.
No, in this case you're not just defaulting fields, you're
building a new domain language on top of it.
So the second skill that you really need to have is you need
to be able to do domain modelling, DDD really Domain
Driven design, but for this business technical layer, right?
It's half cloud and technical stuff.
You talk about databases, right? That's obviously technical stuff
but with a strong business flavor.
Does it have PII? Doesn't need to be Ledger and I
think that is a skill we still struggle with and the techies
will dismiss it. As to fluffy stuff that I got
still a database like whatever what you're talking about and
the business people don't necessarily have the skill to
really understand like Dynamo DB and Maven Bridge and pipes and
all the other thing. So you're living right in that
area, which I find super fascinating, but I've seen it
very rarely that that is done well.
And that touches on sort of how it can be done well, but it also
touches on why so many things fail by just saying, hey, I
abstract SQS into a queue or I default some fields and all that
sounds nice, but it's not reducing cognitive load and it's
not giving you the abstractions that you need.
Wow. I think that's a pretty good
insights, right? The example when you mentioned
they created their own concept like a business technical domain
concept, right? But I think that is really
insightful for me. And when you mention about
creating abstraction, right, I also love the metaphor you
introduced in the book, right? Abstraction, not in illusion,
right. So sometimes we create
abstraction, but actually it's an illusion, right?
It doesn't actually abstract away things.
We create such that it becomes like a unified interface.
But the implementation details can be so, so different, right?
Between, for example, different cue mechanism from different
clouds, right? And people will be stuck like
because, yeah, because they think it's an abstraction, but
the behavior is different. So I think this is also another
danger zone. Just picking on that really
quickly. So yeah, that happens.
If people want to abstract too much, they say, oh, I make this
beautiful logical abstraction. Now I have this cue, this
generic cue. But it turns out any distributed
system has a lot of physical properties, right?
And no logical layer can abstract away physical
properties, right? And Joel Spotsky, right.
Always. Never short of an opinion,
right? He said all abstractions are
leaky. And that's probably true, I
would say the leakiness isn't that horrible, right?
So for example, I don't mind if my queues thing has an SQS
setting on it. That's not what's making my day
good or a bad day. But what leaks through is the
physical aspect. Latency, failures, retries,
queues filling up, all those kind of things.
And an abstraction layer cannot make that go away.
And that's where you know I work in serverless.
As I said in the beginning, that is full of that stuff, right?
Because serverless solutions like fine grained asynchronous
event driven. So the physical properties are
extremely important. And then people try to make it
look very simple. And simple doesn't always mean
better abstraction. So the classic example is RPCRPC
is also beautiful abstraction, except it doesn't work.
It it pretends to be something that it isn't because it
pretends that there's no latency, there's no partial
failure, pretends you have a call stack, right?
It pretends it's always consistent.
It pretends the infallacies of networks don't exist, right.
Or distributed computing like basically pretends all these
things that are not true. And that is the classic example
of you build an illusion. So what we learn is it's not
about taking as many things away as possible, it's about finding
sort of the right level where you can create a new mental
model or a new domain like a new vocabulary for people that's
cohesive in itself, right? And that is in the end, it is
Domain driven design And that in the end is quite challenging.
So when people say, oh, we're going to build some platform, we
have some servers and some cloud stuff, we're going to go build a
platform, I kind of want them to read maybe, well, ideally read
the book first. But whichever way you do, think
a little bit more first about what are you really achieving
and all those really abstractions.
Are you really reducing cognitive load?
We use all these words way too loosely, right?
Like everybody talks about this stuff, but then really making it
work is a whole different story. So yeah, hence the illusions,
right? I'd like to bring another
metaphor that you bring in the book, right, because we have
been talking about, you know, building a lot of components, a
lot of cohesion and things like that.
You have this analogy fruit salad versus fruit basket.
So I think this is a fun one. So if you can elaborate a little
bit more for us to learn from. Yes, and and this fits exactly
what I was trying to say earlier, right?
I like to take metaphors from real life, like one of my most
popular article is still the Starbucks does not use two phase
commit, right? It's like it's very memorable,
but it has a serious meaning and this one has also meaning.
And interestingly, this was the very first chapter.
This came out of my work at the government of Singapore when I
worked for Govtech, where we were actually building an
engineering productivity platform and we had to make
design decisions. So one question was Confluence
and Jira and a few other tools. Is that a developer platform?
Because OK, whichever flavor you prefer, but let's say you have a
ticketing system, a source code repository, a build pipeline,
right? Isn't that making a great
developer platform because it gives the developers all the
things to be productive. And then I was saying, yes,
that's useful, but I coined that the fruit basket, basically
assuming the different systems, you know, like basically the
wiki and the backlog management systems, right, And your code
repository, your build pipeline, they're like the fruit and now
you put this fruit into a basket and that's bundled together.
It's convenient, but it doesn't have like it.
The sum of the fruit is not bigger than the individual
fruit, right? He put four fruit in the basket.
That thing is a basket with four fruit.
So the whole isn't greater than the sum of the parts, right?
The whole is equal to the sum of the parts.
It's a basket with four fruit, and in real life we know the
counterexample. We know the counterexample of
food salad. Now again, it seems trivial
because it's also like fruit in it, but it opens up entirely new
use cases. You don't need tools.
You don't need to peel anything. You don't need a knife.
It's easy to take to a picnic. It's easy to make a mixture that
otherwise you cannot do. If you want to make a fruit
basket and one of your fruit is a watermelon or a jackfruit to
make it worse, right, you're going to struggle to balance
that out. Well, in a fruit salad that is
no problem because you control the mixture.
And what I remind people is the per kilo price of fruit salad is
routinely 2 to three times higher than the fruit because it
has a higher value proposition. So what we learn is like, yes,
food basket is an OK way to start.
You bundle some things together, but don't believe everybody will
be jumping up and down at your fantastic platform because you
didn't really create a whole, you didn't create anything
cohesive. You just bundled a few things.
Maybe you share some accounts or something, but really you didn't
put anything much on top. You just bundled.
So you composed some things but you didn't abstract anything.
So I always much people think about can you make a fruit
salad? And I talked to 1 customer where
folks told me after our meeting they changed their title to
fruit salad maker because they're building an in house
platform and they kept trying to explain to people that sort of,
you know, just like GR and Confluence and a few other
things don't make a really good platform.
But he had a hard time articulating that so he was so
happy. He said fruit salad.
So wherever he goes is we need fruit salad not fruit basket.
And that obviously makes me happy because it means these
light hearted metaphors speak really to challenges that people
have and help them communicate even to upper management or the
famous non-technical people who in many cases are more technical
than some of the developers. But it makes it easy to
communicate the differences and the nuances, and that's what
I'm. Always aiming for, right?
So I think it's always a fun metaphor coming from you, right?
Fruit salad versus fruit basket. I hope people use this whenever
they explain about building platform.
Another thing I think when we talk about platform right,
there's so many probably resources, posts and things like
that related to developer productivity, developer
platform. So in your point of view, in
your experience, what is a good developer platform, What kind of
problem it should solve and what kind of strategy we should build
for developer platform in an organization?
So yeah, that as I mentioned, this is one of the popular use
cases and one that I was personally involved in.
I think there's a a couple of different angles you can take
and we first need to understand that this is actually out of
cloud strategy and also from work at Govtech we called it the
four leaf Clover of application oriented cloud.
So first you need to understand what are all the things that
application needs in its ecosystem, because that's my
candidates for the platform rather than The answer is, is
not that difficult to get to. The problem is, people often
latch onto one thing and forget the other.
So you need a CICD pipeline, you need a build system because
that's how your software comes to life.
You need a runtime underneath, you need monitoring and
observability, and you probably also need some service
integration for things to talk to each other.
All those are good starting points for platforms, right?
If I make it very easy. So basically if I have complete
development environments out-of-the-box, like, I don't
need to do anything and just say what kind of application do I
want to build and it builds that.
Now that is useful. Now interestingly that is so
useful that many base platforms do this.
Now, like I know our things, but Coat Catalyst is basically doing
exactly these things. It's like it's on a template to
give you for development environment, right.
But I think what really helps is to have clarity on the different
parts. So I think observability and
monitoring is often overlooked in these kind of platforms.
And those are areas where having some commonality is extremely
helpful because if something goes wrong, I don't want to look
like 12 different places to find out what's actually happening.
So I would say for teams to build these internal developer
platforms. So there are two parts of
advice, a look at the whole picture.
Too many folks like, oh, platform equals Kubernetes,
right? And they always talk about the
runtime. Well, that's nice, it's all
great. But you're forgetting all the
other pieces. Or people think only CICD
pipeline and forget the other. So see the whole picture.
And 2nd, think carefully about how you're going to build this
over time. Are you going to make a sort of
minimal viable platform and another kind of buzzword?
But are you making something minimally viable for all pieces?
And then you enhance or you do make a really, really good CICD
part, which is like totally awesome, but you're lacking all
the other pieces, right? And both have ups and downs,
right? Like if you're four half
finished pieces, maybe it's very cohesive, but it's maybe not
that feature rich versus the opposite.
It's very feature rich, but it's incomplete.
So there is no easy answer. And the forward of my book has a
warning label like literally. Like it's not all like when you
buy an appliance and it says, you know, don't touch the wire.
So it has like a warning safety label.
And my safety label is the book doesn't give you answers, right.
There's no easy answer. One way or the other way is
better. The book is trying to help you
ask better questions and come to better answers yourself.
And that's the same true here. Both of those are viable routes
and I want to help you be aware of that decision and make that
decision consciously and give you some guidance.
But in the end I cannot tell you which one is better for your
situation. So there isn't a magic scorch
chart or recipe for these developer platform teams to be
successful, but it's more. It would sound a little bit
funny, but it's more around seeing the whole picture.
Decision discipline. It sounds like very fluffy in a
way, but that is by far the hardest part and by far the most
important part. Right.
Apart from developer platform, actually some companies also
think about business capability platform, right.
Things like for example, if you want to reuse some parts of the
solution in the company, right? They want to create a platform
so that other departments or other teams can also reuse that.
Do you also have some advice for people who are building this
kind of a business capability platform so that they avoid that
kind of a loophole or pitfall that people normally go into?
Yeah. And this is actually one of the
frameworks early in the book for delineating in a more fine
grained way. The different kind of platforms
is like in house, people often have technical platforms like
the stuff we just talked about, which is for running
applications and building applications.
And then they often have business platforms and often
they have ecosystem like platforms that connect with
other things. So this is very real and it's
useful. Absolutely.
Again, you know there is more failure modes than one might
think about. And here's the catch that I see
the business platforms, they're stuck in the model of I can
anticipate what everybody needs. And we said right in the
beginning that is dangerous and not exactly what platforms are
about. The picture they tend to use and
the architect elevator actually already makes fun of that
picture is the picture of a pyramid, right.
They say like, oh, I have all this common business
functionality like accounting, HR systems, right.
Whatever I might need that is for all my lines of business and
all my countries. Then I have some other things
that might be country specific. And then I have something like
the little cherry on the cake, maybe a few configuration
settings that just, you know, make the specific market or
product right. It's always that vision.
And on PowerPoint that vision looks amazingly good because
it's massive amount of reuse. And then each solution just has
to like put the little tiny token on top and then everything
is perfect. In reality, this never works and
it's not a platform. It's again the antithesis of a
platform because the platform is not trying to anticipate
everything and it's trying to enable people to build better
solutions. These business efforts, they do
the exact opposite. They're trying to figure out
what could everybody possibly need.
I build this in and then people just need to sort of fill in the
little blank. If they were right, this
wouldn't be so bad. But in reality, it's impossible
to be right on all these things because needs are changing.
You just cannot possibly be so smart.
So my worry there again would be is that the teams who now go on
the platform bandwagon have the same teams who did that before,
who built the pyramids. And my joke is always we stopped
building pyramids 4000 years ago for good reasons, right?
So let's not do this again. But it's the same story as with
the developer platforms. If you have the same teams with
the same mindset trying the new approach, the odds that they
fall back into the old pattern is extremely high and that will
void the whole latform model. And then things get worse that
management will see, oh, this platform stuff actually doesn't
work right. We failed at it.
Who told me that all these platform thingies, right.
And then they hire the consultants for a lot of money
to go fix it and the whole thing goes into some sort of tailspin.
So yes, business platforms very useful, but really you need to
rethink the way you go about making those.
Same as with the developer platforms.
Right. I think there are a lot of lots
of learnings in this conversation about platforms,
right. So I hope the listeners here
after you heard about this from Gregor, right, you rethink again
like the strategy for your platform or if you are actually
building the platform right, maybe you should label it
something else. So it's been a pleasure Gregor.
Unfortunately due to time we need to wrap up pretty soon.
But I have the same question that I asked you in the first
episode, which is I call the three technical leadership
wisdom. You can think of it just like an
advice that you want to give to the listeners here.
It could be related to the platform strategy or it could be
something else as well. Yeah, and one would hope that
over the years I get wiser, so there should be more wisdoms.
At the same time, I think my own bar also goes up.
So let me see what is high on my mind after working on this book.
I think one wisdom I've definitely run into a lot is
that bad architects talking extremes and good architects
talking trade-offs. It's really ever the case that
one thing is the right solution for everything and especially
not a technology architecture. So my wisdom is don't get
latched onto everything must be even driven or loosely coupled,
or Kubernetes or this cloud vendor or that cloud vendor,
right? That is really the right answer.
The other wisdom that I might give is that organizations tend
to reward specialists, right? Like if you're really good at
something, it's very easy to put you in a certain box and you
will do very well. I have friends who do database
tuning and they charge crazy amounts of money because they
are really good at this. Somebody's database doesn't
work. The customer's not happy.
They go in for like a day and charge some crazy amount of
money, but the customer's happy because now everything is
working. So it's very tempting to go this
route. But what I find is that the kind
of solutions that we build also consider being a dot connector,
right? We just talked earlier about,
oh, building this platform is highly technical, it's cloud
stuff, it's queues and time to live in distributed systems, but
it's also domain driven design, very much so.
So my second advice would be look over the horizon and see
whether you can piece different things together because I think
in today's world that might be as important as being a
specialist in some area. And my last advice that I often
give is thinking is the highest ROI activity you can possibly
do. I see too many people who say,
oh, we need to make a decision, oh, let's ask for expert, let's
get an answer, let's move forward.
And when you say, oh, let's think about this like we did
earlier, like, oh, well, the Q versus SQS versus the Ledger
database, right? Like we're sort of musing and
reflecting and it's a little bit abstract.
It's too easy for people to put that away as like, Oh no, we're
not in school here, we don't need to philosophize, we need to
go make a decision and I think that's short sighted.
So my third advice would be take time to think.
Play around a little bit with metaphors and words and
different things, because that time is extremely well spent and
will pay off many many times over.
Wow, really beautiful. I think these are all different
from the first episodes you gave, so I think that's really,
really cool advice. So Gregor, for people who love
to read the book, is there a place where they can find online
how they can reach out to you and things like that?
Yeah, so I'm fairly active on social media.
So LinkedIn is always good and some of my home base for all
these things. As I mentioned the very
beginning, all these books are essentially applications of the
architect elevator concept. So Architect elevator.com is
still the best starting point for the different books and my
blog and everything else. So I'm always happy for folks to
start from there. Thank you again for your time
for this second episode. So I look forward for more
strategy books from you. And thanks again for explaining
about Platform today. Yeah, I'll, I'll do my best.
Yeah. I look ahead for the next, the
next episode when the next book is done.
Always a pleasure. Thank you for listening to this
episode and for staying right until the end.
If you highly enjoyed it, I would appreciate if you share it
with your friends and colleagues who you think would also benefit
from listening to this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at
techlitjournal dot dev website, including the full transcript,
interesting quotes, and links to the resources mentioned from the
conversation. And lastly, make sure to
subscribe to the show's mailing list on techlitjournal dot dev
to get notified for any future episodes.
Stay tuned for the next Techly Journal episode, and until then,
goodbye.