Build Platforms That Can Change
Composable platforms give teams room to adopt new tools without rebuilding everything around them. In the final episode of Platform Engineering 2.0, Alan Shimel and Broadcom’s Pankaj Gupta examine that goal. Their discussion covers the fifth pillar of the framework: composable by design.
Gupta describes infrastructure as a set of building blocks connected through well-defined contracts. Those contracts include APIs, policies and service expectations. Each layer should be able to evolve without forcing changes throughout the rest of the platform.
The conversation moves beyond simply offering a catalog of tools. Replacing a CI/CD component, for example, should not require teams to redesign every dependent service. New capabilities, including MCP servers and AI gateways, also need a place within the architecture.
Make Rebuilding a Repeatable Capability
Gupta introduces repavability as a practical test of composable platforms. Teams need to rebuild confidently and quickly when they replace components. They also need ways to compare performance, assess user satisfaction and move traffic between implementations.
This approach adds an operational requirement to modular design. Having interchangeable pieces is not enough if replacing them creates uncertainty or disruption. The platform needs processes that make change manageable.
Shimel raises the challenge of choosing among an expanding range of technologies. Gupta responds that priorities should follow business goals rather than a universal checklist. Buying a curated platform and building one internally remain options, while composition offers another path as requirements evolve.
Set Priorities for the AI Era
For leaders deciding where to begin, Gupta recommends setting a 12-month milestone for an AI-native platform. That target can guide decisions across the framework’s five pillars. Organizations should then identify which capabilities and user groups need attention first.
Priorities will differ. Teams already running substantial AI workloads may face urgent FinOps needs. Organizations responding to security incidents may emphasize stronger platform-level protections. Developers, platform engineers, AI engineers, business leaders and security teams also bring different requirements.
The series closes by framing Platform Engineering 2.0 as an evolution, not a reset. Skills, culture, cost and complexity all influence that journey. The aim is a platform that can support new workloads and users while remaining adaptable as technology changes.