Day 18: Exploring Capabilities and Boundaries
On Day 1, we explored a bicycle as a simple physical everyday system with (generally) visible parts (although more is hidden with ebikes). The purpose of human powered transport is supported by parts like wheels and brakes, but at a higher level, there are capabilities like steering, braking and locomotion.
On Day 17, we identified a system and asked "What is the purpose of this system?" Now, identify (and draw) the network of capabilities that enable that system to be viable as a system with that purpose.
What capabilities (capabilities, information, activities) are needed to enable that purpose, and what capabilities do those capabilities need? And so on. Some capabilities may take the form of technology. (You might think of this as a Value Chain in Wardley Mapping.)
For example, if the system is a hospital, patient admissions is a capability, and that capability needs patient registration which needs administrative patient interviews, patient (digital) intake, and patient accomodation. Patient intake needs a patient digital records system. And so on. [If you'd like a richer example, and want to stay in the clinical setting: Patient Diagnosis is explored here (scroll down to the Wardley Maps in Section 1), with the addition of the evolutionary axis, which we're not doing now. It also has more depth than we might expect to reach in 15 minutes.]
If you feel that you are guessing at capabilities that are outside your area of experience, take note of that uncertainty, so you can follow up with others if it's relevant to your situation, and keep exploring. This is more about drawing out your perspective on what capabilities are needed, and noticing the gaps and where collaboration is needed.
What capabilities are internal to the system? What external (to the system) capabilities does the system depend on? If we broaden our view to more of the lifecycle of the system, what additional capabilities come into view?
If we back up to consider the problem that users of the system face (why they are using the system), and explore what capabilities they need, does that differ from taking the system purpose as a starting point?
"In systems engineering, boundaries are more than arbitrary lines; they represent critical decisions that affect the design, functionality, and management of systems. By understanding the role and impact of boundaries, system engineers can create more effective, reliable, and innovative solutions."
“A system is a Whole that consists of parts, each of which can affect its behavior or properties.”
— Russell Ackoff