SharePoint Governance Extremes: Wild West or Fort Knox

Greetings and much aloha from Maui! Now that we're well into 2013 (the year), 2013 (the SharePoint product) gets closer to general availability both on premises and in the Microsoft Office 365 cloud. Microsoft hasn't yet announced when Office 365 will be updated to the "Wave 15" releases, but the company promised these updates in the first quarter of this year, so we're getting close.

In recent articles, I've discussed the importance of planning a roadmap and architecture that incorporates both SharePoint 2013 and SharePoint 2010, Foundation and Server, cloud and on-prem, in order to ensure that you can deliver what your business requires. Today, I'd like to add one more dimension to the service matrix: flexibility versus lockdown. As you consider SharePoint governance in your service, there's a constant trade-off or balancing act between a service that's reliable, robust, scalable, and secure, and one that's responsive. The best way to attain the balance is to deliver service on each end of the scale: one that's flexible, and one that's locked down.

Before I share some thoughts and guidance on that topic, I'd like to give a shout out to two of the leaders in the SharePoint community who have been pumping out some great content lately—content that I, for one, rely on:

Now, let's talk about lockdown versus flexibility in SharePoint governance!

The vast majority of customers I encounter came at SharePoint from one of two vectors, which led to one of two outcomes.

First, there are the customers who began their SharePoint journey in order to meet a significant business requirement. For example, I work with several large banks that have loan and transaction processing workflows sitting on SharePoint. A large aerospace company does a lot of its collaboration on engineering projects on SharePoint. These types of projects were understood from the outset to be mission critical, so the outcome is a locked-down, highly governed service that reduces risk to ensure maximum reliability (e.g., uptime) and performance. We'll call these the "Fort Knox" SharePoint environments. (For those of you outside the United States, Fort Knox maintains much of the US government's gold supply—or at least used to—so it's used as a metaphor for highly locked down, secure environments.)

Second, there are the customers who began their SharePoint journey to support broader objectives such as collaboration. Such projects are often about increasing productivity and reducing the cost of other platforms. The projects are intentionally either vague or broad, both of which lead to a tendency for a SharePoint environment that can support lots of different business needs, which often leads the organization to loosen governance, allow rapid change, and maintain less control over code-based customizations, all to provide maximum responsiveness and flexibility. We'll call these the "Wild West" SharePoint environments.

There are other ways to reach these outcomes. Organizations in which the IT or legal department drives the SharePoint journey are more likely to end up with a Fort Knox environment. Organizations where developers, engineers, or the business drive SharePoint adoption are more likely to end up with a Wild West environment, sometimes characterized by "SharePoint on the server under Joe's desk" farms.

These extreme anchors in the governance spectrum aren't the only variation. There are at least fifty shades of grey between these black-and-whites.

The challenge is that if the SharePoint service doesn't support both types of needs, stresses occur. In a Fort Knox environment, the service can't respond to the business's needs sufficiently. New sites, changes, or additional functionality take too long to implement, must go through too much process, or are too expensive. In a Wild West environment, business critical workloads can't be guaranteed the SLA that's required.

Often, the next step in the journey is a slow blurring. The business needs more flexibility to achieve an objective in a Fort Knox environment, so controls are loosened, exceptions are made. The business in a Wild West environment has an objective that requires more control, which forces IT to admit they really don't know what's going on in the environment or, worse, to imagine, pretend, or promise that the service is more secure and stable than it actually is.

Eventually, all environments tend toward the center, making one gooey mess that is neither reliable and secure nor flexible and responsive. Then it becomes SharePoint's fault, right?

The only way to address this issue is to be aware of it and to plan for it. The reality is that, in most organizations, there are going to be mission-critical workloads and there are going to be ad-hoc workloads that require responsiveness and flexibility. And, in some cases, an ad-hoc workload will, over time, mature and graduate to a mission critical one.

Your service sooner-rather-than-later needs to provide for both types of workload in order to deliver what businesses need. If you don't, the business will go elsewhere—to other platforms or to cloud services, both of which might address the immediate need but carry risks of their own.

How do you do it? Farms. In the end, the scope of many service-management controls is exercised at the farm level, including the most important controls: performance, uptime, redundancy, and patching.

So add that to the mix, remembering that SharePoint is a service, not a single technology. A mix of versions, cloud/on-prem, Server/Foundation, and SLAs will be necessary to support diverse business requirements. Yes, there are costs involved, and I've discussed those in the past and will do so again in the future. But there are also risks of not doing it right—and the risk is a gooey mess that doesn't look either secure or flexible.