A Brief History of Size

Providing useful but effective advice on sizing and capacity planning has been a challenge to software vendors since they began.  If you consider the huge range in possible hardware platforms, and then the huge range in products and functionality for a given vendor, you realize its essentially intractable.  Various vendors have made interesting attempts at covering this space in the past.  At the now defunct ERP vendor Baan, they had a very sophisticated matrix of weighting factors for all their different applications. So you would break your user count into various functional groups, multiply each group a magic weighting factor, and Whallah! - you have a magic weight for the overall workload. Their competitor SAP had another approach, with one headline benchmark that would be run on every platform imaginable.  So you could flip through the tomb of SAP benchmark results, and eventually find a little box containing a few numbers about the specific box you were interested in - take it or leave it. 

I would argue that covering either of these two dimensions entirely means that you're stuck with so little information per data point that you really can't learn much.  So you then have the choice of taking those numbers as perfect and betting your deployment on it, or throwing them out and starting with nothing.  We've choosen a different approach for the sizing of the BMC IT Service Management Suite (ITSM 7.0).  We evaluate a very small set of platforms, but hope we can relay enough information about those platforms that the sizing of other configurations can follow logically from this basic knowledge. 

Three Sizes Fit All

Specifically, we provide sizing around a small, medium and large standard configuration, or reference architecture if you like that term better.  We then provide sizing of a few of the key applications in the suite for each of these architectures.  We don't contend to replace the thinking and work that usually takes place when designing a configuration for a ITSM deployment.  But we hope to give a jump start to those activities, and provide some quantitative data upon which to base such activities. 

How wrong could our sizing estimates be?  Unfortunately, plenty.  Consider the variances between really big databases vs very small databases, very busy users and very slow users, Wide-Area-Network response times versus local area network response times, etc.  But the estimates provide a baseline from real testing, and we hope we can help extrapolate to a specific customer case from that.  Why go out on a limb if we can't be sure?  I had various engineers asking me that question.  In the end, it came down to this.  In my team, we have many engineers who have done sizing and performance work for 10 to 20 years.  The average customer just wants to get this configuration built and move on to their day job.  Who should be making the leap of faith to do the best sizing they can?  Clearly my team is the right group to make a guestimate, and the best we can do is base those guesses on pretty solid data.  Now take those guestimates, add in a fair bit of concepts and learning that we got out of our testing, package up in a whitepaper and hopefully we've improved the world at least a teeny-weeny bit for our customers and partners. 

So what did you learn?

We learned this: once you settle on a solid three tier configuration, the fun is just beginning.  Now you'll want to tweak that configuration to do reporting and archiving - while not impacting your on-line users.  You'll want to tweak that configuration to have disaster recovery and failover, all for nearly free.  And you'll want to start planning for the acquisition that might swell your user count by 100%, as well as for the downsizing that might reduce your user count by 50%.  So these are the other fun topics we're trying to tackle next - those other things that customers care about. 

Here's something a bit more specific that we learned.  Grid architectures seem pretty much ready-for-prime-time with this product set.  So when you're thinking about hardware for the ITSM suite or the BMC Atrium CMDB, you don't have to go to page 7 or 8 of your hardware vendors catalog, where they keep the expensive SMP with 16 to 32 processors and 64 G of RAM.  Instead, you can stay on pages 1 and 2, where the cheap 2 CPU and 4 CPU boxes are.  Then just buy a couple boxes for the webtier, a couple  boxes for the apps tier, and perhaps even a couple boxes for the database tier (using something like Oracle Real Application Clusters).  Now if you need to add capacity, or even reduce capacity, you  can just roll another box in or out of the configuration.  Your price point per CPU and per gigabyte of RAM is much lower than an SMP (up to 10X lower!) - and you get some failover characteristics for free, as you put a set of machines behind a loadbalancer, instead of having on single point of failure.  So, despite all the over-the-top marketing that's flying out there on grid stuff - do believe the hype - at least enough so that you'll check it out, before buying an expensive SMP box.   

What does a customer look like?

Big customers have interesting challenges, but ones that are starting to sound typical in our world today.  First, they have a big data center in a place that sounds safe and clean, a place like London.  But of course, most of their users are in a place like Bangalore, because their stock holders thought they were not off-shore enough in the last business review.  They drive their load from one big data center across a WAN.  Except for their regional center in a place like Luxemborg, as they don't have legal rights to export customer data out from that location to their other instances.  And even though they do have instances spread across the world, their CIO lives in a place like Denver, and he likes nothing more than to wake up,  walk to the laptop while wearing his pajamas, and find out how many tickets they serviced in the world since he went to bed.   And the results of that query had better be right and quick, or we'll all hear about it pretty soon. 

So large global enterprises have interesting new problems, but are remarkably converging towards a standard set of requirements that are mostly common across them.  The real buzz around here is how to identify those requirements, and then provide effective solutions for them as fast as we can. 

thanks for reading,

Tim

PS.  Here is a link to the ITSM Sizing Guide I mentioned http://documents.bmc.com/supportu/documents/57/42/65742/65742.pdf