Minimalizing The Mainframe

Application modernization can really take a leaf out of the minimalism concept. Business applications have been developed for many decades in many languages and platforms.  ‘Change being the only constant’ – these applications underwent many changes to support constantly changing business models, compliance and regulatory requirements, user behavior and expectations. Then with evolving managed service models, these applications were handed off from one team to another many times during their lifecycle. Housekeeping of software assets is typically the last thing on the minds of application development and support teams and as a result, inventory of application code grew exponentially over years with a large percentage of code being inactive or redundant.

Minimalism of Application Assets is focused on discarding the assets ‘that no longer spark joy’ (ref: KonMari.com). In the more conventional Re-framework of Mainframe Modernization, it falls under the Retire strategy. This article talks about how Retire can be a very impactful modernization strategy and should be exercised by all the modernization practitioners.

There are primarily three areas to focus while minimalizing the mainframe estate:

1. Inactive inventory: As stated above, application inventory tends to have a lot of obsolete code due to continuous changes and non-removal of old decommissioned components. Mainframe makes it very easy to identify the active inventory. Analyzing SMF logs for Type 30 records gives important details about submitted JCLs in Job Entry Subsystem (JES). The details like name of the JCL, starting program, CPU seconds, lapsed time etc can be exported to a readable file and downloaded for further analysis. Similarly, SMF Type 110 records will provide insights about the active CICS transactions. These SMF records should be analyzed for the last 15-18 months to ensure a comprehensive set of active JCL and CICS transactions. The list then should be compared with Jcls and Transactions in source code libraries like Endevor or Panvalet etc.  Source code library list – List form SMF = Inactive list.

There have been instances where more than 60% of the overall inventory is found inactive! Two thirds of the inventory is just lying there doing nothing. Actually, this inactive inventory is adversely impacting IT operations

1. It’s adding to developer’s impact analysis efforts during day to day managed services tasks.
2. It’s increasing effort towards implementing change for a business requirement
3. It’s artificially increasing the modernization scope.

Removal of redundant and inactive inventory will help have a leaner mainframe inventory and thereby increase developer productivity. It will also address the perception of the mainframe portfolio being too large and will right size the modernization scope and budgeted cost.

2. Orphan jobs and transactions: These are jobs and transactions that run periodically but there is no ownership. Typical situation leading to orphan jobs are:

1. Business requirements and processes are changed due to market demands which translates into application changes involving new jobs and transactions replacing the old ones. Most of the time, new jobs are introduced but the old ones remain (just-in-case-these-are-needed-again scenario).
2. Many times, some product types are decommissioned. Improper housekeeping leads to application components related to old products that continue to run in the mainframe.
3. Regulatory and compliance related changes make application components obsolete but not necessarily disappear from the mainframe source code library.

Identification of orpahn jobs is quite important as they consume MIPS and removal of these will have a direct impact on savings. However, it’s not quite an easy way to identify these jobs. Applications, Operations teams need to work with Business teams to understand the relevance and disposition of these jobs. For the jobs with no ownership and sponsor, shut it down for some time and wait for someone to claim ownership. Then engage with those teams to decide the disposition of those applications.

3. Low business value apps: These are the set of applications within the portfolio that bring less business importance and criticality as compared to other mission critical workloads for the enterprise. While these applications are required, mainframe may not be the right platform to run these applications. These applications should either be decommissioned after feature integration with other like-applications in the portfolio or lifted and shifted outside the mainframe. Google cloud offers a non-intrusive service offering – Mainframe Application Portfolio Assessment – that ranks applications on business value and technical complexity. The ranking helps identify applications that are low on business value and subsequently disposition path for those applications.

As we identify and remove the obsolete and inactive code, similar audits should also be done on installed software on the mainframe.’Follow the money’ seems to be the best way to find out the list of software. One needs to work with the accounting and finance team to get access to invoices and billing statements. Sub-Capacity Reporting Tool (SCRT) reports can be the other source  to find out the list of installed software and consumption thereof. Categorize these in the must-have software, nice-to-have software and redundant software. Depending on the software disposition and licensing cost, create a plan to uninstall the redundant software.

Data can be a tricky one as it gets moved to tape and forgotten forever. But as an adage goes – “If one has it, one would be paying for it!”. One should run a periodic analysis of tapes and virtual tapes.  Archive tape should only have the data needed to meet business and regulations and compliance requirements. One of the customers could delete over 40% of tapes as those belonged to a product discontinued a long time ago.

As one embarks on minimalizing the mainframe, final results will be startling, shocking and profound. It will leave the mainframe much leaner, sharper, lightweight and ready to move on to the next transformational phase. It doesn’t require any additional capital or tools to minimalize the mainframe. All it takes is intent and discipline. And if you do need some guidance and help, feel free to reach out to the mainframe team at Google…