Autonomy is essential for any solution which different organizations use to exchange information in a structured way. This article shows some of the concepts of setting up a synchronization.
Configuration models
There are 2 configuration models to set up a synchronization: centralized or distributed.
Centralized configuration
The centralized configuration is a synchronization setup where all mapping, filtering and transformationhappens in a single location. The decision how this synchronization should behave is implemented in a single, centralized point.
Distributed configuration
The distributed configuration is the setup where all mapping, filtering and transformation is done at endpoints. The common data model ensures that every endpoint determines how shared information is transformed to the local context.
Requirements
When 2 independent organizations want to exchange information in a structured way, some constraints need to be taken into account.
Requirement | Description |
|---|---|
| Access Security | As an administrator, you have a lot of responsibilities. In many cases, thousands of users are using the tracker to manage their day-to-day tasks. The last thing you want is that you have to provide access to your own system to some third party administrator. |
| Information Security | An issue tracker carries a lot of information which is IP-sensitive. You don’t want to leak out the details of your next major feature, do you? So, only fine-grained information can be exchanged. |
| Change management | Configurations evolve as the organization evolves. One week, your workflow may include 4 steps to track the status of an issue, while the other week, you’re going need to expand this with 2 additional statuses to track the delivery into production. When your tracker is connected with 5 other trackers (each with their own configuration), you want to be sure that you have the freedom to change your own configuration without the need to negotiate it with your counterparts. |
| Upgrades | Software evolution happens all the time. In some cases, software gets exchanged with some completely different systems. It is important that these major changes are possible without breaking any existing agreements with the other systems. |
Requirement | Centralized | Distributed |
|---|---|---|
| Access Security |  An admin needs access on the whole system |  Each admin configures the interaction locally, not having to access the remote system |
| Information Security | All information is exchanged between the two systems. A central configuration defines what information is actually used in the synchronization | Each admin defines what information is sent over the wire. |
| Change management | A centrally defined synchronization relation requires cooperation with the counterparty to agree on how this configuration can be changed | Each admin defines what information is exchanged and how it is being applied locally. If the configuration changes, the admin can make sure that the information sent to the other side still complies to the agreed interfaces. |
| Upgrades | Every upgrade needs to be checked with all counterparts. | Each site can upgrade their environment ‘at will’ |
Conclusion
Autonomy is extremely important. You don’t want an issue sync solution where each local change requires an interaction with other parties. As the number of connected issue trackers increases, autonomy will ensure that every individual site can evolve its configuration without having to negotiate it with counterparts.