Have you ever observed how businesses zero in to platforms as if they would solve world hunger? Just install this platform and all your worries will melt away into a well-organized suite of solutions that magically bring agility and resilience to your business. There would be an unified solution ecosystem, one set of skills and SOPs, and one metaphorical throat to choke.

Trouble is, you’re buying a scaffold and not a house. It will help build the house, but it is not the house.

The problem lies in human nature. The human brain is hardwired to seek validation, which directs it to look for easy solutions. That in turn encourages ersatz approaches. Soon we’re designing to solution and not to outcome.

Organizations like the CNCF unwittingly encourage this. It may be comforting to think that one just needs to plug in an application in a framework to cover a use case, but it’s rarely that simple. The CNCF ecosystem is a great idea and a wonderful resource, but there is a large maturity gamut in the applications available there. There’s a gonzo spirit of experimentation and iteration that really encourages innovation and alternative approaches, and that’s brilliant in itself. Leveraging it for consistent results is up to the architect and the developer.

And that’s where human proclivities show up.

For architects and engineers, solutioning is a drug. It helps them get a dopamine hit when they plug a hole in functionality with a product. When you deploy an opinionated platform you buy into the risk profile of that platform. There may be 100,000 products that can hang off of that, and this brings on the problem of abundance of choice, sapping precious bandwidth that could have been better used for actual architecture. So now instead of focusing on the desired outcomes, architects lose themselves in analyzing the comparative benefits of components. In time these choices make the platform the foundation instead of the scaffolding, and it starts to atrophy. Pretty soon you’re sitting on an inflexible shipwreck with components growing like barnacles all over it.

This is why changing the perception of platform as solution is so critical. My friend Jamil and I discussed this one morning around a presentation he was delivering at PlatformCon. He sought to reframe the conversation around platforms — to call them as they really are. Yes, a platform is a product. It is, however, not a solution by itself. Think of a rebar cage before concrete is poured into it to form a column. It is structural support but not the building itself. You can of course build without that rebar cage, but it would take a lot of extra effort and experience.

So how should we talk about platforms then? Let’s try this on for size.

• A plaform is a framework with an opinionated baseline solution built in. It is NOT the target solution.
• A platform is a product. Like any other product, it has features and risks, and barriers to adoption that have to be dealt with.
• A platform is hardly ever an exact fit — it needs customization to deliver a solution set.
• A platform is an investment. You are making a commitment to its benefits, its limitations and its ecosystem.
• A GOOD platform is an accelerator. It brings with it the ability to evolve and help evolve solutions based on it.
• A GOOD platform is based on a loosely coupled framework. This may be fighting words for some, but bear with me.
• As a platform is baked in, it becomes more rigid. That’s natural.
• GOOD platforms can grow laterally, with a clearly navigable dependency map.
• A GOOD platform is tiered, with enough abstraction built in to enable switching out of components without affecting core solution functionality.
• A GOOD platform encourages iterative development instead of hidebound legacy. It does this by leaving enough gaps between the metaphorical tiles, not strongly coupling components.