1,424 articles and 9,601 comments as of Friday, March 5th, 2010

Monday, March 1, 2010

8 Things SharePoint 2010 Needs to Be a True ECM System

Guest Author: Greg Clark
C3 Associates

Note: This article was originally published in August of 2009.

The hype cycle has started for the upcoming release of SharePoint 2010 and I’m certainly not the only one to get caught up in it.

I’m excited about anything that can help my clients better manage their information and I’ve always seen SharePoint as a potentially transformative platform bridging structured content, unstructured content and social computing in one flexible package. The current release of SharePoint does a decent job of this but in my opinion and the opinions of others (here and here) it has some shortcomings when it comes to its capabilities as a true Enterprise Content Management platform.

While this post is all about SharePoint as a technology, I want to be clear that technology is about the very last thing that should be considered when implementing ECM. It should start with a good business case, appropriate sponsorship, choosing the right areas of focus then building capacity within the organization to truly succeed with ECM. Technology is only the last piece of this puzzle. All of that said, there has been an incredible amount of interest in SharePoint and many of my clients have questions about where (or whether) this tool should fit into their ECM strategy.

For SharePoint 2010 to become the ECM category killer and truly threaten the market share of Open TextEMC DocumentumIBM FileNet and others, the new version should have the following eight things:

1. Persistent links.

I’ve told anyone who would listen over the past two years (and many people who wouldn’t…hi mom!) that the single biggest shortcoming of SharePoint 2007 is the inability to link directly to a unique object ID. One of the greatest benefits of ECM systems is the ability to send content via a link rather than relying on email attachments. In traditional ECM applications this isn’t a problem; each content object has its own unique ID that doesn’t change regardless of where it lives in the repository. In SharePoint links will break if you rename or move a file. The other benefit of persistent linking is that it enables the management of compound documents (a container that stores multiple documents like the chapters of a book) and the ability to link directly to an older version of a document. Rumor has it that SharePoint 2010 will include persistent linking and if it does the tool will have taken a big step forward.

2. Store once, use many.

SharePoint has a nasty habit of copying content throughout the system rather than using pointers to a single source of the truth (because content links might break as noted above). Yes, yes, I know that you can “Send to…Other Location” and link that new doc back to the original but this linkage is easy to break and experience tells me that the content falls out of synch very quickly. Perhaps the best example of the misguided use of “copy” capabilities in SharePoint is the “Send to…Records Center” feature where a copy of a document is sent to the Records Center while leaving the original in place rather than either moving the document and leaving a pointer or changing the state of the document to indicate its changed status (see the next point for more on the RM capabilities of SharePoint). The propagation of copies of documents throughout a repository is very bad mojo from an ECM and records management perspective and it is something that Microsoft must fix if SharePoint is going to replace traditional ECM applications.

3. Honest-to-goodness Records Management.

I recognize that that SharePoint 2007 is DoD 5015.2 certified but the statement from the product development team that the DoD 5015.2 components are “not intended for customers…who would like to enhance the records management functionality of MOSS 2007 with particular 5015.2 oriented features but are not required to run their system in a certified configuration” doesn’t exactly inspire confidence. Add to this the fact that SharePoint doesn’t allow users to manage physical objects out of the box and it is clear that Microsoft needs to decide if they are really serious about the records management space or if they will leave it to partners.

4. Better metadata management.

Metadata in SharePoint 2007 took a quantum leap forward with the introduction of Content Types. However, managing metadata in SharePoint 2007 can be difficult especially when dealing with multiple site collections. An ECM system should be able to easily manage relationships between data in the form of cascading attributes and parent-child relationships throughout the entire repository and should also support inheritance of metadata from the container level (eg. folder) to the content within that container. I’m hopeful that we’ll see improvements to the SharePoint Business Data Catalogue (BDC) that make this possible. The other option appears to be Microsoft’s Master Data Management tool (codenamed “Bulldog”) which is rumoured to be included in SharePoint 2010.

5. Reusable search templates and stored search results.

There is no question that search is a focus for Microsoft based on their acquisition of FAST and their push into public internet search with the recent launch of Bing. Search in SharePoint 2007 is reasonably good but the tool does not have the ability to either store a “snapshot” of search results for future reference nor does SharePoint 2007 allow users to create reusable search templates. This feature would save users time by allowing them to create a search query then either re-execute that query in the future or add new criteria without having to rebuild the entire search.

6. More granular security.

This is one area where SharePoint was already reasonably strong but truly deep ECM systems include advanced security features like the ability to deny permission to certain objects on an as-needed basis. The current process for managing security is a bit cumbersome but I expect this is something Microsoft is working on. It will be interesting to see if what changes, if any, make it into the final release of the product.

7. Surface the audit trail.

One of the things I like the best about established ECM applications is the ability to see who has opened my documents. I find this particularly handy on status report day when I inevitably discover that I’ve made a mistake in the document I’ve just sent out (as an unbreakable persistent link of course). I can check the audit trail to see if anyone has opened the document and if not, make my changes without anyone knowing I’d messed up in the first place. While SharePoint tracks most major audit events, the list of events is not as extensive as in a traditional ECM application nor is this information surfaced through the function menu of the content object.

8. More and more mature line-of-business integrations.

This should be a strength of SharePoint given the sizeable .NET developer community as well as the extensive Microsoft partner ecosystem, but SharePoint still has a lot of catching up to do in this area. Organizations deploying SharePoint won’t be able to hold a single vendor to account for a series of modules (or Content Enabled Vertical Applications, as Gartner likes to call them). This may or may not be a bad thing depending on your perspective but established ECM vendors have offerings that satisfy a variety of industry verticals and business functions. To achieve the same thing with SharePoint customers will need to research, purchase and deploy modules from a variety of Microsoft partners. CMS Watch offers a good summary of the issues associated with third party add-ons for SharePoint.

It will be interesting to see whether SharePoint 2010 includes some or all of these features. Microsoft has done a good job of capturing a new market without significantly eroding the market share of traditional ECM vendors; as SharePoint adoption has increased the overall market has grown and, as they say on Wall Street, “a rising tide floats all boats.” Whether Microsoft’s ship will sail away from the rest remains to be seen (as does my ability to stretch a bad metaphor) but they were clearly not able to do so with SharePoint 2007.

This article was originally posted on AIIM President John Mancini’s Digital Landfill blog which contains links to many other “8 things” articles. Some of the 8 things articles have been published as a series of free e-books, available at http://www.aiim.org/8things.

Guest Author: Greg Clark
C3 Associates

Greg Clark is from C3 Associates, located in Calgary, Alberta.  C3 exists to solve a problem faced by most organizations; how to take advantage of the vast amounts of content (documents, email, engineering drawings, web pages, presentations, photos, rich media files, etc.) generated every day in your organization. 

View all entries in this series: 8 Things»
Entries in this series:
  1. 8 Things You Need to Know about SharePoint Governance
  2. 8 Things SharePoint 2010 Needs to Be a True ECM System
 

Please Join the Discussion

2 Responses to “8 Things SharePoint 2010 Needs to Be a True ECM System”
  1. Larry says:

    Thanks for an honest article detailing (at least) 8 of the shortcomings of MO$$.

    The thing that always makes me chuckle is when they talk about their “market share”… just because there are that many copies of an application out there doesn’t mean they are ALL BEING USED. Keep in mind, MO$$ (the stripped version) came bundled with M$Office, so everyone that either bought Office, or bought a computer that was pre-configured with Winders and Office had a copy of it. To count those as “installations of a product” that may be sitting there and not used is a joke.

    MO$$ on its own is NOT an RM software application, at best, it’s a light version of a document management application, and even then it’s primary use is for managing items produced in Office. Users that decide to give it a try soon find out that the functionality they really need doesn’t exist in a native environment in the application and so free REALLY doesn’t end up being free after all. They get the “first taste free”, then they get so much data in the system and learn they need more juice to get the feeling they want, so they go back and buy more and more and more… this is the same model used by some street vendors trying to get people hooked on their products.

    To have any of the more robust features necessary to consider this an RMA requires the addition of modules, purchase of third-party software and/or add-ons from M$ ‘trusted partners’ . One of the big dangers here though is as M$ patches or upgrades, the potential exists for linkages to these third party programs to break, and this is NOT uncommon. It’s typical for the primary system developer to make changes and fail to consider linkages established by others in the open market building tools to work with the software… and in MANY cases, it’s these tools that make MO$$ work for organizations.

    What never ceases to amaze me though is how many of the TRUE RM Application developers (you guys KNOW who you are!) can’t wait to develop modules to allow their products to work with MO$$. I have to assume it’s because of this perceived ‘market share’, and the intent must be to show users that once they buy a REAL RMA, there’s no need to or value in continuing to use MO$$, as an ingestion tool or user interface or anything else. But you can bet M$ will still count these copies as part of their market share, after all, they’re out there, right?

Trackbacks

Check out what others are saying about this post...
  1. [...] are arguments to exclude programs or include SaaS solutions under the CMS umbrella.  There are polemics about some mainstream systems like [...]




Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!