When I changed roles to a DevOps tooling team lead, I inherited a bunch of tools that essentially amount to ready-to-use deployment automation artifacts. They were managed as shared source. Similar to open source, features and fixes to the tooling could be implemented by anyone in the group. As my team started working with the code, we kept finding woefully out-of-date code. We also discovered improvements and features in some tools that were not in others of the exact same kind. Most this tooling was built for both Linux and Windows. We were also finding significant differences in functionality between the Linux and Windows versions of the same tools.

Over the course of my career, I have realized that a key reason I love building tooling is that each and every tool is its own mini-product. Each tool has its own problem-solution fit and a value proposition to a specific user. In the above case we had a suite of very similar tools for which the problem-solution fit and value proposition were nearly identical, but the artifacts differed wildly in their functionality, quality and reliability. I felt strongly that we needed to start using a proactive product management approach rather than the passive and reactive approach that seemed to result from a shared source model. While I felt that product management would cure many of the challenges with the recently inherited tools, it was also clear to me that it would be challenging to communicate why the initial and ongoing investments of product management should be made for tooling that consisted of pre-built automation artifacts.

Eureka! Wardley Maps

Recently, I made a visual work status dashboard to help communicate the status of my team’s many, varied tasks. Upon seeing it, my manager noted a similarity to Wardley Maps and recommended I check them out. Learning about Wardley Maps was one those “where have you been my whole life?” moments!

While it is common place to leverage visuals to communicate complex technical designs, until Wardley Maps, strategic product planning did not have a model on which to build visual maps. Indeed, Wardley claims that this is true of all strategic business planning, and I must admit, that I agree.

The fundamental perceptions that led Wardley to devising his product strategy mapping methodology are intriguing. They carry the hallmarks of deep insight: brutally honest observations followed by simple questions capped by experimentation with cross-pollinated concepts. Wardley analyzed the foundational elements of historical battle maps and created an analog for product strategy planning.

Lean Experiment: Reducing The Risks of Learning a New Planning Method

Trying new “future planning” methods carries leveraged risks and burdens compared to changing other bits of methodology. For instance, if you get your first attempt wrong, how will you know if the method is flawed, if your understanding of it is flawed, or if the method does not work for your scenario? Then there is the burden of proving to others that the new methodology is worthy at all. If you are an early adopter, that’s a heavy burden. Wardley Mapping lends itself to a simple learning experiment to address this challenge.

From my experience with instructional design, I know that associative learning (bridging from something you know to something you need to know) is a catalyst to effective learning. Human cognition is largely about pattern recognition and pattern building. Associative knowledge acquisition aligns with this fundamental characteristic of human cognition. Therefore, the associative learning remedy to reduce the risk of learning Wardley Maps is to retrospectively apply the method to something that has already had a successful outcome. While a retrospective Wardley Map does not predict that you would have made the same map before building, it is still valuable in that you will know if the method could have yielded a predictive map. If the mapping method is incapable of capturing the essence of something that is already successful, it would decrease my faith in the method and/or in whether it applies to this type of work.

I was delighted that my first attempt at mapping yielded something that clearly articulated a product value chain and led to further insights.

To get started, I mapped out what I believe the final product would look like. After generating the map, I took an additional step of using green arrows to show what nodes were moved along the maturity scale by the product build and refinement. By visually showing what has been commoditized in the product build out, the map gives a sense of the value of the product to the customer even though it is done retrospectively.

Mapping the Value of Virtual Machine Image Template Building as a DevOps Tooling Product

The product mapped here is a ready-to-use virtual machine template for use in Amazon’s cloud. Since virtual machine templates are a very common product of DevOps, I am hopeful that many will be able to resonate with this specific tooling.

Here is some information about how to read the map:

Direct User - The Primary Customer

A direct user of the templates is the primary use case and is leveraged the most broadly.

• The “Ready-to-Use-Template” is an Amazon AMI template for Linux or Windows. The “Direct User” simply launches these templates and then uses a variety of automation tools to install and configure software to build out various server configurations.
• For the Direct User “QA Tested” indicates that the results are QA tested to ensure that they will be compatible with common usage scenarios and with other tooling.
• For the Direct User, you can see by “Updated Monthly”, “Patched”, “Hardened” and “Automation Utils Updated” that the final template includes value in the form of being updated each month with OS patching, in-house approved hardening, and updates to automation utilities. Automation utilities includes in-house items like domain join scripts, platform specific things such as updating PowerShell and Python, and cloud specific stuff such as the latest Amazon CodeDeploy and SSM.

DevOps Re-User (Build Next Layer Template) - Building On the Output

One of DevOps Re-User types represents the use case of using automation that was embedded into the template for preparing a template of their own (template built from a base template). This is frequently done for speed of deployment by creating templates that contain the various server roles pre-built. The deployment of new capacity in response to autoscaling events is much quicker than if this automation is done as part of the scaling event.

• The “Embedded Imaging Tools” includes things such as a script for proper shutdown of a machine when it is going to be used as a template (Windows is fussy about this) as well as tools for initializing AWS EBS disks.
• The “Extensible Test Framework” value is delivered by the fact that the platform tests are left in such a way that any user of the template can re-run them and re-verify the platform. The extensibility of the test framework was accomplished by design decisions that standardize test scripts and directory locations. Additionally, the built-in test scripts serve as sample code for teams wishing to build their own tests for software they layer onto the system.

DevOps Re-User (Build from Scratch) - Parallel Template Building

• “Buildable from Source” resulted from some relatively simple design decisions to ensure the automation was not overly teathered to the environment (loose coupling). This allowed the automation to be quickly adapted to build the template AMIs in environments that are completely isolated from the normal cloud environments served by the template.

Customer Value Visualization and Gaps

• The green arrows visually represent the amount of value generated. This is done by showing how far those particular bits of customer value have been moved along the evolution axis toward commoditization.
• Since the effort mapped out all the value that was originally envisioned, it also revealed areas that do not currently live up to the product-solution vision - these are identified by the blue dots.

Unexpected Benefits of Retrospective Wardley Mapping

While I hoped that my experiment in retrospective Wardley Mapping would answer whether I sufficiently understood the method, as well as whether it was suitable for my task, I did not expect that it would generate insights. I guess I had thought of it’s ability to generate insights as one-way, from the current to the future. This assumption was broken when I started to have new insights into the already built product.

One of these insights was the personal realization that Wardley Maps are largely implementation agnostic. You might be thinking, “well duh”, but I hadn’t picked up on this until I did this experiment. The automation that is currently implemented according to this map is AWS cloud specific. However, if my team was asked to build it in another cloud, the value chain map is 100% applicable. This Wardley Map is a logical mapping of the key functional design points that create customer value no matter where it is deployed.

After making several retrospective Wardley Maps, I noticed that multiple points of product use (user types) were a recurring theme. While I knew this aspect of my work brings me deep satisfaction, I didn’t realize the degree to which it has become a subconscious design habit.

I have always found it difficult to adequately articulate that a product has multiple uses by design and that this compounds its value. Yet the map seems to make it self-evident that multi-use was designed-in and is valuable to the customers.

The process of mapping also quickly highlighted implementation gaps - places where the functionality is not complete compared to the vision.

A final insight of this Wardley Map is that the existing value is insufficiently communicated. This includes highlighting of all features, how-to information for leveraging the value, and promotional content such as announcements and live events.

Lessons Learned

• Wardley Maps can be effectively applied to new domains where you intend to infuse a “Product Management” approach.
• Wardley Maps represent a customer value chain in an implementation agnostic way.
• Retrospective use of a planning technique on a past successful project is a great way to offset the risks of learning new planning methods.
• Retrospective Wardley Mapping can give insights on already built products - including gaps and communication issues.
• Multiple retrospective Wardley Maps can highlight common elements of an engineering style.

Wardley Map Templates and Samples

The below repository includes the map in this article and a template. The templates are done in draw.io - it is free and it’s text based source format is easily stored in git.

If you wish to contribute templates, please feel free to do a pull request.

https://gitlab.com/DarwinJS/Wardleymaptemplatesandexamples