Intro

Every mainframe environment usually consits of 70-150 installed ISV (independent software vendor) products. Some products and libraries come with the previously installed operating system (z/OS), and some have to be licensed separately (such as DB2, CICS, MQ etc).

Combined with ever growing mainframe ISV license costs and potentially predatory ISV ven-dors who increase their priceses regularly can put you into a challenging situation. Especially if you can not switch the product or the palette out quickly. In some cases, vendors will in-crease the price up to 3 times, making it extremly expensive to maintain and putting signifi-cant pressure onto your IT budget. In some cases, even exploiting the customers dependen-cy on a certain product.

It is posible to consolidate or even migrate certain products to other, potentially better prod-ucts, who might be open source x86 or cloud based, free or are considered much less “lock-in”. Extensive analysis and evaluation is imperative. It also makes a lot of sense to evaluate and regularly re-evaluate the ISV product palette to stay up to date, avoid potential lock-in or find software that is out of support or not secure anymore.

Even though not always easy, as many ISV products are interlocked with business-critical applications, it is possible to change.

techforge provides expertise and guidance on how to stay ahead technologically and to not get locked in comercially!

Feel free to download the accompanying free extended PDF checklist on how to deal with your ISV products!

Where to start

Getting a full overview of your software stack is imperative. Meaning, you will need to under-stand which produts are in use, how they are used, who is using them and how much they cost. Many companies start off by creating an excel list of their installed software and slice it into:

• Product Name
• Vendor
• Product Usage
• Product Cost / Licensing
• Dependency
• Owner

Most failures happen because of incorrect assumptions! It is highly advisable to invest time to ensure the requirements are correct and the usage and purpose of each product is clear.

It’s not always easy to find out who uses the products, especially with old legacy products. Especially when the usage is interactive. But most products have reporting functions, their entry programs can be traced to figure out which other programs or users utilize them.

Some products are grouped in packages, such as broadcom. Where you will have to remove all broadcom products to achieve cost-savings, simply removing one product of the pack-age will notbe enough.

How to figure out what can be replaced and how it's being used

• Generate Reports, usage statistics of entry programs and interactive programs and interview users and the business
• Map all the requirements and findings correctly. Understanding the dependencies between products and applications.
• Ensure you have enough test cases and do plently of prototyping for new technology to ensure you get the desired outcome.

Replacements

Once you know exactly what you want to replace, its time to evaluate alternatives and vendors. Its important to evaluate plenty, at least 3-5. And do many prototypes and set up testcases to ensure the goalposts are set correctly and also met.

• Do POC's or Prototypes
• Set up test environments
• Set clear requirements and goals
• Set clear vendor milestones for the projects. Incentive fix-price models for vendors are also always a good idea!

Conclusion

It is absolutely possible to migrate even highly complex ISV software if proper analysis is done and the requirements are mapped and planned correctly. There are enough tools and methods available on the mainframe to figure out how these things are being used, however there is never a 100% certainty of usage, some assumptions always have to be made, and some risks need to be taken.

Feel free to download the accompaneid PDF including the ISV streamlining checklist!