Managing Mainframe Costs in the Financial Services Sector
Over the past 25 years of working with Mainframes, one aspect has proved to be a constant challenge – Mainframe pricing. Mainframe software charges are usually based on peak usage. Whatever an organisations’ peak workload in a given month is what they pay for.
Managing workload peaks in the Financial Services sector can be a major challenge. In the Banking sector consumer transactions increase dramatically during Christmas and Sales periods. Similarly in the Insurance sector, quotes rise when new car registrations are released and seasonal trending means that workload peaks during winter months. It is vital that financial services organisations are able to protect themselves against large spikes in usage which push up software costs.
Demystifying Mainframe Pricing
When I’m on a customer site I often get asked “how can we reduce our Mainframe software charges?” Unfortunately there isn’t a simple answer. The key is to gain a real understanding of:
- How Mainframe pricing works
- When, where and why your workload peaks occur
- How those peaks can be reduced
1 – How Mainframe pricing works
Every month an IBM workload report using the Sub-Capacity Reporting Tool (“SCRT”) is produced and sent to IBM. This is used to determine the peak workload and therefore what charges will be applied for the software used.
2 – When, where and why your workload peaks occur
Sometimes organisations are not aware that workload is peaking at certain times. By analysing SCRT and SMF data it is possible to get an understanding of when and where workload peaks occur. Workload peaks can be caused by any number of external and internal forces including:
High/fluctuating transaction volumes
Unmanaged workload mix
Data access paths not optimised
Badly performing/slow running applications
Lets take a look at this last one because badly performing applications can be a major source of woe when it comes to pushing up Mainframe costs. The graph below shows an example of 4-Hour-Rolling-Average (4HRA) MSU usage by software product alongside overall yearly usage. All software products will be charged at the LPAR peak. For example, if your CICS application has not been tuned as well as it could be or it is using up more MSUs than it should then the entire peak will be raised and software costs will increase to the peak. There are potentially significant savings to be made by ensuring that the system is running efficiently.
3 – How Triton’s zTune service can reduce peaks and drive Cost Reduction
LPAR Optimisation
- Possible savings of up to £1M – based on case studies
Workload Optimisation
- Possible savings of up to £1.5M – based on case studies
Workload Tuning
- Additional savings of up to £1M – based on case studies
The fluctuating workload environment that Financial Services organisations operate in means that workload and therefore cost spikes can be a real issue for both CIOs and CFOs. Triton’s zTune service implements controls that remove software cost surprises which gives robustness to both the capacity plan and the financial plan. Focused MSU reduction tuning can be translated into real cost savings.