Path to Production as a Service

April 17, 2019 James Urquhart

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:

 

 

Choice

Speed

Simplicity

Concept/Design

 

Audience:

Product/business owners

Security/Compliance

Application Team

Platform Team

Constraints:

  • Types of solutions that can be provided
  • Technologies that can be included in a solution
  • Integration options for existing applications and services
  • Education and knowledge access
  • Policies and procedures
  • Compliance and regulation
  • Output and OKR alignment

Constraints:

  • Stakeholder alignment
  • Budgeting and resourcing
  • Methodologies and artifacts
  • Dependencies on external teams
  • Education and knowledge access
  • Policies and procedures
  • Compliance and regulation
  • Output and OKR alignment

Constraints:

  • Stakeholder dependencies
  • Application integration complexities
  • Toolchain integration complexities
  • Design-work-outcome alignment
  • Education and knowledge access
  • Policies and procedures
  • Compliance and regulation
  • Output and OKR alignment

Development/Testing

 

Audience:

Product/business owners

Security/Compliance

Application Team

Platform Team

Constraints:

  • Programming tool / language / framework options

  • Available services

  • Integration options for existing applications and services

  • Operations and security tooling options/requirements

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • Development activity “toil”

  • CI/CD process times

  • Review and debugging

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • Development activity “toil”

  • Process “toil”

  • Environment complexity and abstractions

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Deployment/Scaling

 

Audience:

Product/business owners

Security/Compliance

Application Team

Platform Team

Infrastructure Team

Constraints:

  • Deployment environment options (data centers, geographies, cloud providers, etc)

  • Deployment method options (blue/green, rolling upgrade, etc)

  • App Team / Platform Team alignment

  • “Production approval gauntlet”

  • Operations and security tooling options/requirements

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • Manual or poorly automated process steps

  • Platform or infrastructure resource availability

  • CI/CD process times

  • Review and debugging

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • Steps required to deploy to production

  • Deployment environments to manage (number and complexity, both in terms of aforementioned options and “dev -> test -> staging -> production” for a single option)

  • Rollout and rollback complexity

  • Availability and Scale management

  • Review and debugging

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Operations/Availability

 

Audience:

  • Product/business Owners

  • Security/Compliance

  • Application Team

  • Platform Team

  • Infrastructure Team

Constraints:

  • Approval of deployment options

  • Incident response options

  • SLA/Support options

  • Operations and security tooling options/requirements

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • MTTR

  • Incident response “toil”

  • App Team / Platform Team alignment

  • Operations and security tooling options / requirements

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

Constraints:

  • Systemic complexities (emergent behaviors from multiple integrated application deployments)

  • Understanding (anomaly detection, observability, modelling, and event memory)

  • Complexity of multiple deployment option management

  • Stakeholder alignment (SLAs, cost of operations, etc)

  • Resource management

  • Incident response

  • Review and debugging

  • Education and knowledge access

  • Policies and procedures

  • Compliance and regulation

  • Output and OKR alignment

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.

 

About the Author

James Urquhart

James Urquhart is Global Field CTO at Pivotal Software.

Previous
Using Microsoft Configuration Extensions with Steeltoe
Using Microsoft Configuration Extensions with Steeltoe

Next
Know thyself
Know thyself

As a company undergoing digital transformation, it’s important to know yourself and what's necessary. You d...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!