SharePoint Governance Pain Point: Trying to Govern the Private Cloud

Greetings from Down Under, mates! The last two weeks have been a whirlwind.  TechEd 2011 in Gold Coast was a smashing success. Three thousand attendees made the most of the sessions, the labs, the expo, the parties (go carts and crazy games), and the opportunity to meet each other. AvePoint was a major sponsor, so I was in the middle of it all, and I must say the Microsoft team did a great job with the event!

I delivered a significantly revised version of my “Architecting Governance” workshop, which you’ll be able to see at the SharePoint Conference (live in Anaheim or online afterwards).  Last I checked, it was the top session of the SharePoint track, which of course makes me quite happy but more importantly speaks to the value of guidance that helps organizations actually implement governance and management, not just create a governance document. 

I spent every other hour at the event in meetings with Australian enterprises across every commercial, academic, and government vertical.  The following week, we pulled of what was in retrospect an insane feat: five days, five cities, more than 25 meetings (I lost count at 25) with large SharePoint customers, one of which had all 23 members of the SharePoint team.  In each of these meetings, I spent an hour in an intensive consulting environment, in which I learn about what the enterprise is trying to achieve with SharePoint, what obstacles they are facing, and what questions they have, and I work to answer as many as I can and (because of course I know far from everything about SharePoint) take copious notes with the goal of hooking them up with remaining answers in the coming weeks.

One of the themes that came out of these meetings was a series of pain points related to outsourced SharePoint services. I’m not talking about Office 365.  I’m talking about hiring an IT outsourcing company to manage the SharePoint environment for an enterprise—what is now starting to be called a “private cloud” and an outsourced private cloud more specifically. 

I came to identify exactly what the “rub” is, and it suggests a pain that is likely to strike us all as we move to any cloud: public, private, or outsourced.  Honestly, it scares me a bit, for the customers, the cloud providers and SharePoint itself.

The problem is straightforward, but will prove very difficult to  solve. Cloud services, traditionally, have been focused on a very limited scope of service management SLAs, related to uptime and recovery. For a service like email, that might suffice. But the problem with SharePoint is that, as a business-layer platform, the interfaces between the service and business are much more complicated than “is the service there?” A SharePoint service that is well-architected, well implemented, and well managed will not only be available and recoverable, it will scale with and respond to business demands for functionality and solutions.

Because those demands will change with great and ever-increasing frequency, it becomes exceptionally difficult—I’m not one to say “impossible” but this might be the time to say it!—to fully anticipate what your business will need from a service, and to structure a contract to support that.  Furthermore, the types of architecture that an outsourced or public cloud will use to support simple uptime and recoverability SLAs are very different than what you might need to support information management requirements. 

Outsourced and public cloud providers simply don’t have the understanding and nuance in the services they are providing customers today to architect a truly customer-focused solution. I heard this over and over about outsourced SharePoint services that my customers are using.  I won’t name names of these providers because, in all reality, just about every name you could think of was discussed.  And customers don’t know what to ask for.

They don’t know, for example, that if they have part of their organization that requires heavy auditing, they had better get (a minimum of) two site collections from their service, so that auditing settings can be scoped to the “heavy” part of the organization in one site collection, and the rest of the organization can be in a site collection with less burdensome audit settings.  I ran into several specific examples of this, where the audit logs were already huge because the entire organization’s SharePoint service was architected from an information management perspective into a single site collection.  I feel sorry for these organizations, because they’re only in the first year or two of their journey with SharePoint.  Audit log size is going to be a problem for them—one that they didn’t anticipate when they negotiated the service.  And worse, while there are third party tools that can restructure content, they did not include that requirement in their agreement with their provider, either.

So one of the discussions I am going to launch is a discussion of how you can try to drive real governance and management—information management not just service management—into your cloud providers.  I’d be very interested in hearing your stories—victories and defeats—with SharePoint services that you don’t directly control.  And if you are a company that provides outsourced SharePoint service, I definitely want to talk with you.  There are things that need to be done to help both customers and providers succeed in the very near future, before enough customers get tired of getting doused by the cloud.  I’d be happy to do anything I can to help either side of this equation move the maturity of cloud services forward.

I’ll be at BUILD this week in Anaheim, California, for the debut of Windows 8 Server and Client. I’m going to be looking for touchpoints with which to improve identity and configuration management with SharePoint.  If you’re around the event, find me!  Til next week, g’day!

Additional SharePoint articles you might like:
1. 5 FAQs About SharePoint in the Cloud, by Caroline Marwitz
2. To the Cloud: Really? by Dan Holme
3. SharePoint Deployment and Governance, by Dave Chennault

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.