In our latest blog, SIAM Professional Lead Architect and Scopism eConsultant Michelle Major-Goldsmith looks at the second part of an organization’s SIAM journey. You can read part 1 here.
Part 2 – Plan & Build
In my last blog, I introduced Service Integration and Management (SIAM) as an approach for managing a complex IT environment, and why many organizations were considering it as part of their operating model.
“SIAM is a management methodology that can be applied in an environment that includes services sourced from several service providers. It has a different level of focus to traditional multi-sourced ecosystems with one customer and multiple suppliers, since 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.” Source: SIAM Foundation Body of Knowledge
It is for this reason, given the complexity of most organizations’ IT services, that SIAM looks like a good option for a customer commissioning IT services from more than one provider.
Previously, I’ve offered some tips for embarking on the first stage of the SIAM roadmap, Discovery and Strategy. That was about doing some groundwork, thorough research, and understanding the organization’s drivers, strategy, capability and appetite for risk and change. I now want to move into the 2nd stage of the roadmap: Plan and Build. This is one of the most complex stages in a SIAM implementation and efforts invested (or not) here will be the make or break of the transition to a SIAM model. By failing to prepare, you are preparing to fail. As Albert Einstein said: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Fail to think about the (SIAM) problem before considering the solution, at your peril! Rushed transitions without proper planning and design are unlikely to lead to success.
Plan & Build completes the detailed design for SIAM and creates the plans for the move to a new operating approach. During this stage, all plans and approvals are put in place before the Implement stage begins next. The main objectives for this stage are:
1. Complete the design of the SIAM model, including the services that are in scope
2. Obtain full approval for the SIAM model
3. Appoint the service integrator and service providers
This stage is triggered when an organization confirms its intention to proceed with a SIAM transition. The governance requirements and high-level framework defined in the Discovery & Strategy stage provide the controlling ‘guardrails’ for Plan & Build. They ensure the design of the SIAM model is aligned to business requirements and provides all the expected benefits. The stage objective is to create an adaptable, scalable model that is responsive to the inevitable changes within the business and service provider environments.
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, on to the tips….
Tip 1: think holistically
This isn’t just about selecting some service providers and a service integrator. Required services need to be defined, supporting processes need to be agreed and technologies need to be selected. When designing the detailed SIAM model consider these four distinct architectural viewpoints:
1. The organization structure for the 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 organizational hierarchy. This will provide clarity around roles and responsibilities. Consider tools like RACI to support this activity.
2. The service model, showing service groupings, sourcing strategy and the scope of services allocated to the various service providers. The service model shows the hierarchy of the proposed services, the service provider for each service element, interfaces with the services provided by others service providers and the service assets that are required from the customer. Additionally, it can show interactions and activities with external agencies who have a governance or legislative influence. In other words, it paints a picture. It is a good idea to use approaches like OBASHI to support drawing this picture in a way all stakeholders can understand it. The service model should start with an initial definition, and become successively more detailed as each iteration is agreed.
3. The process model, showing roles and responsibilities, interactions between parties, ownership and structural elements. 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. A process model shows process and service relationship interactions with the customer organisation, the service integrator and service provider teams. A continual improvement mechanism should be built into the model. For this, a process model could use an available industry framework like the ITIL® Continual Service Improvement (CSI) process, Business Process Improvement (BPI) or other relevant approaches.
4. The technology model, showing technologies that will be used to support the other three viewpoints, including toolsets. A tooling strategy should be created under the governance of the solutions architecture and assurance functions. It should define policies, for use 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, with different skills sets, tools, policies and procedures.
Consulting organizations that specialize in SIAM designs can often provide blueprints for the above, in the form of SIAM reference architectures, but be cautious. Whilst these can expedite the design phase, allowing the organization to move more swiftly on to the Implement stage, they must be appropriate to a specific organization. The suitability of the reference architecture to the customer organization and strategic outcomes must be tested and not assumed. Specialist support can optimize the effort but remember ‘one size does not fit all’!
Tip 2: designing integrated processes
Within a SIAM model, process execution is likely to involve multiple stakeholders. Despite this, it is not necessary for all service providers to use the same process documents or tools. Consider for example a cloud services provider; it is unlikely that they would accept a prescriptive process flow or mandated toolset as part of their obligations. Whereas a smaller boutique provider who has no defined processes and tools of their own might benefit from additional support, perhaps by defining a process approach for them and providing tools to allow them to collaborate with others.
Regarding process, 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. To manage this complexity, it is suggested that processes are visualized, one at a time, using a single flowchart or a single page, mapping the interactions between the stakeholders for that process. This will allow the most important input-output relationships to be specified without getting distracted by complexity and detail.
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, for instance, 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 will 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.
Street vs. House
Another approach is to categorize ‘street’ level change and ‘house’ level change (or perhaps ‘apartment’ v ‘building’ for those living in more densely populated areas!). Anything that occurs at the ‘house/apartment’ level is subject to change control by the individual service provider. Anything occurring at the ‘street/building’ level requires attention from the service integrator (in conjunction with one or more service providers and/or the customer organization). The analogy can be expanded with a ‘neighbour change’ between two parties that are tightly related, but with no further impact.
When explaining the demarcation to stakeholders have them consider a scenario to explain the scope and impact of each service provider. Imagine returning from work and finding that the lights in your house were not working; when you pressed the switch, nothing happened. One of the first things you might do would be to go outside and see if other houses in your street (or apartments in your building) were experiencing the same issue. If the issue is only in your house or apartment, you would probably contact your electrician first. If the issue did affect the whole street or building, you would probably contact your electricity provider first.
There are instances where approaches like these are not going to be applied. Consider providers such as large internet services, telecommunications or cloud services provider where the customer organization is one of many and has no control over the change management activities of their provider. Changes to service and planned downtime would be communicated by such providers as per contractual obligations but other than that the customer has little direct influence over their process activities. In these instances, the service integrator can provide representation of the providers’ plans in forums such as Change Advisory Board meetings or Working Groups.
Process flow is complex in SIAM, so it is important to consider these various perspectives and design processes with this in mind. It is also good practice (where possible) to include service providers in the design of processes. This can be done via design workshops. Going forward, continual improvement of processes can be undertaken in a collaborative way through process forums, which provide a crucial part of the structural elements that support the Run and Improve stage of the SIAM ecosystem.
That’s my 2 tips for the Plan & Build stage.
This article isn’t intended to provide all the answers (a look at the BoKs can help with that), but rather to highlight some useful suggestions if you are planning and building a SIAM model.
I’ll be back to offer some more advice soon with part 3 of these ‘moving to a SIAM model’ considerations.
Michelle Major-Goldsmith
