I recently started an email list named Platform Thinking. You can subscribe here or read the posts in this topic. Comments are welcome in this topic thread.
Introduction
Product development is hard.
Technical debt tends to accrue at a frightening pace.
A “Platform” approach helps you reign in the chaos.
And provides a framework to reuse, scale, and leverage your efforts.
This newsletter provides tips each weekday to help you in the journey to “Own your Platform.”
The tragedy of no constraints
We never have enough time, resources, funding, CPU, storage, etc.
However, think what would happen if we had infinite resources.
We would never get started because we have forever to do it.
With unlimitted resources, we tend to make a mess and get sloppy.
Getting everything we want leads to bloat and lethargy.
Platforms are a long game, and but no contraints encourages short-term thinking.
The Beauty of Constraints
Constraints are what guide us to good solutions.
Software that is simple enough that average developers can actually understand it.
A user interface that is intuitive.
A system we can deploy without a dedicated SRE team.
Hardware created with open tools that anyone in our organization can maintain.
An architecture that can scale in unforeseen directions.
Flexible core data structures that rarely change.
Platforms are all about constraints.
What is your Platform?
What is a Platform?
There are many ways to look at this. Some might think of AWS, GCP, iOS, Android, etc.
These are certainly platforms, but they are not your platform.
Your platform is the collection of technology, tools, and processes you use to do what you do.
This may be building products, delivering services, developing people, etc.
Simplicity
What is the role of simplicity in your platform?
Simplicity makes it easier for people to use your platform.
Simplicity helps ensure maintainability.
Simplicity moves us toward reliable and secure platforms.
Simple is not easy, actually it’s much harder than complex. But platforms are a long game.
Complex Systems, Simple Platforms
The word “simple” in the context of modern systems may seem like an oxymoron.
We can’t deny that modern systems are complex – they need to be to do the things they do.
The role of a Platform is to reign in this complexity and create a way to effectively manage and interact with the system.
Platforms narrow our focus to the problem we are solving.
Platforms decouple us from being too entangled or dependent on any one technology or system.
Platforms are the abstraction on top of complex systems that make them workable.
It’s about not starting over every time
Platforms are about reuse.
Not starting over on every new product.
Leveraging what you have done before is one way to scale your efforts.
Reuse takes practice and experience to get it right.
Effective platforms are an art.
The long game
Platforms are long games.
If you are building a one-off consumer product that will not be maintained, improved, or ever change, then you probably don’t need a platform.
However, if you are building an long-lived industrial product that will be maintained, or a series of related products, then it gets very expensive to start over every time.
To effectively maintain multiple unrelated products, or a system that that is difficult to update, improve, test, and deploy is a recipe for cripling technical debt.
The expectation today is things will improve over time, because software can be updated. It is not really optional any more.
And with the complexity of systems today, the odds you’ll get perfect on the first release are near zero.
Build for the long game.
Why do we need some level of control?
In today’s connected systems, some level of control of your Platform is needed.
Security problems needed fixed.
Problems needed debugged.
Problematic subsystems need swapped out.
Suppliers go out of business.
Parts go obsolete.
New customers require new features.
We may want to leverage new technologies.
New Open Source projects become available.
We obviously can’t control every detail, but we at least need enough control to adapt and respond to change or the unexpected.
Control is required because we can’t predict everything up front.
With complex systems, this is more true than ever.
What is control?
What is control in the context of Your Platform?
Control is simply the ability to respond to opportunities and problems.
In modern systems we are very dependent on others as there is no way we can do everything ourselves.
But we can also strategically retain enough control so that we can adjust and adapt as conditions require.
We have more options today than ever before.
We may think putting all of our eggs in the “big company” basket is the path to safety.
But if we open our eyes, we soon realize this does not always work.
“big company” may discontinue a service we depend on.
“big company” may have an outage.
“big company” may have security problems.
There is nothing wrong with using “big company” as long as we have the option to move when problems or opportunities require it.
Lock-in is a good short-term strategy, but is rarely beneficial long-term.
Control is a scary thing
Control is a scary thing – because then we are responsible.
And if we are responsible, then we can’t blame someone else.
But if we are not responsible for anything, then what are we doing?
How are we adding value?
Why would anyone want what we are doing?
The smaller you are, the more import YOUR Platform is
This may seem like a contradiction – how can small companies afford to own and control their Platform? Should not this all be outsourced? “Platforms is what large companies do.”
Actually, the reverse is true. Netflix can afford to build on AWS and be locked into the AWS platform because they have enough volume that they have clout and the ability to negotiate. Amazon will make sure Netflix gets what they need.
Small companies cannot get this type of support.
Does this mean “small company” should never use AWS? No, certainly not – AWS is a good option for many things.
But it does mean that we only use stuff in AWS that we can migrate elsewhere if needed.
Use managed Postgres instead of some proprietary AWS.db.
Use NATS running on EC2 or managed at Synadia instead of a proprietary event system.
Owning YOUR Platform does not mean you build all of it, but rather you have some level of control over it. You have options.
And the smaller you are, the more important this is.
Do something different
If you only build on other people’s platforms, how are you different?
And if you are not different, what value are you providing?
We are not talking different for the sake of being different – outlandish, rebel, etc.
We are talking being different in the sense of offering something better – something that no one else is doing.
Something you can do pretty well.
Something that helps others.
And to do this, you need to own YOUR Platform, otherwise, why would anyone come to you?
False vs Real Platform Development
A common objection to investing in a platform is that it is “too expensive.”
“We want to get it right, lock it down, and then crank out our product and make some $$$.”
Many managers and owners are wary of platform development because they have experienced false platform development – endless tinkering, the costly pursuit of perfection, etc.
However, real platform development is focused on shipping as soon as possible and then improving.
Real platform development is realizing that complex, connected systems are dynamic, living things that need maintained. They do not operate in isolation.
Real platform developers have the humility to realize they can’t see and understand the big picture up front until they build something and get feedback.
The key to controlling costs is not locking things down such they cannot change, but rather the opposite – improving your process so that improvements are efficient to develop and and painless to test and deploy.
Owning YOUR platform is not more expensive
Owning your platform sounds expensive.
“We can’t afford ops people to manage servers.”
“Security is scary.”
“We don’t want to manage a database.”
However, at the scale of most industrial products, none of these things are very hard.
A couple servers can easily handle all your traffic.
A backup and restore plan can handle failures in most cases. Redundancy and high-availability are overkill.
Cloud services require management too – often you end of managing the cost instead of the fundamental issues listed above. Six of one, half-dozen of the other – take your pick. And then you still have to deal with problems – often due to the distributed nature of cloud services where the network is the weak link.
See DHH’s posts on “leaving the cloud” for an example. They are saving millions owning and managing their own servers and it is not any more work.
You can hitch up to one of the major cloud vendors and go all in on their services – that is what everyone else is doing.
Or you can do something different. Take the technology that is being developed for the cloud, use the cloud where it make sense, and then optimize for YOUR Platform.
You are not Google
A blog article published 2017 titled You Are Not Google is a good read. This article makes the case that most companies are not operating at the size of Google, Amazon, and LinkedIn. Thus, most of us are solving different problems than the big 5 tech companies.
YOUR Platform needs to fit your problems at your scale.
If one server will work, then you are saving yourself untold pain and suffering by not pre-maturely building a distributed system.
If one monolothic application can run your product, then you are saving a lot of hassle not implementing microservices up front.
Keep it simple – you can move to distributed micro-services later – AFTER you succeed at a smaller scale.
And if you succeed at small scale, then there will be plenty of resources to adjust your architecture later.
The quicker you can get to a MVP, the better, and simple gets you there quicker.
But what if ??? … stay tuned 
But what if …
In the last post, we discussed the fallacy of using complex technology when the scale does not justify it.
But, what if we get a lot more customers, or sell a lot more systems? Should we not plan for the future now? Use technologies now that will work at large scale? We don’t want to paint ourselves into a corner such that we end up with a system that won’t meet our needs in the future.
Certainly, we should keep the future in mind, but the most important way to plan for the future is to streamline your processes and development workflow now so that you can continually move toward the future as it comes.
NOT try to implement the future now. That is costly, and you’ll never get it right that way.
Some decisions are important now and some are not.
You don’t need to use Kubernetes now – you can add that in later. But it is important to use some type of automated configuration and deployment – perhaps a simpler solution like a simple Github Action, or Ansible.
The same with micro-services. It is easy to split things apart later as it makes sense. But it is difficult to deal with a mess that is prematurely split up.
You can plan by using a decoupled architecture, data structures that are flexible, and modern programming languages that are efficient.
If you have an efficient workflow where it is easy to make and deploy changes, the correct architecture will naturally emerge. You will continually simplify things as you see common patterns.
And simple patterns are what scale to any problem.
What is YOUR Platform? (v2)
Had a nice visit with Rod and he asked me to describe what a Platform is in 20 words or less, so here we go:
YOUR Platform is the collection of technology, tools, and processes that enable you to differentiate and consistently deliver your products and services.
sorry Rod, that is 22 words
We have discussed this before, but I want to revisit this question occasionally and see if the definition improves over time.
What got added this time is “differentiate” and “consistently”.
Thoughts?
What are the first steps?
What are the first steps to building YOUR Platform?
Ironically, the first step is not some grandiose new Platform vision, but rather to set your house in order.
Clean up what you already have.
Fix legacy code (code without tests).
Set up CI/CD.
Implement end-to-end testing so that you can deploy with confidence.
Write documentation.
This paves the highway for efficiently moving forward, instead of slogging through the mud.