Monthly Archives: April 2015

ITIL and ITSM in Multi Modal Application Development World

The ITIL framework and the IT Service Management practices have expanded beyond service desk and IT operations a long time ago. ITIL V3 (2007) brought visibility to the full lifecycle of a service, talking about strategy, design and transition of services much before they become operational.

Sadly, a good amount of people did not get it and also did not realize that the technical solution, which includes the application and all the underlying technical infrastructure required to host and manage it, is part of the service. As a consequence, they do not realise that designing and developing an application is part of designing and developing a service and defining the development methodology is part of defining how the service will be managed throughout its lifecycle.

Putting it in different words, these people think that ITIL and IT Service Management are constrained to IT operations and supporting services. They do not recognise the full lifecycle of a service and, therefore, do not recognise that the real scope and applicability of ITIL and IT Service Management practices include design and development.

As far as development methodologies are concerned, Agile and Waterfall can and should be used side by side and collaboratively. I suppose that after wasting millions in failed Agile projects, some organisations will realize that both methodologies have their applicability and the decision to use one or another should be based on a good understanding of the specific circumstances and the pros and cons of each methodology. As these methodologies also represent different ways by which an IT organisation (service provider) engages and interacts with its clients (business areas), more mature IT organisations will develop both capabilities and will invite business stakeholders to participate on the decision taking.

As far as service management framework and high level practices are concerned, an incident will require a quick fix and a problem will require root cause analysis, regardless of who does it and how fast it needs to be done. Changes and new features will still need to be tested before deployed and released, regardless of its size and whether test is manual or automated. Risk will still require to be managed accordingly with its impact and likelihood.

We should avoid to think that universally desirable characteristics and behaviours – such as automation and collaboration between application development and IT operations teams – are exclusive of the latest IT movements, e.g. DevOps. These things have always been part of good service management culture.

We should also avoid to think that virtue is in the extremes. Extremes may be useful to help us understand present contexts and new concepts. But adopting them as targets is not only unwise, it is a sure recipe to keep spending millions in failed IT projects.


Don’t forget commercials!

terms smallThe Quick guide to SIAM by Jan Vromant succeeds in highlighting the importance of the commercial component in a SIAM structure, giving it a separate box in his proposed framework.

Here are some additional considerations that have a big impact on how well SIAM can operate and ultimately deliver business value:

  • Contracts and agreements need to be carefully designed, reviewed       and managed to enable not only integration and interoperability between multiple suppliers, but the correct behaviour and attitude;
  • Non-Disclosure Agreement (NDA) clauses require particular consideration as they may hinder the flow of essential information between the client, the SIAM function and the multiple suppliers;
  • Service definitions must be consistent across all contracts and agreements and be associated to an overall operating model that clearly articulates the role of SIAM and each supplier;
  • If the SIAM function is outsourced, its service provider is likely to require to be assigned as managing agent of the client.

Searching for the right piece

right piece“Assemblying the Jigsaw” is the name of a whitepaper published by ISG in 2013 about the need and the role of Service Integration and Management (SIAM) in multisourced IT environments. The article, which is still available here, provides good guidance regarding success factors and implementation challenges. My experience has also shown that finding the right SIAM model is also essential and tuning it may take a few iterations. There are several alternative SIAM models (internal x external, independent service provider x lead service provider, etc.) and the speed of implementation needs to match the level of maturity of the organisation and the time required to manage the organisational change.

Combining SIAM and DevOps for Digital Reimagination

CEOs are under increasing pressure to move their business into the digital world, reimagining the business model to take advantage of the Social, Mobile, Analytics and Cloud (SMAC) digital forces that are redefining the way organisations interact with their customers. They also expect CIOs to act as a business leader, taking a business-focused approach to leading the IT function and contributing to issues and subjects beyond technology.

The challenge requires not only leveraging new technology, but new ways of working within the IT function and new sourcing strategies.

This has led to an increasing interest and relevance of DevOps and Service Integration and Management (SIAM) in recent years.

Whilst DevOps recognises the importance of integrating development, quality assurance and operations into a seamless mechanism to deploy faster and more reliable software solutions and services, SIAM is the response to IT organisations that seek to rip the benefits of a multi-vendor environment, integrating services sourced from carefully selected IT providers.

But would SIAM and DevOps work together?

To answer this question, let’s take a further look at the key drives and characteristics of each of these approaches.

DevOps emerged from a group of professionals dissatisfied with the results of the silo behaviour that arises from the way roles and responsibilities are traditionally split between development, test and operations teams. Project delays, unreliable solutions and services, high defect rates in production, lack of flexibility, low performance and high cost are amongst the issues that DevOps wants to address.

The most important characteristics of DevOps are the understanding of the business behind IT, the change in attitude in the IT professionals and the use of technology to automate service operations and the develop-test-deploy model.

The change in attitude refers to the way the different IT teams engage, interact and see each other. Most organisations have already realised that trust, integration and understanding of the business do not happen naturally. They need to be fostered and continuously nurtured.

Some critics of DevOps argue it is just an excuse to combine distinct and specialised roles into the same person. It is important to note that, although in small organisations the same person may need to perform all roles, the DevOps principles are also applicable to medium and large size organisations.

On a different perspective, Service Integration and Management (SIAM) emerged from an increasing number of companies opting for an increasing number of IT service providers, to improve cost transparency, reduce risk and take advantage of best of breed solutions and services.

Although not immediately evident, the issues that rise from a multi-sourced environment are now encouraging clients to place increasing importance on the SIAM role.

SIAM aims to address issues such as contractual gaps and overlaps, broken processes and communication channels, conflicting interests and performance targets, distinct governance mechanisms and the lack of end-to-end service ownership that ultimately lead to value leakage and customer dissatisfaction.

The UK government has also adhered to the trend, having included a guidance on SIAM to chief technology officers.

Some of the most important aspects of the SIAM role are the coordination of people, processes, technology and data, and the governance across multiple suppliers, to ensure effective and efficient operations of the end-to-end service delivery to the business user.

DevOps and SIAM converge in addressing current business and IT challenges and targeting people and attitude as primary drivers of performance and value. Whilst DevOps addresses the cons of functional specialisation and the spread of responsibilities across different IT teams, SIAM deals with the additional challenge of spreading services across multiple vendors.

DevOps bring fresh air and enthusiasm to build more dynamic, collaborative and intelligent ways of working, leveraging peoples knowledge and the use of technology to automate routine tasks.

SIAM complements DevOps bringing in Service Management and Contract Management capabilities.

Recent SIAM implementations take advantage of the full service lifecycle approach introduced by ITIL 2007/2011, replacing the traditional support-centric approach of previous implementations.

They also use ITIL and Enterprise Architecture concepts to ensure there is no ambiguity in the definition of service elements, so that a robust and comprehensive framework of contracts, agreements and governance mechanisms can be put in place to clearly link each service element to the vendor that owns it.

SIAM and DevOps are thus two sides of one coin. Combined they can bring in the benefits of innovation, collaboration and best-of-breed sourcing required by CEOs to realise their digital business strategies, and by CIOs to reimagine the IT function beyond the traditional technology perspectives, improving value and customer experience whilst reducing time-to-market and operational costs.

salt and pepper smallSIAM and DevOps are like salt and pepper: they are different things that work very well together.

An Introduction to Service Integration & Management (SIAM) Matters

Service Integration & Management (SIAM) is all about delivering business value in an environment where vital IT services are going to be or have already been outsourced to multiple external service delivery organisations.

From a process and tools perspective, SIAM includes the deployment of ITSM and service management in a multi-sourcing – and, usually, global – environment, where relationships are driven by formal contracts and service delivery organisations are competitors in the market.

My intention with this blog is to share my knowledge, experience and thoughts with other IT professionals and consultants that, just like me, would benefit from a discussion forum around this theme.