2.1 Activity Summary
|
Activity Description |
Use understanding of existing Discovery Center Project Suite instance configuration and data elements to plan deployment of ActiveNav Cloud |
|
Goals |
Plan in place for deployment of ActiveNav Cloud Business Units , Credentials, Collectors, Data Sources and Custom Rules |
|
Participants |
Project Sponsor, IT team, Project / Program Manager |
|
Pre-requisites |
|
|
Outputs |
1. Business Units 2. Users 3. Collector Groups and Collectors Hosts 4. Data Sources 5. Credentials 6. Custom Feature Definitions 7. Custom Scoring Definitions |
Activities
This Activity is the step to take the findings from the Discovery Center Project Suite report Custom Queries and apply them in the planning of the ActiveNav Cloud deployment. Depending on the scope of the project and the breadth and complexity of Discovery Center Project Suite usage it may make sense to work through this step iteratively to allow for a phased migration of components to ActiveNav Cloud. In any case it is important to understand the nature of the Data Governance project and the goals of the use case being enacted prior to any ActiveNav Cloud planning activity, as the specific details will likely inform which components require migration and the relative priority of each.
2.2 Identify Appropriate ActiveNav Cloud Use Case and Migration Strategy
There are a number of Information Governance use cases that ActiveNav Cloud may be used to address. It is important that the nature of the project ActiveNav Cloud is being used for is well understood prior to planning any migration from the Discovery Center Project Suite application. The Project Sponsor, IT Team, and Project Manager, if one is in place, should all have a consistent view of the goals of the project at this point and should therefore be able to determine a strategy for the migration of components from Discovery Center Project Suite to ActiveNav Cloud.
Broadly this strategy will relate to the Use Case being addressed, the current state of configuration and volume under management with Discovery Center Project Suite, as well as the readiness and appetite for change across different business functions of proposed ActiveNav Cloud users.
It is recommended that Business Unit configuration, and the users within each Business Unit that will be responsible for review of data within the ActiveNav Cloud application, are an initial consideration here. The reason for this is that the set-up of Business Units will inform the need for Collectors and Collector Groups, along with Data Sources and Credentials needed to drive data discovery for each Business Unit.
Alongside the Business Units themselves the range of data repositories that relate to each Business Unit should be a consideration when planning a migration strategy. The larger the number of repository types being targeted within a Business Unit, the greater the number of Credential and Data Source components required within ActiveNav Cloud for that Business Unit is. For File Share locations the number of Collector deployments required increases in line with the number of host servers being targeted.
It is therefore recommended that as a first step in any migration a small target Business Unit is identified, if possible, with a relatively small number of different repositories, ideally only using File System locations on a common host. If this is not possible then a larger logical Business Unit may be identified, but only a small portion of the data source locations that make it up need to be migrated initially – ActiveNav Cloud allows for Business Units to be built up over time with the addition of data sources as and when discoveries have occurred for them, so doing this allows for some validation of the process to take place before an entire Business Unit has been migrated.
From that point on it is up to the project team to determine what migration strategy best suits their needs to continue to migrate components from Discovery Center Project Suite to ActiveNav Cloud. The steps outlined here can be followed and repeated as often as needed until all components have been migrated. As the Custom Queries run in the previous activity give a snapshot report of the Discovery Center Project Suite instance’s state at a particular point in time though, consideration should be given to whether they need to be re-run as further phases of migration are planned and undertaken. It is possible the queries will need to be re-run as part of each phased migration step, to ensure any change to volume under management or configuration within the Discovery Center Project Suite data is reflected in planning activities.
Example
Alexander Knight has deployed and run the Custom Queries in the Prest Team Discovery Center Project Suite instance and has taken the results into a discussion with Victoria Black to plan their migration to ActiveNav Cloud. They have determined that the Data Clean-up use case is the one that aligns most with their project goals, though they also have some Sensitive Data Compliance aims. Their initial interpretation of the query results has suggested that their Business Units align closely with the Areas of Interest in place in Discovery Center Project Suite, with the addition of a further Business Unit for the IT file share location being required in ActiveNav Cloud.
They have decided that it makes sense to initially look to migrate the IT Business Unit in isolation, as that represents the simplest migration case and requires no input or ActiveNav Cloud training from users in the wider organization. They will then look to migrate components that relate to each of the Sales and Finance and Operations Business Units in a phased approach after that, before ultimately removing their Discovery Center Project Suite application and the virtual machine host it runs on altogether.
Note – in this case Prest only have a single Discovery Center Project Suite instance so only interpret the Custom Query results from that single implementation as part of this planning process. Customers that have multiple Discovery Center Project Suite instances would need to consider the consolidated result set from Custom Queries run against all instances to aid their decision in this step.
2.3 Map Discovery Center Project Suite Elements to plans for ActiveNav Cloud
This activity is where the specific plans for the deployment of ActiveNav Cloud components are created, based on the results from the Custom Queries and understanding of any Discovery Center Project Suite implementations. In this section we will consider each of the ActiveNav Cloud components in turn, in the order that makes most sense for planning purposes and assess how the results of the Custom Queries should be interpreted to inform ActiveNav Cloud deployment.
It should be noted that while the order of components here makes the most sense from a planning perspective, it doesn’t necessarily follow that this is the same order that components should be deployed to ActiveNav Cloud. The idea here is to come up with a complete migration plan for all components up-front. This plan can then be used in conjunction with one of the other ActiveNav Cloud Playbooks to walk through the process of ActiveNav Cloud deployment.
2.3.1 Overview
The following table provides a high-level view of the components in ActiveNav Cloud to be planned, along with which of the Custom Query results should be used to inform the planning and the specific Discovery Center Project Suite elements to consider in making those plans. The subsequent portions of this section provide further detail and explanation on what to consider when making plans for each of these components.
|
ActiveNav Cloud Components |
Custom Queries |
Discovery Center Project Suite Components |
|
Business Units |
Area of Interest Summary Report Area of Interest Detail Report Index Report Location Report
|
Areas of Interest Network Locations Indexes |
|
Users |
Users Report |
Users |
|
Collectors and Collector Groups |
Location Report |
Servers |
|
Data Sources |
Index Report Location Report |
Indexes Servers |
|
Credentials |
Credentials Report |
Credentials |
|
Custom Feature and Scoring Definitions |
Calculated Field Report |
Extraction Rules Calculated Fields |
2.3.2 Business Units
As noted previously Business Units are a fundamental component within ActiveNav Cloud. They provide the means to segregate data within the application to allow for targeted reporting and review, allowing users with Business Unit expertise to focus only on the data they have specific knowledge of.
When considering how Business Units should be planned, thought should be given to whether splitting data according to business function, repository type, physical location, or some other means makes most sense for the project goals and proposed user group of the application.
Planning of Business Units should also consider target locations that are not under management in any Discovery Center Project Suite instance at this point – there may be additional repository types and locations that will be managed using ActiveNav Cloud in the future that inform the best way to segregate the data estate as a whole.
It is possible to edit Business Units at any point in ActiveNav Cloud though, so any planning decisions made here can be revised later as necessary, but planning these components up-front based on current understanding of project goals and known target locations should aid with the migration process and ultimate project success.
In terms of the results from the Discovery Center Project Suite Custom Queries, if any Areas of Interest are in place in the Discovery Center Project Suite instances these are a good place to start, as they already represent a segregated view of data under management that may align well with the ActiveNav Cloud Business Unit concept. There are two query results that provide Areas of Interest information, these being the 'Area of Interest Summary Report' and the 'Area of Interest Details Report'. Depending on the number of Areas of Interest and the makeup of each in terms of locations they include either of these query results may be helpful when planning Business Unit setup.
Alongside Areas of Interest the top-level 'Location Report' results may provide a simple way of determining a split in locations under management in Discovery Center Project Suite, which could inform location groupings to determine Business Units.
Finally, the 'Index Report' provides details of which locations are configured as index start locations within Discovery Center Project Suite instances, again this represents a form of segregation already in place in Discovery Center Project Suite, so may be useful to consider when planning for ActiveNav Cloud Business Units.
Example
As noted previously, the existence of Areas of Interest in the Prest Discovery Center Project Suite instance for each of the Finance, Sales and Operations business functions aligns well with the Business Unit component in ActiveNav Cloud. Considering the goals of the project Prest team have defined, Alexander and Victoria determined that mapping the 'Sales' Area of Interest directly to an ActiveNav Cloud Business Unit makes sense, with Maxine Steele being identified as the Business Unit owner for it. Beyond that they decided that a further Business Unit named 'Finance and Operational Data' should be planned to combine the data scoped within the 'Finance' and 'Operations' Areas of Interest, with Anastasia Romano holding responsibility for data in those locations. Finally they determined that they should also include an 'IT' Business Unit that mapped solely to the IT file share, and that this should be the starting point for their migration process . They also agreed that they would look to create further Business Units in future as their MS Teams sites, Exchange mailboxes and further locations were included in the scope of the ActiveNav Cloud data catalogue.
2.3.3 Users
With Business Unit planning complete the next consideration is the users that need access to ActiveNav Cloud. There is no direct correlation between the user roles in the Discovery Center Project Suite application and those available in ActiveNav Cloud, but there is some general overlap in functionality for different roles which may be useful when considering user and role requirements for the ActiveNav Cloud deployment. The alignment of users to Business Units may also be important in this planning, as users with the ActiveNav Cloud 'Analyst' role will have data presented from a Business Unit centric position in the application.
For this activity the 'User Report' Custom Query results should be assessed to provide a simple breakdown of each of the users in the Discovery Center Project Suite instance and the roles they hold in the application. Users with either the 'AN Administrator' or 'System Administrator' role in Discovery Center Project Suite should be considered for the 'Administrator' role in ActiveNav Cloud, while the 'Information Manager' or 'Reviewer' role in Discovery Center Project Suite aligns more closely with the 'Analyst' role in ActiveNav Cloud.
Example
As Alexander Knight is the sole Prest user of Discovery Center Project Suite the results of the Custom Query are not required for this planning activity. As Alexander will be the ActiveNav Cloud Administrative user and will also be the custodian of data within the 'IT' Business Unit, initially there is only a requirement for his own account to exist in ActiveNav Cloud, being granted both the 'Administrator' and 'Analyst' roles. In future he will then be able to add further users in the 'Analyst' role for each of the Business Unit areas as and when the data in those Business Units is catalogued in the application.
2.3.4 Collectors and Collector Groups
There are two types of Collector used in ActiveNav Cloud, these being Cloud Collectors and On-Premise Collectors. The Cloud Collectors are hosted by ActiveNav and are used for operations relating to any cloud-based repository and need no management within the ActiveNav Cloud application. On-Premise Collectors must be downloaded and installed onto local servers prior to use in ActiveNav Cloud. Each On-Premise Collector must be associated with a Collector Group as part of the installation process.
When considering migration of components from Discovery Center Project Suite it is a simple case that any File System data under management will require an On-Premise Collector to be installed somewhere with access to it to allow discovery in ActiveNav Cloud. Collector Groups can be considered as a way of logically grouping deployed Collectors together for ease of management in the ActiveNav Cloud application.
In terms of the Custom Queries used to report on Discovery Center Project Suite instance components the required On-Premise Collector deployments map directly to each of the top-level Windows Servers returned in the 'Location Report'. With this information it should also be possible to determine what Collector Groups will be required in ActiveNav Cloud to group On Premise Collectors together.
Example
The 'Location Report' Custom Query indicates that there are four Windows Server locations which include data under management in the Prest Discovery Center Project Suite instance: 'KS-NAS-01', 'KS-NAS-02', 'RBT-543' and 'RBT-231'. There is therefore a need for an On-Premise Windows File Share Collector to be installed on each of those servers for use with ActiveNav Cloud. As the Windows Servers are grouped into two data centers, Alexander decides that two Collector Groups should also be created, one for each of the data centers, with each group then containing the two relevant Collectors.
2.3.5 Data Sources
The concept of a Data Source in ActiveNav Cloud maps to an index in Discovery Center Project Suite. Each Data Source represents a location to use as the root of a Discovery or Feature Extraction process, though beyond this choice and which credentials to use for the operation there are no other configuration options required when creating a Data Source in ActiveNav Cloud.
In terms of mapping from Discovery Center Project Suite components it therefore makes sense to use indexes as the basis for Data Source locations in ActiveNav Cloud. The 'Index Report' Custom Query results can again be used in this case to map Index start locations in Discovery Center Project Suite to Data Sources in ActiveNav Cloud.
It is also the case that ActiveNav Cloud allows for child locations to be used as Data Sources where a parent container is already defined as a Data Source, similar to the way in which Discovery Center Project Suite allows for child or overlapping indexes. However, as ActiveNav Cloud does not allow different configurations of Data Sources, beyond the choice between Discovery or Feature Extraction and the choice of credentials to use, there may be less benefit in this setup for ActiveNav Cloud Data Sources than is the case in Discovery Center Project Suite.
One benefit that may be common to the configuration of index start locations and Data Source locations is the use of individual indexes / Data Sources for children of a common parent location to split operations based on the volume of data being processed in a single operation. As with Discovery Center Project Suite the time taken for all containers objects within a Data Source to be discovered or have feature extraction performed will vary based on the total amount and complexity of data within the whole Data Source hierarchy, along with factors relating to networking and hardware provision of the host infrastructure. It is therefore difficult to determine exactly how long a Data Source operation may take to complete, but as with Discovery Center Project Suite Project Suite it is suggested that smaller Data Sources are assessed initially to get an idea of likely timescales for larger Data Source locations before they are deployed. With that said it is also the case that performance of Discovery and Feature Extraction processes in ActiveNav Cloud is far superior to equivalent processes in Discovery Center Project Suite, so when planning the Data Source deployment in ActiveNav Cloud it may be the case that multiple Discovery Center Project Suite ‘child’ indexes could be combined as a single parent Data Source in ActiveNav Cloud without performance being an issue.
Example
The results of the 'Index Report' Custom Query show that there are seven indexes in place in the Prest Team Discovery Center Project Suite instance, five being applied at the root of Windows file share locations, with a further two at the root of each of the two SharePoint Online sites under management. All seven of these indexes use the same index configuration to run file duplicate and content analysis on all discovered files.
As there is no complexity in this configuration in relation to child or overlapping indexes, and as all indexes include analysis Alexander determines that there is a simple one-to-one map of these indexes to Data Sources in ActiveNav Cloud, with each Data Source needing to be a Feature Extraction type.
2.3.6 Credentials
In ActiveNav Cloud it is necessary for a Credential to be in place for each Data Source to make use of. When a new Data Source is created its top-level server location is recognized as a Host within ActiveNav Cloud, and any Credential that is assigned for the Data Source will apply to the Host by default, and as with Discovery Center Project Suite it will then inherit down to any other new Data Sources created for the same Host. It is also possible to override this inheritance by assigning a specific credential at any Data Source level if required.
With planning for the implementation of Data Sources in ActiveNav Cloud complete the credential requirements for each Data Source should be straightforward. Where Data Sources have been mapped from Discovery Center Project Suite indexes then the Credential requirements for the Data Sources should simply reflect the use of Credentials for each of the Index locations in Discovery Center Project Suite, so a basic mapping of credentials can be planned.
However, some consideration should be given to whether accounts being used in Credentials within Discovery Center Project Suite should necessarily be re-used for a similar purpose in ActiveNav Cloud. Depending on the nature of the work being performed with Discovery Center Project Suite the accounts used in these Credentials may have been granted specific permissions in the locations they are mapped to in order to fulfil their role within the application. The nature of ActiveNav Cloud operations differs from those in Discovery Center Project Suite so care should be taken when mapping Credentials to ensure any security requirements are met in relation to local policies regarding permission levels etc. Likewise, depending on the nature of the migration process it may add complexity to make use of the same user account for Credentials in both Discovery Center Project Suite and ActiveNav Cloud applications at the same time, particularly if there are different permission requirements for the use in each product.
There is also a slight variation in the types of credentials that are available in each application, while both make use of basic username and password types, ActiveNav Cloud does not support the use of certificate type credentials, instead using Azure app registration details for SharePoint Online only. While it may be the case that credentials used in Discovery Center Project Suite also make use of an Azure registered app, our recommendation is to not make use of the same app registration for the two products. While this would again be possible in theory, the two applications have different permission requirements of the Azure registered app, and it is generally considered good practice to keep Azure app registrations isolated to a single purpose. This approach also makes the decommissioning of Discovery Center Project Suite a simpler task that can be carried out without any interference to the function of ActiveNav Cloud.
With these considerations in mind the results of the 'Credentials Report' Custom Query run on Discovery Center Project Suite may give an idea of the number and nature of Credentials that are required in the ActiveNav Cloud implementation, but it may not be appropriate to simply re-use the same accounts when creating the migration mapping plan. The query itself will return a list of all Credential records in use in Discovery Center Project Suite, including the type of Credential and the Network Map location(s) each is applied to. If the Credential includes a username, then that is also returned in the results, but no password values will be included.
Example
From the results of the 'Credentials Report' Custom Query Alexander Knight can see that there are two Username and Password credentials with the usernames 'svc_DCApp_KS' and 'svc_DCApp_RBT' respectively in use in Discovery Center Project Suite. Each is applied to two Network Locations in the application, these being the roots of the four Windows File Servers across the 'KS' and 'RBT' data centers. There is also an Azure App Certificate credential in use in Discovery Center Project Suite that is applied to the root Prest SharePoint Online tenant location.
Alexander determines that three Credential records will also need to be created in ActiveNav Cloud, to follow the pattern of assignment to Hosts as is the case for the Discovery Center Project Suite credentials. However, Alexander and Victoria agree that new Windows service accounts should be set up for use in ActiveNav Cloud, distinct from those used in Discovery Center Project Suite, to allow for their permissions to be scoped appropriately, and to tie their use to the ActiveNav Cloud application only. Likewise, a new Azure App Registration will be required for use in an ActiveNav Cloud Azure AD credential type, again allowing for correct scoping of permissions. This approach will therefore allow the Discovery Center Project Suite specific Windows Service accounts and Azure registered app to be removed at the point they are no longer used in the Discovery Center Project Suite application during its decommissioning process.
2.3.7 Custom Feature and Scoring Configuration
In ActiveNav Cloud there is a single universal set of rules that are used to find content within objects in all Feature Extraction processes, named Feature Definitions. There is a default Feature Definition set that is deployed with each ActiveNav Cloud tenant, but it is possible for them to be customized as required to meet individual customer requirements. Likewise, there is a single default Scoring Configuration that is used in all deployments initially, which may also be customized. The Scoring Configuration is related to the Feature Definitions and determines how the results of Feature Extraction processes are calculated and served up through application UI.
In terms of the mapping of elements from Discovery Center Project Suite the Feature Definitions align with the Extraction Rule and Calculated Fields used within Discovery Center Project Suite Index Definitions. There is no equivalent of the Discovery Center Project Suite Classification concept in ActiveNav Cloud, but the needs fulfilled by the default Classifications in Discovery Center Project Suite are built-in to the reporting interface in ActiveNav Cloud to allow for categorization, filtering and sorting of results directly, without the need for any custom reporting.
At the lowest level there is an equivalence between Discovery Center Project Suite Keyword type Extraction Rules and Keyword type Feature definitions in ActiveNav Cloud. There is also a straightforward map between a Content Pattern Match type Extraction rule in Discovery Center Project Suite and a Pattern type Feature definition in ActiveNav Cloud. Where Extraction Rules are grouped and combined in Calculated Fields in Discovery Center Project Suite, multiple Feature definitions may also be combined into a single Feature in ActiveNav Cloud. In ActiveNav Cloud this combination can either be as an 'All', 'Any' or 'Proximity' filter within a Feature, with the 'Proximity' type being the equivalent of a 'Proximity Matching Rules' field type in Discovery Center Project Suite and the 'Any' type mapping to an 'Any Matching Rule' Calculated field type. There is no direct mapping of a Discovery Center Project Suite 'Best Matching Rule' Calculated Field type to an ActiveNav Cloud Feature type, and as the name suggest the 'All' type in Cloud requires all included feature definitions to record a hit for a result to be captured during Feature Extraction.
Despite the mapping of these types providing some equivalence between the two products there is some nuance and complexity around the way Features and Scoring Configurations are defined in ActiveNav Cloud. For this reason, we wouldn’t recommend any update to these definitions in an ActiveNav Cloud instance without either the assistance of ActiveNav or a user with a very firm understanding of how the Feature Extraction and Scoring processes work.
In terms of migration this step is about understanding where there are custom Extraction Rule and Calculation Field definitions in use in Discovery Center Project Suite, but also whether there is a need to migrate them to ActiveNav Cloud at all. The default Feature and Scoring configurations used in ActiveNav Cloud provide a broad range of Feature Definitions which have been designed to target and report on particular content in support of the set of the specific Use Case, regional and industry dependent criteria of importance to each individual customer. Because of this there may already be Feature and Scoring definitions in place to help you achieve a certain goal in ActiveNav Cloud without the need for migration of custom Extraction Rule definitions from ActiveNav Cloud. If you have specific rules defined that are not covered by the default Feature and Scoring configuration within your tenant though, there is a mapping to ActiveNav Cloud custom Feature and Scoring implementations for each of them, but again we would suggest planning for this is done in conjunction with ActiveNav where possible.
Example
Alexander Knight has taken the results of the 'Calculated Field Report' Custom Query into discussions with ActiveNav’s Professional Services team to help plan for Feature and Scoring Definition requirements in ActiveNav Cloud. They have been able to determine that most of the custom Calculated Fields in use in Discovery Center Project Suite already have representation in the Feature and Scoring model in place in Prest’s ActiveNav Cloud tenant. They have also identified some 'Pattern Match' type Extraction Rules that are used to identify Prest and RBTSkills customer account numbers, based on their formats. These are used in Discovery Center Project Suite 'Proximity Calculated Fields', alongside custom 'Keyword Extraction Rules', to specifically target files that contain any customer account number details.
The ActiveNav Professional Services team have indicated that they will be able to map those Extraction Rules and Calculated Fields to Feature Definitions with Proximity Fields within ActiveNav Cloud, along with a custom Scoring definition to report the results with. They have taken action to make these changes and deploy them to the Prest ActiveNav Cloud tenant without any further input needed from Alexander or anyone else within the Prest organization. Once the changes were deployed, they were used in all subsequent Feature Extraction processes and Feature Score results in the application’s UI reflected that.
2.4 Follow ActiveNav Playbook specific to project Use Case
Once the plan for migration from Discovery Center Project Suite to ActiveNav Cloud has been determined the process of deployment and use of ActiveNav Cloud can proceed to address the business goals of the Information Governance project. ActiveNav have created separate Playbooks to help guide customers through the process of ActiveNav Cloud deployment and use for each different Use Case, so at this point the correct playbook identified in step 2.2 should be referred to and followed to establish the complete project process.
The migration strategy and plan determined in the previous steps should be incorporated into that process to establish the use of ActiveNav Cloud in place of Discovery Center Project Suite as appropriate. As noted previously, this migration can be conducted over whatever timeframe is most suitable for the project in progress, and a phased approach should certainly be considered for larger or more complex Discovery Center Project Suite implementations.