Differences between SharePoint as an intranet platform and SharePoint as a collaboration platform

I spoke about SharePoint to an audience of intranet managers yesterday. The talk was at J Boye’s ‘SharePoint at work’ event in Copenhagen.

I made the following points:
• SharePoint is not the first platform that an organisation could use both for their intranet and for their general collaboration/document management environment. But it is the first platform to be market leader in both spheres.

• Managing a collaboration/document management environment is a different ball game from managing an intranet environment.

• The scale is different. In an intranet environment you can expect a sub-section of the organisation to contribute a small amount of content on a monthly basis. In a collaboration/document management environment you may reach the point where most of the organisation are contributing on a daily basis.

• The risks are different. In the collaboration/document management environment there will be material with sensitivites (personal/commercial/political). Such material is not typically contributed to intranets.

• The difference between the functionality of SharePoint when used for an intranet and the functionality of SharePoint when used for collaboration is paper thin. In either case you store content within SharePoint site collections. If you intend a site collection to be used for the intranet then you use the publishing site template to create the top level site of the site collection. If you intend a site collection to be used for collaboration you create the top level site with a different template (for example a team site template).

• Organisations typically put site collections intended for the intranet in a separate web application to those used for collaboration, with a separate URL address, different branding and different administrators and administration settings.

• There is no licensing difference between SharePoint Server 2010 used for an intranet and SharePoint Server 2010 used for collaboration/document management. Where an IT department have purchased SharePoint Server 2010 licences (for example as part of an enterprise agreement with Microsoft) it is hard for either intranet managers or records managers to explain why they want to buy and use a different system

• There may well be synergies to be derived from having both intranet and document management happen in the same environment, but realising these synergies is not easy. An organisation might identify valuable type of information (for example research reports), define a content type for it and then surface such material from the collaboration environment onto the intranet.

• If an organisation wants to use content types to leverage and make the most of valuable types of information then it becomes very important to control their content types. There is a tendency for content types, like everything else in SharePoint, to sprawl. Content types can be created in any site by any site owner, and be available not just in that site but in all sites underneath it. The more content types you have the less chance there is of a team choosing appropriate content type(s) for their document libraries.

• Your records manager may want to use content types to apply retention rules and/or to route documents to a records centre. If so they will want to apply content types to large aggregations of documents (record series such as ‘refurbishment project records’ ‘client case file records’ ‘consultation records’ etc.) rather than to individual document types (‘project initiation documents’ ‘research reports’ ‘meeting minutes’ etc.)

• There is no way of using content types for both record series aggregations and for document types (because a document can only belong to one content type at a time).

Question from the audience about document sets
I was asked whether ‘document sets’ (a new kind of content type available within SharePoint 2010) could be used to aggregate different content types. I said that although document sets do aggregate content types, I did not think they would not work for records management purposes.

Document sets were intended by Microsoft for use with compound documents (such as ‘health and safety manuals’).

In theory document set content types could allow a records manager to:
• define a document set content type for a record series (for example ‘refurbishment projects’)
• enable content types to be used within instances of that document set (for example ‘architectural drawings’ ‘contracts’ ‘contractual correspondence’ ‘meeting minutes’).

The problem is that if a colleague uploads a document to a ‘refurbishment project’ document set and gives it the content type ‘meeting minutes’ then it would take its retention rule from the information management policy defined for the ‘meeting minute’ content type and not from the policy defined for the ‘refurbishment project’ document set content type.

Facilitated discussion on SharePoint governance
Earlier in the day I had the pleasure of facilitating a round table discussion about SharePoint governance. Two intranet managers told me that their organisations had decided to apply strong governance arrangements in the site collections used for their SharePoint intranet, but to be much less controlled in the collaboration environment, where team sites would be given to local teams on demand.

We talked in the group about the ‘Pontius Pilate’ attitude to SharePoint of some IT departments who treated SharePoint as though it was a tool set. They provide team sites on demand, and when it grows out of control they say it is the fault of the business for not governing it properly.

Someone else in the group said that the trouble with governance is that at first it doesn’t seem like a big issue, you have a system that you want people to use, there are not many users yet, and there is not much content yet. Later on, when the system has grown and evolved you realise the need for governance, but trying to put governance in place is much more difficult (like locking the stable door after the horse has bolted).

I said that governance in SharePoint is primarily about taking away powers (for example the power of site owners to create sub sites, and the power of site owners to create content types). There is a resource implication to taking away those powers. You need to give people a quick way of obtaining new sites and new content types where appropriate. And that means having people in place who have the ability to judge whether or not the new site or content type is necessary and appropriate. If requests for new sites/content types are granted on demand then you have not added any value.

Thoughts on the Department for Education’s SharePoint implementation

On 16 February this year I heard Mark Field describe his implementation of SharePoint for collaboration and records management within the UK Department for Education (DfE). Mark’s talk was at a records management update seminar run by Unicom.

Mark’s implementation has the potential to be extremely influential.   It currently has a userbase of 3,000 people within the Department.  DfE are planning to offer their SharePoint facility as a service via the cloud – firstly to the UK education sector, and later to the wider public sector via the Government Application Store on the G-Cloud.  There is currently no timescale as to when it will be available on G-Cloud (when pressed Mark said ‘hopefully within our lifetimes’).

DfE are using SharePoint team sites (rebranded as ‘Information workplaces’). They use the SharePoint records centre for records management, and have implemented SharePoint for their intranet.   They are currently using SharePoint 2007 but will move to SharePoint 2010 once they have transitioned their service to the cloud.

Governance controls

The Department has tight governance controls in place to control the spread of  SharePoint team sites.  Only their Information and records team can create team sites (information workplaces).   Each team site/workplace must have a ‘Workplace owner’ who signs an agreement acknowledging their responsibilities in managing the site.  They have 200 Information workplaces, which tend to be based around a particular work matter or policy issue.

Records management

Regular ‘sweeps’ are undertaken of team sites to suck documents needed as records, and route them to the records centre.  The sweep captures documents that meet all of the following three criteria:

  • at least a year old
  • a major version (1.0, 2.0 etc)
  • checked in

When a document is routed to the records centre it leaves behind a link in the team site document library from which it came.

The Department has decided not to implement a functionally based fileplan. The record centre is structured to mirror the organisational structure.  Retention rules are linked to content types. The Department has limited itself to 11 content types.

There was a mixed reaction by the audience to the model adopted by DfE.  Some people (including ex `Information and Records Management Society Treasurer Alison North) praised its simplicity.   Others were concerned by the Department’s rejection of a functionally based fileplan in favour of the organisational structure.  The question was raised as to whether organisational churn would render the records centre difficult for future users to understand and navigate.

Mark defended the decision to use the organisational structure to organise the SharePoint records centre.  He said that all a searcher would need to know to find documentation is what the relevant organisational unit was called at the time of the document’s creation.

Replacement of the DfE’s Electronic Document and Records Management System (Meridio)

Mark’s lack of faith in a functional fileplan is based on his experience at a previous organisation, where users ‘ran a mile’ from a multi-level fileplan he had constructed with colleagues; and from DfE’s own experience with using a functional fileplan on a  traditional (TNA 2002 compliant) EDRMS system (Meridio).

Mark said Meridio had good functionality but it  was only adopted by 20 to 30% of the Department.   The  Department have ended their EDRMS implementation, and imported all records from Meridio into a SharePoint records centre (a separate records centre from the one that they are using to handle content generated in SharePoint).

DfE’s application of retention rules

The department are choosing to link retention rules to SharePoint content types, and to limit the number of content types to 11.  This is a radical example of the big bucket approach to implementing retention rules.   In most other implementations of ‘big bucket’ retention rules the organisations concerned have applied between 50 and 100 retention rules to their organisation’s information.  Applying only 11 retention categories seems  low to me.

One of the content types Mark mentioned was for human resource documents.  I presume that a ‘human resource’ content type would need to embrace (among other things) both:

  • all the documentation arising from recruitment campaigns
  • documentation of dealings with individual employees

Most organisations keep records of their dealings with individual employees for a considerably longer period than records of their recruitment campaign.

My assumptions as to the nature of the Department for Education’s SharePoint records centre

It is difficult for me to accurately picture Mark’s model without having seen screen shots.  My assumptions are that:

  • the records centre contains one document library for every organisational unit that has existed since the start of their SharePoint implementation. Each library contains all the documents routed to the records centre that originated from colleagues attached to that unit
  • when organisational churn occurs a new records centre document library would be created to accommodate records routed from that organisational unit (although it might be a year before any documents arrive to fill it!)
  • when documents move from a team site to the records centre they bring with them important contextual information such as the details of the pathway/breadcrumb trail in which they had been stored ( team site/document library/folder/sub folder)
  • a visitor to the records centre would be able to sort each document library by any column of metadata, including which of the 11 content types a document belong to, and which team site it came from.

Does the records centre add value?

The big challenge for any implementation of the SharePoint  records centre is the question what value does the record centre add?   What value does it add to have documents moved from one logical structure (Team sites, arranged by policy issue or matter) to a different logical structure (A records centre arranged by organisational unit)?

Is there any reason why anyone would prefer to look at the records centre rather than the original team site? (I can’t think of one).  All the time that he original team sites are maintained that is not a problem.  But how long will the Department retain its  team sites?

I suspect that the Department for Education’s intention would be to apply a shorter retention period to the SharePoint team sites than to the contents in the records centre.  Once the original team sites are deleted you are left only with the content of the records centre, kept in a different arrangement to that known by the people who worked with the documents at the time that the work was carried out.

Take the example of a document library within a team site set up for three different organisational units to collaborate around policy on special need provision in schools.   How easy would it be for a searcher to virtually reconstitute the contents of that team site document library once the contents have been sent to different records centre libraries and after the original team site has been deleted? Does it matter that other information held in the team site, but not captured in a document library, will not have been sent to the records centre?

Practical reasons for moving records from team sites to the SharePoint records centre

Later in the same Unicom event Sharon Richardson talked about the difference in storage capacity of a site collection containing collaborative team sites, and a records centre:

  • Microsoft recommends that site collections containing collaborative team sites are not allowed to grow about 100GB (which Sharon estimates is only 200,000 documents). The constraint is due to the impact of a large site collection on other site collections held on the same SQL Server content database
  • A records centre can be allowed to grow much larger provided that its’ content is stored in a dedicated SQL Server content database which contains no other site collections

The records centre can mitigate problems caused by the quirks of SharePoint’s site collection architecture – but I am still not sure that this counts as adding value!