Is Platform Engineering a Value Stream?

In this, the fourth of a series of blog posts from the Value Stream Management Consortium, our experts weigh in on, “Is THIS a value stream?” This time, we’re looking at Platform Engineering.

Is Platform Engineering a Value Stream?

Patrice Corbard, Founder of SD ReFocus and Influencer Member of the Value Stream Management Consortium:

YES, as a reflex response by applying the famous quote from John Shook and Mark Rother in their book Learning to See:  “Whenever there is a product for a customer, there is a value stream.” 

• A platform is a product delivered to internal customers
• A platform brings value, even if senior managers can sometimes struggle to understand it according to the 2023 State of Platform Engineering Report by Puppet

What Value is Delivered? 

Clarifying the value expected by customers of the product or service is fundamental to the identification of value streams. In summary of its benefits, a platform brings both: 

• Technical value to its users by reducing their cognitive load, automating workflows, standardizing security and compliance policies, and improving their experience; 
• Business value to the enterprise by letting teams focus on delivering value to the end customers, using self-service capabilities that eliminate dependencies and facilitate a fast flow of software delivery.
  
  

Platform Teams are Aligned to a Value Stream to Deliver a Platform as a Product

If the delivery of an application is well recognized as a value stream and named as such in the book Team Topologies (stream-aligned teams), it is time to do the same for Platform Engineering. 

Platform teams are also aligned to a value stream to deliver products, services, or experiences to internal customers (see Gartner’s definition of a value stream).

So, IMO there are two types of product teams: 

• Application Teams responsible for Application Software Delivery (ASD) value streams, that we can name “Application <x> Team” 
• Platform Teams responsible for Software Delivery Platform (SDP) value streams, who provide support to Application Teams, and that we can name “Platform <y> Team”
  
  

Consider the Whole as a Value Stream Network 

In reality, an organization builds and maintains more than one platform (generally between 2 and 4 according to the Puppet report). Each platform provides self-service capabilities that can also be seen as individual products, and thus seen as more granular value streams. We then have a network of value streams that takes shape as shown in the example below:

Map the Platform Engineering Value Streams

At a high level, Platform Engineering can be represented as an extended value stream, with its sequence of activities to continuously evolve the services provided by the platform(s):

Once this has been achieved, in the same way as for application value streams, it is now possible to map the value streams further by distinguishing the workflows handling the different types of client requests (see our first article of this series of blog posts “Is Incident Management a Value Stream?”).

Make Value Visible! (Or Be Able to See the Forest for the Trees)

What is crucial is to always maintain a systemic view focused on the value delivered to the end customers. The efficiency of each of the internal platform’s value streams is only interesting in its alignment with the value delivered by the applications to their end users and the achievement of business outcomes for the company. This is why the goals, metrics, and incentives of the platform teams need to be aligned with these business goals, the value to the customer and the enterprise, and improving the employee experience, and not with internal metrics of productivity, utilization rates, etc.

To conclude, YES, platform engineering should be seen as a value stream or more realistically as a part of a network of value streams whose global vision must be kept focused on achieving business outcomes. Otherwise, we risk falling back on the separation of responsibilities and the construction of new silos. We are not interested in local optimums, we’re in pursuit of global optimization. 

Platform Engineering is an interesting part of the possible answers to the challenges ahead in 2023, especially if we adopt a value stream management approach to their implementation. The Value Stream Management Consortium and its membership community of partners, consultants, or coaches like SD ReFocus can help you with this.

—

Helen Beal, Chair of the Value Stream Management Consortium and Co-Author of the Value Stream Management Foundation Course and Certification:

I’m a hard YES on this one. But I think there is an important differentiation to point out:

• Platform Engineering: A discipline for building self-service applications A.K.A platforms for software engineering teams
• A Platform: A self-service application for software engineering teams

So we’re not talking about the process here but the product, or platform, itself. This has a customer, the software engineering teams, and has a flow from the idea of value creation to the realization of that value when it’s delivered. The platform we are talking about is the DevOps toolchain - particularly when centralized A.K.A. the Internal Developer Platform (IDP).

We are particularly focused on bridging gaps between product management and software engineering at the VSMC at the moment, so I also want to take a moment to look at this question through this lens. Matt Campbell wrote recently in InfoQ about how Puppet’s recent 2023 State of Platform Engineering Report (superseding the State of DevOps reports) found that platform engineering teams aren’t getting the support they need from product management and states explicitly that the platforms produced are products, natch. Therefore, if value streams are anything that produces a product or service, these platforms are value streams and must be treated as such. Matt refers to another article by Ben Voss at Twilio, who says:

“As Platform organizations scale, a level of autonomy and independence is often still given to the teams. However, without effective product management, many platform teams optimize specifically for their problems, resulting in disjointed platform-level product experiences for the users.”

I also find that this is a great example to use when talking about the different types of value streams. I’m not a fan of the development/operations differentiation in the digital value stream world (see our VSM Foundation course for more on all of this) nor the business/development differentiation (because they are part of the same value stream and separating them perpetuates the problematic separation of the technology teams and ‘the business’), BUT I do like to use core and supporting:

• A core value stream delivers experiences to external customers who pay for the product/service and their revenues sustain the business
• A supporting value stream has internal customers who are delivering the core value stream features and capabilities

It’s easy to see here that platforms are a great example of a supporting value stream.

—

Bryan Finster, Value Stream Architect / Distinguished Engineer, Defense Unicorns and VSMC Board Advisor

What’s a value stream? A value stream is the set of actions that take place to add value to a customer from the initial request through the realization of value by the customer. A value stream always begins and ends with a customer. There’s no requirement that we limit value delivery to only external customers.

Platform engineering can be a force multiplier for value delivery if done correctly. From my experience and from conversations with many other organizations, “if done correctly” is the key phrase. If done incorrectly, it can increase the delivery cost and negatively impact other value streams. What enables platforms to be effective? We treat them like any other value stream.

Platform engineering aims to reduce the effort required for teams to deliver value. Teams delivering platform solutions should do the same product management needed for any other effective product. As platform engineers, we cannot assume that we understand every team's delivery problems. We can’t inflict half-baked solutions or depend on mandates to force teams to use what we build. We need to talk to them, understand their problems, and find solutions to help them. If we can do this effectively, we have a good chance of delivering something useful.

What makes a useful platform? It removes friction. It’s self-service, well-documented, easy to onboard, and reliable. Next, it has the right level of opinion. An opinionated platform reduces its cognitive load, as long as those opinions do not create roadblocks. A good platform will enforce organizational non-negotiables for things like security and compliance. It will strive, as much as possible, to make it difficult to make mistakes without being so opinionated as to make innovation difficult. This requires tradeoffs and is why it’s called “engineering.” Ultimately, what separates platform engineering from being a value stream instead of a roadblock is attitude. Are we truly working to improve other teams' lives or trying to bend them to our will?

I’ve worked on platforms where we cared about the teams we served. We didn’t always implement the features they wanted because sometimes those requests went against the best interests of the enterprise’s goals. However, when policy or strategy needed to be implemented, we tried to implement them in ways that resulted in minimal friction. I’ve also seen solutions that could best be described as “Platform as a Service Ticket,” where using the platform required opening a ticket and waiting for a person to fulfill the request. That’s the opposite of a valuable solution because scaling adoption means increasing wait times or increasing the number of people supporting the platform. Both reduce value. 

Platform engineering can be a significant force multiplier and dramatically increase the effectiveness of all teams using the platform, but only if the focus is on making those teams more effective. We should treat the platform as a real product, and even if the other teams do not have a choice, we should treat them as if they do and build something they want to use. Platform engineering is about delivering products to development teams that allow them to focus on the problems they are trying to solve instead of solving the problems of how to deliver the solution. And yes, the platforms created and the teams that supply them, are value streams.

—

Steve Pereira, Value Stream Consultant, Visible Consulting , VSMC Board Advisor,and Value Stream Lead

You’ve heard many great reasons why and how platform engineering can be considered a value stream, so let me fill in the gaps I see.

1. Platform engineering can easily fail to become a value stream.
2. Platform engineering matters less than providing a platform as a product.

If it’s done poorly, then platform engineering can simply be engineering a platform. Without a focus on flow and value realization, you’ll simply be building a platform and hoping for the best.

Platform engineering in a high-performing organization would typically involve the identification of customer needs, the development of a platform that meets those needs, and the delivery of the platform to customers. If this process is carried out in a structured and continuous manner, with a focus on delivering value to customers, then it can be considered a value stream. However, if the focus is solely on technical aspects and not on delivering value to customers, then it may not be considered a value stream.

This begs the question: Who is the customer?

If your first thought is a developer, consider that most platforms aren’t paid for by individual contributors, the customer here isn’t likely the user of the platform. Most platforms will be budgeted for or bought by engineering leaders charged with improving performance, standardization, efficiency, developer experience, and collaboration.

There’s an interesting point to consider that engineering alone doesn’t capture the full extent of what is necessary to deliver value. It’s important to remember that just because something is engineered —even perfectly to specification— it doesn't make it valuable. It doesn’t have to consider a customer at all. This is the common pitfall of engineering efforts when they aren’t aligned to a value stream. Platform engineering can be considered a value stream if it involves the creation and delivery of results that customers find valuable.

To understand what platform engineering looks like as a value stream, let's look at a couple of dimensions. Depending on the organization’s business model and strategy, it could be considered a core or supporting stream, with a development or operational orientation. 

Typically, a platform is an investment in scale, standardization, and self-service. The user is primarily internal (even in Amazon’s AWS, the first customers were Amazon engineers), as well as the customer. The platform serves internal individual contributors, enabling them to work more efficiently and effectively. That makes it a solid supporting value stream. If you created an exceptional platform and your business model brought it to market, it may become a core stream, but that’s a rare strategy. It doesn’t often have to include advanced, differentiated capabilities, so the orientation would be operational rather than development.

One way to think of an internal platform is as a vending machine, stocked with information and capabilities. A platform value stream ensures the machine is accessible and operational for users. It also provides or creates the capabilities available in the machine. Hopefully, it monitors what is popular and regularly adds and improves capabilities based on customer and user feedback. It should also provide all this securely and at a competitive price.

I’ve seen many examples of platform engineering that delivered little or no value, and in a few cases cost billions of dollars. General Electric is a case of failing to create a platform engineering value stream, and it cost them $7B. Many organizations rush to build platforms with little consideration for the sustainability and customer focus required to deliver value.

It’s important to consider how your platform fits into the flow of development and delivery in your organization. One way to map this out is with a value chain or Wardley map, but you can also simply represent a slice of your organization and the interplay of streams and connections like this:

In the illustration above, Digital twin, Search and discovery, the Value Stream delivery platform and Data platform are all delivered by value streams.

A platform must fit and serve both the organization broadly, the customer providing the funding and support, and most importantly the users leveraging platform capabilities. Without the model and practices of value stream management, that’s a challenging proposition.

In a large telecom I worked with, many teams developed their own platform capabilities within a pilot division, yet failed to scale and serve the larger organization because of the long list of requirements demanded by the broader enterprise. This is why a platform must be treated as a product supported by a value stream. In an organization of any size, there are demanding customers, picky users, steep requirements, and advancing competition.

We’ll see many organizations fail at platform engineering by mistaking engineering for the goal, instead of customer outcomes. Value streams help keep the focus on flow and value realization - two things that make all the difference between success and failure.

You can read more about the key benefits and considerations of platform engineering in a few papers I co-authored here.