On Wed, 22 Apr 2009 10:39:29 -0400, Farley, Peter x23353 <[email protected]> wrote:
>... >Many business processes *do* require the "real" data. Format >preservation does not help when sort order is affected. When a >business needs to determine a 9-digit zip code from the customer >address, format preservation will not do -- the program needs the >real street number and address and the real city and state or it >gets the wrong zip code. I (almost) agree, but draw a very different conclusion. I assume most business processes can accept realistic but bogus data and process it accurately. In your example, the only process requiring actual addresses (rather than bogus addresses that would be in the correct zip code if they were real) are those that validate against a registry of real addresses. For those, part of the obfuscated data would have to be a bogus registry. I think that this really highlights the need for a very sophisticated obfuscation technique. The same details that go into a process design need to go into the data obfuscation design so that the bogus data actually works. That, of course, can't help debugging a problem that is sensitive to only one exact combination of data. >Neither the customer nor the USPS appreciate or long tolerate >incorrect zip codes. Huh? Neither the customer not the USPS would see output based test data. If you mean that the application would produce incorrect zip codes based because it wasn't test enogh using the test data, then that points to a problem with the code or the test data. Pat O'keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
