A software-defined platform represents every integration, feature, automation, and technology as deployable software artifacts managed through versioned source control and coordinated continuous integration and delivery pipelines. This makes platform engineering a software-engineering discipline rather than a collection of manually operated infrastructure procedures. section 1.3.3 section 2.2
Apply the pattern by replacing manual infrastructure habits with consistent product-development practices:
- Represent integrations, features, supporting automation, and technologies in versioned source control and deployable artifacts. section 1.3.3
- Treat the infrastructure lifecycle like software development, rather than relying on checklists, clicks, manual uploads, or human verification at every step. section 2.2
- Use the platform’s own development tools and technologies internally through dogfooding, and agree on shared practices in a team charter. section 2.2
- Build observability into every feature, capability, and technology, while using incremental architecture and architecture fitness testing to support change. section 2.4
An incremental platform delivery pattern
Start with one engineering platform delivery team that establishes architectural foundations. Test an initial experience with alpha users, measure expected value, and expand delivery teams only as needed capabilities emerge. Keep each capability observable and evolve its implementation through the product backlog. section 2.4
Figure 1.5 Software defined is placed in the middle because it is a core attribute of everything the platform engineer delivers. The rest of the principles share a connection because they continuously evolve, and decisions made in applying these surrounding principles can affect the requirements of the others.
The figure places software-defined at the center of platform engineering, showing how surrounding principles interact and evolve with it. section 1.3.3
