The formula for Systems Monitoring

In Formula 1 racing, monitoring and management are designed in from the beginning. All of the teams know they cannot be competitive without it and they are certain that they would not be competitive if they ignored the information provided by their monitoring systems.

In business we tend to leave the monitoring of systems as an afterthought, as a bolt-on at the end of a project, that we will do if we have some spare time. Very few business systems are designed with monitoring in mind, from the very beginning.

The operations benefit and business MIS benefit of having excellent monitoring only becomes apparent, once you have experienced it.

• The value of having all your business systems reporting client activities into your CRM system is only evident when you have an opportunity to impress an important client on your call-centre.
• The value of realtime transaction load monitoring is only evident when Christmastime loads start to hit your online transaction systems and you can see where your systems are starting to struggle.
• The value of detailed audit-logging is only evident when fraud has been committed using your online systems and you can report all the pertinent details to the police in minutes.

But it is costly to implement monitoring, because all of your code has to be modified and metrics thought through and added and the entire system tested and retested. A monitoring system can be added anytime, but the instrumentation that feeds the monitor has to be designed into your system. And it is significantly more costly to add instrumentation to a system after it is built than to have designed it in from the beginning.

Imagine again in Formula 1, if the team needed to add throttle position sensors to the car after it had been completely constructed. There probably wouldn’t be space to attach the sensors and no conduit for the wires, or sufficient processing power to record all the events or adequate bandwidth to transmit all the messages back to the pit. It will be a lot more costly to add all the necessary requirements after the car is built, than to have designed them in from the beginning. Just take one example – not enough space for the sensor. What do we do now?

• Change the design of the throttle assembly to make room?
• Buy the smallest sensor available and shave something to make room for it?
• redistribute the surrounding components so that there is room for the sensor?
• make the compartment larger and retest the aerodynamics in case they have to change as a result?

Wow! It would have been much cheaper to have designed it in from the beginning.

Ask yourself at the requirements stage of your next system:

• What do I need to measure to ensure that I have the right MIS once this thing is up and running?
• What do I need to manage in realtime when this system is running at its peak utilization.
• What information might I need to investigate failures or misuse of the system?

Don’t build it without a conscious knowledge of what it will cost to do now, versus what it will cost to add later.

Here is a copy of the Presentation used at the SPIN forum on 23rd August 2007:

F1 MITTUMAL Presentation