I am learning a lot from Melissa Perri’s ‘Escaping the Build Trap’ in my studies of product management. Perri says in chapter 9 ‘Organizing Your Teams’:
You can’t build an organizational structure without a product vision, because the value streams are not apparent.
Perri, Melissa. Escaping the Build Trap: How Effective Product Management Creates Real Value
Perri is (rightly) trying to help us avoid building organizations and processes that deliver a lot of outputs (e.g. many undeployed software builds), but weak customer outcomes (e.g. low customer satisfaction or responsiveness).
This prompted a couple of questions about how to organize DevOps and Tech organizations to deliver of the greater product value stream:
- What value streams are common DevOps organization topologies best suited for?
- Heck, what are the products or services Tech organizations should provide to support the and organization’s product goals?
These are questions that the classic DevOps Topologies site doesn’t answer directly.
I created a Wardley Map to help me answer the second question for a “Product-led Tech organization”:
The mapping process starts off with the need to: “Deliver software the ‘Accelerate’ way: on-demand, with low lead-time, low time to restore service, and low change failure rate.” Note that I’m specifically thinking about how to help an organization that is currently a mish-mash of silo’d and scattered ‘platform’ and operations teams.
I started with one customer, the internal Dev team. However, it was quickly apparent that the map needed to show how Operations engineers (internal) and external customers of the product touched the value chain.
I think tech organizations should be providing the components in the product and custom zones “as a service” to their internal and external customers. These components are critical to the larger organization’s products and must plug-in to the organization wide product value streams. This is because each of the organization’s products will require a delivery pipeline, operations, and customer service component. Conveniently, the aspects of Software Delivery Performance tell you what you should measure and optimize for the tech org’s delivery component(s).
An interesting question is how many different implementations of these components should a tech organization offer.
The map above is a logical model, but each of the components must be fulfilled with a concrete implementation. For example, the Delivery Pipeline component depends on the Infrastructure Service Catalog and Compute Platform. The service catalog and compute platform will be have specific implementations for virtual machines on EC2 or vSphere or a containerized deployment on Kubernetes or ECS. And those choices ripple through to Operations, Observability Tools, and more.
So, how do you use this?
I think the next step is to analyze the organization’s application portfolio, classify which compute platform it’s currently running on, and identify ideal ‘target’ state compute platform for each application. You can use this information to identify the minimum set of target state compute platforms.
This analysis leads to the minimum set of delivery pipelines and operational models for the application portfolio that fulfills the the tech organization’s commitments to the product value streams. You also have a way to estimate the investment and ongoing operational costs to support each delivery option, which is bound to be useful in architecture and strategy discussions.
Stephen
#NoDrama
