4.10. General deployment considerations

Rather than attempting to use IRM to meet the customer's operational goals immediately, that is, to use IRM in a production capacity, it is often useful to first set up an environment for evaluation, testing, or staging:

an evaluation environment is useful if the customer is deciding exactly how to make best use of IRM
a testing environment is useful if the customer wants to try out specific use cases, data scales, etc.
a staging environment is useful if the customer wants to have a separate system for planning purposes
(for example, developing a bill of materials for creation of a new datacenter or floor with its own wiring closet and "cube farm") vs. operational purposes such as administering an existing datacenter.
the customer may wish to evaluate a new version of IRM without fully committing to a software update to the new version

There are different installation options for evaluation, testing, or staging IRM systems. These options are available whether IRM is licensed as a service or for on-premises installation.

Option 1: Single deployment, single Site

This is the simplest option and can be used if it meets customer requirements. However, Planet generally does not endorse this approach and it may not meet customer requirements in many cases (see disadvanges below).

Different data sets are created using different Areas and naming conventions.

Advantages:

minimal in terms of required hardware and IRM licensing
easiest to administer for on-premises deployments

Disadvantages:

Data sets are not actually separated from IRM's standpoint. Achieving "effective" separation depends on disciplined use of naming conventions and is therefore subject to user error.
Not suitable for testing different versions of IRM as only a single depolyment is available.
Not suitable for very large data sets as all IRM data exists on a single server.

Option 2: Single deployment, multiple Sites

This option still uses a single deployment of IRM but the separate environments use separate Sites. This option is moderate in terms of required hardware and IRM licensing. In SaaS terms, the customer has a single IRM account. In on-premises terms, there is a single Global Console container. In both cases, the users see a single Global Console.

Advantages:

Instance data is separated from IRM's standpoint, while Library data (Types) can be shared. In practice this is often the most convenient arrangement and the mode in which IRM is primarily designed to be used.
It is impossible for anyone using one Site for evaluation, testing, or staging to accidentally or intentionally cause issues with a separate Site used for production, as long as permissions are assigned appropriately.
Each Site can have its own server, the size/power of which can be chosen independently. Intensive work being done on one Site will not interfere with the performance of other Sites.

Disadvantages:

Additional hardware or cloud infrastructure costs required compared to the single deployment, single site option
Instance data cannot be directly shared across Sites (though it can be moved, if necessary, with some effort)
Not suitable for testing different versions of IRM as only a single deployment is available.

Option 3: Multiple IRM deployments

In this option, the customer has more than one completely separate deployment of IRM. In SaaS terms, the customer has more than one IRM account. In on-premises terms, there are multiple machines that are installed and maintained separately. In both cases, the users see separate Global Consoles for each deployment.

Both instance data and Library data are separated for each deployment, from IRM's standpoint, which has both advantages and disadvantages.

Advantages:

Completely separate environments that have separate Library data in addition to separate instance data. Logins to each system are separate, so that a user on one system does not have any access to the other system, unless explicitly granted.
Each deployment can run a different version of IRM, making this the only option for testing or evaluating a different version of IRM without disrupting a production deployment.
Each Site in each deployment can have its own server, the size/power of which can be chosen independently. Intensive work being done on one Site will not interfere with the performance of other Sites.

Disadvantages:

Most expensive in terms of both required hardware and IRM licensing
Most complex to administer from both an on-premises perspective (separate installations need to be maintained) and also from a general IRM perspective -- different users need to be created, permissions assigned, etc.
Data migration is still possible between the deployments, but is the least convenient of all.