Part IV: Designing Platforms

With the widespread success and potential of platforms, it’s tempting to want to build one in your organization, perhaps to streamline application delivery or as the foundation of your organization’s business. That’s generally a sound idea, but, as so often, there’s a lot more behind other companies’ platform success than might appear from the outside.

Designing and building a successful platform requires more consideration and engineering effort than many teams anticipate. Some organizations spent considerable time and effort to build elaborate platforms that, upon launch, didn’t find much adoption. This part highlights critical design decisions that guide the shape of an in-house platform. As platform design is a complex topic, the chapters in this part suggest real-life metaphors to highlight the decision trade-offs and nuances. Those mental models can also be helpful when assessing third-party platforms.

• Architecture is often defined by quality attributes, and it’s no different for platforms.
• A good platform is more than the sum of its parts, so choose carefully whether you are designing a Fruit Salad or Fruit Basket.
• Platforms are generally seen as horizontal elements, but they often sit on vertical pillars.
• In-house platforms that build on top of external base platforms need to decide whether to float or sink.
• Platforms can make great abstraction layers, but it’s all too easy to fall victim to the Grim Wrapper.
• Platforms reduce cognitive load by hiding complexity. But hiding too much can lead to dangerous illusions.
• Even the most awesome abstraction crumbles when failure rears its head and reminds you that it doesn’t respect abstraction.
• A lot changes for platforms for an AI-led SDLC, but some things remain the same.