"Legacy" refers to existing IT assets that have been deployed in the past. These assets could have been installed anywhere from yesterday to twenty years ago, and in many cases, the legacy investment is running critical business processes. Legacy software and applications are often considered to be a "cash cow" for the enterprise, generating unusually high profit margins and thus, are responsible for a large amount of a company's operating profit. This profit typically far exceeds the amount necessary to maintain the legacy asset, and the excess is sometimes used by the company to fund other strategic initiatives. In addition, legacy software or applications may have come into the enterprise as a result of a merger or acquisition. In many cases, the people responsible for development and management of the application are no longer responsible for its life cycle.
Legacy infrastructure isn't necessarily limited to mainframe applications and services. And legacy applications can often represent a significant business value to the company. For example, it is estimated that there are over 200-billion lines of COBOL code in existence and more than 30-billion COBOL-based transactions are processed daily.
Figure 1. Existing legacy environment
Legacy systems are typically built on one or more of the following patterns:
- Green screen. Is a typical character-based application, such as 3270 terminal access to a mainframe CICS® system.
- Fat client. Enables access to a single legacy application using a graphical UI executing on the client workstation, typically a Windows®-based PC.
- Multiple sessions. Indicates that a business process requires a single user to have multiple active sessions across multiple applications, and the user must execute activities in a prescribed sequence.
- Many P2Ps. Interfaces with legacy applications have evolved over time tactically with unique point-to-point interfaces between legacy system and each dependent system.
- Legacy constraint. Means that a technical implementation is limiting the ability of the business to expand.
- Buried legacy. Indicates that over time, because of legacy application unresponsiveness to increasing user demands (see Legacy constraint), a series of distributed applications have surrounded, extended, and buried the legacy application such that business processes and data are spread across multiple systems.
Legacy enablement is the process by which you take your existing software and information assets and enable them to be used in new business processes.
Understanding the need to transform
Legacy systems generally consist of invaluable assets with embedded business logic representing many years of coding, developments, enhancements, and modifications. However, they are often undocumented, tightly coupled, and relatively closed and inflexible. In most cases they were developed independently without a consistent underlying architecture, resulting in overlapping and redundant functionality and data. The main pain points of legacy assets usually fall into one of these issues:
- High cost of ownership, including costs of maintenance, operation, and upgrade of both software and hardware; for example, CPU usage-based pricing for mainframes.
- Slow time to market because of complex and poorly understood code. This may prevent the system from satisfying the evolving business requirements because simple changes take too long to complete and test. Changes tend to cause significant ripple effects and require more regression testing. This, in turn, increases maintenance and evolution costs.
- Monolithic architecture with little or no modularity together with redundant code. This is usually related to extensive patches and modifications as well as duplicated and too-similar functionality implemented in different systems by separate teams.
- Closed and outdated technology that is difficult to integrate and interface with new, open technologies and modern distributed architectures.
- Shrinking talent pool of developers skilled in legacy systems and decreasing vendor support. Knowledge of these systems is usually restricted to a core set of people who are difficult to replace.
- Lack of application knowledge due to the departure of original developers or users, as well as missing or obsolete documentation.
Because most companies have a significant investment in their legacy infrastructure, management is typically not open to ripping out and replacing legacy systems, regardless of the level of shortcomings evident in the infrastructure. Rewriting or significantly modifying large portions of a legacy environment is neither practical nor realistically accomplishable in a reasonable time frame.
Using an SOA approach for legacy systems
The major problem in solving the pain points just mentioned is discovering and identifying the useful legacy functionality and tasks that can be exposed as services to be used by collaborating applications that seek to consume those services. Past architecture designs typically considered legacy systems and black boxes. Standard application program interfaces (APIs) and interfaces were written to access legacy-based systems. Understanding the underlying business processes captured by the legacy systems were typically not addressed. In the black box approach, nonfunctional requirements (NFRs), such as performance, security, management, and maintainability, were often overlooked in the architectural design. Most often the applications and data running in the perceived black box were tightly coupled. This tight coupling makes it almost impossible to modify and reproduce the business processes.
In an SOA environment, business tasks are accomplished by executing a series of "services," which sometime participate in a business process. The services have a well-defined way of talking to other services and well-defined ways in which they talk back. The implementation of a service does not matter to a user as long as the service responds in the expected way and offers the quality of service he or she requires. This approach means that the service must be secure, reliable, and fast, and it makes SOA ideal for use in an IT environment where software and hardware from multiple vendors is deployed, or one in which existing IT assets are mixed with newer applications, integration technologies, or data sources.
Many business and IT benefits are realized from using SOA for legacy enablement. Foremost on the business side is that it creates new value from existing assets and systems, typically from new business processes and composite applications (for example, portal applications). SOA can help provide real-time access to what were previously batch transactions, thereby increasing the speed and accuracy of making business decisions. Reusing critical business data and applications through SOA can help deliver better customer service, thereby improving retention of those customers.
SOA allows you to take advantage of superb quality of services while also repurposing critical processes and data. Furthermore, SOA can help you extend and protect your existing legacy investments and developer skills while helping you achieve greater interoperability with other systems in your enterprise, as well as those of customers, partners, and suppliers.
It is possible to get the best of the old and the new, to take advantage of technology progress while leveraging your existing assets. When you start doing this, you will be on your way to becoming a business that is more flexible and better able to respond to opportunities to better serve your customers and improve your operations. This agility is what is meant by "on demand business," and SOA can make your legacy infrastructure continue to work for you in new and better ways.
Assessing the impact of SOA on legacy adaptation and transformation
Most companies view SOA as a holistic relationship between the business and the IT organization. It is widely accepted that SOA encompasses the tools and methodologies for capturing business design, and using that design information ultimately helps improve the business. SOA also encompasses the middleware and management infrastructure for hosting and managing that implementation. And ultimately, SOA accelerates the time-to-value for these benefits.
Many believe that legacy-based applications are better suited for exposure as part of an SOA environment than many of the modern distributed applications that we build today. When developers wrote mainframe applications many years ago, they wrote them from a business function perspective. Add a customer, order a product, delete a user, and "give me the flight number associated with this traveler," were the usual required actions. As a result, many of those old legacy applications actually adhere better to the fusion that SOA depicts between the business and IT organizations.
SOA accelerates time to value in legacy applications by:
- Decreasing complexity by providing a uniform way of linking services and a uniform framework for integrating them
- Replacing static linkage of services with dynamic linkage and reducing the resistance to change, allowing IT to track changes in business processes
- Providing an environment for reuse and encouraging consistency
- Simplifying operations by providing a uniform way to monitor and manage services
- Simplifying service implementations by handling resources and other management tasks in service containers
Defining the three stages of SOA legacy transformation
Legacy adaptation approaches can be divided in three main categories.
Improve the user experience
For situations where application interfaces are
difficult to use and user workflows are outdated, organizations are taking action to
improve customers' or end users' online experience. Typically, this approach means
upgrading from old "green screens," improving site navigation, providing a simple
Web-based, point-and-click interface, and adding a prefilled fields function so that
online customers need to enter boilerplate information, such as a billing address, only
once during a session. This stage:
- Provides rapid return on investment (ROI)
- Improves end user experience
- Requires low investment and is least disruptive
- Increases customer satisfaction
Adapt for enhanced relationships
Where legacy applications cannot easily be
integrated into modern workflows, organizations are adapting their applications to
participate in today's on demand workflows -- without incurring the risks of replacing
an entire platform. This stage:
- Enables the business to extend its reach
- Requires little or no change
- Means low minimal investment
- Increases customer satisfaction
Innovate for new capabilities
For situations where it's difficult to adapt
mission-critical processes to changing business or market conditions, organizations are
using their legacy applications to create completely new solutions. By understanding what is
in their existing mission-critical applications, an organization is able to restructure
and "componentize" those applications and integrate parts of them into new,
differentiated solutions and ultimately, a Service-Oriented Architecture. This stage
enables:
- Reengineering of existing application
- Higher investment
- Componentization
- API code reuse
Transforming existing legacy patterns: CICS
Traditional (old) applications running in CICS rarely have clear separation of concerns. A 3270 interface was provided because the presentation and business logic were tightly coupled into a single program. This makes it very difficult to transform and adapt those traditional applications into the SOA paradigm. Figure 2 depicts a traditional CICS application where the presentation (P) and business logic (B) is accessing the data model (D).
Figure 2. Traditional "to often found" practice for CICS application design
A best practice in recent CICS application design has been to separate key elements of the application. Those elements include presentation logic, integration logic, business logic, and data logic. This concept provides the ability to reuse each element as subroutines or services that can be decoupled from the original application. For example, the possibility of wrapping the business logic with Web services are now possible. Figure 3 depicts a design that serves as a good candidate for SOA adaption and transformation.
Figure 3. A good CICS application design
Web service provider and requester in CICS
Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, Web Services Description Language (WSDL), and Universal, Description, Discovery and Integration (UDDI) open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL, and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing which services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
CICS applications, as shown in Figure 4, can now be a Web service provider and requester by using a supplied set of Web services that meet the following standards:
- SOAP 1.1 and 1.2 (to send and receive Web services messages)
- WS-I Basic Profile 1.0a (for interoperability with between providers and requesters using SOAP 1.1)
- WS-Coordination (for extensible coordination framework, and specific coordination of atomic transactions)
- WS-AtomicTransaction (for transaction coordination)
- WS-Security (for authentication and encryption of all or part of a message): SOAP Message Security, Username Token Profile 1.0, X.509 Certificate Token Profile
- SOAP over HTTP/1.1 and IBM® WebSphere® MQ (for flexible deployment dependant on application and IT requirements)
Figure 4. SOAP for CICS feature enables CICS programs to be a Web service provider or requester
Java Connector Architecture accessing CICS
Java™ Connector Architecture (JCA) is the J2EE standard for connecting to heterogeneous enterprise information systems like legacy CICS (see Figure 5). CICS Transaction Gateway provides the JCA connector as a resource adapter. JCA adapters require little or none into the legacy system; they gain access to the legacy system by using native APIs, sockets, data access, and a number of other technologies that don't require modification of any existing code bases to be effective. This approach provides the ability to leverage the investment already made in a system in deployment as opposed to investing additional resources into updating the system to support integration.
Figure 5. JCA defines the common client interface (CCI) for the e-business client to use to drive interactions with CICS
Enterprise JavaBeans accessing CICS
Enterprise JavaBeans (EJB) components enable you to support distributed business applications in which the components can be located on different platforms in various locations. A Java client can call a remote object using RMI over IIOP, after obtaining a reference to it, as shown in Figure 6. CICS supports EJBs natively. An e-business client communicates using RMI over IIOP to the EJB container running inside of CICS. The CICS container uses JCA or the message adapter to access the business also running in the CICS region or a separate region.
Figure 6. EJB support in CICS Transaction Server allows any Java program to easily invoke EJBs deployed in CICS
WebSphere MQ supports the easy exchange of information across heteregenous platforms while integrating existing business applications in the process. WebSphere MQ assures guaranteed and assured delivery of the messages and provides both Java Message Service (JMS) APIs and native MQ APIs for use by clients on a wide variety of platforms.
The WebSphere MQ trigger monitor program runs in CICS. When a message arrives it starts a new adapter program in a new transaction. The message adapter uses the MQ native APIs to receive the message, transform it if required and call the CICS business logic program (B), as shown in Figure 7.
Figure 7. WebSphere MQ client accessing CICS using the MQ-CICS Bridge
WebSphere Message Broker accessing CICS
WebSphere Message Broker (Message Broker) enables you to connect a wide range of applications using different interaction patterns, protocols, and message formats. Messages that pass through Message Broker are potentially routed and transformed between different formats on the way to their destination.
Message Broker can take messages from a wide variety of sources in a wide range of formats and route and transform them as needed, so that they can be sent to destinations to be consumed by applications in the formats and protocols that the applications expect. This multistep process is what message brokering is all about -- end-to-end connections between all parts of an enterprise.
It has always been possible to drive CICS transactions using MQ messages generated by the broker, either directly, if the CICS transaction program is MQ enabled or using the CICS DPL or 3270 bridge. However, there are disadvantages with this approach from a broker perspective.
- The flow is broken into several legs, which means that processing is more complex.
- More transactions are required to achieve processing.
- The requesting context needs to be reestablished when the response from CICS is returned, which may involve expensive operations such as reparsing the original input message.
The CICS request node lets a CICS program be driven synchronously within a message flow, simplifying the flow structure, reducing the number of transactions, and maintaining the processing context while the request is being handled by CICS.
Message Broker V6 processing using the CICS node (see Figure 8) is greatly simplified and improves performance up to 3X (for details, see Support Pac IA12). The CICS node extracts a COMMAREA from a node-defined portion of the input message and uses the EXCI interface to execute the appropriate transaction program. The resulting COMMAREA is added back to the message tree upon completion of the transaction. The CICS transaction program may operate within the RRS coordinated unit of work, or be committed immediately according to a node attribute.
Figure 8. WebSphere Message Broker Web service capability to invoke a Web service running on CICS
To help ensure continued viability, a company's IT team must think of new ways of providing value to the business, either through the creation of new business models or the transformation of existing models. In this article, you have explored several approaches and styles for legacy transformation and ways you can adapt existing legacy-based systems to SOA environments. Selecting the right pattern to solve the right problem is key and ultimately determines the level of success in meeting your stated business objectives.
There is no quick fix to transforming existing legacy-based systems. The journey to becoming an agile and flexible enterprise is one that must be seeded with patience. However, benefits can be realized throughout the journey, which means your company doesn't have to wait until the transformation is complete to reap the bottom-line benefits. Those benefits include:
- Reduced total cost of ownership
- Increased end-to-end interoperability compared with existing legacy systems
- Preservation of existing functionality of business applications
- Mitigate and minimize risk by moving off of costly systems
- Provide greater value by leveraging more of the infrastructure and hardware investment
- Self-funding design (which translates to savings) can be achieved throughout the life of the transformation project
- Improved competitive position through enhanced business services based on modern, flexible technology
Learn
-
"Toward a pattern language for Service-Oriented Architecture and integration, Part 1: Build a service ecosystem" is a great overview of SOA, patterns, and integration.
-
"Implementing CICS Web
services," from IBM Redbooks®, can be considered a solid primer.
-
"Migration
considerations for CICS using CICS CM, CICS PA, and CICS IA," also from IBM Redbooks,
goes into more detail.
-
"Legacy Modernization with WebSphere Studio Enterprise Developer" should help give you a better understanding of WebSphere Studio Enterprise Developer.
-
"AMS Legacy Transformation.
- In the
Architecture area on developerWorks,
get the resources you need to advance your skills in the architecture arena.
- If you are new to SOA, visit the
New to SOA area on developerWorks,
get more resources you need to advance your skills in the SOA arena.
- Browse the
technology bookstore
for books on these and other technical topics.
- Check out
IBM on demand demos
to learn more details about various software products and technologies from IBM.
- Stay current with
developerWorks technical events and webcasts.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and
WebSphere®.
Discuss
- Check out
developerWorks
blogs
and get involved in the
developerWorks community.
Calvin Lawrence is the principal and chief architect for SOA in the IBM Sales and Distribution Organization, East Region. His responsibilities include advancing strategic IBM architectures, technologies, and products in support of key strategic initiatives and ensuring the success of customer implementations using IBM technologies. He is former chairperson of IBM Software Group Worldwide Technical Leadership Council.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
