In figure 1 and 2, I provide an example map from an extremely large and somewhat sensitive Government project. I've removed the terms but I provide the basics of where the user needs are represented (always at the top of the map) and how the different components should be treated.
Figure 1- Map and user needs.
Figure 2- How components should be treated.
Obviously a map is a snapshot at a point in time as all components are evolving due to competition from the uncharted space (genesis of the novel and new) to more industrialised (commodity and utility).
Now whenever you deal with a large system, this system is likely to contain many different components at different stages of evolution and the entire system can be described as composing of components i.e. it is composable (see figure 3).
Figure 3 - A composable system
In some cases, the individual components of a system are themselves composable systems (i.e. contain many sub components). For example, in the case of the HS2 (high speed rail) map then the component - Web site - is in fact an entire system of many components and is therefore itself composable. See figure 4.
Figure 4 - A composable system within a composable system.
Hence whenever you look at a complex map, you can often aggregate components for convenience due to fitness (i.e. related components are part of a sub system) or alternatively you might wish to treat components individually or alternatively you might need to sub-divide components into lower order systems. Whether you need to do this depends upon the granularity of what you need to examine.
In figure 5 and 6, the aforementioned project show in figure 1 was summarised to a simpler view. First, components were grouped into general systems based upon fitness and then each system was treated as a component. Each component is an independent and logical value chain.
Figure 5 - Grouping of components into general systems.
Figure 6 - High level view of the overall system
Policy type work and overall strategic play usually requires a fairly coarse view of the landscape (such as those shown in figure 6). Purchasing choices and more tactical play often require a finer grain view (such as those shown in figure 1).
Of course, you shouldn't just view an organisation alone but compare with competitors and other markets (see figure 7). The more information you have, the better the play.
Of course, you shouldn't just view an organisation alone but compare with competitors and other markets (see figure 7). The more information you have, the better the play.
Figure 7 - Comparison with competitors
So when mapping, the level of detail (and situational awareness) varies depending upon what you're doing. A strategic game plan between massive companies requires an often coarse overview of the entire landscape whereas the tactical moves for a particular subsystem requires a more finer understanding of a particular section of the landscape.
However, it's not just the components but the interfaces that matter. Ideally you want to have semantic and syntactic interoperability between components and hence standards become increasingly important as the system becomes more industrialised. At the same time, for reasons of second sourcing and buyer / supplier relationship you want to have substitution for components and hence semantic and syntactic interoperability between different instances of the same component becomes important.
For those with a manufacturing / heavy engineering / biological systems background this is all old hat. However, it doesn't mean it isn't relevant today. Jonathan Murray last year talked about the 'Composable Enterprise Model' and it certainly has struck a cord with the digital crowd trying to grapple with change around them. It's well worth a read.
However as good as it is, just be mindful that these methods have been around a long time and models like Two Pizza and FIST (fast, inexpensive, simple and tiny) exploit componentisation effects. As James Governor said 'ibm has been talking about this shit for YEARS'. Well, the wider industry has been talking about it and doing it for a considerable time.
So whilst it's a good idea to think and act in these terms, don't just assume it'll create you an advantage. You should instead think of it as way of competing on a more level playing field against those who have been doing this for a long time.
Figure 8 - A typical block and wire diagram
Oh, and before I go. Mapping is relatively new - starting in 2005. I designed the system because the alternative block and wire diagrams (see figure 8) along with other forms had no concept of change. Understanding change - which you cannot view over time but instead have to view over ubiquity versus certainty, hence evolution - is essential for any form of strategic gameplay.
Figure 8 - A typical block and wire diagram
Maps are more than just learning how to manage something but they enable you to start to explore common economic patterns, strategic gameplay and rules of competition. It's a critical part of situational awareness and there's little point in consolidating down to shared components within an organisation if by the time you have achieved this the components have evolved to a more industrialised form.
