Despite the fact that legacy integration is a major driver for SOA, most experts agree integration shouldn't be the main reason for committing to SOA.
But blogger and M-Dot Chief Architect Mike Kavis recently made an excellent point: While integration of legacy systems alone may not be a good enough reason to do SOA, it can certainly be a great first step.
Recently, Kavis posted a summary of a longer article he wrote on how SOA can be used to 'rejuvenate' legacy systems. It doesn't matter which you read, but for busy readers, I actually preferred the summary to the original article, because it sums up the essence of his argument:
SOA can be a great way to modernize applications and data running on mainframes.
Remember when the relationship between Business Process Management and SOA was a hot topic? Well, Kavis gives a great example of how this BPM can help you with giving legacy systems a SOA facelift:
"Under the covers, the user interface was driven by a BPMS engine and we integrated with over half a dozen legacy systems through a combination of web service calls and a data services layer. We were able to roll-out out new features in months instead of years and started creating value within the first year of the initiative. We didn't have to redesign years worth of legacy applications. Instead, we created a layer of abstraction above our legacy systems which acted as a bridge from our old application silos to our new wizard based system."
As Kavis describes it, this sounds a bit more like the Burton Group's idea of "bridging silos" rather than integrating them, but to end users, the effect is the same. Therefore, I'm counting it.
I like Kavis' thinking - and not just because my focus is always integration. After all, a 2009 TechTarget survey showed that 32 percent of responding tech pros said legacy application integration is one of their main drivers for SOA.
Then, once you've used SOA to rejuvenate legacy systems, you don't have to sweat so much about whether to replace or retain legacy systems. As Kavis notes:
"This approach is quicker and less risky than the rip & replace approach. Once this is done, IT can evaluate replacing backend systems which become transparent to the business users because of the abstraction of core business services that were previous buried in the legacy applications."
The key here is to remember integration - even integration of legacy systems - is not enough of a reason to do SOA. As Anne Thomas Manes points out, it's not smart to spend $20 million on SOA and only accomplish a few integration projects. BUT, if you have other business drivers for SOA, then integrating legacy systems is an excellent first step, because it delivers immediate business value.
For more ideas on how SOA can help with legacy systems, check out my earlier post, "Four Ways to Use SOA for Integrating Legacy Systems."