Level: Advanced
Jean-Louis Maréchaux, Software IT Specialist, IBM
17 Jan 2008
To remain competitive, your organization has to modernize its IT systems. Modernized IT solutions must create new value from existing systems and provide flexibility and easy interoperability among a broad set of technologies—usually a challenge with legacy applications. Service-Oriented Architecture (SOA), widely adopted by organizations in recent years, offers a practical solution for evolving and reusing existing assets. This article shows you a typical approach to modernizing your legacy systems, including identifying the IT pieces that must be augmented with new features, determining how the required augmentations are performed, exposing each capability through a modern interface, and using the newly exposed services to automate future business processes.<script language="JavaScript" type="text/javascript"> </script>
Modernizing an IT system is a long, complex journey. It begins with a decision to transform the legacy rather than to rewrite it. This decision is often made because an organization has an overwhelming portfolio of legacy systems, many written in outdated languages and difficult to evolve and maintain.
The transformation can be complicated if an organization no longer possesses a deep functional knowledge of its legacy systems. The business processes may have been implemented a long time ago without effective documentation of them or the software systems that realized them. This lack of documentation is made worse by the turnover of resources. The people who defined the legacy systems' business content and who had the deepest understanding of the business processes and the automating software may no longer work for the organization.
So the modernization effort must cover two aspects:
- First, it's important to understand the business processes that are automated by the legacy system and to compare those with the current needs (gap analysis). After you've identified all the existing business processes, you can improve the outdated parts to create new value from existing assets.
- The next step is more technical. Legacy systems are based on outdated technological platforms, often difficult to maintain and possibly not supported anymore. The target architecture must be based on leading-edge technologies, maximizing the reuse of existing assets.
 |
|
The first challenge to modernizing a legacy system is to understand the current business. There are many ways to do this, but you can decide to methodically examine the entire business using the Component Business Modeling (CBM) technique (see Resources for more information). CBM is an analytical framework that you can use to help your organization identify and improve its critical business areas. The CBM model of a business organizes business activities into autonomous, manageable components. Using this technique, you can understand and represent each part of your organization. It's the first major milestone of a modernization effort: the business componentization of the organization. You create a CBM map containing a complete set of business components with their provided services. Those strategic building blocks are the starting point for the technical modernization that you're trying to achieve.
Figure 1. CBM map showing basic business building blocks
After you've defined the CBM map, you can conduct a fit/gap analysis between what your current system does and what your business objectives are. So you need to identify the building blocks that you'll take into account in your modernization effort.
|
|
Implement business services with technical components
Business componentization alone isn't sufficient to achieve the desired business transformation; it's only a description of the components the IT system must implement. The next step is to design the various business functions as well-defined services.
Organizations involved in a modernization effort are usually considering the following key technical objectives:
- Flexibility: The modernized system must improve business responsiveness with a low IT impact and cost.
- Reuse: The modernized system must be based on clearly identified reusable components. It must leverage the existing legacy application, creating new value from it.
- Interoperability: The modernized system must enable communication with other systems from the organization or from business partners.
To meet these objectives in a modernization initiative, you can adopt the SOA approach. SOA is defined by the OASIS consortium as "a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations." (See Resources for more information.)
The SOA architectural style enables the following capabilities:
- Design services to mirror the real-world business activities that comprise the enterprise business processes. SOA enables IT to be aligned with strategic business objectives.
- More easily evolve the initial architecture of a system to include new business function or future technologies. SOA enables technical flexibility and, thus, business responsiveness.
- After existing applications are exposed as services, you can orchestrate them with other services to create complete business processes. SOA stimulates the reuse of existing assets.
- Disparate systems, implemented with a variety of technologies, can more easily interact. SOA enables interoperability between applications.
SOA is a natural approach for implementing the business components identified during your CBM activities. First, it's a way to expose the legacy application as services and then to create new business processes by assembling and orchestrating those services. Second, because SOA is based on open standards that have been widely adopted by the industry, it's an effective approach to enable interoperability with business partners.
Because the SOA paradigm is technology agnostic, it's a candidate approach for any modernization effort, whether legacy systems have been written in COBOL, RPG, C/C++, or another implementation technology.
|
|
After you've chosen the architectural approach, it's important to make sure the technical implementation is aligned with the initial business objectives. The SOA components must enable and support the business processes. But they must be identified, designed, developed, tested, and put into operation in such a manner that risks are controlled and value is added to the organization. You can facilitate the effective management of this development process by using proven approaches to domain-specific (in this case, SOA) software development.
In spite of the relative newness of the SOA approach, IBM® offers a proven approach for software development that incorporates industry-leading practices for services identification, specification, and realization. This method description combines an industry-leading, general-purpose software development process— IBM Rational® Unified Process® (see Resources)—with best practices for SOA design. The best practices, which originally were distilled from over 3,500 SOA engagements by IBM's Global Business Systems consulting practice, are known as Service-Oriented Modeling and Architecture (SOMA). The union of the two, which is a commercially available offering, is known as RUP® for Service-Oriented Modeling and Architecture, or RUP for SOMA (see Resources).
SOMA provides a process that can improve the degree to which the requirements of the business are met by IT systems. It prescribes activities that are geared toward:
- Identifying the IT services needed to meet the needs of the business.
- Specifying those services.
- Realizing the services by designing the components that implement the service specifications and making decisions regarding where those components will be deployed within an organization's overall IT architecture.
At this point, you may be asking, "So what?" The question naturally arises; what does this have to do with legacy modernization?
First, RUP contains a set of guidelines for legacy evolution. For instance, it provides information on evolution types (extension, cosmetic makeover, migration, or redevelopment) along with key process guidance and work product to achieve a legacy evolution.
Second, beginning with the initial list of business components from the CBM, and following RUP for SOMA activities, you can specify needed technical services and determine which ones are best implemented using capabilities provided by existing and modified legacy applications.
|
|
Case study: architecture of a modernized system
A couple of years ago, I was involved in a modernization project for a client in the pharmaceutical industry. After assessing their needs, we determined that an SOA approach could quickly align the IT system with their current business needs.
The application we had to modernize for our client was a legacy system that had been written in RPG 15 years prior. After identifying the services to implement using the SOMA method, we analyzed the existing application and its structure. Given that one key principle in SOA is to create business value from existing assets, the objective was to reuse as much RPG code as we could and create new business functionality by leveraging an innovative approach.
We identified three different candidate areas for modernization: the database, the RPG code, and the technological platform.
Many legacy systems suffer from poor data structure. We weren't surprised to find that our client's legacy system, as expected, also suffered from this problem. The information had been intensively duplicated over the years, resulting in some tricky situations where the same piece of data was contained in several tables. There was no referential integrity, and the concept of primary and foreign keys wasn't applied uniformly across the database.
Our first objective was then to modernize the database to create a clean and easy-to-use information system. We designed a relational database applying the normalization principles (see Resources for more information). To facilitate the reuse of the data across the organization, we split the database into two different schemas:
- One was dedicated to corporate data, reusable in many different applications.
- One was holding data specific to the legacy application we had to modernize.
Then we populated the new database from the legacy database using the Extract Load and Transform (ETL) strategy. So we ended up with an information system capable of providing data for the client's system, but also with a more generic layer dedicated to corporate data.
The business logic of the legacy system was implemented by numerous RPG programs. Just like the initial database, the programs weren't really following a structured architecture. They had been developed to quickly answer business needs and had intensively evolved to fix technical and functional problems. The same business logic was duplicated in many different programs so that the maintenance had became difficult and a major center of cost.
To create value from this monolithic code, we identified a strategy for rigorous modularization. The approach was simple: Design simple RPG modules to create a reusable business layer. Each module had a clear responsibility, and the duplicated business logic was gathered in specific unique components instead of being spread over several programs. We chose this approach to facilitate future maintenance. It also helped us define services on top of loosely coupled components. The RPG componentization was part of the global service-oriented approach.
Empowering the technological platform
Organizations usually have high expectations of an SOA implementation. The business often demands that the SOA be able to turn existing assets into individual business functions and processes and that the SOA efficiently support continually changing market conditions. Because of these demands for reusability and flexibility, the technical platform of an SOA solution is very important. It must leverage commonly adopted technologies and comply with the industry standards to facilitate integration with business partners. In addition, an SOA solution must meet all the nonfunctional requirements to ensure business quality of service (QoS). This typically encompasses quality requirements like security, availability, performance, or portability.
Defining the architecture for a modernized application isn't easy. Compared to a green field project, there are many more constraints to take into account. The most important thing to consider is that a modernization is not a rewrite. In our project, we decided early to base our final solution on the Java™ 2 Platform, Enterprise Edition (J2EE) platform. The client wanted to leverage modern and powerful technology, and Java had already been used in some of their side projects.
Globally, we followed the J2EE architectural patterns (see Resources) to conform to best practices and proven solutions. We defined several application layers, each one with a specific responsibility. It was actually an implementation of the Model-View-Controller (MVC) pattern, but enriched with some SOA concepts. Let's take a closer look at these layers:
- Layer 1: The lower layer is responsible for providing all the data to the rest of the system. It contains the database and some legacy programs in their original version. (Some noncritical programs weren't modernized because there was no business value in their transformation).
- Layer 2: The enterprise component layer is responsible for realizing functionality of the exposed services. It contains the RPG modules defined during the componentization activity and the Java components designed to implement the new features of the modernized system.
- Level 3: The service layer orchestrates calls to enterprise components to form complete business processes. It contains coarse-grained Java components.
- Layer 4: The upper layer is the entry point to the modernized application. It can contain UI components but also processes exposed to external service consumers.
In addition, we defined two supplemental layers to handle critical nonfunctional requirements:
- Layer 5: This is the integration layer that enables the interoperability between different platforms. It was implemented using an Enterprise Service Bus (ESB). The ESB acts as an intermediary layer to enable communication between different application processes. It combines event-driven and service-oriented approaches to simplify integration of business units, bridging heterogeneous platforms and environments.
- Level 6: This layer provides the capabilities to ensure the entire application meets the QoS requirements. In particular, the modernized application needed first-class security, integrity, and availability mechanisms.
Our approach was to adopt a leading J2EE application server for the middleware. It provided a robust security model and reliable transaction management. So our QoS requirements were realized by the application server itself. The different layers in our architecture are summarized in Figure 2.
Figure 2. Example of SOA stack for legacy modernization
|
|
 |
| ||||||||||||||||||
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
