Integrations Defined
Some kind of coupling that doesn't rely on manual intervention.
Characteristics:
- We're most interested in integrations that are generalizable and shareable. Strictly speaking, we're not interested in purely local integrations.
- A plugin can be an integration, shuttling data between different sources can be an integration, and changes to the data model in various ways are integrations.
- We're looking for minimal manual intervention to qualify as an integration. That is, integrations do not have a manual step through, even if that step through is automated. For example, a script that, at a given interval, checks to see what Resources have been updated in ArchivesSpace, and automates the export of MARC records to a watch folder that an ILS checks periodically and uses to import and overlay existing MARC records, while involving separate systems, is not an integration.
Tiers:
To be determined, but the lowest might be a plugin that sits on top of the data model without changing it and the highest would be like Yale's container management work that requires changes to the data model and migration of data already in the system.
Roles of the Integrations Sub-team
Mission Statement
The Integrations subteam supports the ArchivesSpace community by taking a transparent approach to documenting the integration of systems with the ArchivesSpace application. We facilitate this by:
Tracking current integrations and communicating their progress
Creating resources that assist members of the ArchivesSpace community with their integration work
Liaising between those developing integrations, the ArchivesSpace Program Team and the ArchivesSpace community
- For specific integrations, determining scope, writing specifications and testing implementations