One of the biggest issues with ANY costing model is choosing the cost which you are to recover. The choices can make or break a particular platform, this is especially true when there will be an attempt to compare the "total" cost of two different architectures.
As an example, I worked for a firm that had a Mainframe mostly datacenter for many years. In the post 9/11 need to replace inaccessible distributed sever farms (they weren't considered datacenters), the mainframe datacenter was used. The datacenter was built in the days when a M/F took up a large footprint, dasd took up a humongous footprint and now there was more than half of the datacenter empty. Upon migration of these distributed servers, the M/F manager's cost started to increase, as the 8 chillers that were shutdown years before, were restarted, and additional ones added. As the power consumption skyrocketed, his bill did also. Now this shop was a "full" cost recovery shop, at least on the M/F. The datacenter mgr realized his cost per cpu minute was about to go through the roof because the billing only took into account the capital cost of the machine, the cost of M/F software, the applications use of dasd, and spread the total cost of the datacenter (including staffing) evenly over all z/OS and z/VM cpu secs, this without changing the M/F at all. So he told the accountants to calculate the increased costs of the facility as part of the distributed cost, and he realized they were now using 50,000 sqft of very expensive floor space so he charged that to the distributed and in the end, with the reduction in sq ft charges, and savings in staffing (4 fewer server locations), the z/OS and z/VM cpu second charge went down. The distributed groups went berserk! They had never been charged for floor space, nor had they been charged for power or cooling. these charges were covered in the overhead numbers of their business units, since the server locations were in the same spaces as the BU's they supported. Now all the platforms saw the real cost of power, cooling, floor space in addition to cpu,memory,disk, network and the M/F started to look just a little bit more cost effective, especially when they started to build out the mandated DR site, at the second M/F datacenter. This customer did not embrace z/Linux at first (in fact they threw it out the door once) but has since reintroduced the platform and is actively expanding it's use. The change of heart in this case occurred when a multi-million dollar expansion of the power infrastructure was going to be needed to implement a new distributed application, in addition to the application's other costs. I will agree this is not an exact science, but at least it doesn't have to be a skewed one either. Phil Stewart Thomas J wrote:
Best way to be equitable is via usage based charging, ala cell phone billing. First goal is to get a figure for the total costs that you want to recover from all your customers and over what period. Let's say it's 100 dollars over 1 year. Then you figure out some categories to charge back for. Cell phones get minutes or text messages. For servers you want things like CPU and memory that are easy to gather via z/VM accounting records. So let's try to recover 25% of our costs by charging for memory. So find out how much memory all your servers will be using (lets say 10GB over 1 year) and come up with a rate per GB of memory and charge each server some rate per month or year. Note that this won't be exact because what you forecast and what you really end up with over a time period might be more or less, so you might over or under charge. It's not an exact science. Do the same thing with CPU. Estimate total CPU for all servers for some period then divide that into your $75 to get a rate per CPU second. This is hard the first couple years until you build some history of how much different servers consume. But this is basically what phone companies do to come up with a per second rate. If you end up getting too much money back, you can use that to enhance your services, or rebate back to your customers, or lower rates next time around. If you undercharge, you raise your prices next cycle. __________________________________ Tom Stewart Infrastructure Analyst John Deere - z/OS Support Services em: [EMAIL PROTECTED] __________________________________ -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mike Hamner Sent: Tuesday, July 01, 2008 2:41 PM To: [email protected] Subject: Costing Model for Linux-390 I'm new to this group. We are also a new z/Linux shop and are currently bringing up z/Linux. We are trying to determine a good costing methodology to apply to this environment to be able to distribute cost back to our customers in an equitable manner. Does anyone have experience with doing this and have you defined a cost model strategy that you would be willing to share? Michael E. Hamner, CDCP IT Architect/Engineer Chief Technology Office National Business Center U.S. Department of Inerior 7301 W. Mansfield Ave. Denver Co. 80235 303-969-6619 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
-- 'in media stat virtus' Virtue's in the middle ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
