Autonomy is essential for any solution which different organizations use to exchange information in a structured way. This article shows some concepts of setting up 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 transformation happen in a single location. The decision on 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 are done at endpoints. The common data model ensures that every endpoint determines how shared information is transformed into 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 that 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 to need to expand this with 2 additional statuses to track the delivery into production. When your tracker is connected to 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 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 to 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 with the agreed interfaces. |
| Upgrades | Every upgrade needs to be checked with all counterparts. | Each site can upgrade its environment ‘at will’ |
Conclusion
Autonomy is extremely important. You don’t want an issue sync solution where each local change requires 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.