Thoughtful Friday #12: Thin vs. Fat Platforms
Thoughtful Friday #12: Thin vs. Fat Platforms
I’m Sven, and this is Thoughtful Friday. The email that helps you understand and shape the one thing that will power the future: data. I’m also writing a book about the data mesh part of that.
Let’s dive in!
Time to Read: 12m
Twitter has an amazingly “thin” interface.
You should build thin interfaces as well.
Platform faces are NOT APIs, they can also include docs, best practices, and much more.
🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮
11 years, from 2006 to 2017, that's how long it took Twitter to change its maximum tweet length from 140 to 280 characters.
Twitter is very conservative with changes to the most fundamental parts of its platform. Because they are truly that: A platform. But not only that, they are what I’d call a “thin platform”.
If you read my newsletter often, you will have stumbled over the components of any kind of platform somewhere:
complements (the users of Twitter)
the kernel (the internals of the Twitter beast)
and the platform interface.
The platform interface is everything that should stay fixed in order to let the users get value from the platform. And the length of the tweets certainly is a very important part of that!
Twitter knows exactly, that this interface is large and comprehensive and doesn’t just consist of some kind of API. Best practices, services around it, and a lot of things make up the true platform interface.
Key Point: So Twitter does, what every platform should do - to keep this interface as fixed as possible. Changes per part of interfaces: one in every 11 years. That’s about right!
But Twitter does more because there is a second consequence to the platform interface concept. It should be minimal - or thin!
Why is that? Because the fatter the interface, the less I can change internally. But the whole point of a platform is to advance internally while keeping the interface fixed to deliver more value to the parties connected to the interface.
Minimality for platforms also implies ease of use. Take the Twitter search function for instance As you can see below, the quick search actually is dead simple to use, all more advanced functionalities are hidden behind layers and layers which you need to peel off.
But this layering enables Twitter to keep the interface as simple as it is.
Key Point: Every platform interface should be thin, and thus simple to use. Layering helps to hide complexity while still providing full functionality.
Why is a platform interface not thin if it’s hard to use? Because then, whatever is needed in addition to using it, becomes part of the interface! If you need lengthy documentation to make some API work, then the documentation will become part of the platform interface and hence “fattening it up”. This in turn will mean, you won’t easily be able to change the organization of the documentation or the location. Then people soon wouldn’t be able to find the docs and thus not able to use the API.
Key Point: Even if an interface seems thin, it might “fatten up” by being complicated to use. Complication means we need something in addition to the interface to make it work.
Why Fat Platforms Inhibit Their Own Growth
Let’s take a look at an example. The company DataKitchen produces a platform, tooling to enable users to quickly extract value out of their data with this platform. The platform helps users to implement DataOps best practices.
But, the platform puts a lot of weight on its own terminology and concepts. If a new employee joins a data team that utilizes the DataKitchen platform, he will likely be lost. He’ll need to understand “Kitchens” first, then “Recipes” and how they interact. He might need to map his knowledge of other concepts like environments (which are mostly Kitchens) onto these. Basically, the new employee will have to become a DataKitchen expert to start being productive.
Note: I am a fan of DataKitchen as well as the content they are putting out. Based on what I can observe from the outside, this process won’t take long, becoming a DataKitchen DataOps expert won’t take up too much time. And I am not very familiar with the platforms’ details in general, so I might be completely off in my assessment.
Fat platforms feel a bit like using Jenkins as a CI tool. Because Jenkins is such a complex tool - and never tries to hide that complexity behind layers, if a company opts to use it as a CI tool, it will require at least one Jenkins expert on every development team using it.
The problem is, that this inhibits the growth and value creation of the platform itself by a lot! The fatter the interface of the platform,
it's either going to take longer to adopt it because you need to train the Jenkins expert
or the interface will become stale because you need to have a Jenkins expert, or lots and great documentation
This leads to a lower adoption rate in general. Because platforms aim to grow through the value that is created by adding more people to the platform, this is a fundamental problem.
Key Point: fat interfaces inhibit the growth rate of the platform itself.
Summary
Don’t get me wrong, it’s totally fine to build a platform like DataKitchen or Jenkins. These platforms target user groups that are willing to take that on, willing to train people to benefit from the platform.
In fact, the big cloud vendors thrive on creating a lock-in effect on their platforms by fattening up their interfaces - like AWS where you still have to use “AWS CloudFormation” to properly work with infrastructure.
And you also see that people try to hide that complexity by building thin interfaces on top of that - like Terraform or Pulumi.
What I am saying is: If you put in the extra effort necessary to build a thin platform, you might be able to tap a much larger user pool and thus create a larger growth multiplier each year.
So, how did you like this Thoughtful Friday?
It is terrible | It’s pretty bad | average newsletter... | good content... | I love it, will forward!