We are SIAMese, if you please

Posted on: August 20, 2013 by Mike Smith

Atos - We are SIAMese, if you pleaseOver the past few years we've seen, and indeed some of us have been part of, the emerging SIAM model for managing complex IT services. SIAM stands for Service Integration and Management, and like ITIL before it, is being pioneered by Her Majesty's Government in the UK. SIAM is not an alternative to ITIL though; they work hand in hand - SIAM could be considered an evolution of some aspects of ITIL, but it is operating at a higher level.

There are now four broad approaches to managing your IT services – let’s call them “modes”:

  1. Do it yourself, running your own IT department, buying in external services as needed
  2. Outsource everything (in scope) to an IT services organisation; who may deliver all services themselves or act as a prime contractor; combining the services of others with their own
  3. Outsource delivery components to multiple organisations, managing each contract and supplier yourself in a "retained organisation"
  4. Outsource delivery components to multiple organisations, and also outsource the management function using the SIAM model.

I think you can see the evolution; as IT gets more complex and IT service providers can provide more cost effective solutions (than doing it yourself) by leveraging resources, both people and technology, it becomes attractive to move from mode 1 to 2. Throughout the nineties and noughties we saw increasingly large all-encompassing IT services contracts; I myself was the solution architect for over £1 billion of business won by Atos in just a hand full of very large contracts (I must remind the boss!) But this trend is reversing, putting all of your eggs in one basket is considered, by some, to be too risky. Awarding just one IT services organisation with all of your IT business could permit them to become too powerful, locking you in and not necessarily providing what is best for you.

So we have seen a move in the industry to break down services into a few major components and outsource them separately. Moving from mode 2 to 3. Choosing how to break the services down has historically been fairly straight-forward. You could create a lot for datacentre hosting; another one for desktop and service desk services; another for network provision and management etc. These technology "Towers" are typical in our industry and all outsourcers have worked broadly in this way, so it's a model that works.

However this now introduces a large overhead in managing separate contracts with each provider, and more importantly the interactions between them. You need to ensure, for instance, that sufficient bandwidth is provided for any changing application requirements. Or that the service desk can take calls for new servers implemented in the datacentre (loading the relevant information into the configuration management database, so that tickets can be raised against them). All of this means that you're now spending time coordinating this instead of getting on with your own business. Hence introducing mode 4.

So what is in the SIAM function?

I'll be brief here, as you can find more detail on the UK Government website (https://www.gov.uk/service-manual/technology/service-integration.html):

We have already established that Towers are used to provide the actual technology services to the business - application, network, hosting, workplace; you name it. The types of activity undertaken by the SIAM function itself include:

  • Governance of the Tower suppliers
  • Overall service architecture and technology strategy
  • Service Desk services
  • Knowledge Management
  • Service Catalogue (including entries for each of the services delivered by the towers)
  • Security Management
  • Roadmap planning, transitions and testing
  • (and more, but I won't go on ...)

Note that here we have split Service Desk from what has historically been quite closely aligned with workplace (desktop, laptop, onsite support and similar) services. Also quite a few of the associated components (and tools) come with it.

To Prime or not to Prime, that is the question

How does SIAM differ from a "prime contractor" role then? Well, in a Prime contractor relationship all of the contracts are with the Prime, not with the business. It is incumbent on the Prime to ensure that appropriate "back-to-back" agreements are in place, and KPIs match up - their margin is counting on it. In the case of SIAM the contracts with the Tower service providers remain with the business itself. In SIAM it is almost the same as a Prime, as responsibility for the governance of the Towers is passed to the SIAM organisation too. But the subtle difference is that the business still retains control of who it wants to provide the services for each of the technology Towers.

It's actually something Atos is very au fait with, not that this should be taken as an overt advert for Atos services (this is a personal blog post), but it's worth noting that Atos undertakes a "Prime Integrator" role for the Olympics IT services. The Prime Integrator is not a Prime Contractor - it's actually a SIAM relationship, as the technology providers to the International Olympic Committee have direct contractual relationships with the IOC; not with Atos. Anyway, I digress.


As we now begin to deploy and deliver SIAM-based services, and this is really the point of publishing my thoughts publically, I want to ensure that we address the possible challenges that await us across the industry and you, our joint customer base.

The first obvious (to me, at least) challenge is with technological integration across the Towers. Management, monitoring, automation, tooling; there's a risk that by partitioning into separate tower delivery functions we lose the opportunity to operate efficiently and innovate in these areas. I am going to pause here, as I want to make some other points then return to this.

One challenge worth mentioning is that it is frowned upon for IT services providers to be a supplier of both the SIAM function itself and one or more Towers. You can understand that by owning the "high ground" one might be tempted to leverage this to build in other areas. However this (perfectly understandable) stipulation has led to some organisations choosing to withdraw from, perhaps, less attractive (i.e. smaller) SIAM services so that they can continue to participate in competitions for larger (though possibly not more lucrative!) Tower services. We're still working through this.

The changing tower landscape. In fact the technology towers I introduced earlier are aligned with the technical support towers in the Atos organisation (and others too) - in our case we really do call them Towers. So the SIAM model works in a very similar way to how services are managed within large IT services organisations already. This is interesting. We might argue that the way we work internally within an IT services organisation (I'll spare you the gory details, but basically it is a SIAM function) means that we could just do it. However the world is changing and we are changing too...

Let's jump to the World of Cloud. All buzzwords aside, we really are delivering more and more services in this manner, and this cuts across the previously introduced definition of Towers. Instead of separate Hosting, Network, Storage and Applications, we now have converged, software-defined, infrastructures. Some delivering email, collaboration and other vertical services. We are also seeing a desire to integrate large-scale service delivery with smaller, more agile services from niche players. So the composition of Towers, and this means people too, is changing. We need multi-skilled roles - covering those previously separate technologies. We must be cognisant of this when considering the construction of SIAM-based contracts.

Let's return to my technology point. A couple of years ago, through a major acquisition, we brought together two IT services organisations and at that time we defined what we call the Atos Technology Framework ("ATF"). It is the reference architecture by which we manage our IT services contracts. We have standard tools and interfaces that we use across the majority of our customer base (there are always hesitations, deviations and maybe repetitions, but in the main the ATF defines the way we want to manage our services to achieve the efficiencies I referred to in "mode 2"). It covers service desk tooling, service catalogue, monitoring, Anti-virus, provisioning, standard operating systems, capacity management ... these are just examples; in fact everything technology-wise you could think of really. This framework bridges the Towers, and supports the internal SIAM-like functionality, enabling us to provide standardised management services with known interfaces; facilitating automation and reporting across the whole technology landscape.

So my vision is to externalise this. An approach and "API" that enables SIAM contracts to efficiently integrate across the Towers; across the clouds; across the IT service providers. Some of it could be very technical - APIs, interfaces, feeds, JSON, REST. Some of it less so. However my goal in a SIAM world is to join up the ATF with my made up CTF, FTF, ITF, CTF (again), and all of the other technology management frameworks we have in our industry today.

Let's work on it together.

Share this blog article

  • Share on Linked In

About Mike Smith
Chief Technology Officer, Atos Distinguished Expert, Founding member of the Atos Scientific Community
Mike has been in the IT industry for over 20 years, designing and implementing complex infrastructures that underpin key Government and private sector solutions. Setting Atos technical strategy, researching new technologies and supporting the consulting and architect communities. Previously Mike has held technical and management positions in British Rail, Sema Group and Schlumberger. He has a daughter and a son, both keen on anything but technology. Mike's sporting passion rests with Test Match Special, and is jealous/proud of his son's Ice Hockey skills.

Follow or contact Mike