NEWS AT SEI
This library item is related to the following area(s) of work:System of Systems
This article was originally published in News at SEI on: August 1, 2008
Don’t do it . . . yet.
In a nutshell, that was the recommendation in 2005 from the Carnegie Mellon Software Engineering Institute (SEI) to its first customer using the Service Migration and Reuse Technique* (SMART) approach for determining the feasibility of migrating one of its legacy systems to a service-oriented architecture (SOA) environment. The SMART process uncovered significant risk due to the state of the customer’s target SOA environment and the scope of the migration effort. The SEI team suggested a pause in legacy system migration planning while work continued on the SOA environment and the scope of the migration was better defined. In May 2007, the customer successfully demonstrated the migration of a set of legacy components to services.
Recommending that a customer not plunge ahead into SOA reveals a strength of the SMART process and also illustrates the different way the SEI interacts with customers in the U.S. Department of Defense, civilian government agencies, and industry.
Technology vendors tout the advantages of moving to an SOA environment: Organizations, they point out, will benefit from lower development costs, enhanced business agility, leverage of legacy systems, greater access to information, and improved business processes. The SEI is realistic about the effectiveness of SOA-enabling technologies and focuses on transitioning best practices that provide the basis for sound decisions about SOA.
Federal government and others organizations are attracted to the promises of SOA; some are even mandated to move toward an SOA environment because of them. But the adoption of the SOA approach, particularly by the DoD and federal agencies, lags far behind the attraction .
One significant contributing factor is a hesitance to migrate legacy systems to the new environment. For federal agencies, a large amount of information, including mission-critical information written in older programming languages, is housed in legacy systems such as mainframe computers.1 Also, for these agencies—and all organizations with a heavy investment in legacy systems—
The SEI has investigated issues pertaining to software reuse and legacy system migration for several years.2Research in to those issues led to the development of the (SMART) approach by the SEI’s Integration of Software-Intensive Systems (ISIS) Initiative about three years ago.
Using SMART, an organization can obtain a contextual, hands-on identification and analysis of issues in migrating legacy components to SOA environments. Since its initial development, the SMART process has been applied in several customer situations and refined into a state ready for transition.
The story of the SMART process is also an example of how the SEI is able to respond to need with an innovative concept, test it through engagements with customers, refine it based on those engagements, and support its adoption with training and tools.
Eileen Forrester has been involved with transition efforts at the SEI for more than a decade. Forrester says the transition of a technology or approach begins early in its development: “What is the problem we are trying to solve? That’s the first question we ask.” SEI transition moves, generally, through exploration, maturation, outreach, and support phases, according to Forrester.
“As we move through the transition life cycle, the questions get sharper. During the maturation phase, we will ask, for example, ‘do we know that any intended users can use our solution.’ In outreach, we are looking to find out what mechanisms we are developing for transition. And in support, we would ask how we will support the technology and our transition partners,” Forrester explains.
Through the lens of the SEI technology transition life cycle, in this three-part series of articles we will examine:
“SOA allows the reuse of legacy systems. But constructing services from existing systems to obtain the benefits of SOA is neither easy nor automatic,” points out Grace Lewis, technical lead for SEI’s SMART process and system-of-systems engineering research.
“Even before developing services, organizations need to ask whether it makes sense to migrate their legacy systems,” Lewis says. “And that means understanding what services are and what SOA is and can provide.”
In SMART, Lewis and her ISIS colleagues created is a process that guides an organization through addressing six critical questions for determining the feasibility of migrating its legacy systems making an initial migration plan:
According to Lewis, the backbone of the SMART approach is a “questionnaire, which is the codification of migration knowledge.” The questionnaire, called the Service Migration Interview Guide (SMIG), guides the SMART team’s discussions with stakeholders and developers in four activities.
The first activity is to establish the goals of the migration project and make note of its drivers and constraints such as schedule and budget.
“Why does the organization want to migrate its legacy system, what are the business and technical drivers and who are the stakeholders of the migration—these are the key questions we ask,” Lewis says. “We also help the organization collect information on what the legacy system is about, the kinds of services they think it wants to produce, and the types of service consumers.”
After collecting this information, the organization can decide whether to continue. The migration might be feasible, it might be potentially possible with more information, or it might not be feasible. If migration is feasible for the organization, the discussion turns to three other SMART activities: define possible services, describe the legacy components, and define the target SOA environment.
The organization should specify a small number of services, usually three or four. Dennis Smith, technical lead for the ISIS Initiative, notes that organizations at first believe they can turn an entire legacy system into services. But they need to try to identify a few components of the legacy system to make available as services.
The SMART team and the organization then have enough information to complete the last two SMART activities. They can analyze the gap identified between the existing and future states in order determine a preliminary estimate of the effort, cost, and risk for migrating legacy components into services. And they can form a migration strategy, the culmination of the SMART process.
Having designed an approach, Lewis, Smith, and others in ISIS conducted a pilot of the approach to analyze the potential for migrating legacy components of a DoD command and control (C2) system. Among the lessons they learned was that architecture reconstruction might be needed to address issue of dependencies in detail when there is no architecture documentation or it is outdated. They found they can use the SEI-developed ARMIN tool for this purpose.3
With the approach tested, the ISIS group was ready to apply it to a customer situation. The first application of the process showed that SMART is innovative because it recognizes that technologies are not the main aspect of SOA for every customer. Indeed, after initial discussions with its customer, the U.S. Army CERDEC (Communications-Electronics Research, Development, and Engineering Center), the SMART team recommended that CERDEC not proceed with making a migration plan at that time.
“We saw there that their target SOA environment was not mature enough,” Lewis explains. “We have seen that other customers are not ready for a migration; they need more background in SOA, in aligning their SOA strategy with their mission or business objectives, and in what services they can form from their legacy systems.”
Other implementations followed the initial work with CERDEC. Today, the approach has been used or is being used with four large federal-government organizations. In two of those organizations, departments have entered into the process of transitioning the SMART technology to act as centers to guide other departments in the migration of their legacy systems to the enterprise SOA environment.
During the course of these implementations, Lewis and her team proved the value of their solution. And they saw the need to modify some aspects to match the high level of complexity that exists among customer organizations that are considering migrating legacy systems to SOA environments. We will look at those refinements in the third and final part of the series.
They also proved that the central tool, the SMIG, provided the right means to gather data and information crucial to developing a plan for migration. But using the paper-based tool was labor-intensive, and it was becoming more cumbersome to deliver results to customers in a timely way.
In the next installment of this series, we will examine how the ISIS team made the SMIG tool more efficient through an innovative partnership with Carnegie Mellon University.
1 The private sector seems to have overcome obstacles related to migrating legacy systems. The reliance on legacy systems is not less there. It is commonly believed that more than two-thirds of business information resides in mainframe databases . Put another way, in an estimate by the International Data Corporation, there are 200 billion lines of legacy codes on “more than 10,000 large mainframe sites” in use .
2 See for example the SEI’s Framework for Product Line Practice and Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices.
3 The ARMIN tool provides graphical and textual representations of an architecture as implemented. For more, go to http://www.sei.cmu.edu/architecture/start/reconstruction.cfm.
* As of June 2010, SMART is defined as the SOA Migration, Adoption, and Reuse Technique.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.