Applications & Databases
Home >
Applications & Databases > SOA: Year 2000 Déjà vu All Over Again?
 SUB DEPTS
Print this article

< Previous Page 1 2 3 Next Page >
ASG

SOA: Year 2000 Déjà vu All Over Again?



by Don Fowler
December 1, 2008

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.

 

Change the pivot, change the fix, make it so today.”

Let’s take a look at the simmering issue. The original Y2K remediation was done when:

• Server farms were the rage

• Migrating the application was surely going to happen in a near future IT budget

• The business climate was different.

From 1995 to 1999, everyone was on the bandwagon to rejuvenate and modernize their core business applications and move them to the Intel platform. After all, that platform was cheaper. It was just a matter of prioritizing the applications and proper budgeting. Right? Business was getting an inkling of new strategies and architectures for making its systems more flexible and responsive.

So, where are we now?

• The world is going green and server farms are becoming far too expensive.

• Money is tighter than ever. More pressing projects consume the available

dollars.

• The business is rapidly changing due to external influences.
< Previous Page 1 2 3 Next Page >
This article has no comments. Be the first to comment!
 COMMENT ENTRY
Name:
Email:
Location:
Website:
Comments:
Remember my personal information
Notify me of follow-up comments?
Please enter the word
you see in the image below:
   
 SPONSORS
 SEARCH DEPTS
 MAINFRAME JOBS
mainframe consutlant
EDI Specialists
NJ, US
Mainframe
Open Systems Technologies
New York, NY, US
Mainframe Developer

Jacksonville, FL, US
Mainframe Supervisor
Analysts International
Houston, TX, US
Mainframe Programmer
Triune Technologies Inc.
Los Angeles, CA, US
Mainframe Systems Programmer - z/OS
CVS/pharmacy
Woonsocket, RI, US
COBOL MAINFRAME DEVELOPERS
RCG Information Technology
New York, NY, US
Mainframe Programmer Analyst-Madison Office
Sentry Insurance
Madison, WI, US
Mainframe Support Staff
Charles Schwab
Austin, TX, US