Why You Really Need a SIAM Tooling Strategy

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 function can be retained, or sourced as an over-arching tower function.

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

A Simple SIAM model

In this article we will explore and analyse the tools required to successfully create a typical 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 Service Integration & Management (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 and, 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, we are going to take a look at the 6 primary SIAM tools required as set out below, and then clearly set out the requirements for a good SIAM tooling strategy. In this article, (Part 1) we will look in detail at IT Service Management, Discovery and Software Asset Management. You can discover the requirements for success in the areas of Event Management, Reporting, and Capacity Management, by continuing this article.

IT Service Management

The selection and adoption of the right Service Management tool lays at the heart of any successful IT strategy. Organisations with legacy service management tools, first need to redefine their requirements, then reevaluate 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 build an integration between the chosen tool and their own in-house toolset to exchange data with shared service teams within their own organisation
• Configuration Management Database 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 2 steps, which will help to reduce this complexity:

1. Define the CMDB data model, which describes the Configuration Items (CIs), Attributes, and the initial data load and data maintenance mechanisms for each CI.

2. Reduce the circumstances where suppliers are using their own CMDB and then updating the SIAM CMDB. This can be effective for maintaining CI data accuracy, but 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 support the allocation of tasks to multiple resolvers, perhaps on different tools, simultaneously. This is particularly important in a multi-vendor environment given that it’s likely that any incident, request or problem, will require multiple parties 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 toolset 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 in doing so, 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 ecosystem. 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

Discovery

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 be become an extremely very contentious subject matter. 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 toolset 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 focussed 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, which should be used to support impact analysis, and therefore needs to be avoided.

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 to come up with a single, consolidated organisation-wide position.

That concludes Part 1 of this article. In Part 2, we shall look at Event Management, Reporting and Capacity Management tooling, and impart some advice on how to develop your SIAM tooling strategy.

Event Management

A requirement that is often overlooked due to the focus on ITSM tooling is the ability to correlate events generated elsewhere in the SIAM ecosystem 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 focussed, whereas the technical towers are infrastructure focussed. The SIAM function needs a correlation tool to enable them to perform their 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 all the infrastructure and application components that come together to form the service. This information is typically found within the Configuration Management Database (CMDB). The relationships between these “physical” CI’s and their logical counterparts, such as business processes and services, should also be contained within the CMDB but this is seldom the 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 Scotland systems further supports this need. In the case of RBS, not only did they suffer from all of the adverse impacts above, but 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.

Reporting

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. It 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 look at the different types of reporting, which tends to fall into a number of categories, as follows:

• Vendor-focused commercial reporting – This reporting 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 reporting focuses upon the performance of the services provided by the vendor, in terms of SLAs performance, for example, the processing incidents, problems and changes
• Business-focused volumetric reporting – This reporting focuses upon 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 reporting tends to focus upon 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 ecosystem. This “single source of truth” reduce 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 to 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 to manage requirements. Failure to do this could introduce the risk of the organisation developing its own reporting “cottage-industry” which meets every reporting requirement presented to it but fails to provide business value through the provision of insightful and useful content.

Capacity Management

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 will focus 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 get 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 now got a clearer picture of the “shopping list” required for successful SIAM tooling, here’s some tips for bringing this into reality:

• Define a Tooling Strategy that outlines what you need, who is going
  to own what tools 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 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 the SIAM tooling is there to support the SIAM strategy. The original decision to embark upon a SIAM model 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 ecosystem.

To find out how we help organisations like yours design and build highly effective operating models, read our ultimate guide to SIAM.