Mainframe and Legacy Re-Architecture (Part 1)

I see over and over an ongoing debate regarding re-hosting the legacy platform and re-developing re-engineering it. The answer to that question is always, IT DEPENDS. Any of these discussions should not start with an particular approach (SOA Enablment, Rehosting, Re-arch, COTS...etc) but should begin with a business discussion.

So, given that caveat, i want to spend the next few posting to re-architecture and some thoughts behind what it means and how you do it. It isn't a straight rip and replace, or a pure ground up re-write.

What is Re-architecture
In Re-architecture, the strategy is to reverse engineers legacy applications to preserve business knowledge then forward engineers applications to modern architectures which take advantage of open and extensible standards. Characteristics of re-architecture include:
• Application Discovery - Understand applications and develop ‘AS IS’ models using legacy understanding tools.
• Mine and Extract - Mine and extract application business knowledge (business logic / business rules) into a platform independent model.
• Forward Engineer --Forward engineer applications and data to modern architectures using model based design techniques
• Accelerate -- Accelerate application generation for core J2EE application components
• SOA -- Develop and integrate application web services within a service oriented architecture (SOA)
The main point here is that this process is not manual, and it is not fully automated either. With the use of tools and sound process, you can greatly lower the risk, cost and time to market when re-developing legacy applications.
We will dive into these a bit more later in this chapter, and through a step-by-step example later in the book. Re-architecture is distinguished from greenfield development in that engineers utilize the existing application as the specification, and possibly a framework for future development. The promise of this strategy and the strength found in the ability to identify, untangle and isolate legacy business rules for future modeling, enhancement and development. Re-architecture is also distinguished from platform-migration, where tools are used at an automation rate of over 80%. As mentioned earlier, the platform migration method will often deliver code in a new technology (language) but it will
• resemble the legacy paradigm
• is usually unmaintainable
• is a one-to-one transliteration and almost impossible to add enhancements during the migration process.

Drivers and Considerations for Re-architecture
When considering what approach is best for your organization, it is critical to identify what the drivers are for the effort. These can be divided into two general categories of business and technical. We’ll review some common drivers for re-archticture with the objective to help identify when it is a correct choice to take this route. Also, along side mentioning some of the key drivers that make this a good option, we’ll also examine some of the considerations that need to be weighed in light of a re-architecture

Re-Architect starts with learning everything about an existing application (e.g. what it does, how it does it, why it does what it does) and then designing and rewriting the application to take advantage of newer technologies to be more portable, more agile and more scalable. The following are key drivers for a Re-Architect modernization effort.
• Mainframe costs high and continuing to escalate
• Utilization of standard platforms and more off-the-shelf applications
• Positioning applications for next-generation technology
• An IT infrastructure that is easier to manage, maintain and upgrade
• IT continues to increase in criticality to the business
• Current application architecture is not flexible and adaptable
• Reduced total number of applications & platforms
• Implement application changes in days not months
• Major driver is (additional) business functionality
All good IT organizations want to reduce total cost of ownership, increase their ability to react to business demand, and minimize reliance on legacy skill sets – all the while insuring that they are meeting new compliance demands. Forrester reports that 85% of CEO’s view their IT organizations as an inhibitor to innovation. So there is a great drive to allow business to do more than just sustain, but to react. Technology’s promise is innovation, and now it has become like lead boots on a marathon runner.
As we stated above, legacy modernization allows the IT organization to leverage the investment made in core IT applications as a springboard for future development, instead of just throwing it out. We can leverage these legacy assets to deliver a lower TCO business with an increased level of agility, and ultimately an an agent of innovation for the organization.
Of the different modernization options, re-architecture allows for the highest benefits in terms of increased agility, lowest cost and eliminating the reliance on legacy skill sets.

Platform Agility

What do we mean that re-architecture provides the highest benefit in terms of agility, TCO and reliance on legacy skills? To better understand this lets review the modernization options in terms of business benefits. The following chart is a compare and contrast of the Legacy Modernization options and how they impact the business with respect to costs, agility and human resources.

fixed;mso-padding-alt:0in 5.4pt 0in 5.4pt'>

style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Modernization Option


style='font-size:10.0pt;mso-bidi-font-size:12.0pt'>Reliance on Legacy HR


SOA Enablement

style='font-family:"Helvetica Neue"'>Low-Medium

style='font-family:"Helvetica Neue"'>HIgh

style='font-family:"Helvetica Neue"'>High


style='font-family:"Helvetica Neue"'>Low-Medium

style='font-family:"Helvetica Neue"'>Medium

style='font-family:"Helvetica Neue"'>Medium

Platform Migration

style='font-family:"Helvetica Neue"'>Low-Medium

style='font-family:"Helvetica Neue"'>High

style='font-family:"Helvetica Neue"'>Medium


style='font-family:"Helvetica Neue"'>High

style='font-family:"Helvetica Neue"'>Low

style='font-family:"Helvetica Neue"'>Low

Human factors to consider in a Re-Architecture project
The objective to any successful modernization effort is to add clear business value. Many organizations begin these efforts for the wrong reasons. The force behind any modernization effort should be driven by the business.

The human factor is also a key business issue that needs to be managed properly for a successful modernization project. Some examples to consider include:

style='mso-bookmark:_Toc139207466'>Table style='mso-bookmark:_Toc139207466'>1 style='mso-bookmark:_Toc139207466'>. Business Considerations for Modernizations style='font-weight:normal;mso-bidi-font-weight:bold'>

mso-padding-alt:5.75pt 5.75pt 5.75pt 5.75pt'>



style='color:white'>Mitigation Actions

Job Loss

The technologist
of the existing system often sees a modernization project is a path to

Managers and team
members may not have a commitment to the success of the project and can be a
hindrance to overall success.

Utilize team as critical SME role. ( style='mso-field-code:"HYPERLINK \\l \0022techissues\0022"'> class=MsoHyperlink>See Technology
) style='font-size:9.0pt'> id="_anchor_6" onmouseover="msoCommentShow('_anchor_6','_com_6')"
onmouseout="msoCommentHide('_com_6')" href="#_msocom_6" language=JavaScript

personnel in new technology.

loss is a reality in some business drivers. Prepare ahead of time on
personnel attrition.

is important to understand that the value of these individuals is in their
business knowledge, not technical skills. They can be taught new technical
skills more easily than developing business skills in new employees.

Resistance to Change

any change, even for the better, comes resistance. End users have used a
particular screen or set of keystrokes for years and any alteration to this
will not be well received.

Involve user community. They are an integral
part of migration testing.

end users as early as possible in the modernization process.

How IBM views re-architecture
Much of the messaging put out by IBM around migration and modernization centers around growing the Mainframe footprint. The story centers around application consolidation, open architecture and virtualization. Further, with Z/Linux, organizations can run their Java applications on the same mainframes that they are running their COBOL/CICS and batch applications. Much of the white papers and strategies of IBM on this topic focus on the reliably of the mainframe, the scalability of Linux on the mainframe and the TCO of the Z platform.It is important to note that this book it taking an agnostic view to hardware and address the problems around the pain centered on applications. While we think it is good for some customers to stay on their Z platforms, we are addressing what to do with the legacy applications. If an organization has determined they want to migrate their applications from Z/OS, we want to provide a road map of how to get there independent upon the selection of hardware.

Next Posting: IT/Technical Drivers and Considerations


Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016