Designing Development Velocity: A Platform Builder Playbook

Before automating environments for the ultimate modern development experience, platform providers (builders) need a vision and game plan. This guide aims to streamline the process of preparing, ideating, and starting or taking a cloud-native platform project to the next level of success.

What is development velocity?

Development velocity is the time it takes to complete building, testing, and releasing modern software products ready for customer usage. A product can be an entire cloud-native application, a new microservice feature, or a fix to a defect. The ability to maintain a continuous creative process and stream of high quality apps is the desired state of velocity for most software engineering teams.

Development velocity is a desired state and result of experiencing a continuous, high quality stream of creative value for the benefit of customers. It is measured across the development lifecycle including developers, test execution, QA, and running live in production.

What are the current roadblocks to development velocity?

There is an automation gap between cloud-native development and production environments that significantly slows down creativity and development of microservices apps, and consequently, is getting in the way of delivering innovation into the hands of real customers. The gap is most visible in the lack of a modern development experience that removes the friction and toil associated with creating cloud-native applications.

The most exciting project in platform engineering today is the automation of a modern development experience. The experience designs a new abstraction interface and modern development stages for developers to automate the execution of cloud-native environments that are production-like. This self-service development experience is a critical foundation for speeding up the creativity and delivery of microservice applications, from development-to-production.

Development experience automation is the process of "productizing" a modern abstraction interface as the design centerpiece for unifying, executing, and governing cloud-native environments.

How to automate development experience and increase creativity?

Cloud architects and production teams are deploying cloud-native infrastructure platforms like Kubernetes to improve on-demand service delivery, scalability, and the quality of service.  Now, platform teams are designing development environments to mirror production environments and shift left the ability to preview, test and qualify features and microservices to development.

However, development teams must now reduce friction, shorten execution time, lower the complexity of modern app development and testing, and close the gaps between development and production environments. Using local platforms, devops pipelines, and scripted provisioning have not enabled a seamless modern development experience, leading to increased friction, development toil, and reduced velocity and confidence.

"The ultimate goal is to create joyful development teams that can increase innovation for their customers."

Designing a self-service development experience

The opportunity to automate environments with a self-service development experience from development-to-production is now a reality. This is due to the new levels of abstraction and runtime architecture alignment resulting from the growing usage of containers, microservices, Kubernetes, and cloud-native infrastructure tools and automation.

Platform engineers can design a new interface that provides a self-service, end-to-end developer experience and an environment execution architecture that is more unified, automated, and governed than previous versions of local, siloed environments.

Using a self-service modern interface frees both platform engineers and developers from the need to build and maintain custom automation software, which makes more time available for automating developer experiences.

How taking a Development Experience-first Approach enables Development Velocity

Automating the end-to-end provisioning and de-provisioning lifecycle is just one aspect of achieving a modern development experience. Adopting a development experience-first (devX-first) design approach focuses on bridging the gaps between developer creativity, application delivery, and full-stack application configuration administration. This design approach aims to standardize the user experience by using unified, intuitive, and automated concepts, functions, and lifecycle-specific workflows.  The goal is to make the need for  development environment administration totally automated and transparent.

With the development experience automation platform, development-to-production environments can be managed without burdening developers, testers, and delivery engineering teams. By standardizing and modernizing the development experience, the interface and platform adoption increase the visibility, trust, and control of configured development-to-production environments for the entire development team. This allows "The Developers (i.e., the Consumers)" and "The Platform Engineers (i.e., the Providers)" to focus on increasing creativity, confidence, and collaboration. The result is increased development velocity and shipping modern apps.

How to plan for the DevX Consumer (User) and DevX Provider (Builder)

DevX Consumers (Users)

DevX consumers (users) include application and container developers, test and QA engineers, extended product team members, staging and SRE engineers, and production engineers. They all require environments for development, delivery, and production. Consumers also include automation software / tools that require runtime environment deployments via APIs. For example, provisioning environments enabled with every pull request (PR) for test automation.

DevX Providers (Builders)

DevX providers (builders) are the platform/devX engineering teams that design and implement platform automation to deliver execution environments that provide the next modern development experience across every stage of the modern lifecycle. These providers are responsible for both provisioning environments to their entire development and deployment team and engineering the next modern experience platform. The "provider of environments" is forming into a new skill and team with development experience automation as a critical internal deliverable and service responsibility.

Summary

This playbook is a valuable tool for platform and devX engineers and architects who are aiming to close gaps that slow down progress towards achieving a higher velocity in the development-to-production modern lifecycle.

This exciting platform engineering practice has the potential to reach a new level of development usability, ease-of-work environment, and environment automation for an entire modern, cloud-native experience. The guide highlights the need for:

• Creating a New Level of Abstraction (The Missing DevX Interface). This presents an opportunity to automate environments with a modern development experience from development-to-production.
• Taking a Development Experience-First (DevX-First) Approach. Automating environments with the next modern development experience involves more than automating the end-to-end execution environment lifecycle.
• Planning for both Development Experience Consumers (Users) and Providers (Builders).  The “provider of environments are the builders.  DevX consumers are the internal customers.

The ultimate platform builder vision is a joyful development team continuously innovating for their team and customers.

To learn more, get these playbooks:

David ButlerView all posts