Modernizing Mainframe Applications to the Cloud

Note: This is the first entry in a four-part series on modernizing mainframe applications into cloud applications.

Introduction

Government IT organizations face significant challenges maintaining legacy mainframe applications in this era of cloud computing.  These challenges range from the high cost of proprietary hardware and software, to the attrition of people with qualified mainframe skills and experience.  Many IT organizations view the cloud as an opportunity to move off the mainframe environment.  Unfortunately, these organizations also see the prospect of modernizing mainframe applications as a “mission impossible” - the costs and risks are just too great.  As a result, most organizations resign themselves to living with the burdens of a legacy mainframe environment.   And while remaining status quo may appear to be the best option, over time, it only intensifies the challenges, costs, and issues associated with maintaining a mainframe application:  IT operates an inefficient, bifurcated application development shop.  Eventually the business loses confidence in IT's ability to deliver, and costs continue to rise without corresponding value.  Business stakeholders become frustrated with the lack of innovation and enhancements.  Ultimately,  applications becomes irrelevant, or worse; they are replaced by a competitor’s application.Yes, government IT organizations experience competition in many forms, such as when an agency outsources an application away from IT.

In this four part blog, I will address the following questions:

1. Why should government IT organizations consider modernizing mainframe applications to the cloud?
2. What are the obstacles to modernizing mainframe applications?
3. What approaches can be used to mitigate the risks and lower the costs of modernization?
4. What are some cloud application design and architecture considerations?

Why Modernize Legacy Mainframe Applications to the Cloud?

IT organizations understand, at least on the surface, why they need or want to move applications off the mainframe and onto modern, cloud-based application platforms.   However, it's beneficial to identify and detail each reason as this can help define the business case for modernization, as well as the strategy and approach for modernizing applications to the cloud:

Lower Total Cost of Ownership (TCO): This is the first and most frequently cited reason for modernizing mainframe applications to the cloud.  Studies abound from all sides debating, with near political and religious overtones, as to which environments has the lowest TCO.   Most studies supporting mainframe as the lowest TCO tend to be sponsored by mainframe vendors, and most studies supporting cloud or commodity servers as the lowest TCO tend to be sponsored by cloud and commodity server vendors.  Case studies performed by independent analyst[1,2] suggest the TCO for running applications on commodity servers can be more than 60% less than the mainframe.  Since cloud will further commoditize infrastructure, modernizing applications to the cloud should decrease the TCO even more than the 60% offered by commodity servers.

Perhaps more important than studies, some government IT organizations have shared their mainframe costing information; and at the end of the day this is what matters, a client’s assessment of their mainframe TCO.   Many organizations express frustration with expensive licensing and leasing fees, which are out of line with commodity hardware and software costs.  Unlike cloud application platforms, mainframe software licensing must be paid up front and billed based upon expected peak usage, not average or actual usage.  We suspect the high costs are, in part, attributed to the concentrated oligopoly of vendors that control and support the mainframe[3] Another reason mainframes are very expensive is because they provide extremely high reliability, availability, and serviceability  (RAS).  However, many IT organizations have experienced equal RAS running applications within that cloud, and at a fraction of the cost of a mainframe.

Desire for Greater Agility: Agility, with regards to applications, defines the rate at which an application can be successfully modified and updated to meet the ever-changing needs of the business.  Mainframe applications are primarily developed with general-purpose, static, procedural languages such as COBOL and Fortran.   Most mainframe applications were developed many years ago in a monolithic, stove-piped fashion, which has left them “brittle” to change.   Some of this “brittleness” can be attributed directly to the technology itself.  For instance, unlike modern runtime environments, a mainframe developer can not simply update code and test immediately in real-time.   Instead, the developer typically goes through a pre-compile, compile, and link-edit process before executing on the mainframe.   Brittleness is also caused by the way applications were originally designed and developed, with little thought to code modularity or service orientation.  For instance, one organization explained the difficulty of maintaining a 22,000-line COBOL program.   The developers made several attempts to modularize the program but had little success because of the tight coupling between other programs that makeup the entire mainframe application.  Compare and contrast those challenges with modern programming languages and frameworks.  They support and encourage a highly decoupled, service-oriented architecture.   They are purposed-built tools used to solve specific problems very well.

Some clients have attempted to make the mainframe “agile” and "cloud-like" by using technologies to address mainframe shortcomings. Technologies including virtualized Linux, screen-scrapers, and middleware which “wrap” mainframe programs and CICS transactions into callable web services.  But these technologies add an extra-layer of complexity, which only exposes or repurposes brittle legacy apps; the technology doesn’t contribute to making mainframe applications more agile.  It’s a bit like installing a GPS system onto a horse and wagon – you’ll eventually get where you need to go, but it will be a slow and bumpy ride.

Declining Mainframe Skillsets and Experience:  Based upon varying public research, this point is debatable.  However, talking with several organizations, many express great concern regarding the upcoming retirement of skilled mainframe workers within government.    A recent study[4] done by Computerworld supports this concern.  The study indicated two disturbing trends: 46% of the 357 respondents noticed a shortage of COBOL programmers, and a majority of the respondents indicated that current COBOL programmers were of an older generation, which implied a fear of impending retirements and the attrition of knowledge that follows. Also debatable are observations that fewer students are learning mainframe technologies at universities and colleges, despite efforts by mainframe vendors to provide free hardware, software, and training to learning institutions.    Perhaps fewer students are learning the mainframe because the newest generation of programmers is more interested in working with "cooler" front-end application technologies—the more visible and lucrative aspects in the industry. They're not as interested in the seemingly less exciting opportunities associated with the mainframe[5].  With fewer graduates entering the workforce with mainframe skills, organizations settle for training in-house.  But trying to groom a younger generation of workers to become mainframe developers has challenges and drawbacks.  First, most application developers and system administrators coming out of college, or relatively new to the workforce, do not want to work with mainframe technologies; they want to work with cloud, mobile, and open source technologies. Second, in order to apprentice the newbies, the experienced mainframe staff must be pulled from their regular work duties, which is often difficult if not impossible to do without impacting business.

The Move Towards Mobile, Social, and Big Data Applications:  Every government organization is using, or assessing the use of, mobile, social, and big data applications.  With few exceptions, mainframe technologies do not support mobile, social, or big data.  For the mainframe to play a role in these new technologies, several layers of bridging and infrastructure software must be incorporated.  For instance, many banks extract data from the mainframe and load it into commodity server applications in order to support online and mobile banking.  Banks do this because the mainframe doesn’t inherently support mobile or web technologies.  In addition, banks don’t want to pay the additional cost that comes with the extra mainframe MIPS (processing power) required to support a large and active mobile user base.  One might think big data and mainframe would go hand-in-hand.  In theory, you can run big data applications such as Hadoop on the mainframe but why would you?   Hadoop was designed to run distributed, across hundreds or thousands of inexpensive commodity-priced x86 servers.   It’s the antithesis of a mainframe application.  Mobile, social and big data applications have qualities and characteristics best supported by the cloud: on-demand, self-service access from a broadly available network, with the ability to expand, contract, and pay for computing resources as needed.

Modernizing Mainframe Apps is Not for Everybody

Some IT organizations state they don't have these issues, or that they are addressing these opportunities using mainframe applications.  This may be well and true: depending upon which study you read, an estimated 60-90% of all business transactions and data are processed by mainframes.    However, many IT organizations don't see a way to remain relevant using a mainframe in the age of cloud.  They want to modernize their legacy systems to the cloud but they see many obstacles in their pathway to success.  I'll discuss those obstacle in detail in the next blog entry.