Taking a Break

We have some busy times ahead, so we're going to be taking a break from blogging for a bit. Talk to you soon.


The Child Prodigy Joins a Band

Steve Gaitten of Bamboo Solutions really caused a ruckus last week with a blog post entitled "SharePoint is Going Away". Besides a flurry of blog posts from other SharePoint community members, I got several earfuls from colleagues at this weekend's SharePoint Saturday NYC (which was a great success, by the way, thanks to some fantastic organizers).

Honestly, I'm not sure where I stand on the matter. I agree with most commentators that the post's title is clearly meant to be as inflammatory as possible, especially when compared to the content of the post. So SharePoint wasn't featured prominently at the recent Microsoft World Partner conference. Okay, and…? I'm sure many of Microsoft's mature technologies weren't singled out for special treatment (and SharePoint, 10 years old at this point, is mature. Growing but mature).

Where I do agree with Gaitten is that SharePoint as we have known it may be changing. I don't believe Microsoft's cloud initiative is a passing fancy. I firmly believe it's the way forward for them, and they're going to give it their all or go down trying. Steve Jobs is right when he says we're entering the "post PC" era, and while Jobs is referring primarily to consumer systems, I continue to see the consumerization of business computing as mobile connected devices continue to make their way into businesses as equal partners. Business users are coming to expect constant availability of data, and putting your data in the cloud makes that much easier and cheaper to achieve.

So what does the cloud mean for SharePoint? Nothing really. It becomes a part of Office 365, on par with Exchange, and we continue to use it to facilitate a wide variety of business processes and needs. It's the same, but different. Since I've never been a big fan of the practice of pushing the SharePoint brand onto end users, this new downplaying of the brand may actually work out better in my estimation. Sometimes we forget that users don't care what the tool is, they care what problem the solution solves (and rightly so). To them, it's the Vacation Calendar, not SharePoint. By de-emphasizing the SharePoint brand, maybe we'll be able to focus more on deploying solutions instead of platforms.

I think a lot of the uproar boiled down to SharePoint people being told they're not that special anymore, and not liking it. That's an understandable reaction, and I'm sure the Exchange folks are feeling the same thing right now.

SharePoint may not be the child prodigy anymore, but all child prodigies grow up eventually, and the good ones continue to create beautiful things in adulthood, many times as part of a group. Whether you're solo or in a band, it doesn't matter. The key is to remain relevant, and I think SharePoint has that covered.


SharePoint Online's Public Website: The Heart of Darkness

The horror, the horror...

Having tried out SharePoint Online's public website functionality for several weeks now, and failing miserably to make anything even marginally worthwhile with it, I give up.

I understand Microsoft's position that the public website in SharePoint Online is not really meant to be a substitute for a full-blown hosting solution. And I understand that some functionality may change between now and the end of the Office 365 beta.

But this is ridiculous.

The style/theme/color scheme -based layout model is so limiting as to be useless. By the time I gave up I had so much hand-coded CSS in the Advanced Style Sheet that I would've been better off starting from scratch. Which you can't on the pages they give you, because there's no way to turn off the dumbed-down formatting interface.

Sure, you can paste in /_layouts/settings.aspx and get behind the scenes and create a site from scratch, but most things don't work for anonymous users. For example, lists cannot be accessed anonymously, which on a platform where just about everything is a list is a problem. Setting up a simple blog site works, as long as the anonymous visitor doesn’t click on anything. Clicking on the post title, categories, archives, or comments all lead to a login screen, making it useless for a public website.

In short, unless your site is simply a set of pages with nothing but text and images on them, you're out of luck.

Hello, Microsoft? The Nineties called, they want their website functionality back.


The SharePoint Online Sandbox - I Like It

Speaking with SharePoint developers, I hear a lot of concern about the Sandbox, usually in reference to the upcoming Office 365. SharePoint Online in O365 will require that code be deployed to the Sandbox,  which means all manner of indignity for developers, like losing access to the file system and certain parts of the server API, but honestly, I'm not all that upset. After working in SharePoint for years and dealing with misbehaved solutions and sloppy code, I generally think the Sandbox is a good thing. Discipline in coding is generally a good thing.

What I don't understand are the developers who plan to avoid coding for the Sandbox and just wish it away. After all, this Cloud thing is a passing fad, and on-premises SharePoint deployments will always be the way to go.

I'm not so sure.

I'm beginning to view SharePoint Online and on-premises SharePoint 2010 as functionally equivalent for most use cases. There will always be businesses with specific data or functionality needs that will want to have some or all of their SharePoint farm in-house, but the big meaty middle of the market won't. They don't need the headache. And I see this meaty middle moving to the Cloud thing in big numbers.

One day, a client will tell you they're moving from on-premises to SharePoint Online. And when that day comes, the developer who didn't code for the Sandbox will have to recode. And that will be unpleasant.

So I'm going to build everything we do with the Sandbox in mind, unless it absolutely positively requires farm level functionality or is for a specific client that requires on-premises servers. Because I'd rather figure it out now than have to tell a client we have to rebuild from scratch later.

It's the SharePoint version of Java's old "Write Once, Run Anywhere" tag line, only this time it's actually true.


The Two Faces of Governance

A perennial hot topic in SharePoint discussions is the need for governance. Ask 10 SharePoint experts about structuring a deployment and the one thing they'll all agree on is the need for governance. But I think what is typically referred as governance is really an unfortunate mashup of two different things, and those two things need to be treated separately to be effective.

Microsoft defines governance as "the set of roles, responsibilities, and processes that you put in place in an enterprise to guide the development and use of a solution based on SharePoint". That makes sense. But it mistakenly groups technical development and use into one document. In my experience, those two things are worlds apart in practical terms.

The development of a SharePoint environment, from requirements gathering to ongoing support, is primarily a technical exercise conducted by technical people. The use of SharePoint typically revolves around businesses process performed by business personnel. This crucial distinction is lost on a lot of people. Even Microsoft's own governance plan template lumps both groups into one document. But the needs of these two groups are markedly different and should be treated as such.

The technical aspects of SharePoint, as with most complex technology projects, absolutely require the creation of detailed documentation. There are myriad technical details that must be thought through, planned out, and implemented in a tightly choreographed dance to ensure minimal business impact. The information architecture and design of the SharePoint sites must be developed and implemented. Technical support resources must be developed and put in place. These folks are charged with the care and feeding of the beast, and deal with SharePoint as SharePoint, a complex system that needs to be organized and maintained in a predictable way. This behind-the-scenes detail work is well suited to extensive documentation and the typical governance plan is adequate to meet the need.

The business aspects of SharePoint are a very different animal. Here, the users don’t deal with a piece of technology, they engage with a business process. It's not SharePoint, it's the HR Onboarding application. A finely crafted SharePoint governance document full of policies and procedures will get the same attention as every other user manual they're handed. They just want to get on with their job.

And that's the heart of the matter: for the technical team, SharePoint is their job. For business users, it's not. For the techs, the governance plan is the bible to keep their system running. For users, it's just another distraction keeping them from their job.

So what do we do?

Luckily, most companies already have the answer: training. The user governance documentation should really be written for the training department (or a training firm brought in), not the end users. Trainers are the ones who know how to distill the document down into lessons the users will understand and absorb. The governance needs to be presented in terms of how will it help them do their job and make their life easier. Even though it's in reality top-down, it needs to feel bottom-up. In short, the end users need to be convinced they own their tool, and that doing things in a certain way will be in their best interest. It's a tricky balance for the trainer to maintain, but that's why they're professionals. Yes, as part of the training effort some user documentation should be created to reinforce the learning and serve as  reference, but success hinges on ensuring the policies are internalized, not just documented.

In the end, a governance plan which isn't followed is even worse than not having one, so properly planning the implementation of the user governance plan is a crucial part of planning the deployment as a whole. And here it serves us well to understand the affected audiences. Give the detail to the people who need the detail: the techs. User governance is a training exercise, not a publishing effort.