In our latest guest blog, Simon Dorst, AKA the ITIL Zealot expands on the SIAM basics to consider framework integration and management. If you’d like to share your thoughts with Simon, you can find him on twitter.
Now that the SIAM Foundation Body of Knowledge has been released there finally is a succinct answer to the question, “What is SIAM?”. The debate has now changed (in some cases) whether to ‘use’ SIAM or instead perhaps stick with more traditional ‘frameworks’ (like ITIL®) or instead adopt perceived modern alternatives (mostly around AGILE).
First up: the use of the word framework is contentious enough by itself. It is often interchanged with words like methodology or my personal preference: practice (in fact I prefer to gather all and sundry under the heading ‘enabling practice’). For this article the word framework is chosen, but this can entail methodologies and practices and the like!
The key point here is that SIAM doesn’t fall under this terminology: it’s not really a framework like the others, in that it doesn’t provide a particular ‘way’ of doing things (processes etc.), at least none that aren’t borrowed from other best practices. It’s not really a practice either again because it doesn’t focus on what to do (and how to do it).
At the heart of SIAM is a structure, distinguishing roles (and positions) within a multi-supplier ecosystem. The key to this structure is the three layers:
Source: SIAM Foundation Body of Knowledge, Copyright © Scopism Limited 2016
Within the structure of these layers the various, other, known frameworks (and practices) can be defined and applied. For instance, one service provider may prefer to use the ITIL® framework, whereas another has embraced a more DevOps culture. Within the service integrator, COBIT® could be used for governance and simultaneously Lean or Theory of Constraints (TOC) concepts for end-to-end management and improvement.
Thus SIAM isn’t an alternative to any other frameworks, but rather a superstructure within which each framework can be positioned (and defined, executed, managed, …). In fact, SIAM provides the structure that can be helpful in managing different providers, using different frameworks (for different purposes).
Service Providers
In the theoretic\perfect-world the service providers within the SIAM model are like black boxes: they deliver the services they were contracted for, without the customer or service integrator having to worry about how they do this.
Source here
The service integrator manages the inputs and (more importantly) the output of each provider, and whilst a level of oversight is required, everything in between is more-or-less tangential.
Of course we don’t live in a perfect world, but different providers will require a different level of prescribed framework. Cloud providers for instance pretty much deliver a black box solution: you often don’t know exactly which technology they use (hardware, software) -or even where- and what operational processes they apply. What you are interested in is the service\value you receive (the utility and warranty in ITIL terms).
Internal providers on the other hand, will need far more descriptive guidance on how to create the correct output from the inputs. For them (and various outsourced service providers) the service integrator may recommend or in some cases even mandate certain ITIL® processes (or Lean or COBIT® or …) defining the activities and relationships between the provider and the integrator (and/or with other providers).
As a result, SIAM is not actually prescribing any specific framework to be used by the multiple providers. It does however define a number of processes (as described in\with the Foundation Body of Knowledge) and in some cases, it may recommend a particular framework (or provide guidance to the providers) but in many cases it will be up to the provider to deliver their contracted service in the most efficient and effective way!
Customer retained governance
On the other side of the SIAM model we find the Customer retained functions & resources, referred to as ‘retained capabilities’. These provide the ultimate governance and alignment to the business of the overall services provided (through the service integrator and the multiple service providers). As such there is not a lot of operational activity being done here, and thus no direct need for a particular framework.
Of course there are various governance frameworks available, such as COBIT® and ISO38500, but regardless of SIAM these always need to be integrate with the more specific IT frameworks and thus this poses no different challenge in a SIAM ecosystem. In fact, if anything then due to SIAM’s focus on end-to-end value and business alignment this should be an easier exercise.
Service integration
As so often the real challenge lies in the middle, in between the black box service providers and customer retained governance of IT.
But there is an opportunity here: as our providers are not bound to one particular framework, so neither should the service integrator be: horses for courses! (one of my favourite expressions to justify both an adequate amount of rigour as well as a pragmatic flexibility, as discussed in this earlier blog)
The key to me is understanding the outcomes required and often the nature of the activities. Thus a logical structure within the service integrator would be the separation of BUILD vs. RUN. The latter is on-going, day-to-day, business-as-usual and the framework(s) here need to support coordination, collaboration and improvement across the various providers (ITIL®, Lean, etc.) as well as reporting back to the customer on performance, compliance and value delivered.
On the BUILD side we’re more focused on time-limited, one-off activities (although potentially across many providers, and on occasion involving the customer as well) and can apply suitable frameworks for this (PRINCE2®, Agile, etc.). A refinement here is to integrate the multi-modal concept within BUILD: separate FAST vs. SLOW ‘build’ activities and apply the suitable framework to each (Agile or derivatives for FAST and more traditional waterfall project management for SLOW).
Personal I think that within the service integrator there is also the activity-‘block’ of PLAN, which is neither BUILD nor RUN. In this PLAN structure we are creating forward-looking initiatives (which can then be handed to BUILD) and integrate with the customer and their future direction. And again the most suitable framework & techniques for this can be applied (ITIL®, COBIT®, balanced scorecard, etc.).
In fact, ITIL® zealots could structure the service integrator ‘blocks’ around the ITIL® service lifecycle, with specific functions (and frameworks) for strategy, design (plan & build), transition, operations and improvement.
The name of the game here is (once again) ‘horses for courses’, once you know the outcome you want to achieve, you can implement the framework that provides the most efficient and effective means to achieve those.
SIAM is not a competitor and not ‘just another’ framework in this, but SIAM is the structure that provides distinctly defined functions (customer-retained, service providers, plan-build-run) which each can use their own framework, but connect and collaborate to achieve overall results!
If nothing else, the ability to harmonise across multiple frameworks should be another reason to embrace the SIAM ecosystem and the structure it provides.
the ITIL Zealot
February 2017
