NEWS AT SEI
This article was originally published in News at SEI on: April 1, 2007
One reason organizations are keenly interested in service-oriented architecture (SOA) is that it offers the promise of reusing legacy-system code as services that represent business tasks. Some common services are customer lookup, account lookup, credit card validation, and hotel reservation.
Recently, the Software Engineering Institute (SEI) introduced a new method for planning the migration of legacy components to services called the SEI Service Migration and Reuse Technique* (SMART) method. One of the first organizations to adopt SMART is the U.S. Army Communications-Electronic Research Development and Engineering Center (CERDEC).
news@sei spoke with SEI staff members Grace Lewis and Dennis Smith, who are leading the project to increase adoption of the SMART method.
What is SMART and what problem is it designed to solve?
Lewis: SMART is a technique for helping organizations understand in detail the effort it takes to migrate specific legacy components to a service-oriented architecture. When we do a SMART engagement, we look at code and say “You would have to do this to the code; you would have to do that to the code.” Then, we get people to understand that what is required is more than adding an interface to the code.
Smith: SMART helps an organization get a very realistic sense—is it viable to migrate these components as services, which services make sense, and what kind and level of resources are needed?
Do you find that organizations think migrating legacy components to services is easier to do than it is?
Lewis: There is a lot of hype about service-oriented architecture, in part caused by vendors who tell organizations that it is something extremely easy.
Smith: A lot of the literature about SOA has been produced by vendors who sell products. So is it the accurate picture? We take a vendor-neutral approach: What about SOA has value and what does not have value. If you are a top-level manager, you hear a lot about leveraging legacy systems as services, but you probably don’t know where to go next.
You are now transitioning SMART to the U.S. Army CERDEC.
Lewis: Yes, CERDEC is an Army transition program. The CERDEC job is to build systems and look at technology (which is what they are doing with SMART). When they understand the technology well, they transition it to other people in the Army.
Why is CERDEC interested in SMART?
Lewis: Our first engagement with CERDEC was about two years ago. Back then, CERDEC had been developing a system and wanted to know what it would take to move that system to a service-oriented architecture. CERDEC had two targets for service-oriented architectures, SOSCOE [System of Systems Common Operating Environment] and NCES [Net-Centric Enterprise Services]. We worked with the people at CERDEC—looking at their code, analyzing their architecture—and at the end of that we recommended that they wait. SOSCOE and especially NCES then were still evolving so that any effort at that point could have been wasted. Also, our customers were initially thinking that they would migrate the whole legacy system, not components of it, to a service-oriented architecture. But you actually need to find the specific set of components that it makes sense to migrate. We advised them to wait 18 months at least, to a time when SOSCOE planned a build. Eighteen months after our recommendation, we re-engaged with CERDEC at their request.
What has been done to transition SMART to CERDEC?
Lewis: First, we gave people at CERDEC a tutorial to help them understand what SOA is all about and gain an overview of SMART. The tutorial was well attended, by about 25 people. We have given this tutorial on the migration of legacy components to service-oriented architectures in several other settings. Then, we scheduled pilots. The first pilot was for them to watch us perform SMART. We repeated that pilot to make sure all of the key people saw us performing the SMART process. The second pilot will be for us to watch them conduct the SMART process. We will coach them on their use of the technique.
Smith: And at some point, we will check to be sure that we are comfortable with their understanding and that they are comfortable doing it. They want to be sure that they can facilitate the use of the technique. We may repeat this process if needed.
Lewis: After that, CERDEC will understand the method and be ready to apply it.
How does the SMART approach start?
Lewis: The first step in SMART is to establish the migration context. We have a set of questions about why organizations want to migrate, such as do they understand what a migration will entail and what are the business and technical drivers. We also want to know what the legacy system is about, at a very high level, what kinds of services they think they want to produce, and what are the types of service consumers.
Smith: Both the kind of services and the service consumers are important. As Grace pointed out earlier, many organizations initially want to turn a legacy system into services. In reality, they need to target more finely. They need to determine what specific services they want from a legacy system. It is also important to understand who is going to use those services. If they don’t do this, they could run into a situation thinking "if we build it they will come." It might be that nobody will come.
Lewis: At the end of this step, you reach a decision point: Do you have enough information to continue? If not, you need to get the answers to those questions before continuing with the process.
After an organization knows the services and service consumers, what then?
Lewis: Then you describe the system capability and the target SOA environment. In parallel to determining that information, you can start to map components to services.
Smith: The focus at this stage is on the specific components identified earlier. One goal of SMART is to find a relatively small number of components that you can target for turning into services. You home in on them, rather than plowing through the entire legacy system.
Lewis: The most common target is Web services with some enterprise bus-service product; this kind of environment we call “plain vanilla.” For CERDEC, SOSCOE is not a common target; it is built from scratch almost, so that will allow real-time systems to be created.
Smith: Most people equate SOA environments with Web services. And it is common, but it is not the only environment. And for SOSCOE, it is built from the ground up because it has hard, real-time constraints.
What if a customer doesn’t have a target in mind?
Smith: We can do an SOA strategy workshop to help a customer find ways to make some of those decisions.
Lewis: It is important that organizations decide the target or targets, based on IT infrastructure. If they haven’t identified the target, then they should not go ahead. This is something that SMART enforces.
After organizations identify the target, where does SMART take them?
Lewis: Our next step is to analyze the gap between where they are and where they want to go. To this point, SMART helps them understand their key legacy components, service consumers, and target environment. Now, SMART helps them look inside each component. What would a developer have to do to the code for that component to turn it into a service that meets the needs of the consumers? The involvement of the developer is critical here because the developer can say, “We must do this, and this, and this.” In this stage, the organization gets into a great deal of detail. The organization gains a truer understanding of how long it will take and how much it will cost.
It could also happen that people do not understand what they have—a legacy system could have been created long ago, and documentation is missing, if it existed at all. We can do some architecture reconstruction, some code analysis to try to understand basics about the legacy system. We can offer some services in doing this, if the code is written in a language where there are tools we can work with. Ideally, the developer is there; otherwise, we have to do some work to arrive at the information the developer can provide.
Smith: With SMART we try to take as little time as possible to get the most significant information to make decisions. We think that this approach saves customers money and makes the best use of our resources. If there are real gaps, we have to delve deeper, which costs more. At CERDEC, the people who developed the legacy components are still around. They really understand their code, so we have great confidence in their estimates of how long the changes will take.
What does SMART help an organization produce from all of the information?
Lewis: The final step in SMART is producing a migration strategy, which is a combination of a lot of things. This is important: The outcome of SMART is not the migrated code; the outcome is a strategy for people to follow to do the migration.
The strategy could be straightforward—as in “take the code and do exactly what you said you needed to do.” Or it could be “define an architecture for your services and conduct a strategy workshop because you really don’t understand what is needed.”
Part of the migration strategy is to address what is known about the technologies that the organization wants to use. The SEI can offer the SEI T-CheckSM method to investigate technologies. This method is a low-cost way to separate hype from reality about a technology as its use pertains to the target environment the organization has chosen. For example, if a part of the system will involve the transferring of images, the organization needs to be sure that its chosen technologies are capable of doing that.
Smith: There’s also the SOA strategy workshop to help organizations understand the value of putting together a realistic approach for moving into the SOA world. This involves looking at technology in general and what they want to do with their legacy systems and infrastructure options, among other things. And we can also offer an SOA governance workshop.
How long does it take for you to teach SMART to an organization?
Lewis: It does depend on the situation. At CERDEC, our first pilot took one visit, and we spent some time to do a report—about six weeks in elapsed time.
Smith: Typically we expect about three visits of two to three days each with time for report preparation—six weeks to two months in elapsed time. We are developing an automated tool to streamline the interview process. The work in establishing the migration strategy, describing existing capability, and describing the target SOA environment is done through a service migration interview guide [SMIG], which is a series of questions we ask to gain full understanding. This use of SMIG is a manual process. Our tool will include the SMIG and will be able to tell the interviewer, for example, “you have covered these points and still need to address these other ones.” Eventually, using this tool, we will produce a draft report that says, based on the findings, “Here are the potential issues.” Using this tool will cut down the time spent writing the report, which is most of the elapsed time.
Where else have you seen interest in SMART?
Smith: In fact, there is interest now from inside and outside the Department of Defense. For example, personnel at a large government contractor with good software expertise want to get involved with SOA because many clients ask them to. They are interested in the SEI as an objective broker about SOA approaches and are looking at SMART. We’ve also talked with other medium to large organizations in this country and Europe.
The material presented in this tutorial is now available in a publicly available two-day course called Migrating Legacy Systems to SOA Environments; for details and registration information, go to http://www.sei.cmu.edu/training/p59b.cfm.
* As of June 2010, SMART stands for SOA Migration, Adoption, and Reuse Technique.