This article was originally written as a contribution to a collective post for the VSM Consortium blog (find the full article using the link below)
: https://www.vsmconsortium.org/blog/is-platform-engineering-a-value-stream (February 17, 2023)
–
“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.”
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”
| Notes on Naming Conventions: I always advocate naming teams for what they deliver, not for the techniques or methods they employ. This allows us to be clear about their mission and to let them evolve in the practices they apply. It also means we don’t localize an approach (agile, DevOps,…) on a particular team at the risk of letting it be interpreted that it does not concern everyone. I also prefer to use the term “Software Delivery Platform” (SDP)* rather than “Internal Developer Platform” (IDP) because these platforms are not only intended for developers but for multi-disciplinary product teams in charge of delivering software. Our naming decisions are important to facilitate the evolution towards a culture of teamwork breaking down the functional silos. *And so do Fidelity Investments – check out their story here. |
–
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.
–
