Lifecycle and Data Masking

Lifecycle and Data Masking

TEXTData masking is not a separate activity that happens somewhere in the centralized place in organization. It is a step in the application lifecycle architecture properly positioned in the overall process - whether the tool makes depositories centralized or distributed.

Lifecycle Architecture

TEXTOverall data lifecycle architecture differs for startups and developed companies in the beginning - before at least one product in the organization becomes customer facing.

Environments

In startups, in the beginning, there is a process of building infrastructure and processes and there is rarely plenty of consumer data. Thus, majority of the test data is created via CRUD statements or small uploads and all of it could be fictitious.

Only when the startup product hits "production" ( becomes customer facing), the application starts receiving real data, and often times parts of it are PII ( personally identifiable information).

The moment the product is deployed to the production environment is the starting point when there might appear a need to move production data into the development environments. It is done in order to create as many test cases close to production as possible with little development effort.

This is also a starting point for data masking processes.

In the developed organizations, the development does not start with from the blank page. There is always data in the organizations and when the new project starts, this data is transferred to the development environments as it would be done in the production. The requirements of the initial data population will depend on the application; however, most likely, the data will start flowing and integration processes will be established from the beginning - be it CRM, patient records via HL7 messages or other types of files, or account information in the form of the batch file uploads.

This is the point when the lifecycle architecture gets established.

Usual lifecycle consists of 1. creating the repository in the source control, 2. developing code in the sandboxes with unit testing 3. propagating successfully built code to the source control for further integration 4. integrating ( hopefully with CI server) on the integration server 5. resolving conflicts 6. upon successful conflicts resolution, propagating to the further environments - testing, UA, deployment, performance testing, etc. 7. deploying to production 8. branching 9. figuring out data quality 10. refreshing environments A. propagating new production code B. sub-setting or up-setting, according to requirements and required purpose of the environment C. masking sensitive data and moving production data backwards. Data will include: c.1 master data c.2 transactional data,

###Environments### TEXT

Methods of Creating Data

TEXT

Development Data Creation

TEXT

QA Data Creation

TEXT

User Acceptance Testing Data Creation

TEXT

Data Masking and Test Data

TEXT

Marrying Data Masking and Specific Use Cases

TEXT

Creating Test Data via Automated Tools

TEXT

Creating Test Data via Data Masking

TEXT