For most modern Digital Asset Management solutions in larger organisations, integration with other systems is a common requirement. In some situations, enterprises may find it necessary to integrate two different DAM applications that fulfil different functions (e.g. a video archive with an image or document library).
There are also other scenarios where integration is essential, for example where a decision has been made to offer some of the organisation’s assets to third parties, either through e-commerce websites or channel partner portals. In these cases, integration between a public and internal system (even if developed by the same vendor) is essential because of the security risks of opening up the internal system.
In our experience, providing all parties are willing to cooperate and there is a free exchange of information, this can be a very effective method of rapidly leveraging the skills and expertise of each service provider. We have found the following to be useful best practice principles for successful integration projects:
- Agree the integration protocols as early as possible – preferably before implementation work on at least one of the systems starts.
- Use standardised and supported interoperability protocols that fit the use case of the assets. In some sectors there is agreement already, for example, the SPECTRUM object definition protocol used by museums. This is less common in commercial sectors, but research carried out into what is already being used can potentially save weeks or months of time in developing new, untested protocols.
- Ensure that all applications support modern ‘on demand’ techniques such as SOA (Services Oriented Architecture) via web services and XML.
- Check that the flavour of web services both systems use are compatible with each other and test developer assumptions by getting them to do an initial smaller test exercise that uses a number of different kinds of data that you are likely to need to share.
- Avoid batch processing techniques (e.g. data loaders). These are ‘one shot’ attempts to exchange data and can cause data loss and failures. Although popular amongst system developers because they are easy to write initially, over the longer term, they are more failure prone and harder to maintain.
- Define a ‘header’ or ‘stub’ metadata standard that defines the base attributes of all assets (whether time-based or otherwise) and use this as the basis for integrating the two systems. This allows both systems to be developed independently but provides a fundamental basis for integration if the finer details have yet to be confirmed.
- Agree a high-level ‘discovery’ protocol about assets that will allow additional metadata not initially enumerated to be added without significant impact on interoperability. If an existing standard is used, this will often already be defined, however, the system developers of both DAMs will need to make sure that their application is compliant.
- Cache metadata that is will be slow to extract on-demand from the other system but ensure that there is communication between both to notify when an update has occurred so the data can be synchronised.
- For each integration operation or activity, always nominate one system to assume a master role to reduce the potential for confusion about which has responsibility. This should typically be the system that will write rather than read data (so it may vary from one task to another).
- If both systems write data in a single operation, split it into two discrete ones.
Document explicitly and precisely everything that will be required for each operation and make no assumptions about what data will be sent/received, the format, or type. - Plan for the range and types of data to change in the future.
- Build in fail-safe mechanisms to stop corrupt or incomplete data from disrupting either systems.
- Document the integration protocol not only for the initial development work but also for ongoing use so that new developers can quickly get up to speed with the integration process.
- Test the integration early, often, with both expected and unexpected data.
If the integration is in scope for the release of a new or replacement DAM system, build integration into the plans from the outset. See Digital Asset Management: Implementing A Strategy for more details.
The risks and rewards of Enterprise Application Integration (EAI) are considerable for Digital Asset Management systems. If not planned and executed with great care and attention to detail, they can result in systems becoming available and the need to restore data from backups just to get back to the original starting point. On the upside, the combination of two systems that have been refined and optimised for your organisation can provide a system that offers many more benefits than one alone.
As described, if digital assets are to be offered to external users via a public website, an integration project can generate revenue that will increase the top-line growth of the organisation. This option can be particularly beneficial for cultural institutions and can help to reduce their reliance on state funding, donations or other grants.
As well as functionality and features, integration can bring substantial bottom line benefits also. The cost of redeveloping a single application to fulfil a dual role can be expensive and risk prone. Both can be avoided or deferred by integrating a Digital Asset Management system with an existing solution. As with any IT solution, it is important that a proper assessment of the costs and benefits of either route is conducted before it is carried out.