Actually in a fairly/good/large implementation of test data privacy the numbers don't seem to be unreasonable (but there are a number of factors that need to be looked at. (i.e ONLY DB2 data, or MVS/Oracle/VSAM as well, instead of?).
Also a number of differnet aspects need to be. An example. 1) Data consistency. Since no application software runs by itself, one needs to make sure that whatever you apply in application A data element A1 ( example Postal code) is the same in application B data element B7 (postal code). And even if, for now, Data Masking (DM) is only for that one application you do not know what will happen later on, within the entire enterprise 2) Quality of the Data. One must make sure that the DM rules reflect the business rules of the application/enterprise. And that whatever software is used, minimized special coding of exits (harder to maintain if a lot of exits need coding). Not every type of data elements can be disguised the same way. What are the 'best practices' that others have used successfully. To make the data quality that ones need in a testing environment 3) Documentation. The 'four' letter word within IT ;-). But especially within a Data Privacy project to ensure success, Documentation is vital. Without proper documentation one can end up missing data masks, redoing rules, etc 4) Politically. Who owns that data? Who will determine which elements will be masked, and how? 5) As you touched based, the environment. The 'window', the platform, the repeatability etc 6) The software. Not all software are created equally. The ease of use, the enterprise wide requirements, the support, etc. all should be factored in any discussion of this magnitude. Are those partners knowledgeable about the issues. Do they have publicly obtainable certification on the question. Software is just one aspect of this large type of project. And I am only scratching the surface. If you want, feel free in contacting me. Robert Galambos CIPP/C, CIPP/IT Certified Information Privacy Professional Canada/IT Compuware Corp. 1-800-263-7189 Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of P S Sent: May 22, 2009 9:40 AM To: [email protected] Subject: Re: IBM Optim question... On Thu, May 21, 2009 at 7:45 PM, Bob Rutledge <[email protected]> wrote: > Ummm, guys, I kind of guessed that obfuscation was the general intent > of the exercise. The ignorance part was about the mechanics involved; > e.g. if the OP is talking about masking a database record for each of > those billion operations per hour, I hope his client has some serious iron. Ah. In that case, it's only mostly as bad as you suggest: a "masking operation" usually means one column in one row. So if you mask (say) firstname, lastname, address, city, ZIP, ssn, creditcardnumber, that's seven operations in one row. Still sounds like some serious iron. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
