How well is your mainframe outsourcer managing capacity and performance?
Part 5: CPU based pricing models
This is the fifth in a series of blogs about how to follow up on your mainframe outsourcer. Previously I’ve discuss why it is important to follow up on your outsourcer, understanding MIPS and MSU, and the pitfalls of MIPS. In the last blog I discussed the outsourcer’s cost structure. In this article I will dig further into the commercial aspects of CPU capacity. Specifically, we will look at how the monthly invoice for the customer is calculated from the technical measurements.
Pricing models
CPU based pricing from an outsourcer can be usage-based, capacity-based, or a combination of the two.
Usage based pricing
As discussed in the previous blog, IBM software is generally billed based on CPU usage, so it is natural for the outsourcer to ensure some level of back-to-back agreement with its customers by also charging based on CPU usage. Some variations on this theme that we have seen are:
– Monthly peak rolling four-hour average
– Absolute monthly peak
– Peak during working hours during the month
– Monthly percentile peak (e.g. 95th percentile where the highest 5% of the peaks are ignored)
– Total or average usage during the month (e.g. average MIPS or total CPU seconds)
– Bands (penalties for using too much or too little)
The units are generally MIPS or MSU. Note that while the outsourcer may be paying IBM for their peak usage and charging you for your peak usage, those peaks may be at different times.
Capacity-based pricing
The advantage of capacity-based pricing is predictability. You pay a fixed monthly fee for a fixed capacity, no matter how much you use. There are typically well-defined mechanisms in the agreement for adjusting that capacity on an ongoing basis. Example of this theme include:
– Reserved capacity, sometimes referred to as guaranteed capacity, based on the LPARS ‘weight’
– Maximum capacity based on the LPARs configuration, e.g. number of logical CPU’s
– Maximum capacity based on hard or soft capping
Combinations
These elements can be combined in many ways. Here are some examples:
– CP capacity billed based on peak, but zIIP and IFL capacity billed based on number of logical CPU’s
– CP and zIIP capacity based on the combined CP + zIIP peak – or based on the peaks for CP and the peaks for zIIP determined independently
– Peaks based on combining the usage of all LPARS or based on each LPAR independently
– Some software products billed based on usage and other software products based on capacity
Best Practice
We recommend the following best practices when deciding on a billing model:
- Work towards alignment of interests with your outsourcer. Think win-win by looking for ways you both can save money.
- Avoid complexity that doesn’t add value.
- Ensure transparency through access to data and reporting.
- Understand your current and projected usage patterns when considering alternate billing models.
- Get independent advice from subject matter experts when evaluating your current situation or considering alternatives.
- Understand the relationship between cost and quality of service.
The relationship between cost and quality of service will be covered in more detail in another blog.
Originally published on the SMT Data Blog.
0 Comments