Path to Production as a Service

Across our customer and prospect portfolio, BATs are reporting that platform teams struggle with a number of common issues, including adopting new team practices and philosophies, creating a platform that generates developer demand and scales to meet that demand, and effectively promoting the platform across their organization. These issues often rear their heads at ugly times, such as when renewal discussions begin. They also are key impediments to accelerating the growth of platform usage within these organizations. This blog discusses a specific description of what it is enterprise platform teams do, Path to Production as a Service, and how guiding our customers and the market to understand that focus can help accelerate both sales and services activities.

Technology Is Not The Service

Pivotal is engaged with many enterprise technology teams that struggle to understand how to deliver platform as a common technology service to their application development customers. We see it at large, multi-faceted organizations where each application seems to result in a custom path to production with a variety of activities that constrain the flow of an application from development to production. We see it at companies whose traditional IT approaches and mentality lead them to focus on enforcing application architecture decisions before they really have a platform available to all development teams. Each customer has its own nuance to these issues, but it seems that all but a few of our most advanced customers are struggling with how to provide a compelling platform service offering.

In the course of investigating two separate problems at the request of account teams and sales management, namely “path to production” complexity and “platform as a product” adoption challenges, I found myself asking many of the same questions. How does the path to production manifest itself in the platform offering? In what ways do the non-development steps in the path to production (such as regulatory, legal, or financial approvals) affect the development experience? What can the platform do to reduce the pain of the overall path to production, not just the build and deploy process itself?

The fact that these questions come up when investigating both issues puzzled me for a while, until I realized there is indeed a direct connection between “path to production” and “platform as a product”. That connection comes together quickly when you ask yourself the question “what service is the platform team offering application teams?” What is the “product?” Is “product” even the right term?

Let’s consider first whether platform teams deliver a product. On the one hand, well-executing platform engineering teams behave very much like product companies. They have product managers, backlogs, OKRs, roadmaps; all the things you would attribute to a tech company building a product for the market. But there are also other activities that these organizations deliver: training for developers and product owners (i.e. onboarding), support, and “marketing”/evangelism to the organization at large. They also run the platform as a managed service, rather than delivering the bits to each team like a product. In the end, I think the skills these teams need to adopt are “software as a service” skills and creating (and constantly improving) their deliverables is a service design problem.

In other words, the outcome the platform team should focus on is not the technology delivered, but an end-to-end service experience that enables and delights their customers, the developers. Now, what is that service?

Path to Production

To answer that question, let’s first understand what developers need the most to help their organizations be successful in their respective markets. There are many ways to look at this topic, but I think many developers have staked their future on three facets: choice, speed, and simplicity. Innovation is key as more and more businesses get good at experimenting in software at scale. The more experiments (of varying types) that they can run quickly, at scale, and with a minimum of toil, the more successful they’ll be.

We call the entire value chain that it takes to identify an innovation—or even a revision to an existing idea—from concept to development to deployment to operations the “path to production.” I am always careful to note that “path to production” is not the same as “continuous integration” or “continuous deployment.” Rather, it is a superset of those practices that also includes planning, prioritization, compliance, incident response, legal, and a myriad of other activities. In fact, there are probably more “extra-development” functions that vary from industry to industry or even use-case to use-case.  

Path to production is the link between application team needs and platform objectives. Designers, product managers, and developers seek choice, speed, and simplicity in getting their ideas through the development process. An inefficient path to production, conversely, requires developers to stop designing and coding, either by generating toil such as writing required documents or updating dependencies, or by waiting for others to complete required activities such as providing approvals or configuring infrastructure. These constraints, in turn, reduce the speed at which innovation can be delivered while raising the overall cost.

Developers want to deliver software quickly without predictable toil, but also without incurring the kinds of issues that would result in unexpected toil or even loss of reputation. The platform team, is tasked with removing or reducing those constraints while providing the core software infrastructure to meet those application team needs. To do this, the platform team must take ownership of certain risk management, innovation, and operations tasks throughout the path to production process. A platform team that focuses on other elements, such as application architecture or legacy policy, at the expense of meeting these needs will fail to build a successful service.

Thus, there is a huge opportunity to expand the field of view from strict developer needs to the set of activities required to complete the entire path to production. Looking beyond build pipeline automation, for instance, to understand how to automate and integrate with approval and auditing tools would create differentiation that would really stand out from those platforms focused solely on CI/CD.

It is easy to see there is room for improvement in all three facets across the simplified path to production value chain I described above if you map the audience and constraints into a table as such:

To take the unique view that it is the total toil for all teams that design, build, deploy and operate software is a unique, differentiated position, and one for which Pivotal is well positioned.