Enterprise Level Deployment of Delphix Solution Design – High Level Timeline

The week I will discuss the high level timeline for transitioning the fictional healthcare company's non-production database and application environments from physical copies to virtual copies using Delphix VCDM.

Jeannine Crownover

Sep 13, 2016

Hi Again!  In today's post I will continue my discussion of my building a Solutions Designs for an enterprise level deployment of Delphix Virtual Data systems in our fictitious healthcare company. If you are new to Delphix technology, please go to https://www.delphix.com or just search for Delphix online.

To bring you up to speed from the last post - The Solution Design, we walked through the first 6 subjects of the Table of Contents. The week I will discuss the high level timeline for transitioning the fictional healthcare company's non-production database and application environments from physical copies to virtual copies using Delphix VCDM. Please refer to my previous blogs for Enterprise Level Deployment of Delphix listed here in order...

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 Solution Design Document

We have already moved through the first 6 chapters of the solution Design. Let's look at chapter 7 - the High Level Timeline.  Defining a high level timeline for an infrastructure implementation project not only requires first hand experience in infrastructure implementation projects but also an understanding of the time involved in similar projects within the company's recent history. Depending on the nature of the project, it may take the experience of an entire team, to properly define a time line.

Solution Design Document

Table of Contents

1.0     Project Background.............................................................................................        6

2.0     Technology Descriptions.....................................................................................        8

3.0     Theory of Operations.............................................................................................       19

4.0     Next Practices (What Changes with Delphix)....................................................          25

5.0     Migration Process.................................................................................................       36

6.0     Masking Solution.................................................................................................        52

7.0     High Level Timeline..............................................................................................        71

7.1    Deliverables Timeline...........................................................................................         71

7.2    System Deployment Timeline...............................................................................        72

High Level Timeline

The high level time line I am defining here is specific to the project scope of this blog. This is not a timeline that can be paired down to just any Delphix implementation. All enterprise level projects intersect with conflicting budgets and operational and resource commitments. Many times there are other project dependencies as well as unforeseen blockers such as a divestiture or merger that may not be known at the beginning of the project nor during an impact analysis of integrated system. My point here is please understand this timeline provides you a view into a Delphix DevOps implementation project that worked for this company. The format of the high level timeline, the consideration discussion points and acceptance criteria may help you formulate an understanding of how to judge what timeline will work for your project.

I am breaking the timeline into two parts the deliverables timeline and the actual system implementation. The deliverables timeline is to address the project start to finish and the system deployment that focuses on the efforts surrounding the installation, configuration, acceptance and operational deployment of the VCDMS at this healthcare company.

Deliverables TimeLine

I placed the deliverable time line on a Calendar year for ease of reading since start to finish this is a yearlong project. As you see from this timeline I have also included the project phases I have discussed in previous blogs. These deliverable documents may or may not be required in your implementation but I highly recommend these in some form for any infrastructure technology implementation. A lead architect should have most of these types of documents in a template library that can be modified or customized according to the technology implemented. I have been using documents like this since 1997 although they have matured and expanded based on my responsibilities over the years. I think I have a really good base library now and I don't mind sharing.

I think the timeline chart below provides a clean overview of the documents. Just keep in mind things like requirements analysis, system development, readiness certification & test and detail design documents iterate throughout the project. So a detail design document may be 1 document and associated to 1 database or application. Or may cover the API Automation Task separately from a performance and monitoring system API integration. Or could be 1 mega document with each system called out in a Table of Content entry. Again these documents are best handled by the company implementing the project and should be based on their standard implementation procedures.

System Deployment TimeLine

The system deployment timeline follows the 5 months of system deployment on the deliverable timeline.  Remember this is for the solution design document only. A detail project plan will be created and shared in a future blog. These times were defined during the initialization and rollout project plan development.  If you have ever been a project or work stream manager you will know these timelines need to be thorooghly vetted and appriopriate resouces and dates added during in a project plan deliverabl.  A focused project manager will strive to keep the project on track and moving forward based on this promised timeline. A determined work stream manager will properly define the timeline his or her team's tasks will take based on all the other commitments the team is facing.   Ideally the project manager will hold regular meetings  or just reach out to the work stream managers to monitor the projects progress.

As you can see from the chart below this implementation will happen in 4 stages. The first will be the installation of the Delphix VCDM Engine & Masking Engine, and a 1 system transitioned within 1 month. I like this stage because within this month the project team is motivated and eager to get started and momentum is high. After 1 month with one system successfully transitioned, the work streams and operational support teams have a deeper understanding of the task they will be faced with through the project rollout.

In stage 2, I have included the detail training of staff. At this point of there is an OEM or GSI engineer supporting the install of the Delphix systems they will most likely be responsible for training the staff in the features and functions of Delphix VCDM and Masking. Stage 2 allows the teams to integrate the transitioned systems into the ITIL systems,  the monitoring systems and provides the ability to change the transition process of any incorrect assumptions. I also feel this is a good time to move all the in scope systems into the Delphix VCDM as a dSource.

Having a system setup as a dSource  early on in the project does not hinder the ongoing operations of the physical non-production copies. It just makes the rollout of the systems more agile in that if for some unforeseen delay in one system rollout another can be easily slotted since the dSource ingestion can be the most time consuming task is complete. Also having all systems ingested as dSources will most like close a story and be able to reported as a milestone complete. Now after 2 months the senior leaders and investors see lots of progress and 50% complete well on its way to fulfilling the promised return on investment.

Finally at stage 3, the project should be well understood and the teams slowing transitioning each system to meet the requirements identified in the planning phases of the project. Requirements identified s gaps should have a clear path to closure and the project manager should know that the project is on target for a successful completing in the time allotted.

The last stage is simply a wrap up  stage that allows for returning of physical assets and for  the project manager to hand of the Operations and Maintenance tasks the operations teams. The IT teams will understand their new roles, as defined mentioned in my second blog. The Delphix administrator and the Masking administrator will begin need to ensure the system they are responsible for are adequately sized and considered for any expansion or budgetary needs moving forward.

Just remember it is important during the Solution Design  development to have a deployment plan and high-level timeline include in the design document. This will allow other project teams to be aware of a concurrent project that may be competing with resources they are depending on for their project.

Next Installment Post - The requirments definition

This ends the blog for today. It looks like Solution Design Document is complete and ready to bring to the project managers office (PMO) for a Project Manager assignment. It is important to thoroughly review the project with the PM assigned and the PM direct Manager. Explain the concepts behind Delphix VCDMS and the pain points it will solve. This educational review with the PM will help the PMO prioritize the project and ensure they have the best resources and work streams teams helping you complete the implementation.

For now here is where we stand on the blog Chapters...