NEWS AT SEI

In the previous column, we discussed the important role of service-oriented architectures, especially as an enabler for interoperability. With the advent of universal Internet availability, many organizations have leveraged the value of their legacy systems by exposing all or parts of their functionality as services. A service is a coarse-grained, discoverable, and self-contained software entity that interacts with applications and other services through a loosely coupled, often asynchronous, message-based communication model [Brown 02]. A collection of services with well-defined interfaces and a shared communications model is called a service-oriented architecture (SOA). A system or application is designed and implemented as a set of interactions among these services.

The characteristics of SOAs (e.g., loose coupling, published interfaces, and standard communication model) offer the promise of enabling existing legacy systems to expose their functionality, presumably without making significant changes to the legacy systems [Lewis 05]. SOA migration tasks can be considered from a number of perspectives including that of the end client or user of the services, the SOA architect, or the service provider. This column focuses on the service provider.

Organizations often look toward developing services from legacy components. However, constructing services from existing systems to obtain the benefits of an SOA is neither easy nor automatic. In fact, such a migration can represent a complex engineering task, particularly when the services are expected to execute within a tightly constrained environment.

One important task is to evaluate legacy components to determine their potential for migration to services within a specific SOA. This column outlines an approach, the Service-Oriented Migration and Reuse Technique (SMART), that gathers information and identifies the risks for such a migration effort in a systematic way.

Creation of Services from Legacy Components

Enabling a legacy system to interact within a service-oriented architecture, such as a Web-services architecture, is sometimes relatively straightforward—this is a primary attraction to the approach for many businesses. However, characteristics of legacy systems such as age, language, and architecture, as well as of the target SOA, can complicate the task. An analysis must be performed to consider

1. requirements from potential service users (It is important to know what applications would use the services and how they would be used. For example, what is the information expected to be exchanged? In what format?)
2. technical characteristics of the target environment, such as bindings, messaging technologies, communication protocols, service-description languages, and service-discovery mechanisms
3. the architecture of the legacy system, including dependencies on commercial products or specific operating systems, or poor separation of concerns
4. the effort involved in writing the service interface
5. the effort involved in the translation of data types
6. the effort required to describe the services including information about qualities of service, such as performance, reliability, and security; or service-level agreements (SLAs)
7. the effort involved in writing service-initialization code and operational procedures
8. estimates of cost, difficulty, and risk

SMART performs these types of analyses through five activities:

1. Establish stakeholder context.
2. Describe existing capabilities.
3. Describe the future service-based state.
4. Analyze the gap between service-based state and existing capabilities.
5. Develop strategy for service migration.

These five activities are briefly outlined below.

1. Establish Stakeholder Context
   To establish the context in which the migration to services will take place, SMART first identifies the stakeholders, including the current end users of the legacy systems, the potential end users of the migrated service operating within the SOA, and the owners of the legacy systems. The activity identifies who knows most about the legacy system, what it currently does, and what it should do as a service or set of services.
2. Describe Existing Capabilities
   The goal of the second activity is to obtain descriptive data about the legacy components. Basic data solicited includes the name, function, size, language, operating platform, and age of the legacy components. Technical personnel provide information about the architecture, design paradigms, code complexity, level of documentation, module coupling, interfaces for systems and users, and dependencies on other components and commercial products. Historical cost data for development and maintenance tasks is collected to support effort and cost estimates.
3. Describe the Future Service-Based State
   The goals of the third activity are to
   
   
   • gather evidence about potential services that can be created from the legacy components
   • gather sufficient detail about the target SOA to support decisions about what services may be appropriate and how they will interact with the architecture

   Initial information about potential services often comes from conversations about the function(s) of the legacy system during the second activity. However, the information gathered often must be tempered by data from users, corporate architects, domain groups, communities of interest, and reference models that address service definition. In some cases, these groups and models will define the entire set of services that support the organization’s goals and into which any potential services built from the legacy components must fit.

4. Analyze the Gap
   The goal of the fourth activity is to identify the gap between the existing state and the future state and determine the level of effort needed to convert the legacy components into services. This analysis may also suggest potential tradeoffs between the target architecture and the legacy components.
   
   The tasks of this activity include the following:

• Develop an analysis strategy for legacy components that are being considered for migration.

• Analyze the legacy components to determine the types of changes that must be made to enable migration. SMART uses three sources of information to support the analysis activity:

  1. the issues, problems, and other concerns that were noted as the team completed the previous, discovery-oriented steps form one source of information.
  2. a Service Migration Inventory (SMI) that distills the many desired traits of services executing within SOAs into a set of topics. The team uses the SMI to assure broad coverage and consistent analysis of difficulty, risk, and cost issues.
  3. (optional) the use of code analysis and architecture reconstruction tools to analyze the existing source code for legacy components.

5. Develop Strategy for Service Migration
   A key feature of SMART involves building cost projections for each migration option still under consideration. This is accomplished by considering organizational characteristics, difficulty, and risk associated with various migration options and applying historical productivity numbers where possible.

Pilot Application of the Process

We applied an early version of SMART in a recent pilot analysis of the potential for migrating a set of legacy components from a DoD command and control (C2) system to an SOA.

1. Establish Stakeholder Context
We initially met with the government owners of the system and the contractors who had developed the system. At this meeting we received an overview of the set of systems, the history of the systems, the migration plans, and the drivers for the migration. We received a brief orientation to the SOA and also obtained system documentation.

The owners of the systems recognized that if selected components from their C2 system were to be converted to application domain services within a specific target SOA, they could have applicability for a broad variety of purposes. Our role was to perform a preliminary evaluation of the feasibility of converting a set of their components to application-domain services within an SOA.

2. Describe Existing Capabilities
The pilot C2 system has two parts: (1) a mission-planning system and (2) a mission-execution system that adds situational awareness to the planning capability. These two systems were initially developed as part of a product line. Both rely on a set of core components for the data model, data analysis, and visualization.

Given the information about the target SOA, we met with the contractor and representatives of the government to focus on a limited number of legacy components and to select criteria for further screening. We focused on seven potential services that the government team had previously identified as part of its initial analysis of ADS requirements. These seven potential services contained 29 classes.

The current system, written in C++ on a Windows operating system, had a total of about 800,000 lines of code and 2500 classes. In addition, the system had dependencies on a commercial database and a second product for visualizing, creating, and managing maps. Both commercial products have only Windows versions.

The 29 classes that we selected enabled us to focus on potentials for high payoff. In conjunction with the team, we developed criteria for screening the potential reusable components. These criteria included

• size
• complexity
• level of documentation
• coupling
• cohesion
• number of base classes
• programming-standards compliance
• black-box vs. white-box suitability
• scale of changes required
• commercial-mapping-software dependency
• Microsoft dependency
• support software required

These criteria formed the basis for the more detailed analysis discussed below.

3. Describe the Future Service-Based State
The system owner had done a preliminary identification of potential services that could be built from components of the legacy system. This analysis was derived from high-level requirements for applications that were being targeted as users of services to be provided by the SOA. The system owner had matched legacy functionality to these high-level requirements and provided some initial estimates of the contents of the potential services.

We investigated the target SOA through an analysis of available documentation and through a meeting with the developers. Because the SOA was still under development, the specifications for how to deploy and write services were still unclear.

4. Analyze the Gap
Given the known and projected constraints of the target SOA, we performed three different types of analyses: (1) an analysis of the changes to the legacy components that would be necessary for migration to the SOA, (2) an informal evaluation of code quality, and (3) an architecture reconstruction to obtain a better understanding of the set of undocumented dependencies. The results of these analyses allowed us to define a service-migration strategy based on the risks resulting from the unknown future state of the target SOA.

Analysis of Required Changes
We initially met with the contractor to get an understanding of the required changes, as well as estimates of the level of difficulty and the risks of making the changes. The contractor provided estimates for converting the components into services, based on a set of simplifying assumptions on the actual make-up of the target SOA and the final set of user requirements. These estimates initially suggested that the level of difficulty of making these changes would be low to medium, and the risk would be low because of the contractor’s familiarity with the systems.

However, we found that the tools in use on the project picked up only first-level dependencies between classes. This indicated that the coupling and the amount of code that was used by each class was higher than could be estimated from the existing documentation. There was also no consistent programming standard, leading to idiosyncrasies among programmers. Because of the inadequacies that we found in the architecture documentation and the underestimation of the amount of code used by the potential services, there remained a number of gaps in our understanding of the system.

Code Analysis
To address remaining issues, we first analyzed the code through a code analyzer “Understand for C++.”

The code analysis enabled us to validate the input from the contractor and to produce input for the architecture reconstruction tool that would identify dependencies.

From the code analysis, we found that the code was better organized and documented at the code level than most code that we have seen. However, there were inconsistencies in the quality and documentation among different parts of the code that made the analysis complicated.

Architecture Reconstruction
To address the issue of dependencies in more detail, we conducted an architecture reconstruction with a tool called ARMIN. Architecture reconstruction is the process by which the architecture of an implemented system is obtained from the existing system [Kazman 03].

In our analysis, we were interested in dependencies between

• services and user interface classes
• services and the commercial mapping software
• services
• the services and the rest of the code that mainly represented the data model

The architecture reconstruction identified a substantial number of undocumented dependencies between classes. These will enable a more realistic understanding of the scope of the migration effort if it succeeds.

The architecture reconstruction also enabled us to document the central role of the data model and to identify it as a potentially valuable reusable component even though it had not been identified during the initial analysis.

5. Develop Strategy for Service Migration
In looking at the potential for reuse of the existing legacy components, we found that the current legacy code represents a set of components with significant reuse potential. However, because the current legacy system does not have sufficient architecture or other high-level documentation, it was difficult to understand the big picture as well as dependencies between different classes. The largest risk in reusing the legacy components concerns the fact that the SOA has not been fully developed. We also recommended that the government organization require the following changes from its contractors to make reuse of its legacy components more viable:

• a suitable set of architectural views
• consistent use of programming standards
• documentation of code to enable comments to be extracted using an automated tool
• documentation of dependencies, especially when they violate architecture paradigms

Conclusions and Next Steps

We found that the initial task of determining how to expose functionality as services, while seemingly straightforward, can have substantial complexity. Our conclusions, while not definitive, did point out a number of issues that the client had not previously considered. The type of disciplined analysis that we performed appears to have applicability for other organizations considering migrations to SOAs.

References

[Brown 02]
Brown, A; Johnston, S.; and Kelly, K. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications. Rational Software Corporation, 2002.

[Kazman 03]
Kazman, R; O'Brien, L.; and Verhoef, C. Architecture Reconstruction Guidelines, 2nd Edition (CMU/SEI-2002-TR-034). Software Engineering Institute, Carnegie Mellon University, 2003.

[Lewis 05]
Lewis, Grace and Wrage, Lutz. Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020). Software Engineering Institute, Carnegie Mellon University, 2005.

About the Authors

Grace Lewis is a senior member of technical staff at the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU), where she is currently working in the areas of constructive interoperability, commercial-off-the-shelf- (COTS-) based systems, modernization of legacy systems, enterprise information systems, and model-driven architecture. Her latest publications include several reports published by Carnegie Mellon on these subjects and a book in the SEI Software Engineering Series. Grace has more than 15 years of experience in software engineering. She is also a member of the technical faculty for the Master in Software Engineering program at CMU.

Edwin Morris is a senior member of the technical staff at the Software Engineering Institute, assigned to the Integration of Software-Intensive Systems (ISIS) Initiative. He is currently investigating approaches to achieving technical interoperability between complex systems and programmatic interoperability between the organizations that build and maintain them. Previous activities involved improving processes and techniques for the evaluation and selection of COTS products, and the development of the COTS Usage Risk Evaluation (CURE) technology. Before coming to the SEI, Morris developed custom operating systems for embedded microprocessors along with support tools to predict and monitor the performance of real time systems.

Dennis Smith is the lead for the SEI Integration of Software Intensive Systems Initiative. This initiative focuses on addressing issues of interoperability and integration in large-scale systems and systems of systems. Earlier, he was the technical lead in the effort for migrating legacy systems to product lines. In this role he developed the method Options Analysis for Reengineering (OARS) to support reuse decision-making. Smith has also been the project leader for the CASE environments project. This project examined the underlying issues of CASE integration, process support for environments and the adoption of technology. Smith has published a wide variety of articles and technical reports, and has given talks and keynotes at a number of conferences and workshops. He has an MA and PhD from Princeton University, and a BA from Columbia University.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.