Refining Activities: Artifacts and Processes in Wardley Value Chains
After stewarding Wardley mapping sessions for a while, I noticed people defining activities in maps in various ways. Say we’re mapping a web application. Some people will say we need “static file storage”, other people will say we need “Amazon S3”. If we’re mapping a tea shop, some people will say we need “water heating”, others will say we need a “kettle”. We need “labour” or we need “employees”. What’s the difference between those two things? At first glance, they seem to be equivalent.
Lexicographers really don’t like to define the word “activity” or, even worse, “do”. I’ve included some dictionary definitions for some words below. Note the abundance of circular definitions 🤣:
- Activity: the condition in which things are happening or being done
- Do: to Make or Perform; Execute
- Make: cause to come into being
- Perform: Carry Out; Execute; Do
- Execute: Carry Out; Accomplish; Perform; Do
- Carry Out: Accomplish; Execute; Do
- Accomplish: to bring to its goal or conclusion; Carry Out; Perform;
This is one giant circular definition. The only end points seem to be to cause something to come into being, or to bring something to its goal or conclusion, which is really causing something to come into being according to a goal or regular process.
Based on my research in information theory, living systems, and cognitive science, I’ve been able to come up with a more precise definition. “Activity” is a process causing something to come into being.
- Process: a transformation which takes one or more inputs, transforms them, and outputs something.
- Causing: an agent affecting change in its external environment
- Something: a loose boundary us humans like to define for abstraction purposes.
- To come into: change over time.
- Being: arrangements of matter-energy or information.
“Something” deserves expanding on. In reality, there are few to no boundaries actually separating things. If you could zoom in on your surroundings, you’d see the molecules in your body are just as about as close to the molecules in the air, and there are massive gaps between everything. It’s a property of animal cognition to denote things that are visually contrasting as having boundaries, and thus, being separate objects. This is called object segmentation and discrimination. These boundaries exist, but are useful for abstracting things we interact with into discrete units, that we can use to build semantic meaning around. Since these boundaries are a useful concept, let’s call them “things”.
“Things” is pretty generic, so let’s borrow a slightly more specific word from the design world, “Artifact”. An artifact is any product of human workmanship or any object modified by man, whereas the antonym of artefact is a “natural object”. At the very bottom of the world’s supply chain lie natural objects, and every other object we use to build technology is an artifact. This includes both physical objects and information.
Through Simon’s research on the evolution of technology (technology includes all things that undergo competition whether activities, practices, data or knowledge.), he discovered that everything evolves through different stages of development, with different characteristics at each stage. Simon discovered common labels for each stage of evolution and type of technology and you can use them interchangeably. Note: these labels are the result of Simon’s research cataloging thousands of media descriptions of technologies over their evolutions. [2]
Brief Aside on Practices
Simon also explained how practices co-evolve with the evolution of their underlying activity. i.e. in order to use an activity, you need to develop a set of techniques for working with the particular affordances of the activity. Necessarily, our expertise at practicing the use of an activity will lag behind the activity’s evolution. It’s hard to practice something that doesn’t exist yet.
The map above explains the process of a climatic forcing need pushing a component through inertia and causing it to commoditize. As the technology stabilizes in its commoditized form, it allows us to meet new user needs. Dealing with the component in commoditized form requires new emerging practices. But if you recall Figure 1, practices have different labels, but really, evolve in the same way as all technology.
On Processes
We’ve explained artifacts, they’re the outputs of a process (aka technology), but what are processes? The Jobs to be Done Framework is gaining some popularity in the Mapping community. Jobs to be Done introduces the concept of, among other things, the Job Step. Each Job Step is a verb and it takes artifacts (physical objects or information, aka activities) as inputs, transforms them, and outputs new artefacts.
Which is also how functions in programming work. Pure functions in programming take arguments (inputs) of a certain type, transform them, and output data of a certain type.
I’ve had an intuitive sense that there is much to be learned in Wardley Mapping from fields such as Category Theory, Information Theory, Complexity Theory, etc. Last week I was perusing Seven Sketches in Compositionality: An Invitation to Applied Category Theory and saw this diagram:
My brain immediately went, “that’s just a sideways Wardley map” (at least the value chain part), and I became curious.
Here’s the string diagram rotated to have the artifact with the highest complexity at the top (I find coincidentally the highest complexity thing is usually the thing the user cares about most). We’re close to a Wardley value chain, but not quite there. In Wardley value chains, the unspoken practice is to mainly represent the artifacts (activities in Wardley terms) only. I wonder why this is? Is it our modern bias toward substance metaphysics, physicalism and scientism? I digress. Below are just the physical objects represented in a standard Wardley Value chain.
One problem I have when building Wardley maps is it can be difficult to determine the dependencies of a particular component. I believe this is because we commonly skip the step of thinking about processes. Chris Daniel has a great blog post, When Stuck, Think Verbs, Not Nouns. Chris talks about how we often get stuck thinking about the physical things in a business system, and forget to think about the processes that transform things into other things, which are arguably more important than the things. It just happens that verbs usually correspond to processes and nouns usually correspond to artifacts. If the process is broken, you quickly run out of things to use in other processes. If the thing is broken, but the process is working, you can just replace the thing with another.
Category Theory can be confusing for some because it focuses more on the processes (morphisms) than the artifacts (objects).
Brief Aside on Abstraction
One great thing about Category Theory is that processes are abstractable. We can just mush all the granular steps in a process together and treat them as one thing. The same principle exists in programming. If we know the inputs of a function and the outputs of a function, we don’t need to know all the steps inside the function. There might be 1,000,000 sub-processes and we can treat the function as one process.
This is an important thing to think about when mapping, as we want to make sure we’re operating at the right level of detail. If we’re mapping an entire company, we don’t care what the steps for taking meeting minutes are, but if we’re mapping our meeting process, then we might want to break things down into more detail.
Meta-processes
Discussing this concept with Tristan Slominski, the creator of MapKeep, we realized there are certain meta-processes, where the output is another process. For example, if the process is a picking a project management framework, the artifact is lean, scrum, or six sigma. If the meta-process is figuring out how we go to the store, the processes to get us there could be bike, drive, or walk. The outcome of these meta-processes are a particular strategy, tactic, or procedure we take to achieve something. In this way, there exist meta-processes, that help us decide processes. This is the equivalent of the Strategy pattern in software architecture.
Where does this lead?
Where does this all lead? Each component is comprised of a process and an artifact. There is existing similar notation in Wardley maps that lets us represent interchangeable artifacts, the pipeline. I feel like Wardley mapping is approaching alignment with information theory, cybernetics, and category theory, but as it’s organically growing, it hasn’t quite yet reached parody. If you notice the maps coming out of Simon’s recent research groups, there are tons and tons of pipelines. I feel we’re slowly realizing this truth of processes and artifacts, just without the language to formally describe it. Well, I posit that each component in Wardley map is a pipeline, and that we should stick to defining components as processes or jobs to be done. Within each component pipeline exists at least 1 but usually more artifacts that can perform that process.
The next steps would be to discuss this. Do you think this is an accurate observation? Would you change anything? Try it out in your maps or in a group and see if it helps add clarity!
References
[2]: https://blog.gardeviance.org/2015/03/evolution-diffusion-hype-cycle-and.html
