Can we Make our Software Cost Less?

In talking with IT managers and reading the trade press, it seems that software costs are the bane of the existence in the mainframe world. Much has been said and written about this primary mainframe cost driver of late. There is an entire cottage industry springing up to control the four-hour rolling average and save on IBM software costs.

What about the third party products? Does your mainframe have software that is under-utilized – a Cadillac product where a Chevy will do just fine? Do you have more than one product that performs a similar function but is used by different departments because they love it (or simply because they are used to it)? Do you even know every product that is running and that you are somehow, somewhere paying for?

While this sounds daunting, software rationalization does not have to be a “change the world” project requiring hundreds of man-hours or an army of consultants.

In our practice, we see many shops with one or more of these issues. A lot of cost can be shed a little at a time with some practical and simple steps. Taken one at a time as resources permit, improvements can be made and before you know it, the budget has decreased with programmers and users feeling minimal discomfort.

Set the Foundation – Software Inventory

In the interest of starting at the beginning, a full and complete software inventory is essential. This can take a lot of time and digging but is the key to finding any meaningful success.

We see many shops that have three or four inventories: the Systems Programmer inventory which is very detailed but includes components that are not necessarily related to licensing, the Procurement inventory which reflects what IT is paying for but may not include all software in use (Isn’t it amazing how many pockets of software can exist in one company!), the manager’s inventory which is more high-level but not necessarily complete and may include software that is no longer on maintenance but still running and may not have been touched in years. The trick is to find and consolidate these lists to provide a firm foundation of all mainframe software.

Look for the Easy Stuff

We’ve found that the best way to get some immediate “bang for the buck” is to scan your complete list. What’s really, really expensive? What’s no longer used? It might help to organize the inventory by cost or usage for this exercise. The key here is not to look at every single product, but to get the low-hanging fruit – either products that are very costly or products with little use.

Armed with these few products, a financial analysis can be done to determine if there is a business and technical case for replacement. For the products no longer used, there may be a “Why do we still have that?” moment. If you’re not sure, a bit more research is required. Skip it for now and move on.

Redundant Software

The next step is to organize the inventory by function. If you’re like many mainframe installations, there are some functions where you have multiple products that do pretty much the same thing. Take a good long look at what can be consolidated. Did a department decide they just had to have this particular product? Did an acquisition or consolidation bring in a competing product that did the same thing?

At this point, it may be a religious debate, but many times finances can win the day. Another question to ask is which product does that particular function in a way that best meets your particular need? Maybe it is the more expensive product, but do you really need both?

Under-Utilized Softwar: Is it the right product?

For most common mainframe functions, there are multiple products that can be found in the marketplace. As a general rule of thumb, in IT as in life, the more expensive software has more features and is more sophisticated. For some functions, depending on the use case, the features are a necessity (or at least make life a LOT easier). But is that always true? The key here is to determine how the product is used, what features are needed and how much customization is in place. We find that in many cases, the high-end tool was procured based on someone’s bias that the best is always better. While generally true, do you really need the software version of a Rolls Royce to drive the two miles to work each day?

While the steps above may be an over-simplification and do not attempt to take into account corporate politics or the ongoing software vendor religious debate, these are the basic steps that we’ve used time and time again to aid our clients in reducing software budgets. Some are simple – some are vastly more complex and sometimes the right answer is to keep doing what you’re doing with many of your vendor products.