I had a good conversation with an active TSG Blog reader this morning that I thought was worth sharing.  The topic was on how best to leverage an ECM strategy for a life sciences company that is moving away from their first ECM platform and trying to map out the strategy going forward.

Housing Development/Planned Community Analogy

In talking about an ECM strategy, we both thought a Housing Development/Planned Community project offered a good way to visualize the issues associated with an ECM strategy.  Say we have a new area we want to develop for housing, just like an ECM strategy it would need:

• Roads, Sewers, Power Lines…..for our ECM strategy, we talked about integration points with existing systems and new systems.
• Cost of Infrastructure – who pays for the roads/sewers?  Like ECM, the infrastructure has to be funded with the overall community in mind and not the first house paying an incredibly high cost that will be leveraged by subsequent home builders.
• Mixed Use – like a community, an ECM strategy has to embrace more than just a one size house fits all.  During our conversation, we talked about how an Alfresco solution would have to co-exist with SharePoint solutions.  Different users seeking different “houses” could pick from a variety of solutions based on business needs.

Collaboration and Records Management

We (Reader and I) couldn’t come up with a way to fit the difference between collaboration and records management into the analogy.  (Different types of Houses?)  Basically, in talking about SharePoint, email or other means, users will always have ways to work on documents that aren’t records.  Our biggest concern is not having users mistake a record or effective document with one that is still DRAFT and being worked on.   While we have mentioned this in previous posts we agreed that for a DRAFT document to become effective:

• The user had to identify it as needing to become a record
• The user would have to add all the taxonomy details (attributes/locations) that they avoided doing for non-records
• The document would have to be routed and approved in a record environment
• The document in the non-record environment would be locked/altered to make sure no one mistook it for a record
• The document in the record environment would be versioned and controlled going forward

Service Orientated Architecture – the heart of ECM integration strategy

We (TSG) have seen our financial services clients make the most progress in establishing a SOA infrastructure.  For multiple clients, we have seen construction of a service orientated architecture as one of the infrastructure steps.   Goals of an ECM SOA would include:

1. Provide a consistent access point for ECM integration
2. Speed the development of new solutions/integrations
3. Simplify upgrade and maintenance of ECM system components.
4. Isolate ECM details from non-ECM developers (ex: Application developers shouldn’t have to know DQL)
5. Isolate ECM from the application to allow the application to run on more than one ECM back-end.

For you Documentum developers, DFS, while an SOA, does not satisfy point 3, 4 or 5.  As with the housing development analogy, there are several ways to get there:

• Build It – many of our clients have constructed their own SOA architecture – some better than others.
• Buy It – there are commercial vendors that offer SOA solutions.    Wingspan is one that many evaluate particularly with SharePoint in mind.
• Wait for It – Content Management Interoperability Services (CMIS) is a “specification for interoperability between Enterprise Content Management Systems”.    Most of the major vendors are behind it.
• Borrow It – We (TSG) are partial towards of OpenContent our SOA Open Source layer for Alfresco and Documentum (possibly SharePoint in the future).  Feel free to download and leverage for your efforts as appropriate.

What are TSG’s thoughts about CMIS?

In a nutshell,

• Great idea – we love the idea that we can develop applications that can talk to a variety of ECM platforms.  All of our solutions leverage OpenContent for that very reason
• But…..Been there, done that –  we have seen similar efforts from AIIM (anyone remember DMAPI?) that never reached their potential because:
  • Small Vendors – all over it looking to leverage consistency to get market share
  • Big Vendors – don’t really want to lose market share to small vendors.  Adoption was always stated but in reality only partial portions of the specification were ever developed (typically just retrieval).

 Choice Computing

Lastly we discussed the any ECM strategy should really consider that the PC is just one of the many ways users will want to access and store documents.  Some interesting points:

• Email – we agreed that email integration with desktop devices (Outlook for example) really doesn’t make much sense when the bulk of users are using their iPhone, BlackBerry, Android, iPad or web based email clients.  Check out our approach with OpenInterchange to only rely on the “Forward” button for Choice Computing.
• Clients – users wand iPads and other devices.  The SOA is the best way to allow for a variety of different interfaces all leveraging a consistent ECM backend and development framework.

Let us know your thoughts and comment below…..