In this post I'm going to cover some issues with the SIAM Tower model. I'll use mapping to do this.
Wardley Mapping is a technique that I developed out of utter frustration with IT and the business. I've used it for over a decade with continued success. It's based upon two things. Firstly a value chain (derived from user needs) which describes an organisation. Secondly, evolution which describes the process of change. The two are essential because there's not point in try to deal with an organisation 'as is', you need to also consider 'where things are heading'.
The evolution axis wasn't developed by sitting in a room thinking up what might be a good idea in a powerpoint presentation. It took over six months of intensive collection of many thousands of data points just to test it. In total the mapping technique took over ten years to create (1995-2005) and several more years to test the validity of the axis.
I'm going to start with an example of a map, an early draft from HS2 (high speed rail) and then compare the approach. This is what a Wardley map looks like (see figure 1)
Figure 1 - a Wardley Map.
Couple of things to note with the map. At the top are the systems that provide the user needs. Underneath is a chain of needs i.e. components that the higher order systems require. Each component (or node) is positioned according to how evolved it is.
What might not be is obvious is that each component could be an activity, practice, data or piece of knowledge. All components evolve through the same mechanism and as they evolve their characteristics (i.e. properties) change. The mechanism of evolution is shown in figure 2 (it is driven by demand and supply competition)
Figure 2 - Evolution
I've summarised some of the changes of properties in table 1. Ignore the class / phase part - that's part of a classification system which isn't relevant here.
Table 1 - Changing properties of an evolving component.
What this means is when you look at your Wardley map, then the components of the map have different properties depending up how evolved they are. This is summarised in figure 4.
Figure 4 - Change of Properties.
Hence the Wardley map (figure 1) has the terms 'uncharted' and 'industrialised' at the top. When applying methods to a complex system then you have to use many methods because each method is suited to a different part of the map (see figure 5) whether it's project management or purchasing.
Figure 5 - Appropriate Methods
So when you start to manage your map, you treat each component individually and apply the right techniques. In some cases you'll get variation in the high level maps because the node might represent an entire map underneath and has been simplified (see Sub Maps in Other Tools post). An example of applying the right methods is given in figure 6.
Figure 6 - Apply the right methods
Now the danger of outsourcing a large chunk of activities is that if you do this then it's probable that a single (and inappropriate) method will be applied i.e. a very structured method like six sigma will be used across all of the map. This will inevitably lead to change control costs overrun as the uncharted components will change (they are unknown, uncertain and require experimentation). There is nothing you can do to stop this cost overrun. You can't more fully specify the uncharted activities precisely because they're uncertain and unknown. Arguments inevitably kick off and the supplier will point to all the industrialised acts which didn't change and were delivered efficiency. The "fault is you" but this is NOT true. The fault is the application of a single and inappropriate method. I've summarised this in figure 7.
Figure 7 - How you don't want contracts to be structured.
Now, many companies have little or no situational awareness. They have no maps. So they outsource large chunks, get hit by excessive change control costs and invariably get told it was their fault for not knowing what they wanted and specifying enough. The vendor wins, the customer loses. This is pure hokum, it shouldn't happen and many vendors exploit this to their advantage. The reason for the cost overrun caused by excessive change control costs was simply the single method used.
In general what you want to do is break down a system into small focused contracts which use the right methods i.e. you don't want some broad and widespread contract across the map. A comparison is given in figure 8.
Figure 8 - Contracts - Good vs Bad.
So, what's wrong with SIAM and the tower model?
Well, lets look at it (see figure 9). The grand idea is to break things up into smaller chunks called Towers (which is a good move) but these chunks completely ignore evolution. They are arbitrary divisions such as application development, hosting, operations, end user services etc. These are all then reintegrated and combined with business retained IT organisation.
Fortunately, some of those towers are quite commodity by nature e.g. IT infrastructure. So we do strike lucky twice with smaller contracts and a few towers being commodity. But other than that, it's up there with Bimodal IT - lipstick on a pig. It is ignorant of the process of evolution and of dubious long term merit despite being slightly better than the past.
Figure 9 - SIAM and Tower model
Of course, most companies have no situational awareness, no maps and many will think the Towers of SIAM will be a grand idea because (by pure probability of placing the right components into a small contract and some of the towers being more commodity like) then it will be slightly better than the past models. But it's also easy for a savvy vendor manipulate, not grounded on any understanding of change and simply breaking a system into towers and outsourcing those is far removed from where good management is. It's true merit can only be as a transitional move to break an even more undesirable 'outsource everything' approach.
I wasn't surprised to hear Alex Holmes wanted to tear down the Towers. It's time they were. Departments need to start learning how to manage things effectively. Some already are.
