Neven Zitek Imagine designing a new generic service, such as e-mail, for example. Even before we start designing the service, we’d need to find out how it will be used and for what type of communication (internal, external, automated, messaging and/or document sharing, etc.). Will it have to support calendar and task functions or delegates? What would the service interfaces be – client based and/or web based, and which client platforms should be supported (e.g., Windows, OSX, Linux)? Is it a Vital Business Function (read more about Vital Business Function according to ITIL principles), and what is our Business Continuity Strategy, or Business and IT Strategy in general? All of these questions, and many more, simply allow us to find best the matching technology, but we still have to design and produce supporting processes that will allow us to build and operate such a “simple” service. In order to streamline and control Service Design, we use the Design Coordination process as described in one of our previous articles Design coordination process – creating a solid foundation.
The purpose of the design coordination process is to ensure the goals and objectives of the service design stage are met by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle.
Coordination of complex processes and activities
Now we jump to the next step of the service lifecycle: Service Transition (or, more specifically – Transition Planning and Support. While Service Transition in general is responsible for Release and Deployment Management, Service Validation and Testing, Change Management, and Knowledge Management, the Transition Planning and Support process is there to provide overall planning for service transitions and to coordinate the resources that they require. Read more on Service Transition in ITIL.
If we refer to our e-mail service example, Service Transition would be the part where we build, test, and deploy technology (infrastructure, servers, software and licenses, etc.), processes (can service performance be monitored, measured, and reported; can the operations team support and operate the service, etc.), interfaces (are service interfaces to end-users and other components working as desired), and perform deployment readiness itself (check the execution of new/changed service deployment into environment).
At this point, you can probably see the similarities between Design Coordination and Transition Planning and Support – they are both responsible for orchestrating very complex and interconnected actions, in order to holistically streamline, control, and coordinate the joint effort.
Service Design and Transition mishaps may not be visible immediately!
I’ve seen the implementation of a PaaS (Platform as a Service), which was considered very large for the private company. It was a massive technological and operational challenge, but due to the great technical competence involved, everything was set up and deployed into operation according to expectations. After a couple of years, the first performance-related issues arose. It was strange, because the underlying infrastructure was a massive powerhouse, and performance issues were reported during night hours when demand for resources was lower. At the same time, business applications had great demand for additional resources, so the capacity management team was constantly busy ordering more resources. But, it looked like more resources generated more issues, until it all crashed one day.
Not to drag out the story, but the issues could be traced back to the design stage; due to the complexity of the underlying infrastructure, most of the knowhow used was technology related, and only a miniscule amount of service management practices were used. All documentation produced was mostly present, but due to the individual approach, each person was using his own interpretation and style, without any coordination with the others. Such approach enabled one crucial mistake: a back-up policy within the SDP (Service Design Package) was created for the infrastructure and general template for applications. Those two policies were created by two different people, but both were the same – which led to a situation where each application (and we’re talking about hundreds) started performing backup at 1:00 A.M., at the same time that the reporting services were run, and everything would be backed up on an infrastructure level – at the same time.
On top of everything said before, the transition phase was executed under great time pressure, meaning that the first services were in operation before the transition was actually finished, leaving some gaps in the testing phase that might have uncovered any flaws from the design phase. We could say that poor Transition Planning and Support, or the lack of it, was partially responsible for enabling this mishap being transferred into production.
The ease of creating new platform instances required for business applications, coupled with poor Change Management practices (aligned with the previous platform, but not the new one), enabled rapid and uncontrollable application service and reporting service deployment, which after some time was just too much demand on the underlying infrastructure.
Do individual processes require coordination even if performing well?
In short, yes. How else would you know that they are performing well? Control processes are implemented because we want to know how well something is performing, and whether it is meeting the expected minimum.
As a people, we all bring something individual into our line of business, but uniformity of the service is one of the value generators. And, in order to provide it, we need to ensure uniformity in our design, transition, and operation processes.
To implement ISO 20000 easily and efficiently, use our ISO 20000 Documentation Toolkit that provides step-by-step guidance for full ISO 20000 compliance.
