The Demise of the Mainframe (Again) –
Microsoft’s Mainframe Migration Alliance

"The news of my death is greatly exaggerated." – Mark Twain

 

 

Commencing in the second half of 2004, Microsoft and approximately 20 other IT product and services vendors formed a new alliance, the Mainframe Migration Alliance, which has one mission in life. That mission is to migrate workloads off the mainframe and onto the Microsoft platform. 

 

In the last twenty years, this is the most comprehensive, targeted, and determined attack on the mainframe environment ever launched. While still in its infancy, the Alliance has deep technical skills and vast array of tools and products to be used to move legacy applications to “more modern” languages and lower cost operating environments.

 

Developing a totally new system or replacing legacy systems by manually rewriting the system’s software is costly and time consuming.  According to Gartner Group findings, legacy system modernization using manual methods can cost between $6 and $26 per line of code and thus far, such projects have a success rate of approximately 7%; a success rate that has not bred confidence within the IT community [12].

 

Using semi-automated system transformation tool-based solutions, while relatively promising, have not provided a sufficient level of automation to overcome the drawbacks associated with manual intervention required to address untransformed code.  Once the untransformed code has to be developed, all the shortcomings of the manual approach come into play.  And once developed the IT manager has to address code non-uniformity during the integration process.  

 

The Alliance is pushing for Automated Transformation. Automated transformation focuses on fully automated transformation and migration of the legacy system’s application code and database structure to achieve a functional equivalent of the original system and re-hosting in a modern computing environment.  From this baseline, the IT manager can continue operations without the disruption of user and support personnel retraining, and can more efficiently begin to expand the system’s functionality as required.

 

Reported “Automated Transformation” projects1 indicated about .5 defects per thousand lines of converted legacy code being introduced by the transformation process. The transformation of system applications2 code and database at automation levels exceeding 99 percent is now a viable approach to legacy information system modernization. The benefit of the approach is migrating the legacy system to a modern computing environment while preserving the repository of business knowledge and processes imbedded in the legacy system.

 

However it appears that Microsoft is pressing for leaving the applications in their native language.

 

1Statistics from “Think Outside the COTS” by Randy Doblar, Philip Newcomb and Lisa Smith, March 2004

2 Automated Transformation of Legacy Systems by Philip Newcomb, The Software Revolution, Inc., 2001

 

 

In a direct quote from Microsoft,  “Micro Focus Enterprise Server with its new Mainframe Transaction Option underpins the new platform alliance and now enables the migration and deployment of CICS/COBOL mainframe applications to the Windows platform. Enterprise Server offers the most rapid and lowest-risk way of re-hosting mainframe applications on Windows. Once the application has been re-hosted it can be extended more easily and effectively through the use of the .NET Framework, SQL Server (TM) 2000, XML and Web services.”

In probably the most interesting statement made by the Alliance members,  "As organizations increasingly realize that they need to re-use rather than replace their existing mainframe applications any initiative that enables them to do this at lower cost and risk is extremely valuable to them," said Gary Barnett, IT Research Director at OVUM. "This alliance will help enterprise users take a more cost-effective and reliable approach to the task of migrating applications to the Windows platform than the expensive and risk-prone 'rip and replace' approach that was the vogue in the late 1990s."

OK. So everyone seems to agree that you need to reuse your 40-year inventory of legacy applications. The Alliance seems to be falling into line that leaving the application in its native language makes more sense, costs less, and introduces less code defects. Furthermore, the Alliance seems to agree that you need agile, open environments for today’s IT world.  

Look Before You Leap

One must carefully look at the stated reasons for legacy migrations before jumping on to the migration bandwagon.  The Alliance’s reasons stated are:

1.      High cost of mainframer operations and upgrades,

2.      Lack of flexibility and agility,

3.      Long time-to-market for new products,

4.      Shrinking mainframe labor pool,

5.      Vendor roadmaps forcing tough decisions

Let’s discuss the first item of the above list, the high cost of mainframe operations and upgrades. The Marion Stern Associates paper, Total Cost of Information Technology @ URL http://www.marionstern.com/totcost.html, had the following quote on distributed (desktop) costs (i.e. the Microsoft realm):  “The study showed that the total costs of computing, including external computing costs that were directly charged to users, the costs of the "shadow" computing groups discovered in the user community and group costs were more than double the IT budget”.

In The Center For Human Development paper “Server-Based Computing” – they make the following statement on total cost of computing:

“In the past year alone, nearly three thousand articles and press releases have been written about or referred to the concept of total cost of ownership (TCO).  In addition, a variety of research studies have been published on the topic.  All reflect a common principle – that the true cost of procuring, deploying and maintaining computing applications for an end-user community is significantly more than the initial acquisition cost of a PC and software.  How much more?  Recent Gartner Group estimates put the total cost of ownership of a network Windows95 PC at $49,915 over its five-year life.  The average of all the studies for any PC at $12,000 over its three-year life (a standard life-span). 

High TCO estimates have been controversial.  Lower estimates have often seemed understated.  What are the underlying cost elements on which these estimates are based?  And more importantly, how can these costs be managed and reduced?  Studies have shown that by using Server-Based computing, TCO can be reduced as much as 57 percent and perhaps even more.

 

An organization’s total cost of ownership encompasses four key areas:

1)      Hardware, network and software capital costs for new acquisitions and upgrades

2)      System and network management costs

3)      Technical support costs

4)       IT and related costs shouldered by end users

 

Recent TCO analyses have also recognized other important categories of costs, including software development expenses, network communications charges and lost opportunity costs resulting from system downtime.”

 

So we know that there are hidden costs with the “server farm” approach based on what we read.

 

So what about the mainframe costs?

In an article Total cost of ownership - the search goes on to locate IT's holy grail in Computing magazine, the author states, “The mainframe option - which gives one machine overall control of an organisation's desktops - may offer better value in the long-term, but the initial outlay and installation can be very off-putting.” Don’t you love the way the English phrase things?

But they have hit on a critical point. One must look beyond the upfront outlay and determine the total cost of ownership over a three, four, five, or even longer time period. The mainframe offers the advantages that it has a truly industrial strength operating system strengthened and built over a 40-year span of time. This operating system, z/OS, has already fought the battles with reliability, availability, and servicability (RAS). The operating system is designed NOT to need booting (in mainframe terms it is known as Initial Program Load or IPL). In fact only planned scheduled outages, IPLs, should be considered normal, any unscheduled outage violates the design point of the z/OS operating system. Further the security protections from accessing system or user resources is far and away the most protective in the IT world. These protections rely on both the native operating system capabilites and one add-on product such as RACF or ACF. How many patches has Microsoft shipped over the last thirty-six months that are specifically plugging security holes?

The operating system has grown in these years from a single thread, single process work horse to a multi-processing, multi-threading, processor-balancing and workload-balancing thouroghbred.  This operating system fought and won the battles of multi-processors, true workload balancing,  mirroring/duplexing and recovery years before the Servers and their operating systems were even a gleem in the eye of their developers. We defy you to find a feature in the Server operating systems that doesn’t currently exist in the Mainframe operatings system or was tried decades ago and replaced by something better.  So maybe there is some costs in availability and reliability with still maturing operating systems that are “re-inventing the RAS wheel” to some degree?  

Which Mainframe Applications Are We Talking About?           

When we deal with mainframe versus PC, we tend to talk in terms that equates to user transactions. These user transactions normally equate to CICS TS applications. Why? Look at the numbers. The facts3 are:

·        40 years and $1 trillion invested in CICS applications (IDC)

·        20,000+ CICS/ mainframe licenses worldwide

·        14,000+ CICS customers worldwide

·        Used by 490+ of IBM's top 500 customers

·        30 million end users of CICS applications

·        150,000+ concurrent users/system

·        5,000 CICS software packages from 2,000 ISVs

·        900,000+ programmers earn their living from CICS

·        CICS handles more than 30 billion transactions/day valued at over $1 trillion/week   

The “Reasons” Versus the Facts

So what are we saying here?

If we inspect the capabilities of CICS TS and z/OS as the mainframe environment that Mainframe Migration Alliance is proposing re-platform with their .NET as an addition, let’s see how we stack up to the Alliance’s reasons for such a migration.  

Well, we already have seemed to cover the costs issues. One must tackle the total cost of ownership of the mainframe to the proposed Server solution over a multi-year period to gain a sense as the true facts.

The second reason presented was one of lack of flexibility and agility. As of the writing of this paper (Dec 2004), CICS TS V2.3 is current and CICS TS V3.1 has been announced for availability in March 2005. We will discuss the functions in both versions in response to the Mainframe Migration Alliance’s stated reason of agility and flexibility.   

Microsoft & IBM are main cogs in the Service-Oriented Architecture community. The idea of SOA is that users need services that can be requested from service brokers who supply the services. The user looks up the service needed in a ‘yellow pages’ and the brokers provide the contract that they and users agree to adhere to for requesting and fulfilling the service. The idea of SOA is to provide agility with not worrying about the transport or platform inhibitors. SOA is an architecture and not a protocol or standard.

THE SOA Service Network

A layer of SOA is the Service Network. A Service Network is an application level network that leverages a Service-Oriented Architecture. The Service Network is composed of a number of Service Network Participants and many Services.  See the graphic example below.

3 From article Integrating CICS Applications as Web Services by Russ Teubner.

 

 

The SOA Service Network

 

 

The Service Oriented Architecture (SOA) is a distributed software model. The primary characteristics of an SOA are:

 

Services are used to divide larger applications into smaller discrete modules.

Services are integrated via service composition mechanisms to create larger applications.

It is said that an SOA is usually comprised of three primary parties:

A Producer (of services)

A Consumer (of services)

A Directory (of services)

Web Services are considered an example of Service-Oriented Architecture. Service Networks take on the properties of an SOA.

Web Services embrace WS-I Basic Profile 1.0a Final Specification for Interoperable Web Services.  The non-proprietary Web services specifications covered by the Basic Profile include SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and W3C XML Schema. 

 

A Service is a callable routine that is made available over a network. Services have well defined interfaces (inbound and outbound). The interfaces are often published in a directory. Optionally, directories are often utilized by a Consumer (or requester) to discover available services. The Consumer may then call the service to have some action performed.

Services are often compared to components. One difference that is usually noted is that services are “live”. That is, they usually reside inside of a multi-threaded engine that is network aware. The engine allows multiple consumers to utilize the services and provides some basic infrastructure (security, logging, etc.)

The term Service is often interchanged with the term, “provider”. A provider is usually used in conjunction with Consumer to differentiate between the entity that consumes a resource/result and the entity that produces the resource/result.

 

The Enabling Components of a SOA

Service Network Participants are those entities that play a role in enabling a service-oriented architecture. Participants commonly include:

·        Service Engines

·        SOAP Engines (CICS TS SOAP Server Feature)

·        Application Servers (CICS TS and/or WebSphere)

·        SOAP Routers

·        Domain Routers

·        Content Routers

·        Transaction Processing

·        Saga Monitors (CICS TS Business Transaction Services Feature)

·        Short-lived TP Monitor (CICS TS)

 

 

 

 
SOA Needs

CICS TS 2.3

CICS TS 3.1

Act as Requestor/Consumer

 

Act as Producer/Provider

 

Support Web Services

 

Support SOAP 1.1

Support XML 1.0

Support UDDI 2.0

Support WSDL 1.0

 

Support W3C XML Schema

Support SAGA Monitor - BTS

Support J2EE - EJB

Support C+

Lets take a look at the features required in a SOA Web Services Role and as a Industrial Strength Server providing modern tooling and languages for today’s IT environment.

 

The Web Services at CICS TS 3.1 provides for legacy applications in COBOL to be re-used as a SOA requestor or provider.

 

J2EE support at CICS TS 2.3 and above provides full compliance for J2EE (CORBA and EJBs.)

 

CICS TS fully supports C+ Language

 

CICS TS COBOL support allows for XML in/out as well as SOA re-use in the SOA.

 

CICS BTS provides event driven (SAGA) enveloping of application programs.    

 

 

 

 

The “Reasons” Versus the Facts (Continued)

Returning to the reasons stated by the Mainframe Migration Alliance, we will pick up at reason number 3, long time-to-market for new products. Who are they kidding? I’ve never seen new IBM versions and release coming as fast as they are today. New applications based on Java J2EE should run on any J2EE compliant platform when given the appropriate container. This includes CICS TS (might require the BTS feature also) and WebSphere Application Servers. So what new products are the alliance members speaking of? COBOL and PLI can participate in Object Oriented Architecture environments and utilizes the JAVA environment to accomplish the participation.

 

Reason 4, the shrinking mainframe labor pool, is also a misstatement.  Since CICS TS and/or WebSphere are J2EE compliant, the JAVA developers with little or no CICS expertise can create new applications (EJBs). The C+ support has been strengthened with every release of CICS for over seven years at this point. If you wish to have Object-Oriented participation of new CICS programs or enhanced, use the C+ capabilities or the JAVA capabilities.

 

There is still a large amount of COBOL, PLI, and CICS skilled individuals around the IT community. They have just been overlooked, underutilized, and non-inspired in the last ten years. IBM and many IBM Business Partners are teaching CICS curriculum for both application programmers and system programmers so there is a pipeline available.     

          

Finally, reason 5, vendor roadmaps forcing tough decisions, is not really explained anywhere by the Alliance. They may be saying that since the AMDAHL, HONEYWELL/BULL, and HITACHI types went away, there is only one mainframe provider. With that provider adding Web functionality to all of the z/Series hardware and software, what difference does it make? The alliance would seem to indicate that since here is only one mainframe vendor, the vendor has no incentive to lower the costs of ownership. It would seem to this author that the existence of the Mainframe Migration Alliance is more than sufficient incentive to keep IBM on its toes to ensure that the mainframe per user costs of ownership over a term period is competitive with the .NET environment.

 

Conclusion

This paper has been written with the IT management, IT architects, and CICS system programmers as the target audience. The CICS professional can use the content of this paper as ammunition to defend and, indeed, put the mainframe on the attack. IT management and architects may not know that the mainframe is capable of today. This paper has tried in a concise, informative manner to present these capabilities. The one table in this paper shows the whole story in graphic form. If nothing else extract that table and use it as discussion points with decision makers when the opportunity presents itself.             

 

 

Authored by Don Fowler, MCE Inc, 2004