This is part 1 of a series of blogs by SIAM specialist Kevin Holland. This blog addresses the history of SIAM ‘towers’. All views and opinions expressed in this blog are Kevin’s own.
Knocking down the towers of SIAM
In February 2015 Alex Holmes, then the Deputy Director and Chief of Staff in the Office of the CTO for the Government Digital Service, published a blog entitled ‘Knocking down the Towers of SIAM’.
In this blog, Alex criticised the way that Service Integration and Management (SIAM) was being implemented in many parts of the public sector, and in particular the ‘tower’ model:
“It combines outsourcing with multi-sourcing but loses the benefits of either”.
Many took this blog to mean that SIAM was dead, and no longer a preferred delivery model for the UK public sector. This interpretation was completely wrong. In this blog, I will explain why, and what the future holds for SIAM; but first you need to understand how the UK government in particular, and SIAM in general, got to this position.
DWP 2005
The concept of SIAM was ‘invented’ in 2005 for the Department of Work and Pensions (DWP), a major UK government department. They had previously outsourced delivery of their IT services, and wanted to improve delivery and value for money.
The main idea of this transformation to SIAM was to remove duplication of service management activities from the multiple delivery units, by creating a ‘service integration’ layer within the outsourcer, known as a ‘SIAM tower’. This layer would perform many of the day to day service management activities for the delivery units, but also provide co-ordination, assurance, and governance.
The activities of the delivery units were separated and aligned into ‘delivery towers’. Each tower provided a unique type of IT service: hosting, networks, application development and maintenance, application support, and desktop. Each tower was provided under a separate contract with DWP.
Figure 1: ‘tower’ contracting model
In essence this initial incarnation of SIAM was still an outsourced solution, delivered under a prime supplier/systems integrator arrangement, but with a much improved and transparent operating model. Subsequently, some of the tower contracts were awarded to different organisations.
This SIAM model, and the associated ‘tower’ terminology, was then adopted by a small number of other large government departments.
NPfIT 2004
About the same time, the National Programme for IT (NPfIT) was established for the National Health Service in England (NHS). This was a green field environment with a different challenge – integrating fully managed application services with fully managed infrastructure services and locally delivered services, from scratch, in less than 6 months, in order to deliver high availability services to over 350 different customer organisations in the NHS. The resulting architecture had a matrix of interconnected services, connecting over a shared network and shared messaging services.
In this model, each service provider continued to perform their own service management activities, supporting their own services. There was no concept of ‘towers’, or separating services into unique types of IT service (although there was a single provider for the wide area network). The delivery units were the service providers. The service integrator was (and still is) part of the NHS. Subsequently, some of the services were provided by in-house ‘DevOps’ delivery units from the same organisation as the service integrator.
Figure 2: NHS service integration model
This delivery model was at that time unique to NPFIT in the UK public sector, but has since been adopted in the private sector.
History of government IT projects
The reported success rate of government IT projects has never been good. Whilst there were some successes, before 2012 most government IT projects historically shared the same characteristics and foibles:
Projects and services:
- long delivery cycles
- nearly every project was delivered late
- very few projects delivered the expected benefits
- high costs of development and maintenance
- high costs of change (a well-known supplier once quoted £10,000 to make a minor change to a report format)
- expensive component services, such as hosting, when bench-marked against the open market.
Sourcing and commercial:
- always delivered by very large prime suppliers as ‘outsourced’ services
- long contract periods (a 10 year term was common)
- high use of subcontractors
- a perception that the prime suppliers made good profits out of the services
- difficult and costly to move away from the incumbent supplier (contract extensions were common)
- very little use of small & medium enterprises (SMEs)
Solution architecture:
- nearly every solution was unique, and bespoked to meet large sets of often complex but often unclear requirements
- solutions were usually created by integrating off the shelf systems and components stitched together with bespoke code
- no sharing or re-use of ideas and solutions between different government departments, and even within departments
A government minister allegedly once summed up the situation as:
“We never get what we really need, we always get it late, it always costs us a lot more than we anticipated, and some suppliers have been making a lot of money out of us for years”
New strategy for ICT in government
In order to start addressing these issues, in 2009 and 2011 the UK Government developed and published new ICT strategies, aimed at changing the nature of government computing for ever. I was personally involved in the design and development of these strategies, and the supporting GCloud, PSN, IT professionalism, and SIAM Enterprise model initiatives.
The intended outcomes included:
1. Change from single supplier to multi-supplier solutions
2. Significantly reduce contract terms
3. Increase the number of SMEs supplying to the government
4. Move to commodity pricing (pay for what you use)
5. Use what’s available in the marketplace instead of bespoking solutions
6. Reuse solutions across government and the wider public sector
7. Build internal capabilities and bring work in-house
8. Incrementally release functionality, and associated spend
9. Avoid supplier lock-in
The imperative running through all of these was the need to move away from large and long-term outsourced contracts to a mix of multiple, smaller, and more flexible contracts and in-house provision, using small to medium enterprises (SMEs) where possible.
This would require a major shift in how IT services were designed, procured, and operated, and a corresponding major shift in mindset. It would also require a change from prime supplier models to SIAM based models.
What happened next?
Government departments who were coming to the end of their single supplier outsourced IT contracts came under pressure to move to a SIAM model, in order to get the necessary funding. Many of them had limited time before contract expiry, and limited in-house resources with very little, if any, knowledge of SIAM. They also had to follow OJEU procurement rules, with the associated long lead times between initial approval to proceed and supplier mobilisation. At the same time, the global financial crisis led to considerable pressure on them to reduce costs and headcount.
The ‘tower’ model was strictly followed in the design of their SIAM models. This meant that departments with legacy applications that were previously wholly supported by one organisation divided them into hosting, application development, and application maintenance and support Towers. Small departments using just standard desktop applications thought that they too had to move to a SIAM model.
The big service providers quickly re-aligned their delivery models with the tower structure. They wanted long-term contracts, to make it worth their while. Some of them developed SIAM tower solutions, re-working their ITIL processes as SIAM processes.
The departments put out tenders for the SIAM tower and delivery towers. In many cases, potential suppliers were told that they couldn’t bid for the SIAM tower if they also wanted to bid for a delivery tower. Contracts were awarded after competitive procurement processes.
The result
In short, the aims of the government’s ICT strategy were not met. Departments went from one single high value, long-term, outsourced contract, to several high value, long-term, outsourced contracts. Many services were bespoked to each situation.
Alex Holmes’ blog neatly described the result:
“A fundamental part of our guidance was about taking accountability for decisions about technology and digital services back into government. For large parts of the Civil Service that had so completely outsourced their IT, this meant a massive shift in approach, which takes time and can be scary. This fear of change meant some organisations clung onto the concept of outsourcing, which they understood, but they also wanted to comply with the new policy of multi-sourcing IT provision – something that is recognised as best practice across the industry. Rather than changing their approach and emphasis, they have ended up outsourcing their IT again, but in pieces.”
There is a view that the service providers contributed to this undesirable situation. Here is part of a comment on Alex’s blog from Nicky Stuart, an experienced public sector procurement professional:
“Curiously, in the noise (about the blog) there has been a deafening silence (from the suppliers). The vendors with the most vested interests in the tower model have been unusually quiet. They have a lot to defend. Holmes’s blog strikes at the heart of SIAM – precisely where the incumbent vendors have been re-positioning to ride out the changes of the last five years: digital by default, G-Cloud, and the SME agenda.”
Alex went on in his blog to focus on the design of services and bringing work in-house:
“An important point about multi-sourcing is that different things are bought in different ways: there is no “one size fits all” methodology. Commodity products like hosting will still likely be outsourced to utility suppliers, but novel or unique things close to the user may be built in-house. And components can – and will – be changed often.
Generally speaking, you should understand user needs, bring in the right capability and skills, analyse existing applications, architect a disaggregated desktop using cloud infrastructure and consider platform options before procuring and commissioning what’s needed.”
Unfortunately hardly any departments had done it this way. There were many valid reasons, including lack of time, lack of expertise, headcount restrictions, attitude to risk, and lack of available guidance on SIAM.
The Tower model – guilty as charged?
Alex focussed the title of his blog on a major contributory factor – the tower model.
“The Tower Model doesn’t work because it doesn’t fully consider what services are needed, or how they fit together and it uses a “one size fits all” methodology. It relies on procurement requirements to bundle together vertically-integrated outsourcing contracts called things like ‘network’ or ‘desktop’. It also usually outsources the service accountability, architecture and management to a third party.”
Whilst the tower model worked well in the past for DWP and some other departments, it is now out of date with technology and development trends such as Cloud and DevOps. It drives a service landscape with high levels of dependencies, service provider interactions, and service integrator workload, and therefore risks and costs. The term ‘Tower’ itself implies isolation and barriers to entry. That’s why the new SIAM Body of Knowledge from Scopism recommends dropping use of it, and sourcing services in the most logical way to meet organizational needs.
Unfortunately, there were many in the IT industry who took Alex’s criticism of the Tower model to mean that SIAM in general doesn’t work. That isn’t the case, and there are plenty of examples worldwide to prove it.
The second part of my blog will explore this in more detail, and provide an alternative and better approach to the Tower model.
