Decoupling ECM

As your enterprise content migrates from one repository vendor to another, you will feel the pain of not following decoupling standards that I’m sure were implemented but not fully. By “not fully” I mean in 2001 you tried an interoperable integration only to cancel it because the APIs were limited and the performance was slow. To add fuel to the fire, CMIS is being pushed on us and that means if you’ve been following standards of information architecture with metadata, linking from external sources, training application integration, workflow, taxonomy, and databases, you’ll be fine. However, who has been able and/or could afford to follow all of the best practices? Anyone?

Below is a list that starts to detail what needs to be looked at when thinking about decoupling and preparing for CMIS or a migration.

Metadata
Is the object model and attributes designed well? Are there issues with attribute that have one name, but are used for other functionality? Will system date attributes like creation date and modified date trigger any unexpected actions? For example, if you have a retention schedule based on creation date and you migrate your content (creating a new creation date), what’s the real creation date?

Intranet/Portal
Links from a website via a URL that points to content in the repository will most likely be broken during a migration. Portlet Integrations that use APIs to query content in the repository will have to be checked. Content that is published to a separate website will have couplings with attributes from the repository which will break.

Training
Links to content (SOPs) as training material that is triggered by changes in modification dates will have to be redesigned.

Taxonomy
Relationships of folder structures with attributes will have to be reviewed.

Web services
Any dependencies with attributes and content ids will be broken.

Database Integration
Redesign any dependence the integration with repository database has on system generated dates.