A road trip to SIAM — start your engines…

Road trip to SIAM 2

In the second of her articles on the journey to service integration implementation, Michelle Major-Goldsmith explains the importance of planning your route with care.

“A journey of a thousand miles begins with a single step” – Lao Tzu

In my last blog, servicemuse.com/siam-road-trip, I introduced the Service Integration and Management (SIAM) journey by suggesting some of the most important considerations of the first stage of the SIAM Roadmap: Discovery and Strategy. This is very much about preparing an organisation for some serious decision making regarding their IT services strategy and it isn’t to be taken lightly. Shortcuts taken at this stage will likely turn into anything from a minor bump to a full-blown road traffic accident.

SIAM is becoming a more familiar approach. It is a management methodology that can be applied in an environment that includes services sourced from several service providers. SIAM introduces the concept of a service integrator, which is a single, logical entity that combines the outcomes of the various service providers and is accountable for the end-to-end delivery of services and the business value that the customer receives.

If you haven’t already, I recommend that you download the SIAM Bodies of Knowledge from Scopism: www.scopism.com/free-downloads.

I now want to move into the second stage of the roadmap: Plan and Build.

Off we go…

“Some beautiful paths can’t be discovered without getting lost.” – Erol Ozan

This is a complex stage in a SIAM implementation. Plan and Build completes the detailed design for a SIAM model and creates the plans for the move to a new operating approach. The objective of this stage is to create an adaptable, scalable model.

The design activities are often delivered in iterations, starting with an initial definition and becoming successively more detailed to complete the design and create plans for transition during the Implement stage.

So, let’s look into some considerations for starting on a Plan and Build journey.

The bigger picture ― providing a scenic route

“Sometimes it’s worth lingering on the journey for a while before getting to the destination.” – Richelle Mead

This isn’t just about selecting some service providers and a service integrator. Required services need to be defined, and the design of service groups needs careful consideration, as these will define the scope of services sought from the various service providers. Supporting processes need to be agreed and technologies need to be selected. Within the design process, detailed distinct architectural viewpoints need to be considered, such as:

  1. Organisational roles. The structure for the customer-retained capabilities, any internal service integrator and any internal service providers, including the formal positions and headcounts as they relate to each other, showing the organisational hierarchy. Using tools such as a RACI matrix (Responsible, Accountable, Consulted and Informed) can help and will provide clarity around roles and responsibilities.
  2. A model for the services. This should detail service groupings, sourcing strategy and the scope of services allocated to the various service providers. The service model shows detailed elements around the who, what and how. This includes elements such as the hierarchy of the proposed services, the service providers for each service and any interfaces between them. It should also show how the customer contributes as well as interactions and activities with external agencies who have a governance or legislative influence. In other words, it paints a picture. Using a tool such as OBASHI (http://obashi.co.uk) to support drawing this picture can work well as the straightforward pictorial depiction can bring clarity.
  3. Process models. These should show roles and responsibilities, interactions between parties and ownership. In a SIAM model, the execution of most processes will involve multiple service providers. Each service provider might carry out individual steps in a different way, but as part of an overall integrated process model. I’ll come back to process models further into this article.
  4. The technology model. This should show technologies that will be used to support the other three viewpoints, including toolsets. A tooling strategy should be created that defines policies, which can be used by the service providers when they design the technology to provide the services and to support the processes. This includes tools for service management processes, system and service monitoring, end-to-end service reporting, collaboration and communication. Having a well-defined tooling strategy will allow consistency and effective collaboration across providers that have different skill sets, tools, policies and procedures.

Integrated engineering for a smooth ride

“Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works.” – Steve Jobs

Of course, within a SIAM model, process execution is likely to involve multiple stakeholders. However, it is important to understand that this does not mean that everyone must follow the same process or use the same tools. In fact, a good integrated process flow is the way to go if all the stakeholders are going to remain engaged. The service integrator needs to provide the appropriate inputs and define the expected outputs and outcomes, but on the understanding that some service providers might carry out individual steps in a different way, within an overall integrated process model with defined interactions, rules and controls.

One approach is for the service integrator to provide a macro process, which contains a number of micro processes. The macro process provides an overview, has an owner and contains the policies, goals and metrics. The micro processes are prescribed procedures such as normal change, emergency change or standard change for change management. The micro processes are modelled in detail and each activity is linked to roles. Some service providers may adopt the micro processes, whereas others, such as large ISP, cloud services or telecoms providers, will probably use their own. As long as the interactions, inputs and outputs between service providers and the service integrator meet the prescribed macro process, the service integrator can retain consistency and control across the end-to-end process.

When designing processes, it is important to consider the range of stakeholders and design processes with them in mind. It is also good practice (where possible) to include service providers in the design of processes.

So, these are just a few considerations for embarking upon the Plan and Build stage of a SIAM implementation.

Reflections from the ‘pit’

“Divide each difficulty into as many parts as is feasible and necessary to resolve it” – Rene Descartes

As I said at the top of this article, planning and building your SIAM model can be complex. The key to success is recognising the challenges and taking time to design holistically, considering all elements and their impacts on all stakeholders. Effort invested here will make for a smooth implementation journey.

I’ll be back to offer some more advice soon with part three of these ‘moving to a SIAM model’ considerations, where I will focus on the Implementation and Run and Improve stages.