ADSM-L

Re: TSM Reporting tools

2005-12-29 00:51:50
Subject: Re: TSM Reporting tools
From: Steven Harris <steve AT STEVENHARRIS DOT INFO>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 29 Dec 2005 15:51:52 +1000
Astounding,

Amusing,

and Educational.

I'll ask more often!

Many thanks


Steve.


On 29/12/2005, at 1:57 PM, Allen S. Rout wrote:

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>