In The Promise of Clouds and Optionality, I said:
Cloud providers are competing to offer high quality services that meet their customers’ needs at decreasing cost and increasing scale. They want you to offload whatever you consider undifferentiated heavy lifting to them.
But what the heck is ‘undifferentiated, heavy lifting’ and where do I find it? After all, that sounds like obvious stuff to hand off to a managed service provider so that you can focus on core competencies.
I suggested a few examples: running DNS, a database, a Hadoop cluster, or an application’s identity provider (authentication service). You may or may not feel like these are undifferentiated heavy lifting depending on your current responsibilities and experiences. But we need to move critical architecture and business decisions past pure intuition to avoid strategic missteps and expending effort that won’t matter to our customers.
Understanding how value is delivered
Every product adopted by customers provides value in some way. That value is provided by a system of components and people (aka entities) that have responsibilities ranging from the application used directly by a customer to the object store where that customer’s data is persisted. Each of those entities must fulfill their current responsibilities or delivery of customer value is impacted.
Wardley Mapping is a visual approach to analyzing how systems provide value to their customers and exploring strategies for evolving them. Simon Wardley developed this approach because he felt lost with the existing strategy frameworks. In the short book he published on why and how to map (Medium), he starts off with defining strategy:
Strategy is all about observing the landscape, understanding how it is changing and using what resources you have to maximise your chances of success.
Simon Wardley
To use Wardley mapping, first plot the user needs your system serves, the system’s entities, and the dependencies between each entity onto a two-dimensional chart. This chart is called a Landscape. The following landscape depicts the (very-) high level entities in a photo storage and printing service:
Entities that directly support user needs go at the top of the landscape and those that are necessary dependencies, but invisible to users, at the bottom. This represents the Value Chain. Arrange entities left-to-right according to how evolved that entity is. The Evolution axis ranges from Genesis (we invented this), through Custom Built, Rental, and Commodity/Utility.
Note: The figure above is from HiredThought’s excellent ‘Evolve‘ site dedicated to teaching how to create and use Wardley maps. The figure is a derivative of Simon Wardley’s own work. I have added a ‘Storage’ entity and expanded the collection of prerequisite dependencies.
Now… let’s analyze a landscape and explore some changes.
Exercise
Quickly draw or imagine the landscape for the system you work with most. Represent users, competitors, components of your system, obstacles, and other entities that help you understand your competitive situation.
Which portions of the system are either invisible to users or features that competitors in the market have parity? The Data Center, Compute, Platform, Storage, and Power entities in the Photo Service example are good answers.
Would any of your users care if the those services were provided by someone else, as long as the system kept delivering its promised features?
The team architecting and building the example Photo Service might look at their map and notice that they spend a lot of effort on their custom-built Storage system that is held together with duct-tape and is struggling to scale. Object storage is a great example of undifferentiated, heavy lifting. While users care that they can upload, modify, and order their images, they don’t really care if the underlying storage is provided by one giant hard drive, NFS from a SAN, a Ceph cluster, or AWS’ Simple Storage Service (S3). Users really don’t care that lifting this storage load gets harder and harder once you have more than a few Petabytes.
Entities in the lower half of a landscape are good candidates to evaluate replacement with managed services. Those entities that were invented or custom built, but are invisible to users or indistinguishable from competitors’ implementations are the best candidates for migrating to a Commodity or Rented option. Note that components likely won’t disappear from the map, at least not at first. Rather, they will shift right as features are rebuilt on top of supplier’s standard service offering.
Many managed service offerings are less expensive, perform better, and have higher availability than the custom-built system they replace. Much of this can be attributed to the relentless progress and commoditization of ever powerful functionality.
Since every system is different, you’ll need to create your own landscape so that you can analyze and map out your own path forward. Make the economics of managed services work for you.
#NoDrama
