Video clip:

Fiat Bravo vs. Ferrari 550 Maranello vs. Ferrari F1

The three cars in this video are clearly very different. For a formula one car the objective is easy to define. “Get around the track as fast as possible while meeting all FIA regulations and maintaining appropriate (two race) reliability of every component.”

For a Ferraro F550 it is a little more difficult to define. Probably somerhing like “Meet super-luxury standards and reliability for a road going sports car while offering super-car performance at a super-car price-point.”

For the fiat it is more likely “provide basic mass producable budget transportation”

Based on their specific goals it is obvious that we would define performance slightly differently.

For the F1 car it is about winning the constructors championship. For the GT car it is being recognized as the best luxury sports car. For the fiat it is about sales and market share in the budget category.

The point is that for three products produced by the same organisation the goals are completely different and the performance goals are consequently completely different as well.

The key is understanding your goals, understanding how you could measure success, and then target optimizing those metrics.

My view is that architecting for performance starts here. It isn’t a one- time thing either. This is why monitoring is key.

I will be speaking at an Enterprise IT Architecture Conference on the 28th and 29th of July 2008.

Attached are my Presentation Notes that I will talk to on the topic of Architecting for Performance and IT Asset Management

Asset-management-practices

Performance

The videos used in the Performance Presentation are:

Fiat vs Ferrari F550 vs Ferrari F1

F1 Safety Focus – Telemetry

Alonso in McLaren vs 3 Mercedes

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

KNOW YOUR ENVIRONMENT
If you bought a specialised mail-monitoring system you would still have to customise all the threshholds and metrics for your specific environment because your servers may be scaled differently, your mailbox structures may be configured differently etc. If you make the mistake of leaving all that up to the manufacturer of the monitoring tool, then the chances are you will be ignoring most of the info the system produces and eventually say “This thing is always wrong” and untimately it will fall into disuse. Ok that’s a worst case, but my point is you need to KNOW YOUR ENVIRONMENT. There is definite value in researching what metrics are relevant for YOU and what the appropriate threshholds are in YOUR environment. So am I saying there is no place for specialised tools. Not at all. As long as you recognise the responsibility stays with YOU to manage YOUR environment, and cannot be delegated to a tool.

Where is the Value?: Part 2
If I were a departmental manager or executive, my requirements of a management system would be completely different. I would want a very general overview of the state of affairs in the organisation. In fact I would want period summary reports and would probably never look at a realtime console. So the requirement is completely different. If the underlying monitoring systems contributed their information into a centralised warehouse, I could draw a report off that and get what I needed.

Caution: Information Overload in progress!
The question is WHAT INFO DO I NEED? That is the RIGHT question (see iRobot – the movie) to start with. Too much information can be as useless as no information, except that now you have spent money on tools (and support staff for those tools) to produce that information that you never look at. Exactly the right balance of information is critical, especially in large environments.

I used to look after all the servers for a medium-sized corporate and after about six months of harassing the systems-management guys I had exactly the reports that I wanted. I sent a monthly report to the senior IT managers exhibiting the outages and incidents that occurred with a comment from myself on each. I also had a weekly report summarising the top 10 major potential and real issues across all servers. Each week I tried to deal with the issues on the top-most-unhealthy server. I also had a daily report on the configuration and health of each server, which I archived and kept for 3 months, which I only looked at if I needed to research something later (reading that report daily would have been overload).

It shouldn’t be easy
My parting comment is that you need to get to grips with your environment and do the investigation and research into what it is that YOU need to manage in YOUR enviroment. It is extremely unlikely that someone can do that for you. You need to make the time to do it. It will save you (I say that deliberately – it may save YOU) in the long run.

Technorati Tags: Systems Management, Operations Management