Overview of Working Across Sites
For a Modeler client to work directly with a model on a Modeler server, ideally you want a connection that has a latency of less than one 1 millisecond. As the latency of a connection increases from 1 millisecond, the performance and responsiveness of the Modeler client decreases. When a connection cannot support direct editing of remote models, you should consider which of the available solutions works best for you.
The following table summarizes the solutions that are available for accessing remote models based on the strength of the connection you have between sites.
To perform cross-site working it is essential to clearly identify the responsibilities and ownership of all project data. The physical separation of team members creates an additional barrier to communication however, Modeler can be used to reinforce these responsibilities and ownership.
These are the preferred solutions that allow you to directly edit remote models:
This solution requires a high-bandwidth, low-latency connection between the Modeler client the server software.
This is the simplest solution, but will often not be possible across sites.
This solution can provide direct editing of remote models when the latency and bandwidth of the connection is not fast enough for an acceptable performance of Modeler, but is fast enough to support Microsoft Remote Desktop Services or Citrix MetaFrame.
These are the preferred solutions that allow you to edit remote models when the connection cannot support direct access of those models. These solutions import Packages from a remote model to a local model so that those Packages can be edited locally:
This solution requires an email or FTP connection.
This is the safest way of editing a remote model by importing the Packages from a sandbox of the remote model to a local model. The sandbox features of Modeler ensure that the changes you make to the local model are intelligently reconciled to the remote model.
This solution has the benefit of allowing items to be changed in both the remote and local models with any clashes being resolved at the time of reconciliation.
This solution requires an email or FTP connection.
This solution imports Packages from the remote model to a local model for editing, and then exports those Packages back to the remote model after the required changes have been made. While Packages in the remote model are being edited in a local model, those Packages must be protected in the remote model so that they cannot be changed by other users.
This solution has the disadvantage of the Packages being edited must be mostly self-contained in the remote model, so that when those Packages are protected they do not prevent further development of the remote model.
These are non-preferred solutions that allow you to edit remote models through a master model being stored in a CM tool or a shared folder:
This solution requires use of an external Configuration Management tool (CM tool) that is integrated with Modeler.
This solution stores the master version of a model (as Package export files) in a CM tool. The CM tool integration and CM tool features are used to provide access and change control to that model.
This solution requires a folder that all users can access, such as a network folder.
This solution stores the master version of a model (as Package export files) in a shared folder. This solution provides configuration management of a Model without the need to integrate Modeler with a configuration management tool. However, this solution needs to be carefully managed to ensure that different users do not edit the same Packages at the same time.