Monday, 13 April 2015

Avoid knocking down the towers of SIAM by designing them propely.

On 18 February 201, Alex Holmes published a blog article called "Knocking down the Towers of SIAM", this article sparked a debate about how fit for purpose the Tower Model was as a key part of the SIAM Service Delivery and Management Operating Model.

I have included an extract from this article below and I have added personal thoughts from me (in boxed blue text) on some of the points made in the article.
The complete article can be found here

Tower Model
Unfortunately, the combination of these two forces created a hybrid model unique to government. The model is usually referred to as the Tower Model. It combines outsourcing with multi-sourcing but loses the benefits of either. The model has arisen because organisation have used a procurement-led solution in response to legacy outsourcing contracts ending. Rather than changing their approach and emphasis, they have ended up outsourcing their IT again, but in pieces.

It was still all about us, not about the needs of our users.

Organisations have adopted the Tower Model, believing they are following government policy and using best practice, but they are doing neither. I am now writing this post to be clear that the Tower Model is not condoned and not in line with Government policy. Government should use the best of what is already out there – not develop its own model.

As the programme that has replaced IT services in Cabinet Office, DCMS and the Crown Commercial Service has shown, multi-sourcing can deliver over 40% savings, delivering services that transform how people work, quickly.

Multi-sourcing works because at its core is an understanding of user needs. The team responsible for the IT service knows what services are needed to currently deliver those needs. The team, which is largely made up of civil servants, owns the accountability and architecture. Departments should make sure they have the capability to do this.

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.
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.

A well design and governed Tower Model that is part of an effective SIAM IT Operating Model is key in enabling component based services which can be consumed both as discreet services in their own right or as integrated end to end services. Any well designed Tower Model would take into consideration the service needs of the business and users in order to ensure that it can deliver the types of services needed at an appropriate cost and with the right functionality and service levels.

Any failure to fully consider “what services are needed” would more likely be caused by poor alignment between Business Relationship Management, the End Users and IT Service Design. 
This failure is often made worse when IT Departments take a bottom up view of the IT lifecycle, starting with products and technology first and using this to define and often influence service design often creating unnecessary restrictions is supplier choice.

Service de-aggregation and integration of services from components is a key feature of SIAM, this approach helps avoid the “one size fits all” development by increasing choice and flexibility enabling a “best fit” service and solution design

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.

Service Accountability and Architecture are good examples of core strategic capabilities and as such these roles that would normally be kept within the Retained IT organisation. Responsibility for governing and managing the delivery of services would be split between the SIAM and the Managed Services Providers in the Towers.

In summary, when developing a responsibility model for SIAM it is important to work out what capabilities are key and can differentiate the business and make sure there is sufficient ownership and control of those while only outsourcing the more commodity functions which can be easily interchanged without strategic risk to the business.

There can be a role for this Service Integration and Management (SIAM) layer, but placing too much responsibility with it increases risk for both the department and the supplier by confusing roles. The SIAM provider should not replace good in-house IT capability.

In my experience a well-designed SIAM function triggers a well thought out review and re-mapping of roles in the new IT Operating model. This mapping also defines who is best placed to perform these SIAM roles ensuring that an IT department can play to its strengths.

Business differentiating roles with a strategic or governance impact should stay with Retained IT, while commodity and more operational roles are candidates for outsourcing.

A well designed and implemented SIAM function should aim to remove any duplication of effort ensuring that Service Management happens once and is paid for once thereby creating a Service Management Centre of Excellence.

In order for a SIAM function to be successful it needs to be intelligent, informed by the use of information and data from across the ITIL Lifecycle giving it the end to end view it needs to orchestrate and manage end to end activities across Towers.

The Tower Model can create a situation where the customer buys a number of incompatible parts and then asks a SIAM provider to put them together and make it work.

This is a risk, however mitigation of this risk is to ensure that Retained IT develops and publishes a baseline of architectural and design standards which take into consideration service integration and that these standards are included is the specifications, selection criteria and obligations that procurement use to buy services.

This will result is towers providing discreet services which are used in their own right as well as component services that follow standards which allow them to be integrated to create manageable end to end services.

Own the solution

What’s much more effective is to design and own the overall solution so that you know it works and can put it together and run it yourself. Or you own the solution, put it together yourself and you use a SIAM provider to run it.

Most organisation go with the second scenario, i.e. they play to their strengths by knowing their business, setting the technology strategy and owning the solution. Solutions are designed, integrated and procured by Retained IT, using the SIAM to manage delivery using services from best of breed suppliers in the Service Towers

Both of these options require a number of steps well before looking at procurement options. Tom Read’s blog post explains the steps you might take in selecting solutions.

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.

No comments:

Post a Comment