Platforms: Build abstractions, not illusions by Gregor Hohpe

Platforms should enable innovation and diversity rather than constrain - they are meant to standardize the middle layer while allowing variability at the edges

Good platforms surprise you with what users build on top - if you can anticipate every use case, it’s not a true platform. The goal is to enable unforeseen use cases.

Platforms need to use different vocabulary than their implementation - naming things after implementation details creates leaky abstractions. Focus on purpose and intent.

Standards and platforms should harmonize without restricting - they remove constraints to afford more flexibility and innovation, not limit options

Scale economics at the base, speed economics on top - platforms benefit from standardization and scale underneath while enabling rapid innovation above

Static models don’t work for dynamic platforms - platforms deal with change and need dynamic models that account for evolution over time

Abstractions should remove complexity, not just add convenience - sane defaults are helpful but true abstractions eliminate cognitive load

Platform teams should avoid becoming bottlenecks - their job is to enable others, not control everything. Stay out of the development cycle.

Cloud platforms prove you can have both standardization and customization - they standardize infrastructure while enabling diverse innovation on top

Focus on business/technical domain understanding - successful platforms require deep knowledge of both technical capabilities and business needs