Mainframe COBOL Application Modernization:

A Revolutionary Approach to Evolving Legacy Systems

This white paper discusses COBOL systems modernization scenarios and how those scenarios interact with the Knowledge Discovery Meta-model (KDM). The KDM is an open standard knowledge repository that will be used as a vehicle to store and analyze application meta-data for the purpose of transforming and evolving the application.

What is Application Modernization?

Application Modernization can be defined as an initiative, such as the ongoing task of portfolio management, a project, such as migrating from one platform to another, or a series of project phases (i.e., a super project) as would be the case when consolidating, redesigning and redeploying an application in a model-driven architecture.

Standards for Application Modernization

Benchmark Consulting, along with, the Object Management Group (OMG) Architecture-Driven Modernization Task Force (ADMTF), is creating a set of standards to facilitate the interoperability of modernization tools and develop a consistent means for the gathering of system information. The main vehicle for defining these standards involves creating a Knowledge Discovery Meta-model (KDM) that defines a common view of application meta-data. The KDM provides the structure for detailed analysis of legacy environments relative to data flow, processes, functions, code issues, interfaces and more.

Breaking down the concept of modernization into scenarios

Large legacy system modernization initiatives inherently are complex. The use of scenarios in discussing modernization has several benefits. First, it is difficult for someone unfamiliar with modernization to envision all of its potential applications. For example, it may not be readily apparent that a modernization initiative can help leverage the refactoring of several applications, facilitate migration, and/or enable services oriented architecture (SOA).

Second, scenarios provide templates for crafting project objectives, plans and related deliverables. This includes defining tasks, KDM usage and personnel requirements. For a modernization initiative that has multiple scenarios, the use of scenarios as a project management approach can greatly reduce the overall complexity of the initiative or project. With this approach, task identification within a project plan becomes more simplified. However, task identification is no less important in that a modernization project can encompass several types of scenarios involving existing information systems. Fortunately, the entire universe of analysis, improvement and transformation tasks are rarely applied within a given scenario.

For example, a language-to-language conversion or a platform migration would not involve the redesign of application data structures. Similarly, a data architecture migration effort, in which a flat file or hierarchical database is redesigned and redeployed as a relational database, would not employ tasks needed to convert from one language to another. Scenarios, therefore, define tasks necessary to complete a given modernization initiative and omits unnecessary tasks that would not apply to such a scenario.

Finally, carving out specific tasks that apply uniquely to a given scenario allows a user to pinpoint the types of tools necessary to perform these tasks. For example, a language-to-language conversion would not require a data redesign tool. Similarly, a platform migration does not require a business rule extraction tool. Therefore, task identification, based on a given scenario, is essential to identifying the necessary tools for a given project.

Modernization Scenarios & the KDM

Knowing which modernization tasks are required for a given scenario helps identify the specific role of the KDM within that scenario. By identifying the possible modernization scenarios and tasks within each scenario, it is then possible to establish the role of the KDM within the overall modernization project. The remainder of this white paper outlines these scenarios and their relationship with the KDM.

Each of the following sections outlines a modernization scenario, why an organization would pursue such a scenario and some of the ways that the KDM could be used to implement such a scenario. The points highlighting the role of the KDM within a given scenario are not meant to be exhaustive but merely exemplify how the KDM facilitates a given scenario.

These scenarios address various application improvement, migration and redesign initiatives that an organization may pursue. Scenarios may be mixed and matched based on an organization’s goals. The language-to-language conversion might be coupled with a platform migration for example. Other scenarios may be added to this list from time to time.

I. Application Improvement

The application improvement scenario is a “super scenario” comprised of several sub-scenarios. The goal of this scenario is to improve the robustness, integrity, quality, consistency and/or performance of applications. Activities include the correction of program or system flaws (e.g., recursion), source code restructuring, data definition rationalization or field size standardization. Organizations may address some or all of these issues depending on their objectives and basic weaknesses in the applications of interest. This scenario involves no architectural modifications and is based on the following requirements.

A growing upgrade request backlog cannot be met due to system quality.
The system is experiencing high failure rates or reliability problems.
There is a long learning curve, poor IT responsiveness and user dissatisfaction.
System upgrade costs are not proportionate to business returns.
One or more systems are being prepared to be outsourced or are being brought back in-house.
Management has given up even trying to change the applications.
Field expansion is required based on specific business requirements (e.g., uniform bar code, phone number or revenue growth).

The portfolio analysis and asset management scenario may precede this scenario, but this is not essential. The KDM supports this scenario as follows.

Store and associate application and business meta-data associated with the systems of interest for the purposes of planning, management and execution.
Expose system and program weaknesses discovered by system analysis tools.
Provide planning input to improvement tasks by linking system weaknesses with business needs, particularly across systems, platforms and languages.
Assist analysts with the process of rationalizing system-wide data names, attributes, records, segments and tables.
Assist with the change management throughout the improvement process.
Facilitate the tracking of system meta-data as it changes through the system improvement process.
Streamline the planning and execution of the validation and verification stage of the project.

II. Language-to-Language Conversion

This scenario involves converting one or more information systems from one language to another language. The language-to-language conversion scenario addresses the physical need to move from one language to another. This may be driven by a variety of factors, but does not involve a redesign of the application functionality beyond that which is required by the language change itself. This scenario is driven by the following needs.

A language has become obsolete, is no longer vendor supported, is no longer understood by available programming talent or is just too hard to change.
There is a business requirement to enhance the functionality of the current system but the language is no longer supported or readily adapted to change.
Systems must move to a new platform and the new platform does not run the existing language or particular version of that language.
A baseline system must be established from which current applications may be migrated to a strategic architecture

The KDM plays the following role in the language-to-language conversion scenario.

Tracks system artifacts through the planning, phasing and staging of the conversion effort.
Facilitates discovery of high risk issues such as the use of runtime libraries or language constructs not available in the target environment.
Assists with the change management process as the conversion proceeds.
Streamline the planning and execution of the validation and verification stage of the project.

III. Platform Migration

Moving systems from one platform to another is driven by platform obsolescence or the desire to standardize applications to an organizational standard. This scenario does not involve any functional or data redesign beyond that which is essential to the platform migration. This scenario may also be combined with a language-to-language conversion, although language conversion is not always required (e.g., UNIX to LINUX). The following situations typically drive a platform migration.

The hardware and/or operating system is no longer supported or viable.
Management has decided to “right size” a system by moving it to a distributed environment or back to a mainframe.
The current platform does not support the accepted operating system standard.
Management has mandated a platform change.

The KDM plays the following role in a platform migration project.

Tracks system artifacts through the planning, phasing and staging of the migration, particularly if it has to be phased in over time.
Facilitates discovery of high risk issues such as the use of runtime libraries or language constructs not available in the target environment.
Assists with the change management process as the migration proceeds.
Assists with the comprehension and understanding of platform services and the definition of their equivalency.
Streamlines the planning and execution of the validation and verification stage of the migration.

IV. Non-Invasive Application Integration

Organizations with an immediate need to bring a graphically oriented look and feel to end users can utilize middleware technology to replace existing front-ends with Web-based front-ends. While a non-invasive integration project qualifies as a modernization scenario only at the most superficial level (i.e., the user interface), this scenario is still supported by the KDM. The integration scenario is characterized by the following requirements.

Business users want to replace aging front-ends with Web-based front-ends.
Users gain value from replacing older front-ends while leaving core system functionality, data structures and interfaces essentially unchanged.
An integration project is seen as a stepping stone to subsequent modernization objectives such as an SOA migration.

In spite of the fact that this is a non-invasive approach (i.e., does not change underlying application) to providing new user front-ends to business users, the KDM plays a role in the planning, execution and post-project documentation of new user front-ends. In general, KDM aids in the discovery and adaptation of existing user interfaces. KDM also supports the post-implementation phase because middleware environments are becoming so complex. Because larger organizations are losing track of which interfaces and systems are connected to other systems, documentation is a key aspect of integration deployment. The following points exemplify the role of the KDM in a non-invasive integration scenario.

Aids in determining how to create a new interface to existing business logic because it has high-level and granular information about existing screens, application data and processing logic.
Allows analysts to pinpoint all user interface candidates targeted for migration to Web-based front-ends.
Helps identify existing front-ends that may be redundant with other front-ends across application environments.
Highlights front-end consolidation opportunities for redundant back-ends.
Facilitates the tracking of distributed user interfaces and middleware on an ongoing basis as new front-ends are deployed.
Ensures alignment with the OMG Enterprise Application Integration (EAI) standard.

V. Services Oriented Architecture Transformation

The transformation to services oriented architecture involves more than just attaching new front-ends to legacy user interfaces as some analysts mistakenly believe. Because most existing application functionality is embedded in monolithic, functionally and architecturally dated systems, application and data architectures cannot be segregated into services in any useful or meaningful way. In addition, business logic is typically intertwined with user interface and data access logic. In these situations, a true SOA cannot be created without retroactively applying modular design principles to existing, back-end systems. The SOA scenario is applicable in the following situations.

Business functions embedded in monolithic batch or online applications need to be accessed in a modular, services oriented fashion.
System functionality is locked into backend batch processing systems.
Complex user interface and data access logic complicates the isolation of business logic that may be deemed a service.
Online applications do not update data in real time, which results in a service relying on back-end batch update systems.
Existing front-ends rely on segmented, inconsistent and redundant functionality in back-end systems, which is not conducive to forming well-bounded services.

The KDM plays a key role in an SOA scenario by helping identify and track relationships between the physical system, program functionality, data usage and user interfaces. Such a project requires the componentization of existing applications to facilitate the reuse of business logic contained within them. Based on this requirement, the KDM helps as follows.

Facilitates the front-end planning necessary to identify redundant, inconsistent and segregated functionality that needs to be refactored to create services.
Identifies the application interfaces that could serve as prototypes for creating a service that hooks into an existing system.
Allows analysts to determine the need to consolidate and reconcile redundant and inconsistent user interfaces and program functionality into reusable services.
Aids in discovery and extraction of the business logic as service candidates.
Helps with the discovery and adaptation of new, component level interfaces.
Streamlines efforts to track consolidated user interfaces and program functions throughout the service creation and deployment process.
Facilitates the tracking of new user interfaces into back-end applications as a way to document post-project SOA architecture.
Simplifies the planning and execution of the validation and verification stage of the project.

The KDM as a conduit for evolving Mainframe COBOL Systems

The above scenarios create a baseline for visualizing how the KDM can help facilitate various types of modernization scenarios. When dealing with Mainframe COBOL Systems, the insight into that system, gained from proper analysis of a KDM, can be invaluable. Also note, that due to cost, resources, time and erosion of system knowledge, considering a “big bang” approach to modernizing a mainframe is generally not feasible or recommended. Therefore, breaking a modernization effort down into scenarios based on knowledge that is extracted from the KDM is imperative in undertaking such an initiative. Generally, when modernizing a mainframe system, the effort should be viewed as an evolution; an evolution that starts with gathering system information and analyzing the information. Through proper analysis of the KDM, a roadmap for modernization will begin to unfold. The KDM analysis, will determine such events as:

Isolate, modularize and consolidate selected functional program logic into components or services
Create a comprehensive view of logic within a system that relies on or otherwise modifies related business data
Isolate and refactor logic related to a specific function
Rationalize cross-system data definitions to a common set of attributes (to prepare for database migration)
Isolate and refactor logic that accesses hierarchical data structures into relational data structures
Identify and eliminate functional redundancies across a system or systems (to support consolidation)

Combining this information with an understanding of modernization scenarios, decisions can be made as to the evolution of the system. With this level of system knowledge, applicable scenarios can be determined, tasks within that scenario can be identified, and the relativity of the tasks can be aligned with the overall project goals.

Application modernization done the right way should take the guess work out of modernization, provide full legacy code assessment capabilities, be able to define application structures, automate code conversion and significantly reduce engineering time.

About this White Paper

IRIS™ is a trademark of Benchmark Consulting. All other product and company names mentioned herein are for identification purposes only and are the property of, and may be trademarks of, their respective owners.

Benchmark Consulting has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. Benchmark Consulting assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by Benchmark Consulting or its representatives.

Certain statements made in this document may constitute “forward looking statements.” Forward looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Words such as “anticipates,” “believes,” “expects,” “estimates,” “intends,” “plans,” “projects,” and similar expressions, may identify such forward looking statements.

Future plans for products may be discussed in this document. Benchmark Consulting does not guarantee that any work discussed herein will be initiated or completed. Nothing in this document should be taken as an absolute direction of the company, but rather as plans that the company may or may not pursue in the future. Benchmark Consulting has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. Benchmark Consulting assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by Benchmark Consulting or its representatives.