Business Service Management:
Operating IT from the Business Perspective
by Peter Armstrong
When I was young motor cars had a plethora of switches and dials on the dashboard, which were supposed to help you. Unfortunately they didn't, as most of them were meaningless to anyone without a degree in automotive engineering. The cars themselves also required copious amounts of self-maintenance to keep them going. Fortunately the motor manufacturers realised that the customers were actually the ones who bought the motor cars, and hence keeping them happy was the route to more sales.
So motor cars matured and started to be equipped with inbuilt diagnostics, and features supposedly designed to help the driver. Some of these have been excellent, like central locking and GPS, others a waste of time and money. For instance, my car, which is an automatic, has a rev counter. Why? As with many so-called technical advances, you have to ask the question “who was this feature designed for?” The manufacturers have the right idea, but are sometimes swayed by the desire to prove something is technically feasible, rather than being useful, and hence chargeable.
We have seen the same with computer systems. They used to be the private world of IT, run by techno-freaks behind locked doors, who were more interested in proving their technical prowess than delivering something useful. Fortunately business now realises that IT was, is and always will be a business tool designed to help run the business more efficiently and effectively. If an IT system does not deliver on that, then the question should be who was it designed for, why are you running it and why on earth are you paying for it?
However, this requires the business to be able to tell the IT department what they truly require. Please note the word “require”, not “want” or “desire”, but truly required to run the business. The business must be able to explain how much money will the systems help to generate, how much will it cost for them to be offline, what availability is required, what response times are acceptable, what level of service has to be provided in the event of an outage, what level of data loss is acceptable etc.
There is, of course, also an onus on the IT department to ask the correct questions. There is no point in the CIO going to the CEO and asking which flavour of UNIX he/she would like. When talking to the business, IT people need to phrase questions in meaningful language and not descend into jargon. They also need to be able to explain the options available and the costs, advantages and disadvantages of different approaches. For instance, if the business says it wants 24x7 (because they have heard the phrase and it sounds good), IT needs to ask whether this is what they truly need, as real 24x7 is hideously expensive to achieve. Why do they need 24x7? Should it be available on all systems? Is a small outage acceptable? How much would an outage cost the business? Does this vary according to the time of day/week/month? etc.
Running IT the old way, like the old motor cars has, therefore, become unacceptable. Hence we have seen in recent years the maturation of IT systems, and the emergence of BSM, where IT is run strictly from the business point of view. The first wave of this change was the uptake of ITIL round the world, with people putting in service desks and incident management. As ITIL became more popular, people realised that change and configuration management was the key to future control, and hence there is a current rush to implement a Configuration Management Data Base (CMDB). For many, this seemed to be the ultimate goal, but it is, in fact, merely a step along the way to BSM. Having a data base of your configuration is only useful, if it is kept up-to-date and then exploited fully so that everything in IT can be performed from the business point of view.
Most vendors / specialists talk a lot about the arrow going from IT to the business. They will tell you that you need to automatically discover your configuration, understand how this maps to the business systems and hence be able to determine business impact in the event of a failure. All extremely good and useful, but it misses the vital prerequisite to BSM of the arrow going the other way – from business to IT. How can IT determine business impact unless the business tells them which systems are vital, the relative priorities of these systems, and the cost of their being offline?
It is amazing how many companies cannot answer these basic questions and then they blame IT when something fails. If no-one can tell you, then try asking the business which systems they want back first in the event of a total failure. It is also amazing how many new applications are put on the web and crash the first day - “We never expected so much traffic”. Sorry, then your capacity management is not working, and the fault lies with the business not telling you the correct volumes, and with the IT department not asking the correct questions about the new system.
Some years ago I used to help customers design disaster recovery systems and procedures. I always started with the same questions:
• How much data can you afford to lose?
• How much time do I have to recover?
• How much impact can I have on the production system?
• How much money do you want to spend?
The business, of course, answered “zero” to all four questions. The IT department had already designed the bomb-proof duplicate data centre. BSM is about IT and the business working together. We need both arrows to make BSM work.
Register for our monthly newsletter