Diane Mueller very kindly invited me to share Wardley Maps with the OpenShift Commons, and I can’t help but write about the challenge she’s shared:
The problem I have is how do I map an open source technology ecosystem like CNCF as the currrent tools although helpful don't drive any actionable strategies see: https://t.co/dO2EeMWVbd and let's discuss further tomorrow!
— 🌍Diane Mueller 🇨🇦 (@pythondj) July 24, 2020
Okay, now I just gotta figure out how to map an entire tech ecosystem that I have near-zero understanding of. No pressure!
First, let’s look at the website she shared…
That’s… a LOT of logos! Mild overwhelm aside, I think there’s enough here to work with.
Step 0: Set Reasonable Expectations
Why would we want to map a tech ecosystem like this? Diane wants something that drives actionable strategies, but because I’m new to the space, I have lots of questions about why, to what end, and for whom! For now let’s assume we just want to shorten the time it takes for someone new like me to get oriented to all the different moving parts in the ecosystem. We’ll start there and refine our primary goal as we go.
Often times we see how folks have made super complicated Wardley Maps, but I want to emphasize that all maps start small and get bigger over time. And most of the time, it’s more helpful to make many separate, smaller maps anyway. So I think it’s reasonable that we not worry about making one map to rule them all. We just want to make getting oriented easier.
One final suggestion is to start with a shallow dive and the push all the way to “the end” of the process. You can always do more research, make a more perfect map, and so on. But if you go too deep too soon, you’ll drown in detail. Or you’ll tire out before you get to learn anything.
Step 1: Make Lists
First thing’s first, let’s make some lists. Wardley Mapping wants you to figure out what “the things” are and how they relate to each other (primarily in terms of dependency). So first, we gotta find some “things” to write down.
I think getting the right words on the first try is really difficult, so some mostly unguided reading of news articles, blog posts, Wikipedia pages, press releases, etc. about an ecosystem can be super helpful for learning what the things and the words for the things are. John Cutler also taught me a neat trick where you just type a few words you know in an image search and browse quickly through all the diagrams that come up to get a feel for the space.
But, sometimes you don’t need to work so hard. It’s often more fruitful at first to map out other people’s existing assumptions rather than trying to come up with your own based on your research. This is why I wholeheartedly endorse stealing existing ontologies you find and taking them as far as they’ll go as you map.
Sidebar: What’s an ontology?
Basically… an ontology is “the things” and how they relate. What they’re like and how they “be.” It’s not as complicated as it sounds, promise.
Think of it like decomposing the ecosystem into its component parts, giving those parts names, and identifying what depends on what else, and then considering their evolutionary characteristics. Some things “be” in stage 1 of evolution, where their existence is high failure and high potential future value. Other things “be” in stage 4, where they exist in exactly the opposite ways.
Back to the ontology theft…
Okay, right, stealing ontologies. I noticed in the diagram above that there are headings on the columns and rows. That’s a common place for ontologies to lurk. (Another place is bulleted lists, but many times the ontology is just scattered indiscriminately instead of being organized in one place.)
I’m just gonna make a quick list here, based on those headings:
- App Definition and Development
- Database
- Streaming & Messaging
- Application Definition & Image Build
- Continuous Integration & Delivery
- Orchestration & Management
- Scheduling & Orchestration
- Coordination & Service Discovery
- Remote Procedure Call
- Service Proxy
- API Gateway
- Service Mesh
- Runtime
- Cloud Native Storage
- Container Runtime
- Cloud Native Network
- Provisioning
- Automation & Configuration
- Container Registry
- Security & Compliance
- Key Management
- Platform
- Certified Kubernetes – Distribution
- Certified Kubernetes – Hosted
- Certified Kubernetes – Installer
- PaaS / Container Service
- Observability and Analysis
- Monitoring
- Logging
- Tracing
- Chaos Engineering
- Serverless
- Tools
- Security
- Framework
- Hosted Platform
- Installable Platform
- Special
- Kubernetes Certified Service Provider
- Kubernetes Training Partner
- Members
The above took about 5 minutes, mostly just from the reading and typing. I have no assumption that it’s the perfect ontology for the space from a Wardley Mapping angle, but it’s a pretty decent starting point. I at least know whoever wrote these words put a lot of thought into it, so I feel comfortable starting here. (I’ve started with lists based on much shakier source material before. You just need a place to start playing, so don’t worry about quality.)
Step 2: Learn What the Words Mean
Once you’ve got some words, start learning about what they mean. Your goal is to understand why they exist and what the things they mean are like.
I’ll start with the high level items from the list above:
- App Definition and Development
- Orchestration & Management
- Runtime
- Provisioning
- Platform
- Observability and Analysis
- Serverless
- Special
- Members
Guess what — I’ve already made my first mapping decision! I’ve culled the detail, and in doing so decreased the granularity of the ontology.
Sidebar: Uh…. granularity?
Yeah, think literal grains of sand. Increasing granularity is like looking at every single grain of sand individually, while decreasing granularity is like looking at the different piles of sand. You can also think of it like the “level of detail.” It’s a relative concept, so it’s more a gradient than a binary.
…and we’re back.
Remember our original expectations: We want a shallow dive, so let’s keep granularity not super detailed. The first level of items, without sub-items, will be fine.
Now, let’s get back to learning what the words mean. I would bet $5 that the folks who run the website in the image above have definitions of these words written down somewhere. Worst case, we’ll just hit up our favorite search engine and see what we find.
My first search: cncf "App Definition and Development"
The results surprise me, and I think I’m out $5, as I can’t find any definitions except for this one blog post from Cherry Servers, which describes almost all of the things in the list. (I’m making a mental note to myself that the space could use some more content about the words, if the CNCF ontology is going to be the one that sticks around. Or perhaps someone else’s ontology will have a more accessible presence? I could be wrong here, so I’d need to validate.)
Now, as a reminder, I have no idea if the definitions in the blog post are the right definitions. And I don’t actually need them to be right. I’ll settle for the opinions of one person in a blog post for now, since I intend to iterate on the knowledge as I build it out.
So here’s the definition the post suggests for App Definition and Development:
…components directly involved in enabling application functionality, communication between microservices, application data storage, and image creation.
Not the most comprehensive definition, but it’s got enough new words that I can search for and read about:
- software applications
- microservices
- data storage
- image creation
Then I’d repeat the same process for the rest of the words in that high level list of items up above. My goal here is just to learn enough so I know what the words are and a cursory idea of what they mean.
One item in that list, “Members” turns out to just be a list of people in the CNCF membership. I’ll remove it, since it doesn’t seem to belong with the rest of the “things” in the ontology.
Step 3: Sketch It Out
Okay, I’m probably an hour in at this point. I’ve done enough reading to be dangerous (and very probably wrong) about the ontology. It’s time to sketch out a rough idea of the space so we can at least look at what’s happening.
Normally at this point I’ll start with something I call a Minimum Viable Wardley Map (MVWM, for short).
Sidebar: What puts the “MV” in the MVWM?
A Minimum Viable Wardley Map just ignores relationships. That’s it.
A MVWM is a faster artifact to make, though it is limited in its usefulness as compared to a conventional Wardley Map. The good news is that all you have to do to convert one to or from the other is to add or remove dependency relationships between components. Sometimes the ontology has to change when you do that, but that’s totally okay and expected.
If you want a rapid (~1h) intro to Wardley Mapping that uses MVWMs and the strategic thinking process, I made this online course to get you up to speed.
Back to sketching…
To get ready, I’ll grab a piece of paper and sketch out the below MVWM template:
It’s a basic Wardley Mapping template, minus the Y axis. (The Y axis isn’t real anyway, so this isn’t too weird yet.)
Now we’re going to answer a really important question: Who is served by this ecosystem of parts?
Let’s review the list of parts real quick:
- App Definition and Development
- Orchestration & Management
- Runtime
- Provisioning
- Platform
- Observability and Analysis
- Special
- Serverless
All this screams “software” to me. So I’m going to lean into my naïveté and assume this system serves humans who use software. I write that exact phrase up top to anchor our minimum viable map on the user:
Next, I’m going to do an overly simplistic categorization exercise for each of the ecosystem parts into the stages of evolution. (Oh yeah, that’s the other thing that makes a MVWM “minimally viable” — imprecise evolution. Categorization is good enough for a first pass!)
Wait… what just happened?
If you’re new to Wardley Mapping, I just reverse engineered which stage of evolution each thing is in based on a combination of guesswork (based on the reading I’ve done so far) and Simon Wardley’s Evolutionary Characteristic Cheat Sheet (original reproduced below, CC BY-SA 4.0):
Okay, but how can you be so sure about your sketch?
Spoiler alert: I’m not sure whether my MVWM is even remotely right. All I’m doing is getting a (probably wrong) baseline map put together. I’ll decide whether it’s worth investing in next.
Wait, all of this was too fast.
Yes, I imagine so. This step can take 30 seconds or days and days. I suggest doing the 30-second version. (If you’re not sure where something goes, just guess. You’ll be coming back around eventually to validate your choices.)
Step 4. Invest and Iterate, or Start Over
Now we have to make a judgement call. Does our MVWM seem remotely worth investing in? If we iterated on our understanding of the space from this map, would we be likely to learn something useful?
It’s hard to tell up-front, at least without experience. In this case, I’m not super happy with the ontology as it is. The “things” are too high level, and based on the absence of available definitions for categories from the source, I’m not sure it’s going to be right.
The sub-items might be worth a try, though. My likely next move would be ditch the category headings and make a MVWM with a flat ontology of sub-items, like so:
- Database
- Streaming & Messaging
- Application Definition & Image Build
- Continuous Integration & Delivery
- Scheduling & Orchestration
- Coordination & Service Discovery
- Remote Procedure Call
- Service Proxy
- API Gateway
- Service Mesh
- Cloud Native Storage
- Container Runtime
- Cloud Native Network
- Automation & Configuration
- Container Registry
- Security & Compliance
- Key Management
- Certified Kubernetes – Distribution
- Certified Kubernetes – Hosted
- Certified Kubernetes – Installer
- PaaS / Container Service
- Monitoring
- Logging
- Tracing
- Chaos Engineering
- Serverless Tools
- Serverless Security
- Serverless Framework
- Serverless Hosted Platform
- Serverless Installable Platform
- Kubernetes Certified Service Provider
- Kubernetes Training Partner
In some cases I had to change the names to make sure I knew what to research. This feels like a more meaningful ontology, though maybe it’s a bit too detailed… Might as well try and see!
You might have to try a few different pathways. Some of them might not work out. That’s all part of the process.
Step 5. Repeat the Cycle
I’d want to do more reading about the terms, make another MVWM, and then make a judgement call on whether to invest in the map or start over with a different ontology.
If I do get to a point where “the things” seem pretty solid, that’s when I might start working on relationships — articulating which thing depends on which other thing, resulting in a conventional Wardley Map.
I would also want to talk to other people familiar with the ecosystem. Instead of showing them the completed map, I might re-draw it collaboratively with them from scratch. They’ll get caught up on my weird understanding of reality and have the ability to provide critique. They might also find that parts of it resonate or parts that they can help expand.
Conclusion
Understanding an ecosystem is a lot of work, no matter what tool you use. Wardley Mapping is a good choice if strategic thinking is the eventual goal, and especially so if defining the ecosystem’s parts and sharing those meanings in visual form are useful intermediate milestones.
Too much detail can be an obstacle to the process at first. Looking back, I’m wondering if I should have made the problem smaller from the start. For example, I could have scoped it down to something like Observability and Analysis. I would have ended up with a more specific and useful MVWM encompassing Monitoring, Logging, Tracing, and perhaps their underlying parts.
I could have considered climatic patterns and their implications for the MVWM, which could make change in the ecosystem somewhat anticipable, or at least help us know what’s happening in it that we don’t have a choice over.
I could have also considered the doctrinal principles with respect to the “things” on the map and the perspectives of organizations I work with. Which principles are worth examining based on the map, and what implications do they have for how organizations in the ecosystem should behave?
And lastly, I could have considered various strategic interventions that are possible given the current state of the ecosystem. (It’s tempting to jump straight here, but the previous considerations are important to explore first so we develop an appreciation of the full context before attempting to change it.)
This whole process can feel like it makes a bit of a mess, and that’s okay. It’s going to feel uncertain, and maybe even frustrating at times. There won’t be “right answers” so much as a visual record of assumptions that placehold our thinking and make the occasional “ah-ha!” moment more likely. Stick with it, and you’ll be sure to find some wild and amazing insights, just by virtue of looking closely in places others aren’t even aware exist.
I’m excited to share this with Diane when we meet!
Update: We met! Here’s the video.