Enterprise Level Deployment of Delphix Impact/Change Propagation Analysis

Hi Again!  In today's post I discuss conducting a solution impact analysis. Some of you may call this change propagation analysis because in a sense I am evaluating what systems and process will change with the implementation of Delphix Virtual Copy Data Management. 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 posts we completed the sections describing the requirements definition phase. This week I will walk you through the steps of impact analysis. The impact analysis is critical for the project manager to frame out project timelines, identify technical resources, estimate budget requirements, and competing

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

Why an Impact Analysis

An impact analysis looks beyond the broader system level aspect of the solution and on to the detail component integration level. An impact analysis is critical in that the results of the analysis will provide the detail of the systems and processes in scope, will identify competing or dependent projects, will ready the staff resource for the project at hand, and most important to the Delphix Engine is that the results will provide the key information necessary for sizing the engine's hardware needs.

I generally start my impact analysis by first reviewing the solution design.  In most cases, as the lead systems architect, I authored the solution design in such a way that the document addresses the processes and systems involved.  A well-defined solution design makes the data gathering aspect of the impact analysis very succinct.  As I outline the component detail of the impact analysis, I begin interviewing the department leads for their input on the systems and processes under their purview.  In most cases, the department leads have had a heads up on the project already because, they have been in involved in the requirements gathering, or the development of the solution design document itself. They should also be aware of the goals and objectives of the Delphix implementation project so they refer back to these goals as they design their systems and processes to make the transition to secure Virtual Copy Data Management (VCDM).  I have listed here my standard requests of the department leads:

1. Can you provide me a detail inventory of your systems or process responsibilities

2. Can you provide me a high-level LOE for this work

3. What resources are you assigning to this project

4. Do you have technical or staffing resource constraints that prevent you from completing the project in the estimated timeframe

5. What if any additional training do you foresee your team needing

6. What other projects or time constraints that you are aware of impact these systems

7. Did you identified gaps during the requirements definition and if so which gaps

8. What do you need from me to help you understand these requests

If you recall from my blog Delphix Goals and Objectives, I defined two categories of goals and objectives: a set for Infrastructure and a set for Processes. The next two topics address analyzing the impact of these two categories,

Infrastructure System Inventory

In terms of the detail inventory of system, databases and application, you will have received during the presales interviews with Delphix engineers, a 'Customer Inventory Sheet". This sheet was most likely filled out during the presales work for initial sizing estimates. It is a spreadsheet that includes fields for systems identification, use and resource capacity, sensitivity masking needs, and copy data management needs. Gathering the inventory detail is crucial for several things. One, during the project rollout the inventory sheet can be used as input for tracking task completion at each item. Second, the sheet can provide information that identifies the gaps missed in the initial requirements gathering. Third, it is used for sizing the storage and server resource needs for the Delphix Masking and Virtualization engines.

As you, the system implementer or technical architect, begin compiling the results of the inventory sheet into your tracking document, review the Integrated Functional Components Diagram. The review will guide you to the system managers responsible for the component. The managers will be able to begin the detail collection of host names, database names, application and operational run book information, LOE for their teams contributions, staff resources, change control processes. The Customer inventory sheet you collected from the Delphix website will guide the managers on what is important to collect from the Delphix sizing needs and then certainly include other items necessary to allow you proper tracking and definition of the project plan resources and implementation tasks.

The inventory sheet includes such fields as database name, RDBMS platform, RDBMS Version, Server name and server OS versions among other critical data elements that must be reviewed. It is important to know the databases RDBMS platform to ensure it is compatible with Delphix Software, same is true for the RDBMS version and OS platform and OS version. I discuss database and OS compatible products in the The Solution Design - The Transition Process blog.

Process System Inventory

Very similar to the infrastructure inventory is the process inventory.  Processes are sure to be impacted by introducing Delphix and these processes need to be identified as such. In my The Solution Design - Part1, and The solution Design Part 2 blogs I provided swim diagram that gave an example of what vDB provisioning process could look like with Delphix VCDM and how a masking process may look like. It is important to identify processes that will change with Delphix.  The solution design documents should have called out the process components and potential impact the Delphix implementation will have them. Now it is important to define the critical nature of the changes and where in the implementation and operational plans these changes will occur.

For instance there will be a security impact in that the Delphix management software will have user access needs and these user access needs must be reviewed for compliance and role definition. The impact analysis will indicate if these roles are a prerequisite to any downstream project tasks so when the project plan is developed the dependency can be tagged.  In other words, there will be a Delphix OS service account with specific server level privileges that needs to be present on the souse and target servers in order for the Delphix engine to connect and "see" those servers. Likewise a Delphix database user that must be created on source databases in order for the Delphix software to ingest the initial backup needed to provision the virtual databases. The process of verifying that these users exist before any attempt to provision is something new to a database provision process. That did not exist before the Delphix software was introduced into the operational flows. Or better yet the users and project managers requesting new non-production databases will now have an option of virtual or physical database requests. If the request if for a new virtual database the architects will now need to see if there is a dSource that can service the vDB or must they grab that initial database synch first. Now if there is a service request approval process that accompanies a new DB request that process will likely change to include these new decision points and handoff flows.

Competing Projects

Most companies I have worked on have several projects running at the same time. This means that the components critical to the Delphix implementation may be undergoing a change with some other project.  For instance maybe the company is swapping out its Enterprise Service Bus Software and many of the jobs and tasks integrate with databases, the very databases that your project will be virtualizing. Keeping track of the key deliverables and timeframes of that project will help you understand the impact the change has on your Delphix implementation project. Similarly if, the database team is in the middle of a DB upgrade project, then it is important to know how to work within the changes there. The DBAs may want to leverage the agility of Delphix and request the two projects find a way to complement each other tasks timeline. Or maybe the company is in the middle of implementing a security review of roles and service accounts and there is a moratorium on new user accounts unless a specific authorization is obtained and presented, that would be something to track as a risk and consider as an important impact to note especially since Delphix will require new service accounts to be installed.  I can provide a number of examples, but I think you get the idea.

Next Installment Post - We finish the Pre-Planning and Solutioning of our Delphix Implementation

This ends the blog for today. It looks like we are very close to finishing the Pre-Planning and Solutioning phase of our project. Once we review the Budget process and the Systems conversion review then we will have enough information to engage the project team and get them working on their tasks.