SOA's legacy

One reader of this blog recently made a very astute point: that the reason people think older houses were built better is because the ones that weren't built well probably collapsed some time ago. Likewise, the legacy we see around are the solidly built applications that survived years or decades. The clunkers fell by the wayside and were never discussed again.

All the more reason to keep legacy systems around and make the investment in a Web services layer that could help modernize the still-chugging, but nonetheless clunky, green-screen system.

In a recent post, IONA's Eric Newcomer talks about the recent ComputerWorld article on the second look many companies are taking at legacy systems that would have been on the way to the proverbial landfill. (Also referenced in this blogsite a couple of weeks back.)

Newcomer points out that SOA and Web services begin to pay for themselves when they "recognize the value in existing systems and easily enable them for reuse."

I agree.  

Newcomer also adds that "we are not talking about replacing COBOL with Java anymore; we are talking about adding a layer of XML to what's already there and getting more out of existing investments, which is a very good thing. We are not talking any more about replacing stuff that works just because a new technology came along. Legacy is definitely beautiful when it's dressed up in XML and exposed using Web services."

The time spent Web services and SOA-enabling such systems may be far less and far cheaper than attempting to replicate such systems, and the business processes they support, on another platform.

Dan Kusnetzky of IDC has identified several "golden rules of IT," of which I'll mention a couple: "if it’s not broken, don’t fix it," followed shortly thereafter by, "don’t touch anything unless people are screaming."

Some may say Web services/SOA is one more layer of complexity. But, implemented right, it can far less complex than attempting a rip and replace the old system. An especially expensive exercise if nobody was even screaming about it yet.

The only issue is -- and it's a big one -- is that of talent. Namely, where are we going to continue to find the people that can keep back-end systems running at peak performance levels?  COBOL and RPG are not top courses of study on university campuses. Who's going to volunteer (or be volunteered) to maintain the lumbering CICS engine, versus tackling the sexy new Web technologies? IBM and various industry groups know this is a major issue that will keep growing from year to year. This is an issue that needs to be addressed.