Enterprise Level Deployment of Delphix Integration, Resource and System Dependencies
Note: This is the 14th in our series of Enterprise Deployment of Delphix. Read the first 13 posts here -
Data Integration Points
Really the only way to know the integrations points of the Delphix Virtual Copy Data Management (VCDM) platform is to know the data flow of the components in scope. It is not necessary to detail at the message and packet level; but it is important to provide a visual representation of the data stopping and starting points that consume the data for processing and for what processing purpose. Identifying these processing points will help us define when the Delphix Virtualization systems will interact with other systems for automatons, masking, sourcing, virtualization and provisioning. Delphix would have provided a Customer Data Inventory sheet that provides staring points for collecting this information. There is a tab for collecting database information, such as the database name, the parent source database, applications that connect to the database, the host name, masking activity, expected growth rate and database environment usage (QA, Dev, etc).
The Database Inventory
It is important to grab as much information as possible to accurately identify the database landscape that will be transitioned onto the virtual data platform. Much of this work would have been completed during the impact analysis phase, but it is a good time here to reemphasize its importance. Below is a sample of the In Scope Database inventory sheet for review.
The Application (Unstructured Files) Inventory
Very similar to the Database information capture any application that will be virtualized must also be inventoried in a much similar way. When Delphix virtualizes an application it is acutally virtualizing the filesystems that contains the binaries. Delphix will refer to this functionality as Unstructured Filesystem Virtualization. The biggest difference in copy data management in the SDLC world is that with applications the parent source tends to be pushed from lower systems on up to a production layer and not pulled from a production environment and overlaid on lower systems.
Masked Files Inventory
The last information to grab is the files that will be masked to ensure consistency among the DB loads. These files should have been identified during the masking requirements phase. Many of the files will be coming from external sources with "live data" that your ETL team will load into your non-production system to validate load routines. Or files from B2B partners that may move through an enterprise service bus and the transition and load is automated. Identifying the location point these files are picked up from the service bus will provide the information needed to mask before the pickup process.
In all cases, there will be a technical owner of the systems, whether it is a DBA, or an application administrator or the Integration services engineer that will identify and control the information for the project. These SME professionals will most likely be the contact for the transition process as well. You may consider adding the SME to these documents as well.
Systems Component Dependencies
It is important to create the data flow diagram for each system as defined by the company. For instance this company differentiates between Core member care, core claims processing and provider management. Your company may treat them slightly different. The company's system architect will know how these systems are categorized. This diagram will help determine system components that may be impacted by the change. Since the Physcial to virtual database transition will simply replace 1:1 in my project the systems that connect to the downstream databases such as desktop components or load balancers, and etc. will not need to change, any connectivity strings but will need to be notified when the transition occurs since this will require a bounce of the databases.
Once the customer data inventory and the data flow diagrams complete, you will have the high level visual representation of the architecture accompanied by the system detail needed for sizing the Delphix HW and SW needed and a project well on its way to transitioning to a Secure Delphix Data Platform. The three diagrams shown provide icons where Delphix masking and Delphix Virtualization will be used on my Blog Healthcare company within the QA Landscape environment. If the company maintains a landscape environment for QA, UAT, DEV, SIT, Training, Demo etc you would want the data flow diagram for each landscape.
Next Installment Post - Sizing the Delphix System Software and Hosting Hardware needs.
Join me next time as I talk about sizing the Virtualization and Masking Engines and step you though managing a typical HW/SW procurement process.