I am perpetually in search of a good topic for “this week” and was intrigued by James Lappin’s post on the AIIM ERM Community Blog this week. Lappin said he taking the time to “look at SharePoint 2010 with a skeptical and questioning eye”. Overall, his article offered many important insights into SharePoint RM and presented a well informed perspective. But, it took SharePoint 2010 records management to task in some areas that we think are strengths of the product. So here is my response to Lappin’s post based on what we are seeing in our implementations of SharePoint 2010 for enterprise content and records management.
SharePoint 2010 Records Management (RM) Model
Lappin states in his post that he is concerned about the “lack of a clear records management model” in SharePoint 2010. From our experience, Microsoft has provided multiple mechanisms to support RM in different organizations. His article identified these, including in place RM, content types, folders, record centers, etc. Microsoft shouldn’t necessarily be expected to take the same software development approach that others have taken when they prescribed a single model for RM. The bottom line is that Microsoft has provided a platform to create multiple “best practice” models that, together, leverage a SharePoint 2010 environment to enable enterprise RM.
His post indicates that SharePoint 2010 offers too much flexibility in its records management models, because clients must make choices between various approaches to RM. An example of this flexibility is applying retention on the folder versus on the content type. We believe that the SharePoint RM model is a core strength of the product. For example, it could be beneficial to apply an Information Management Policy (IMP) on a content type but override that IMP in the records center to apply the record retention IMP at the folder level. The jury is still out if this is a best practice, but it works well in some client scenarios we have evaluated.
File Plans and Content Types
Another area Lappin has concerns is that SharePoint 2010 “requires you to use content types”. We believe that the primary alternative to enforcing information policy based on content types in SharePoint is to train an entire organization to classify information within a records category model and that this is equally or even more burdensome. It is correct that content types require some overhead for configuration and maintenance. However, in our experience, content types are a requisite layer of abstraction and translation that is required to achieve user adoption. We have seen the content type model work in companies with tens of thousands of SharePoint sites, and we believe it is a foundation capability of SharePoint 2010 that enables the achievement of enterprise RM in large organizations. It takes a lot of up front planning, and may be best implemented at a version changeover of SharePoint (e.g. 2007 to 2010), but it works at the scale of a global company in ways that have rarely been achieved with more traditional vendors of RM software. We agree that a lot of separate elements need to be integrated to implement a file plan in SharePoint 2010.
Routing Rules
Lappin is concerned about the “administrative overhead of maintaining all the routing rules”. We have found that routing rules and their management are only as complex as they are designed to be. Routing rules by default are stored in a list in a SharePoint site collection. Routing rules consume and are based on content types. Routing rules are stored in a significantly different structure and are not part of any hub/subscription service. Simplifying routing rules and their maintenance has been a goal on several of our projects.
Managed Metadata
Lappin identifies several issues with using the SharePoint 2010 managed metadata service. While the Managed Metadata Service (MMS) is an example of a hierarchical taxonomy structure, similar to a file plan, there is no reason to consider the MMS as a repository for the file plan because of the inherent limitations in its structure, capabilities and performance. The MMS wasn’t intended to be used to maintain the file plan or Microsoft would have added additional properties for each term node. The bigger issue with the MMS, and the closely related content type hub, is we are using the first version of Microsoft’s implementation of the MMS. We are finding significant limitations and some use cases that don’t seem to have been considered by Microsoft. We’re still identifying these limitations and working on ways to avoid them.
In Place Records Management
We agree with Lappin that “in place records management” is of questionable value as the sole strategy for RM, and not only for the reasons he identified. We are concerned with hosting records in “temporary sites”. Even if those sites exist for a relatively long time, say for a long-lived project, there are issues related to moving those records to a permanent location when the site has been deleted or the project ends. In place RM is valuable in other use cases within the context of an overall RM strategy and should not be abandoned as an alternative.
Certification
Lappin acknowledges that Microsoft has been innovative in SharePoint 2010 RM, but he is concerned that Microsoft is not obtaining RM certifications for SharePoint 2010. Our understanding is that the Microsoft rationale for not certifying SharePoint RM was that they sell their products in so many jurisdictions that the SharePoint features that enable the certifications in specific jurisdictions are overlapping and conflicting. They chose in SharePoint 2010 to leave certifications to specialists in each jurisdiction who would build and enable the SharePoint features to achieve required certifications. We agree that certification is important, but also believe that Microsoft’s approach is valid and provides opportunities for Microsoft’s vendor partners and solution providers to fill this gap on a jurisdiction by jurisdiction basis.
Dual Repositories
Given the issues Lappin discusses, the implicit alternative to SharePoint 2010 RM in Lappin’s article is third party repositories of record such as those found in the traditional ECM suites. This is important because (almost) everyone accepts that RM is a requirement, so if the records aren’t managed in SharePoint, then where should they be stored? There are lots of current articles on the benefits of third party records repositories instead of the RM capabilities of SharePoint 2010. It is important to note that using a separate records repository has issues compared to the SharePoint 2010-pure RM approach. First, two repositories cost more than one. There are no SharePoint licensing costs saved by using an external repository of record because SharePoint RM is part of the Standard Client Access License (CAL). Depending on the vendor, the external repository of record may cost dramatically more than the SharePoint licenses.
Second, if the external records repository has its own file plan and retention schedule, this must be carefully integrated with the management of content types and information policies within SharePoint. Our experience is that it takes lots of development effort to coordinate these repositories successfully. I will explore the relative strengths and weaknesses of using a separate repository of record versus using a SharePoint 2010-pure RM approach in a separate blog posting.
Records Center in SharePoint 2010
Lappin states that there is “no guarantee that the records in the records center will be useful”. We emphatically believe that with careful planning and the implementation of best practices for SharePoint 2010 RM, records management within SharePoint 2010 will achieve a dual purpose: Compliance and a Trusted Source of Information. While we agree with many of Lappin’s points and can understand some of his caution related to the use of SharePoint 2010, the article seems more negative on SharePoint than it deserves. Careful organizations will recognize these limitations and implement best practices for SharePoint 2010 to achieve their enterprise RM objectives.
#ElectronicRecordsManagement