guest commentaries: Debunking Encapsulation
Now that push has come to shove on Y2K projects, some customers are starting to look to vendors who can provide them with a miracle drug to solve their Y2K problems.
This is especially true for AS/400 shops running large legacy applications. They have run out of time to be choosey. Most don’t have time to replace their software but must instead remediate their existing code using a combination of the most efficient tools and talent possible. So the big question now is, "Do I need to cut corners to get done in time?"
The answer is a resounding NO!
Vendors touting database encapsulation (a.k.a. encryption) are playing into fears that it is too late to apply a better solution. Some people are buying, but others have realized that encapsulation is no less invasive or speedy than other approaches like database expansion.
The Basics
If you choose expansion, the year portion of dates in your database files are converted from 2 digits to 4. For example the date October 31, 1998 previously stored as 981031 gets expanded to 19981031. In this fully Y2K compliant form, database dates can be sorted properly and are recognizable as the actual date on the calendar that they represent.
Using the "trick" of encapsulation, October 31, 1998 becomes 701031. It is true that dates beyond the year 2000 will sort properly if they are backdated by 28 years. But is this gimmickery and confusion worth the risk?
Encapsulation Vendors Claims vs. the Facts
Claim: Encapsulation is less invasive –
Fact:Encapsulation vendors say that by not changing the date format in the database, there will be a lot less work. It turns out that expanding dates in the database is relatively painless. There are a number of tools on the market that can make the database conversion an entirely automatic batch operation.
Encapsulation vendors say that with their approach, program impact is minimal. The fact remains that even with encapsulation, every program that brings users into contact with dates must be modified at the source level, recompiled and tested. That means that even with encapsulation you must find the correct source code and devote system time for recompiling. And contrary to these vendors’ advice, common sense suggests that a certain amount of time should be spent testing any programs that have been recompiled in a production system.
In terms of thoroughness and accuracy of program changes, the Y2K tools available for both expansion and encapsulation are quite mature and complete. With the sophistication of current Y2K tools, there is no longer any reason to believe that encapsulation requires any less manual effort than more robust remediation methods.
Claim: Encapsulation is faster-
Fact: As discussed above, Y2K tools offering either database expansion or encapsulation have evolved to the point where you can find tools from either camp that are highly accurate, thorough and automatic. As such, batch machine (CPU) time for remediating and recompiling programs becomes the yardstick against which vendors compete. Both the expansion and encapsulation vendors are claiming conversion rates for large ERP systems as taking between 12 and 48 machine hours on a high-end AS/400.
But let’s get real – who really cares whether an automatic batch process takes 12, 24, 48 or even 100 hours on a project of this scale. The real time will be spent on preparation (finding source code, establishing the conversion environment) and then on quality assurance (testing, making sure interfaces are accounted for, etc). Choose the method that will deliver the better technical solution within a reasonable overall project timeline.
Claim: Encapsulation is reversible –
Fact:Encapsulation vendors want you to believe that reversing out their changes is easier than with other Y2K remediation approaches. Reversing Y2K changes out of the database is sometimes necessary when you want to upgrade your non-Y2K compliant version of a vendor’s software to a newer version. The truth is that reversing out Y2K changes is just as simple with an expanded database as an encrypted one. Both require a sizeable batch process that runs against the entire database returning the datefield values to their pre-Y2K converted representation.
Hidden Costs of Encapsulation
Beyond failing to demonstrate advantages over more accepted remediation techniques, encapsulation has unique hidden costs and risks that should be considered:
- encrypted dates may be misinterpreted or overlooked during data analysis
- all new program development must incorporate encapsulation logic
- ad hoc queries and SQL retrievals must incorporate "add 28 logic" to year values
- DFU/DBU activity – hope that everyone remembers to subtract 28 years from dates during file maintenance
- interfaces to other systems may be more difficult to manage when the data from an encapsulated system is shared with systems using more acceptable date representations such as expansion
The Bottom Line
Currently, encapsulation tools are priced similarly to tools offering more robust approaches. In addition, most view encapsulation as a "quick and dirty" approach to an important problem. The fact is that more robust Y2K approaches such as database expansion have caught up and are passing up their "trickier" counterparts. With so little time left, it is good to know that you can be "quick and clean" about your Y2K remediation and reap the benefits later that "doing it right the first time" affords.
Dan Mitchell is Chief Technology Officer and principal of Nexgen Software Technologies. Nexgen is the provider of Focus/2000, an automated century enabling technology used to correct century date defects in legacy ERP packages. [email protected].