This post has been excerpted and adapted from the 2022 DevOps Enterprise Forum Guidance paper The Role of the Platform by Satya Addagarla, Josh Atwell, Mik Kersten, Thomas A. Limoncelli, Sara Mazer, Steve Pereira, Jeff Tyree, and Christina Yakomin.

1. The Balance Between Standardization and Flexibility

To achieve a productive and sustainable flow of engineering effort, find a happy medium between too much restriction and too much flexibility. Having too many restrictions can lead employees to shortcuts around the rules, while having too much flexibility can lead to complexity and a lack of resource coverage. It is important to have enough stability and predictability to allow for clear management and to minimize chaos and duplication of effort, while still allowing for innovation and employee autonomy.

• Make Standardization Easier than Alternatives: Rather than forcing teams onto standardized platforms, platform-engineering teams should aim to make their standardized approach the obvious alternative.
• Known Good Practices by Default: It is during platform rollout that well-planned defaults are particularly powerful. Everyone is new and unsure, so adopt effective and easy-to-use practices, processes, and procedures up front, so that developers will not be tempted to go their own way. Done properly, we nudge developers to “fall into the pit of success.”
• Value at Context: Standardizing tools for developers will help them become more familiar and will reduce the team’s cognitive load. Therefore, we recommend creating standards within and around tools already in use.
• Operational Simplicity: Platform-engineering teams building foundational platforms should take care not to overengineer their platforms to the point that they become too complex to understand. Even though the development teams didn’t design the platforms themselves, they should have a fundamental understanding of what they are and how they run. This is necessary if they are to be responsible for the operational health of the systems, including incident response.
• Treat Standardized Platforms as Products: Standardized platforms should be treated as first-class products, just as external customer-facing products are treated. 

2. Recommendations for Flexibility

We have provided numerous recommendations on how to design and develop standardized platforms for developers and the teams that support them. When applied, they should provide a framework for greater work productivity. There are two important considerations that exist throughout our recommendations for platform standardization:

• Change is constant: what works today may not work for long.
• The best tools are adaptable: what works for most may not work for all.

Even when considerable effort is applied to provide robust and effective standardized platforms, everyone involved should recognize the need for the platform or system to change to meet evolving needs. These changes will be most effective when done in partnership with the developers using the platform and when providing them with specific frameworks to aid the evolution of the platforms they use.

Platforms should provide a path to experimentation, customization, and evolution.

To facilitate experimentation, as described in Sections 1e and 2b of the full Role of the Platform paper, the platform should provide open access to suggest improvements so that developers can:

• Suggest changes to documentation.
• Issue a pull request against platform components to make configuration or code changes.
• Propose and/or develop new features or capabilities that can be made available in the platform.

To facilitate customization, the foundations of a platform should be small, composable, and have interconnected components like APIs. Developers can:

• Integrate platform capabilities with other systems via access APIs from various platforms (Slack, command line, and other services).
• Create new and novel solutions based on some or all of the APIs available.

To facilitate evolution, a development platform should be paired with a management platform to provide feedback on performance that can inform improvements. Whereas a development platform provides capabilities for delivery, a management platform provides observability into the work performed within the development platform and beyond. It can capture issues and allow for informed decisions on how development can best evolve.

Two terms for development and management platforms have emerged from Gartner’s analysis of the platform ecosystem: value stream delivery platforms (VSDP) and value stream management platforms (VSMP). The two work together to support action and observation.

• VSDPs provide access to capabilities that enhance and support development, and VSMPs provide visibility and measurement of development activity.
• VSDPs provide a broad range of capabilities supporting end-to-end development such as CI/CD, infrastructure provisioning and management, testing, access control, and visualization of activity at the team level.
• A VSDP can provide self-service automation and support for development and delivery requirements
• A VSMP can provide insights on where friction or delay is present in developer workflow from a more holistic perspective, especially at the organizational level. These insights can inform improvements to the VSDP.

In general, we recommend that platform development consider the following guidance:

• Apply an Minimum Viable Product (MVP) Approach: A platform doesn’t have to be a fully automated, self-service digital experience from day one. A standardized platform providing clear and accessible support to its users may be its primary value.
• Treat Platforms Like an Open-Source Project: Organizations are increasing their adoption of open-source-development methods for internal development, termed InnerSourcing. Successful adopters are finding that the practice accelerates project delivery, improves quality, and empowers the development of shared features by embracing cross-collaboration at its core. InnerSourcing your platform development makes it easier to allow prospective users to contribute new use cases and improvements to your standardized platform. Users should be able to contribute a feature that isn’t on your road map.
• API First for All Platforms: Internal platforms should adopt an API-first approach for self-service to reduce the friction between platform-engineering teams and development squads. The primary goal is to reduce the cognitive load of developers and to create a ticketless interaction model between the engineers who leverage the platform and those who operate the platform.

Conclusion

Once an organization decides to roll out an internal development platform, it is important to have enough stability and predictability to clearly manage the effort, minimize chaos, and reduce duplication to continue to allow for innovation and autonomy. Here we provide a set of recommendations to achieve a successful rollout, starting with an MVP, treating the platform like an open-source project, taking an API-first approach, and managing the platform like one would manage external products.

By standardizing on a platform, an organization should be able to achieve the following business benefits:

• Cost reduction
• Cost and waste avoidance
• Agility
• Efficiency
• Visibility
• Continuous improvement
• Auditability
• Scale

Finally, a capable platform can be defined and built once and then leveraged across the entire organization. A platform improves onboarding and offboarding, access, confidence, focus, flow, and joy. It provides a mechanism for elevating engineering across the organization when improvements are made and features are added: a rising tide that raises all boats. 

To read the full set of recommendations, please download the full Role of the Platform paper here.

- About The Authors

Satya Addagarla

CIO Home Lending at Wells Fargo

Follow Satya on Social Media

• 

Josh Atwell

Multi-disciplined marketing and technology leader who has moved from hands on technology to leading marketing and advocacy teams to improve customer enablement and engagement.

Follow Josh on Social Media

• 
• 

Mik Kersten

Dr. Mik Kersten started his career as a Research Scientist at Xerox PARC where he created the first aspect-oriented development environment. He then pioneered the integration of development tools with Agile and DevOps as part of his Computer Science PhD at the University of British Columbia. Founding Tasktop out of that research, Mik has written over one million lines of open-source code that is still in use today, and he has brought seven successful open-source and commercial products to market.Mik’s experiences working with some of the largest digital transformations in the world has led him to identify the critical disconnect between business leaders and technologists. Since that time, Mik has been working on creating new tools and a new framework for connecting software value stream networks and enabling the shift from project to product.Mik lives with his family in Vancouver, Canada, and travels globally, sharing his vision for transforming how software is built.

Follow Mik on Social Media

• 
• 

Thomas Limoncelli

Thomas Limoncelli is an internationally recognized author, speaker, system administrator, and DevOps advocate. He manages the SRE teams at Stack Overflow, Inc., and previously worked at Google, Bell Labs/Lucent, AT&T, and others. His books include Time Management for System Administrators (O’Reilly), The Practice of System and Network Administration (3rd edition), and The Practice of Cloud System Administration. In 2005, he received the USENIX SAGE Outstanding Achievement Award.

Follow Thomas on Social Media

• 
• 

Sara Mazer