Is it good or best practice to call ITIL® a catalogue of best practice?
What happens to documented bad practice? In my opinion it becomes almost indistinguishable from good or bad practice – it becomes the way things are done. And the way things are done is never rethought again. Good or bad, best or worst practices become common practices – things that you don’t think about agin.
Why do I blog about this? Well in a recent project I started to think again about the strange separation that all practices seem to make about Availability-, Capacity- and Performance Management. The more I started to think about this, the more these seem to be different aspects of the same tasks.
- Gather your requirements
And this is not just about functionality!
Gather information about Availability needs (Will people die when this stops working? Will we all lose our jobs? Will some people lose money? Will we all be surprised by what we get in the cantina?) early in your project.
Do the same for Capacity (Will some people use this? Will this number increase with organic company growth? Will it grow according to the population growth? Or will it just skyrocket as soon as we are published on TechCrunch?).
Of course the same is true for Performance (Will people accept to wait 15 minutes for our analysis report? Will our customers turn away if they get a bad performance once every 10 requests? Or once every 1000? Will a delayed transaction cause us lose the next war?).
- Design for these requirements
That is the easy part: If you provide the requirements, developers, system architects and other specialists will do their job properly.
- Design & Develop for managed service
Many applications log issues to some obscure log file. Many report timings somewhere when run in Debug mode. Others will deliver information about the number of concurrent users when treated right. Make sure your application/service/software or system does this all the time. Make this compatible with the monitoring environment your ops is using – allow them to monitor health before (!) you go to your first testing phase. Have this as a basic non-deleteable requirement, including defining thresholds.
- Prepare for production of these requirements
The most overlooked part. If you expect skyrocketing growth of usage, prepare for skyrocketing growth in support. If you have 0.1 % of failed transactions that need manual verification or override be aware that increasing usage by 100 also requires you to have more staff on hand. Do not leave this to developers – they tend to underestimate this.
- Report and Analyse your Quality
Take the information on availability, capacity and performance and report it regularly. Tweak your monitoring threshold so that the most important stuff generates just enough alerts to keep your staff busy. If they are doing nothing in the night – your alerts need to be more sensitive. If they start ignoring alerts, decrease sensitivity. If your overall agreed targets are not met – tough luck, add people to the problem.
- Feedback loop by using and empowering Problem Management
ITIL® does not tell you this, but all the Design processes have a secret interface towards problem management. Every time you do not meet your targets in availability, capacity, performance (and all the others) you need to log a problem. Make sure the design team gets those.
Strange – this started as a simple rant post on the term best vs. good practice – and has changed a bit. Be prepared for innovation.