ADSM-L

Re: TSM Reporting tools

2005-12-28 22:57:09
Subject: Re: TSM Reporting tools
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Dec 2005 22:57:03 -0500
>> On Thu, 29 Dec 2005 10:53:49 +1000, Steven Harris <steve AT STEVENHARRIS DOT 
>> INFO> said:


> I like your graph, would it be too much to ask for you to explain your
> charging scheme?  That is always a vexed issue particularly with those
> managers who make unreasonable volume or retention demands, and giving them
> what they want, but charging them what it really costs for the service is a
> nice stick to be able to beat them with.


Not at all; I can hold forth on this at some length. (shocked, I know you are)


Billing is always an exercise in shared fantasy.  Pretending that this is not
so will only frustrate you.  You have to start with a set of principles which
are politically acceptable, and then do rigorous math from those principles,
ignoring that they may be insane from an engineering standpoint.

My organization is (was) a so-called "Auxilliary of the State of Florida".  We
were mostly a State agency, but we had special accounting rules that permitted
us to have bank accounts and retain money across years.  This was because, as
a 'data center', we were expected to regularly make purchases which were far
in excess of a given year's budget.  We were also permitted to bill other
state agencies for our services, in real dollars, which we put into banks, and
periodically bought new mainframes.

My politically-acceptable fantasy principles were as follows:

+ Recover costs
+ Recover enough that the service can be prepared for growth
+ Don't recover more than that

What are the costs?  We had a director-level employee whose entire writ was
answering that question; the cost evaluation experience was fascinating and
educational, and not a litle painful.  Your organization will have its' own
standards for things like amortization, measuring benefits overhead for staff
time, redistribution of front-office costs, cubage in the machine room, power
and air handling, etc. etc.  But we have ours, and at the end of the day
(koff-months-koff) it came down to a bottom line of our annualized costs.

These principles are insane.  Most of our computer equipment is amortized at 4
years.  For the library chassis, we're at 8 and counting.  For the CPUs, we're
lucky if we make it to 3.  Disk is all over the map, and how do you note that
my TSM disk is often cast-offs from another project?  Insane.  But it matches
the principles, so soldier on.


That was the number I was supposed to recover.  Now, how should I split it up?
I started out taking every measurement I could get TSM to cough up (and we all
know that we can measure it MANY ways) and trying to assign numbers to them
all.  This was hideously complex, and incomprehensible even to the architect.

I went through several iterations of simplification, and finally realized that
I had the wrong end of it: The metrics for charging must be easy to measure,
but that's only necessary, not sufficient.  The important measures are ones
over which the clients, the end-users, have direct control.

They don't care about tapes, they don't need to know when I move from 3590-J
to K, or B to E, or to 3592s.  And if I bill them for frational-tapes, then
they will be aware when I change underlying system structure.  Ew.

I ended up with basically two numbers: Transfer, and storage.  Transfer is
upload (backup, archive) and download (restore, retrieve), as measured by the
acctlogs.  Storage is whatever Q occ comes up with (or actually a select, but
you get the idea).


Pleasantly, I'm a pack rat, and retain logs and accounting logs. Every time I
came up with a new set of rates, I could re-apply them to the last [period] of
data.  This let me start twiddling rates, seeing how I could weight billing
towards one or the other.

I decided that I would start off aiming for total storage charges to be about
equal to total transfer charges; that is, when I add up a years' bills, about
half of it should be in each category.  As time has passed and costs have gone
down, I've nudged one or the other rate, mostly focusing on how I'd be
changing user behavior.  If people are keeping too much stuff around (I had
one customer seriously claim they wanted 40 copies) then the transfer cost
goes down instead of the storage.


I presented the completed charge algorithm to management, and it passed
muster.  I presented it to customers, and they screamed.  We changed the
inputs.  Less fantasy FTE, different fantasy purchasing behavior, less
theoretical total cost.  This is where I realized I was dealing with a matter
of shared fantasy instead of engineering.


We went through several adjustments along these lines, and ended up with a
rate that my customers absolutely love, at least those of them who have a
grasp of the differences between TSM and running dump against a local tape
drive.  From the fact that they love it, I can infer that we're not charging
enough.  Oh well, I'm running a University service, not a business.

I'll add to the fantasies reflected in my situation that much of my backup
work is in fact not billed, it's "internal".  This is less interesting from a
dollars perspective (the Data Center pays for it one way or another) than from
a "poor feedback" perspective.  My internal customers have only me carping at
them to help them understand and control their behavior.


- Allen S. Rout
- That'll teach you to ask me to explain something. :)

<Prev in Thread] Current Thread [Next in Thread>