This Text will be saved in my computer museum
among other basic literature pieces, like "real programmers write in Fortran"
Really good reading - thx!
Juraj
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Allen S. Rout
> Gesendet: Donnerstag, 29. Dezember 2005 04:57
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: TSM Reporting tools
>
> >> 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. :)
>
|
