In the game of balancing weights and counter weights in ITIL, let us look at the balance between stability and responsiveness.
The design of IT services is evaluated on the basis of stability. Stability dictates the availability and reliability of an IT service. For example, in the case of a web hosting service from Bluehost Hongkong, if the IT infrastructure is stable and has been up every single second for the past three months, that translates into the service having no downtime for the past three months. This is stability and this is what the customer needs. Any outage of services will lead to customer impact, and mostly the impact translates into financial losses. So, the customer would expect your infrastructure to be extremely stable.
So what happens if an organization is extremely stable. For one, the resources who are deployed for the maintenance of IT infrastructure will have zero experience in handling outages if it ever happens. Anything can happen in IT, no matter how stable it is. As the saying goes, prepare for the worst and plan for the best. How can this organization which has not experienced any outages prepare for the worst if they do not get an opportunity for hands on troubleshooting experience?
Also, as you are aware, IT is evolving all the time. The technology of today is redundant tomorrow. So, in a stable environment, an IT organization will find it uncompelled to make changes to the IT infrastructure in fear of losing this acquired stability, although the new technology can offer better service levels and better customer experience. Banking organizations today still vouch for stability and hence most of them are running on mainframe computers as opposed to modern technology.
So, there is a good chance that stable organizations put their stability ahead of business requirements which will eventually render them untouchables in the IT market.
While we have a north pole, we have a south pole as well. The south pole in this balance equation is being over responsive. Responsiveness is the ability of an organization to respond to changing IT environment, like upgrading to a newer technology without impacting the IT services offered to the customer. For example, if a bank decides to transition from mainframe technology to a java based engine, with all the existing and additional features, a responsive organization will be in a good position to carry out the transformation.
Organizations that are highly responsive tend to be at the forefront of technology, toying with latest trends and conducting a number of experiments. The end result is two fold. Number one, most technological changes involve a downtime of services.
Customers will not be able to use the services during the transition and not only that, when changes are implemented, a number of defects and mis-configurations are exposed – leading to further outages in the form of incidents. The customer although agrees to new technology implementation, he will not be happy with the number of outages he has to face. Remember that outages translate into financial implications. For example, if a certain website for an insurance customer is not available for an hour, the losses will mount up to thousands of dollars. I am quoting this from my working experience.
Number two, the IT organization in a bid to stay ahead in the IT technology race implements a number of technological changes, some necessary and some aren’t. These changes will be expenditures for the IT organization. More the changes, more they have to shell out. Not only the cost of changes include changes to the IT infrastructure, but also the cost they have to bear by engaging resources when incidents are reported which are an outcome of the implemented changes. And, if the outages end up affecting the SLA targets, there may be financial penalties imposed by the customer.
The sane thing to do is to achieve balance between stability and responsiveness. Like we discussed, a highly stable organization is likely to ignore business requirements and a highly responsive organization might spend a bit too much onto changes.
How can an organization achieve balance between the two? The IT organization must ensure that the IT infrastructure is stable for a certain period of time before going in for a change. Once the change is implemented successfully, there must be a waiting period to see if things have stabilized. Once stability is achieved, move onto the next change and so on. By implementing changes before achieving stability, you are risking falling into a quick sand which will sink you even before you realize that you are indeed going down.