SOA-enabling legacy systems is fraught with pitfalls. There are some dos and don’ts that can make this journey easier.
First, organizations must determine if it makes sense to reuse legacy systems
Grace Lewis, senior member of the SEI technical staff, uses SMART when she teaches the SEI’s course on Service-Oriented Architecture: Legacy System Migration. “We emphasize that the [SOA] infrastructure has to be selected already because infrastructure places a lot of constraints on the system in terms of if it’s feasible or not.” Also, the legacy system identified for migration should contain “functionality or data that is good mapping or can help an org implement business processes identified as key in SOA adoption.”
In thinking the migration through, Lewis said an organization may see that there will be more work to do than expected. Potential barriers to modernization/migration include a lack of tools for a very old platform; the difficulty of integrating a batch-oriented system with an interactive request/response style system; and “user interface functionality very tightly coupled with business functionally.” It’s not impossible, but it’s more difficult to separate the code, she said.
Lewis said there are three common mistakes or misperceptions when it comes to SOA-enabling legacy systems:
- The legacy system does not goes away. “Some think that by migrating to SOA, legacy goes away. The system still has a day job, and it still has users and runs daily operations,” she said.
- Migrating a legacy system is not just a simple matter of wrapping. “It’s not just matter of wrapping; other things need to be taken into consideration,” she said. “That’s why you need a system-by-system analysis.
- Everything does not have to be a service. “You really only need to expose what makes sense from a business process perspective,” she said.
This was first published in April 2011