The experts always add a lot of addendums and explanations whenever anyone says it, but by now we all know that one of the main drivers for service-oriented architecture is to simplify integration, particularly legacy systems.
But it turns out, when they're digging around in that legacy code, organizations sometimes uncover something unexpected: Bad Y2K fixes.
You read that right. It turns out, companies using SOA to integrate legacy systems are unearthing ugly code dating back to the Y2K fixes, according to a recent Joe McKendrick post, cleverly titled, "Blast from the Past: Will Y2K Patches Trip Up SOA?"
And as you can expect, it's slowing SOA down and adding costs to SOA implementations. McKendrick takes a very philosophical view of the situation, writing:
Sometimes, in the interest of expediency and budget, things were buried behind remediation layers -- things that have to be addressed as they are service enabled. Perhaps things would have gone a lot smoother if we had SOA back in 1998. Then we could have just done the remediation in the service interface. And we would have had a great business case for SOA.
Ah, the irony. The bitter, expensive irony.
You can thank Don Fowler for figuring this out. Fowler is an IBM-certified SOA solution designer and System z technical sales representative for Vicom Infinity, an IBM business partner.
McKendrick linked to Fowler's article, which actually ran more than a year ago in zJournal. I asked McKendrick why he's writing about this now. Back in the day, he covered the Y2K problem quite a bit, and he'd long been mulling over the potential that it might resurface. While he hasn't heard of any organizations that have actually encountered the problem, he pointed out it's something companies probably wouldn't want to talk about it.
So, I contacted Fowler and asked if he still considered some of the Y2K "fixes" a ticking time bomb and had he written anything since the January, 2009 piece.
Yes, he responded via e-mail, it's definitely a problem. In fact, he's working on a remediation project at "one of the largest financial institutions" to correct upcoming failure situations:
I raised the alarm via the 2009 article. All a follow up article would do is point out specific live code examples that we found that will fail and some statistics on total software inventory to infected members of that inventory. We did find several cases where failures were already occurring and data store was being corrupted.
In particular, Fowler says he would be concerned about any enterprise that had planned to retire an application between January 1, 2000 and around 2010:
Did that application actually get retired? If not, did that anticipated retirement affect the remediation decision made on how to resolve the original Y2K issue? An example might be using a Y2K repair action called "windowing" and setting the window "pivot" to 50. Any year variable greater than or equal to 50 is a 1900 for century. Any year variable less than 50 is a 2000 century.
Some other issues Fowler suggests you consider:
So, obviously, it's still an issue. In fact, it's arguably more relevant this year-the 10-year anniversary of the Y2K crunch - since some of the Y2K fixes actually just used a method that could expire sometime between now and 2013, according to Fowler:
A lot of the pivots I've seen are set to 50 or 51. So I guess the bulk of our problems will surface the morning of 2011 or 2012. The Mayans may not have been too far off! Let's be honest. This problem is not nearly the disaster or cost of the original Y2K bug. But it will continue to plague us with scenarios like I've painted above.
Tick, tick, tick, tick.
But at least the problem has gotten easier to resolve. Fowler says the Y2K remediation team uses a solution that automates the Y2K identification and repairs, which was created by a Netherlands-based company called Cornerstone Technology.
The smart approach is to view SOA and legacy integration in general as an opportunity to catch those kinds of hidden bugs in legacy systems. (And if you think Y2K was all hoax, talk to these banks about it. Sony can also tell you how bad bugs in the date field can be.)
But this issue also highlights a bigger, systemic problem for IT: How little organizations have matured in the way they deal with legacy systems. In an InfoWorld article on Y2K's 10 year anniversary, Gartner analyst Dale Vecchio says many companies ignored the big lesson: Know Thy IT Portfolio, Inside and Out. Vecchio covered the Y2K bug back in the day. He told InfoWorld:
I'd like to tell you that there were a lot of lessons learned, but I'm not sure that I've seen a lot. ... once they passed the risk of Y2K, they went back to the same lack of knowledge and now, when faced with an aging portfolio and aging workforce, they don't know any more now than they knew then. ...Baby Boomer retirements [are] bringing back a recognition that [IT shops] don't understand these application portfolios to move forward.