What is (qualifies as) Mainframe Modernization?
There are varying opinions on classifying the projects that we execute in Mainframe technologies. I am almost certain this is also true to an extent for other legacy technologies as well. If you are a developer (typically experience from 2 to 8 years), you really need to understand the big picture of the project you work for.
In my view, if your project does any of the following, then it can qualify as modernization. These are not exhaustive but usually fits in 80-20 rule based on my experience.
- Business requirement related
- Maintenance, cost or skill constraints related
The first one is driven by either the need to scale or by competitors of the business. The second one is driven by the need to simplify existing processes to make headway through competitors or sustain business.
Driven by Business requirements:
Various scenarios in business requirements can drive modernization. Few
of them are listed below.
- Expand channels (user interfaces options) to existing customers - This includes (and is not limited to) providing interfaces to mobile, tablets, android and ios apps.
- Collaborate with other applications outside mainframe - get data in and out of mainframe with currently popular RESTful messaging.
- Faster response to market demands - this might trigger refactoring your legacy applications or building wrappers that will enable RESTful connections to cloud-based applications
- Get faster insights into data - triggering a need for an analytics platform
- Make mainframe workloads to collaborate with cloud workloads to satisfy growing business needs
Driven by maintenance, cost or skill constraints:
These are projects that are typically driven by IT leadership to optimize their operations. Some of the patterns include:
- Improve workload execution time by upgrading to new z hardware
- Exploit new features available in the latest versions of programming languages, compilers, databases and transaction servers.
- Adopt latest development practices - triggering the need for DevOps in the mainframe
- Migrating workload off the mainframe to cloud
- COBOL/Assembler/PL1 to Java migration within z/OS
- Migration from not-so-popular framework to popular framework - for example, migration from SUPRA DB to DB2, Migration from VSAM/IMS to DB2, exiting all products bought from a specific vendor and EzTrieve to COBOL.
What is not Modernization:
The following projects cannot be considered as modernization according to me, although there may be exceptions:
- Application development triggered by functional needs
- compiler and software upgrades
- Performance optimization and fixes that doesn't involve changes to hardware
- Regular maintenance and bug fixes
Note: The views expressed here are based on my experience and are neither exhaustive nor may be in line with definitions of modernization available in the market.
Thanks to my friend Srivani Natarajan for reviewing this post as well as agreeing to review my future posts.
Comments
Post a Comment