SOA on legacy: lipstick on a pig, or extended value?

Jeremy Miller, not an avid fan of SOA, says there's a better way to adapt software to evolving business needs than attempting code reuse. And that is to simply write good code in the first place. Its cheaper and less risky to write brand new code than fiddling around with with existing code, he argues.

It's a matter of doing things right the first time. As he puts it in a recent post: 

"The positive goal of a service oriented architecture is to eliminate duplication of effort in software projects across the enterprise by reusing existing code assets and reducing the cost of changing the behavior of software to keep pace with evolving business needs.  ...it's usually easier and generally less risky to create new behavior by writing brand new code instead of breaking into existing code to make modifications. Call me Pollyanna, but I firmly believe that those very goals can often be achieved at a lower cost by a relentless focus on creating well-factored code backed up by a healthy dollop of test and build automation."

However, there problem with this Nirvana, Jeremy says, is "the mass majority of the code out there in production is of dubious quality and the kind of test and build automation that enables change simply doesn't exist for most systems."

The reality on the ground for many enterprises contemplating SOA is figuring out how to break open or streamline creaky legacy systems. There's too much emphasis on attempting to expose pieces of such applications as Web services, when all this does is put on a new front-end to the same moribund application. ("Lipstick on a pig.") Jeremy cautions against a common approach used in composite applications, in which legacy processes are replicated in a new environment -- resulting in two code bases. The risk is that companies may still not exactly be sure "what the correct business logic should be because the original code is not entirely readable or documented." As a result, maintenance costs are even higher, because the new application tier is "duplicating functionality without retiring the existing legacy code." 

Jeremy's observations raise important points about the great frontier of SOA -- tens or hundreds of thousands of legacy systems across today's enterprises. Sometimes, putting SOA lipstick on a pig is an act of expediency for overextended, understaffed, and under-budgeted IT departments. In fact, this is often seen as score one for SOA value -- the ability to work with assets that are already in place, without disrupting those assets.

For many companies, their legacy systems, no matter how creaky, are "good enough" to get the job done, even though they may be a spaghetti-tangled mess. The goal is to simply bridge the gap until they someday reach enough of a service critical mass to make a large-scale move. Until then, there's an appeal to quick-and-dirty projects that can squeeze more years out of such systems -- even if it doesn't add much real value to the business other than recovering some sunken costs.