No Free Lunch
Chargeback systems can help organizations better allocate resources and pay bills
11/7/2012 1:47:48 AM |
By Gabe Goldberg
Many experienced mainframers are amused by the idea of cloud computing and services being considered new, given how long ago we knew of, worked with and worked for data-processing service bureaus providing conceptually similar services. In fact, for all we know, Egyptian pyramids and the Chinese Great Wall were constructed using early clouds: rented or timeshared abacuses.
In modern times, chargeback (accounting, billing, etc.) systems are often used to report on computing/storage/network resources consumed and allocate costs or charge users/departments for work performed.
Interestingly, sites either live and die by chargeback, or don’t care at all about it. There's not much middle-of-the-road opinion because good arguments can be made for and against chargeback. Implementing and maintaining an accounting system can be burdensome, consuming computing resources and staff time, and not advancing an organization’s mission. And users who’ve been feasting at a free all-they-can-eat technology buffet (perhaps not being billed for supplies or dedicated resources such as telecommunications) might resist sudden but realistic fees. Remind them that “unaccounted for” doesn't mean “no cost to the organization.”
On the other hand, chargeback can impose discipline on resource consumption, influence user behavior in desired directions, provide ROI data on company initiatives and justify allocating costs to paying customers. And accumulating cost/billing figures aids user budgeting, which allows better data center workload and configuration planning. Of course, differences among industries, and between government and private organizations also influence the need for cost accounting.
An added benefit of cost allocation and chargeback can be demonstrating the mainframe's cost-effective nature, allowing objective total-cost-of-ownership comparisons with other installed service platforms, rebutting the "it’s too expensive" gripe regarding acquisition cost.
Successful chargeback systems—that is, comprehensible, accepted and reliable ones—involve management, staff and technology considerations.
Politics arises when chargeback is implemented or changed, because people can consider themselves winning or losing with anything new. If there’s been no IT chargeback, users may resent losing “free” resources (which of course weren’t free, simply buried in another cost center). Some departments may consider themselves more equal/favored/important and, therefore, deserving special accommodations. Hash out such matters early in implementation rather than waiting until reports start arriving.
Set fair rates to an appropriate level of detail, ensuring that resources consumed are accurately measured and apportioned correctly. While what’s fair is subjective, it essentially means charging for a service component in proportion to its cost—and being willing to share external cost details and explain how rates are set.
Avoid burying unrelated costs in various IT categories—for example, burdening mainframe charges with all power or network costs, or IT staff, when those facilities/people are shared with other computing platforms.
As usual for anything affecting how people work, strong and consistent management-chain support is essential to prevent bickering, appealing to higher authorities for dispensations, special circumstances and budget violations.
It’s challenging imposing chargeback for services for the first time. So the first step is setting goals for implementing accounting. Possibilities include:
• Using workload/expense budgeting to plan IT support and upgrades
• Allocating costs fairly to projects, departments, customers, etc.
• Providing repeatable costs or repeatable service levels
• Billing only for what users control (e.g., priority execution or time-of-day)
• Charging for performance or imposing level charges
• Allowing the exploiting of underutilized resources for organizational benefit without encouraging freeloading
Taken together, system goals can influence and motivate user behavior, beneficially or otherwise. For example, under VM, if you charge on a per virtual machine basis, projects will add more applications per server than they otherwise might. And charging less for off-hours work will shift workload to those hours. So it’s worth developing a charging model and putting yourself in the users’ shoes to understand how they might react in order to—reasonably enough—save their projects’ money. Beware unintended consequences, though; for example, offering free off-shift work creating such demand that a nighttime backlog is created.
Resist rolling your own custom accounting system. It’s all too tempting to think that one’s requirements are unique and that no off-the-shelf system can accommodate local business requirements for reporting. But developing such applications means committing to their long-term support and maintenance. Such efforts often grow as environments change, and can hinder or prevent essential IT evolution. It’s painful telling management that significant resources are consumed by non-business-line efforts, and worse admitting that necessary projects can’t proceed until chargeback supports them. So focus on native system data-gathering facilities, and evaluate vendor products for budgeting, cost reporting and analysis.
Of course, also evaluate widely used freeware packages from SHARE and other sources—but recognize that if their developers disappear, orphaned software may suddenly require local support resources. So full source code and complete documentation should be required.
Ideally, accounting applications will work across platforms in use or likely to be installed, integrating disparate data for detail or dashboard viewing. And no matter how it’s implemented, when installing/upgrading/changing system components, test all chargeback components—from data gathering through storage, reporting, archiving and analysis—to avoid nasty surprises. For example, as I’m writing this article, a VSE discussion list thread describes more POWER job accounting being generated in z/VSE 5.1 than 4.3. So watch for changes to data quantity, format, delivery, etc. Especially ensure cost validation across major system changes, such as processor replacement—presumably, cost per unit work should be level or decline, reflecting newer technology efficiencies.
Use technology to support desired behavior—for example, providing a workload scheduler to manage and automate off-hours processing and arranging for necessary resources to be available during unattended operation.
It may be desirable letting users bid for enhanced performance—as on new toll highways lanes being constructed near Washington, D.C., with rates set dynamically to maintain reliable traffic speeds.
Archive detailed processing records for later review. Not only will this be useful for budgeting, it will answer more user questions than aggregated data or reports/bills. You may get questions and requests for credits long after reporting periods—perhaps when projects suddenly realize they’re out of money. And the more tools provided for self-service analysis/projections, the fewer requests received by help desk staff or management.
Many systems allow refining the amount and type of data collected. Review options in the context of your installation’s operation and chargeback goals. The more data collected, the easier it is to tweak processing and charging algorithms and to answer unanticipated questions. But monitor the amount of data being generated and don't mistake the chargeback system for a reason your data center exists.
There’s no shortage of chargeback system stories: gratifying, surprising, amusing or horrifying. An installation where I worked billed for whatever could be measured. So an enterprising user working on a small budget realized that while we billed for terminal connect time, keypunch time and punch card stock were free (yes, this was a while ago!). So he ran PL/I Checkout Compiler jobs under CMS Batch—hardly its intended environment—spending less than a dollar all morning making multiple runs.
A less wise user left work Friday evening not realizing that a program he’d started was looping. By Monday morning he’d “spent” about $30,000 in CPU time. Of course, after he briefly panicked, he was counseled on paying closer attention, and the charge was cancelled.
Gabe Goldberg has developed, worked with and written about technology for decades. He can be contacted at email@example.com.