Eight years after the turn of the century, many organizations must now face the fact their Year 2000 (Y2K) patchwork solutions are coming back to haunt them. Some are being found as Service-Oriented Architecture (SOA) projects encounter problems.
“’Twas almost the end of 2008. When, what to my wondering eyes should appear?
Eight tiny words that should strike fear. The little old IT executive said so slick, I knew in a moment, it must be Mr. Quick Fix.”
The memo from the IT executive started, “Our Y2K remediation solution for application XYZ is going to fail. We need to come up with a quick fix to get us around the problem.”
Come up with a quick fix? Millions of dollars and thousands of man hours were spent dealing with Y2K less than a decade ago. There was the menu of industry standard approaches to fixing the problem, ranging from pivot year to sophisticated algorithmic logic and bridge programs. None was a magic bullet then and none is a magic bullet now. Date field expansion was the only sure-fire remediation that alleviated future issues. Well, at least until the UNIX Y2K+38 arrives.
Why Has the Issue Resurfaced?
The biggest reason this issue has resurfaced is due to management’s decision to do as little as possible to get by because, in their infamous words, “That system will be replaced.”
Guess what’s happened since that proclamation? Nothing, zilch, nada, nil, zero, zip. The system that was supposed to go away is still part of core business processes.
We’re now seeing Y2K-related issues emerge that involve prior decisions to use pivot year and encoding remediation methods.
“More rapid than PTFs, their edicts, they came.