A tooling strategy for SIAM
|“To make multisourcing arrangements effective, customers must get suppliers to work together, both from the commercial and operational standpoint. The Services Integration layer, comprising elements of process, tools, service level agreements and related structures, is absolutely critical to the success of these arrangements”
Forrester Research, September 2011
What is SIAM, and how can it benefit your business?
As organisations move towards a multi-vendor, tower-based sourcing model, there is a need to create a central capability to coordinate and manage service management processes, exert governance and manage service provider performance. The SIAM (Service Integration and Management) function can be retained or sourced as an over-arching tower function.
As Forrester stated (left), it is critical to get the suppliers in the eco-system to work together, and this is facilitated to a large extent by the tooling.
The SIAM function is accountable for ensuring consistent execution of processes, as well as acting as the translation layer between the technical services provided by the tower providers to business services consumed by the business. This is described in the simple SIAM model in Figure 1.
In this article we will explore and analyse the tools required to successfully create an effective SIAM model. To keep things simple we will keep tools that are specific to other functions, for example password reset tools used in a Service Desk environment, out of the equation and look at them in more detail in a future article.
SIAM tooling strategy
As more and more organisations embark upon a SIAM strategy to IT sourcing, where a multi-vendor approach is adopted, the importance of a robust tooling strategy has become even more important.
This renewed importance is primarily due to the fact that, in a multi-vendor environment, ownership of the various tools in the overall portfolio can become unclear. In order to maximise the business benefits of the SIAM model, your existing toolset will, at the very least, require configuration changes. In all likelihood, a completely new toolset will be required if you want to see the full value and of your transformation and a clear return on your investment.
With these business goals in mind, let’s take a look at the six primary areas of focus for SIAM tools, as set out in Figure 2, and then clearly set out the requirements for a good SIAM tooling strategy.
IT service management
The selection and adoption of the right service management tool lies at the heart of any successful IT strategy. Organisations with legacy service management tools first need to redefine their requirements, then re-evaluate their existing tools and decide whether they are fit for purpose in a SIAM eco-system. The next section explores some of the core attributes of an ITSM tool in a SIAM environment, which are over and above the core functionality expected from an ITSM tool.
From my experience, a good ITSM tool will have the following features:
• Seamless integration
Uppermost of these essential characteristics is the ability to integrate seamlessly with other tools through the use of industry standard interface technologies. This will allow the real-time transfer of incident, problem, change and request tickets between different systems, which is particularly important in a SIAM environment as there is the potential for numerous suppliers to be involved in the resolution of a single ticket. Ideally, a single, common toolset should be established, as the single source of record and all suppliers should use this system for simplicity and accuracy. This avoids the requirement for complex tool integrations, but SIAM organisations need to be wary of the fact that, if a supplier is forced to use a designated toolset, they will undoubtedly have to integrate the chosen tool and their own in-house toolset in order to exchange data with shared service teams within their own organisation.
• CMDB integration/synchronisation
In a multi-vendor organisation, it is critical to have a single consolidated Configuration Management Database (CMDB), so that there is only one point of reference for impact analysis and a single view of the end-to-end IT services delivered. However defining, building and maintaining this model can be extremely challenging for an IT organisation.
From my experience of CMDB implementation, I would recommend taking the following two steps, which will help to reduce this complexity:
- Define the CMDB data model, which describes the Configuration Items (CIs), attributes, and the initial data load and data maintenance mechanisms for each CI
- Reduce the circumstances where suppliers are using their own CMDB and then updating the SIAM CMDB. Separate CMDBs can be effective for maintaining CI data accuracy, but this approach fails completely when attempting to maintain the dependencies and relationships between CIs. Whilst many suppliers will need to use their CMDB as part of a broader shared service offering, the risk of CI data inaccuracy as a result is a very real one
• End-to-end workflow
This functionality enables the definition of complex workflows, which simultaneously support the allocation of tasks to multiple resolvers, perhaps on different tools. This is particularly important in a multi-vendor environment, given that any incident, request or problem is likely to require multiple parties to be involved in its resolution/fulfilment. In the case of change management, the process can become more complex, as reviewers and approvers of a given change will be drawn from the entire supplier eco-system, and as such there are multiple ‘calls’ out from the SIAM tool to the supplier eco-system at each stage of the change process.
A failure to create an end-to-end workflow across the supplier eco-system will mean either manual data entry or manual processing is necessary, which will slow down the process and introduce the risk of errors occurring. Ultimately, this will reduce the speed with which incidents can be implemented, changes assessed, authorised and implemented or user service requests fulfilled.
• Common data dictionary
The tool set needs to reference a common data dictionary whereby data such as incident priorities, change types, and request catalogues follow common definitions and data values. This will avoid the need for data translation across groups and thus reduce the risk of information being lost in translation.
The common data dictionary is best defined in an interface control document, which describes, at field level, the contents of each ticket type and the CMDB CIs and their attributes. The interface control document also needs to describe the relevant data transmission protocols that allow ticket and configuration data to pass between the SIAM ITSM tool and the tools being used elsewhere in the vendor eco-system. This is critical to ensure that service providers in the eco-system can work together collaboratively, using the service management tool as the single source of record for all of their work.
Above, we made reference to the CMDB and emphasised its importance. However, we also need to understand how data gets in there and how is it is maintained. This is critical to ensure that the CMDB data is complete and accurate, as the CMDB will be used across the SIAM eco-system for impact analysis of incidents, problems, and prospective changes.
In order to achieve and maintain CMDB accuracy, initial data loads and the auditing of CMDB content should be undertaken using a discovery toolset. These can range from simple ‘asset’ discovery, right through to complex application dependency mapping tools, which provide end-to-end service views based upon the components discovered.
In a SIAM environment, discovery can become an extremely contentious subject. The need for it is undisputed, but each service provider in the eco-system is likely to have their own discovery tool, and will want to insist that this is used, as they will trust their solution and have staff trained in its operation.
Ideally, you need to impose a single tool set here, to reduce the CMDB integration challenges that arise when you try to populate the CMDB from multiple discovery sources. In addition, if you accept an ‘anything goes’ approach to discovery tooling you may end up with tools that cannot transmit to the CMDB effectively or that are unable to capture valuable data about the relationships between CIs. This could negatively impact upon the wider business by reducing the availability of service-focused CMDB data. Remember, if the CMDB is inaccurate or incomplete, critical impact analysis decisions could be made on incidents or prospective changes which are based on false data. This will eventually lead to service unavailability, reputation damage and customer dissatisfaction.
Software asset management
Allied to discovery is the need not only to manage the hardware assets, but also the software assets and particularly the licensing. In a SIAM environment, this is more complex due to the fact that:
- Suppliers in the eco-system may each retain some software licensing responsibility, but it is generally the organisation using the software which has the software liability.
- There is often a need to consolidate software entitlement and usage data across systems managed by multiple vendors.
In order to combat/pre-empt these issues, I recommend that the SIAM organisation maintains a central software asset management tool that is able to receive and analyse data from multiple sources in order to create a single, consolidated organisation-wide view.
A requirement that is often overlooked due to the focus on ITSM tooling is the ability to correlate events generated elsewhere in the SIAM eco-system and apply a service view to these. In other words, if a technology component fails, which service is impacted by the failure? Another way to look at this is that the SIAM layer is service-focused, whereas the technical towers are infrastructure-focused. The SIAM function needs a correlation tool to enable it to perform the service integration role effectively
Due to the siloed nature of the SIAM sourcing model, the service providers in the SIAM eco-system are unlikely to possess the full end-to-end view of the all the infrastructure and application components that come together to form the service. This information is typically found within the CMDB. The relationships between these ‘physical’ CIs and their logical counterparts, such as business processes and services, should also be contained within the CMDB but this is seldom the case because of the complexity involved in obtaining information about services and the infrastructure upon which it runs.
This issue needs addressing because, in a complex SIAM model, a service-orientated CMDB will improve incident impact analysis and improve change impact assessment. Failure to build this ‘single version of the truth’ CMDB could lead to unexpected service failures, business productivity impact, dissatisfied users and reputational damage. To combat this issue application dependency mapping is required to supplement the information relating the physical CIs to the business applications, operations and processes so that the complete service can be mapped, dependent infrastructure items identified and impact analysis performed effectively.
The recent failure of Royal Bank of Scotland systems further supports this need. In this case, not only did they suffer from all of the adverse impacts above, they also received a massive regulatory fine.
One CIO I know gave a great reason for needing this functionality by saying: “when my phone rings, the event correlation tooling will tell me why it’s ringing before I pick up”. I thought this really summed up why this tooling was required.
A common problem in a SIAM organisation is the production of reports, because there is a tendency for reporting to become all consuming, with a myriad of reports all showing supplier and service performance metrics which often mean little to the business. Reporting can easily become a ‘cottage industry’ in its own right. There is a simple way to address this which we will look at below but first let’s consider the different types of reporting, which tend to fall into a number of categories, as follows:
• Vendor-focused commercial reporting
This describes how the vendor is performing against their commercial SLAs and KPIs, and describes the overall commercial picture, highlighting where measures have been achieved and describing where failures have occurred and why they happened
• Vendor-focused service reporting
This focuses on the performance of the services provided by the vendor, in terms of SLA performance, for example the processing of incidents, problems and changes
• Business-focused volumetric reporting
This focuses on the number of tickets raised during the reporting period, and provides trending over time. In my opinion, there is limited value in this type of reporting, but it is surprisingly common! The fact is that this type of reporting is quantitative rather than qualitative, and is therefore fairly one-dimensional in nature.
• Business-focused service reporting
This tends to focus on the performance of the business in terms of end-to-end services, and is perhaps the most useful in giving business insight into the quality of service being provided.
Ideally, reporting will be largely sourced from the service management tool, which should act as the single authoritative source of ticket data from across the SIAM eco-system. This ‘single source of truth’ reduces the need for manual data manipulation and provides a sound and trusted basis for all reporting.
Where the service management tool is not sufficient to meet the reporting needs, it may be appropriate to supplement this with a specialist reporting tool with sophisticated data analytics capabilities. However, this is likely to require a significant amount of configuration and user training before the organisation can receive valuable management information from it. In my experience, the configuration effort pays dividends in the long term. However, be sure to build the analytics capabilities gradually to ensure they are sustainable, and ensure that there is strong governance in place to manage requirements. Failure to do this could result in the organisation meeting every reporting requirement presented to it but failing to provide business value through the provision of insightful and useful content.
Commonly, the service providers in the SIAM eco-system will each have a responsibility to deliver capacity data to the SIAM organisation. Typically this will be ‘tower-focused’ data, which focuses on the infrastructure or applications within that service provider’s tower. In ITIL terms, we would call this resource/component capacity data.
This data needs to be consolidated and brought into service views, so that you can really gain some confidence that your business processes and services have sufficient capacity to meet the planned needs of the business. This is the role of the SIAM organisation, and the tooling that performs this consolidation should be managed by the SIAM organisation.
However, the means by which this is achieved needs clarification. In essence, what we are hoping to achieve is to take all this component-focused data, apply a service lens to it and produce capacity reporting, which will allow us to demonstrate to the business either that all is well for the foreseeable future or, more commonly, that they need to invest in some new infrastructure to meet the growth plans of the service.
So, having drawn a clearer picture of the ‘shopping list’ required for successful SIAM tooling, here are some tips for bringing this to reality:
• Define a tooling strategy which outlines what you need, who is going to own what tool, and how they will come together to meet the stated requirements
• Define a set of functional and non-functional requirements and score each potential vendor using a formal process
• Use a set formula and agreed common language for defining your requirements, selecting potential vendors and managing a slick selection process
• Don’t be tempted to go with the vendor with the shiniest brochures or the slickest salesman!
• Focus upon interoperability between tools, not just the tools themselves.
Remember that tooling is only one part of the challenge. Tools are configured to perform against defined processes. They are operated by people who are working within an effective and appropriate organisation model. The people, process and tools come together to deliver outcomes, which are managed by an over-arching governance model.
Above all else, remember that SIAM tooling is there to support the SIAM strategy. The original decision to embark upon a SIAM approach will have had its own set of objectives and outcomes it was looking to achieve. The implementation of the tooling strategy should seek to deliver against these objectives and outcomes. After all, it is likely that SIAM objectives which involve reducing complexity, improving service quality and efficiency, and improving end-user satisfaction will be largely delivered through an effective set of tools, processes and people deployed across the SIAM eco-system.
|Steve Morgan is Director of Syniad IT Solutions. He has over 25 years of experience of working in IT, both in operational and consulting roles. He led the KPMG Service Management team in the UK before leaving to form Syniad IT Solutions Ltd in February 2012. Steve has extensive experience of working on complex SIAM programmes, having helped organisations such as BP, Royal Mail Group and Zurich Insurance design, build and operate multi-vendor IT sourcing models. He is also the former Chairman of the ITSMF UK SLM Special Interest Group.