Joseph, one of your engineers, would like to share a set of draft design documents with a team of four external contractors with whom he has worked with in the past, when email was used to send revisions back and forth.  With email there was some confusion and delay as different versions of the document were referred to.  Each time someone made their change, everyone on the design team was emailed a copy. Now the documents live on your secure SharePoint intranet, but should you open that site to external parties? What is your next step?

This type of issue is faced by many different types of employees, anyone who collaborates on documents with others outside their organization, mainly lawyers, engineers, marketers, sales people, consultants, buyers, and accountants, people we generally term knowledge workers or information workers.

I came across this blog post by Mauro Cardarelli, a Boston-based consultant who writes about designing a SharePoint extranet:

“When I design an extranet with a new team, the first discussion session I lead is on defining a security model.  Here’s why:

Design Session Objective:

•  Define the collection of unique user types (e.g. Client, Executive, Project Manager, Team Member)
• Create a matrix of business functions and allowed participants (i.e. only Project Managers can update content)
• Create a framework for the site taxonomy (i.e. each Client has a landing page and underlying project sites) and map defined user types to the respective security for each site type
• Document any exceptions to the rules above

Design Session Outcomes:

• Well-formed security model with a complete list of user types and associated permissions
• Framework for overall extranet navigation
• Framework for content associated with the various site types based on who can update specific content
• List of exceptions

Design Session Next Steps:

•   Validation of security rules and taxonomy with business users, sponsors and IT
• Actionable plan for IT to start building the appropriate authentication model (e.g. AD users and groups; DMZ-based AD domain)
• Follow-on discussions on the next design stages: Site Templates, Navigation, Working wih External Data Sources, Dealing with the Exceptions, Customization… and, ultimately, the creation of a design document and associated project plan.”

This is a sound, perfectly valid approach to building a SharePoint, or for that matter any platform, extranet.

Now let’s say instead of sending those documents, Joseph would like to have a conference call with the four external contractors where he will read the content of the same documents, they will discuss its contents for several hours and Joseph will use their input to create a new draft.  Would Mr Cardarelli recommend first a meeting with Joseph to define a security model with all of the above steps?   Why not?  Would Joseph’s IT department consider their telephone system to be any more secure than their intranet?  What about IT’s view towards the individuals who need to collaborate?  Do they think that Joseph and his contractors are more trustworthy on the phone than on their computers?  What about IT’s attitude towards the data? Just because the information is stored in documents and documents are data and data security is the realm of the IT department, are documents deemed to have more value? Do they merit a more stringent security policy than a telephone conversation that may impart more meaning than the written word?

As an employee, Joseph has the trust of the organization and no one department is the arbiter of who Joseph can or cannot trust.  The onus is on Joseph to ensure that whomever he collaborates with externally is trustworthy, irrespective of the collaborative medium.  Developing a security model just because documents need to be shared is akin to building a car when a journey needs to be taken.  There are Microsoft tools that Joseph can now use without having to build things from scratch.  The first is the External Collaboration Toolkit for SharePoint (ECTS) from Microsoft, and a second is Microsoft Office Groove 2007.  But there is also Google Docs (not terribly secure), Basecamp and now Microsoft’s  Live Mesh  which, for the moment, Microsoft seems to be pitching at a consumer market for synchronizing an individual’s files on multiple devices, yet it seems terribly useful for synchronizing files within teams.  Live Mesh should eclipse Office Live Workspace and, if it can offer presence, messaging and calendaring, would be a very interesting alternative to Groove.  Yesterday at Microsoft I saw how they are using SharePoint as the basis for managing their consulting engagements. Within their internal engagement site is a button that will spawn a Groove workspace to house the documents needed by those working on a project, then when the engagement is over, SharePoint shuts down the Groove workspace. 

This is how Microsoft positions its alternatives.  Live Mesh, still in early beta, is not included.

The terms “precise access controls” and “data control” must be explained.  Precise access controls and data control mean that the IT department has precise control or at least a view over who has access to what information and what is done with data.  That is not the same as precise security.  It puts the onus on the IT department to keep a handle on the trustworthiness of external individuals.  That centralization of responsibility is counter to how organizations work.   Joseph would not normally ask permission from the IT department to have a telephone conversation with an external vendor.   By IT shouldering most of the data security responsibility, an organization is vulnerable because data is concentrated and because there are communication delays and breakdowns where there is a human security “switchboard” maintaining a directory of individuals.   By devolving security responsibility to reflect the way employees need to work with external parties and by embedding always on security features into the tools, such as in Groove, an organization can gain higher control and security of information

An article in Microsoft’s TechNet Magazine post Katrina on Louisiana State University’s Emergency Operations Center, highlighted some deficiencies in ordinary IT during crises.  First, you can’t depend on vast bandwidth or even any bandwidth at all in an emergency.  Second, your constituency can increase dramatically.  One day you’re managing the IT needs of staff, the next, you have to deal with external agencies, contractors or volunteers; people that aren’t in your directory or who can be provisioned quickly and easily. 

That’s where Groove comes in.  Once files are downloaded in a Groove “workspace”,  information to be shared with others, only the changes are exchanged.  Work can continue off-line, and when one goes back on-line, documents are synchronized.    For cross agency or inter company working, it’s like manna.  No files attached to emails, and all the versioning problems those entail.  No server to set up.   Everyone has their own synchronized copy of the information on laptops.   For keeping business continuity plans up to date, ensuring they are distributed and always available, or for sharing project information in a distributed team, it has a lot going for it.