Enterprise Level Deployment of Delphix Defining the System Conversion Plan

Hi Again!  In today's post I discuss defining the system conversion plan. To me this is the meat and potatoes of the entire process. As I have mentioned in past blogs, converting from a physical copy data management to a virtual copy data management is as simple as it sounds. However, there is a point in this exchange that involves planning for the conversion. And that is the part I want to talk about today.  If you are new to Delphix technology, please go to https://www.delphix.com or just search for Delphix online. Also I do plan on a webinar to help explain these blogs as I know reading can be tedious. I will let you know when those happen.

To catch up, please see my previous blog for the Enterprise level Deployment of Delphix.

You have Delphix Now What | Delphix Goals and Objectives | The Solution Design - Part1 | The Solution Design Part 2 | The Solution Design - The Transition Process

The Solution Design - Add Masking | The High Level Time Line | The Requirements Analysis | Impact Analysis | The Budget Analysis

Defining the Conversion Plan

Deliverying system environments for IT projects, mergers and acquisitions, and hosting services onboarding and a myriad of other purposes has been my lifeblood for over 25 years. So I may ramble on and on. The conversion plan I speak of here is the aspect of swapping out the physical database and applications with a virtual database and application. Then returning the resources that were dedicated to the physical counterparts. This is where the return on investment becomes apparent.

You want to engage the various IT teams to help you build the conversion plan. Certainly the DBAs and Application delivery team needs to be involved. But some application development teams have a step-by-step assurance process they work though to validate a successful transition. Having them review the solution design and impact analysis will spark a need for them to participate. They may see areas of automation improvement and release delivery where they can add value to your final deployment design.

Walk them the transition plan data flow diagram. They are certain to find gaps that need to be filled based on their expert knowledge of their systems. You can then save as with that teams area or responsibility. Something like Physical to Virtual Transition Plan - Oracle E Business Suite, or Physical to Virtual Transition Plan - SAP, Physical to Virtual Transition Plan - SQL Server, and etc

The diagram below show the data flow and decision points for the transition process

RDBMS

The straight transition from a physical to virtual RDBMS is quite strait forward with Delphix. The physical to virtual migration process summary is needed to frame the high level overview of the migration efforts required by the Solution Architect, the Delphix administrator, Database Administrators and Data Security Teams. It also provides the management an idea of the level of effort required as they determine resource needs from their respective team.  In the diagrams shown the process boxes are annotated to indicate it is a process that will be executed from within the Delphix technology.

Applications (vFiles)

Here is where my approach to VCDM may differ from my colleagues and that is that I believe the application vFile dSource will start from a non-production staging location and pushed forward through the SDLC environments rather than pulled down from a production deployment.  The vFiles can be an application as complex as and multi file system SAP environment or s simple as custom Web application hosted by Apache. I believe this because in the deployment of an application environment should come from a core set or dry installation of the OEM files. What I mean by dry installation is a location that has the minimum amount of configuration changes required to run. This allows the operations team a documented starting point where a before and after image of configuration edit points for ease of automated deployment methods.  There may be a future need to provision from a dSource ingested from a production environment, but I would expect that would be more in line with break-fix analysis of a production related issue more so the from a standard SDLC promotion process. Since the source vFiles will be coming from a dry installation location there will be no sensitive data lurking about the file systems so the masking and selective data distribution process decision point is unnecessary. So keeping true to those two VCDMS deployment tactics of mine, the swim lane diagram provides the transition process I use for a physical application to virtual application or vFile migration process.

Defining the LOE resources needed for each application stack transitioned

The diagrams above provide the synopsis of action to be taken to swap the physical to virtual instances. But the team responsible for the development, delivery and Service Level Agreements (SLA) depending on these systems will have validation checks, access checks and automation steps to integrate with these systems to perform.  They will want their staffing Level of Effort  (LOE) identified and considered during the transition phase. It is imperative to capture the time required from these teams The impact analysis previously discussed with have given the manager a heads up and the manager can provide the detail LOE, the resources name to perform the work and whether or not the work will be performed by the Full Time Employees (FTE) or Augmented with Consultants.  The costs associated to the LOE should be recorded in both the budgeting process and the project plan as the resource and completions time.

The graphic below shows a sample tracking method for an Accounts Receivable application and App Development teams that may have stake in the transition process. Using an excel tool like this will help you address full commitment from each team and then help build a budget and project plan for the LOE.

Next Installment Post - Creating the Implementation and rollout plan

This ends the blog for today. We have finished the Pre-Planning and Solutioning phase of our project. Next we work through the process creating an implementation plan.