Thoughts on Baselines

Establishing baselines are a critical component to long-term management of any system (IT, manufacturing, etc.)  Baselines allow you to understand your norms and help forecast your future.  I find myself constantly baselining in everyday life. When I take the kids to school, is there a more efficient or faster way?  How long should it take me to commute?  We tend to do these things without conscious thought.

One area where I am consciously and constantly measuring my baseline is when I am in the security lines at the airport… 

I gauge which line is moving the fastest.  Once I pick a line, I also identify another individual that is in the “other” line to determine if I chose correctly.  I am picking an optimal “setting” AND establishing a control variable to determine if my decision was the correct one.

I then RESET this after I get through the boarding pass creen but before I go through the radiation death x-ray machine.  Much like George Clooney in Up in the Air, I gauge who  can get through the security checkpoint fastest. I avoid families and tourist, if I can. I try to identify the experienced business travelers and queue up.  Again, once I pick a line, I then visually mark another traveler to see if I get through security faster than they do.  Did I win?  Did I get through as fast or faster?

Yes, this may sound neurotic.  Especially if you are not a regular business traveler, you might not relate.  My point is that I establish a baseline and then I modify that baseline based upon the results.  That same theory applies in business systems.

One of my specialties is Citrix systems architecture and design.  Many of my projects involve helping customers determine which technologies best fit their needs and designing a scalable solution.  Scalability is the key.  It is not enough to design for today, you need to prepare for tomorrow.  To do that, you need baseline data.  That baseline data may come from historical performance, it may come from vendor requirements, it may come from capacity analysis or it might be SWAG – scientific wild ass guess.  I see SWAG more often than not, but even SWAG is generally based on industry best practices.

During the design phase and scalability planning, I stress the methodologies we use.  This is the baseline and THIS is how we establish that baseline…  I then stress with the customer that this is a PAPER design.  We can validate how we got the numbers, but new systems always have variables that are different from current systems (newer processors, more RAM, different platform, etc.), all of which can impact performance and ultimately scale.

Now that we have established an initial baseline, we then have to monitor the ACTUAL performance/capacity/scale and revise the baseline.  As a sports fan, I find pre-season rankings interesting.  They help you gauge where your favorite teams are forecasted to perform.  However, once the season starts and the games are actually played the rankings and standings are revised to reflect this.  If your #1 team loses, odds are they won’t be #1 the next week because their actual performance did not reflect the forecast and the expectations are revised.

Revising the baseline is not enough; we also need to revise the forecast and long-term capacity planning.  I recommend reviewing and revising baselines and capacity plans on a regular basis.  At most, you should revisit this every six months, but quarterly may be better.

Additional Resources:

This entry was posted in Blog and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *