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.

SharePoint for SMBs? - An Answer

Informationweek.com recently had an article by Ivan Schneider in their SMB section entitled "Is SharePoint 2010 Right for SMBs?" Among the points made in the piece, which never did answer its main question, was a statement I take a bit of exception to.

 

The article relates the story of the Greater St. Louis Boy Scouts Council working with a local tech firm to deploy SharePoint. In the midst of the article, the author notes that the local firm was subsequently acquired by another firm, and that "the logic behind the merger is sound, and we can certainly expect similar deals to surface." In his estimation, the services market is splitting into large firms and smaller SharePoint-specific boutiques, and that he'd "bet on the big guys." He then goes on for a while about open source, IBM and Oracle's professional services organizations, and about how in tech, "the most important question is who's going to install, build, maintain, and upgrade it."

 

Well.

 

Let me take a shot at answering the title question and at addressing why I think Schneider is wrong about betting on the big guys.

 

The short answer to the title question is "maybe." The longer answer is "in some cases, maybe."

 

One of the primary misunderstandings about SharePoint among our clients is that it's a product. You buy it, install it, move your data over, and it automatically makes your business more efficient. And that's pretty much flat wrong. SharePoint is a platform upon which to build products. And once those products are built, you will have to alter your way of doing things to fit the SharePoint model. Only then will the efficiency come. If you're not willing to put in the self-examination, either alone or assisted by a SharePoint analyst, to derive and refine the processes that make your business run, you will not see value. If you're not willing to invest the time and expense to customize SharePoint to model those processes, you will not see value. And if you're not willing to change your processes where needed to accommodate SharePoint's capabilities, limits, and process model, you will not see value.

 

So the answer is "maybe." It all depends on the commitment of the business to the platform, and its willingness to work with SharePoint. If they're willing to commit, then the answer is a solid "yes." Very few technology investments will completely transform a small business for as little money as a well-implemented SharePoint Foundation installation or BPOS subscription.

 

The statement I took exception to above is also directly related to the title of the article. I honestly don't believe the big guys will win in the SMB market, because they don't provide good value to small businesses and SMBs can't afford them. I say this not only as the co-owner of a small SharePoint -specific boutique, but as the veteran of 9 years with a large professional services firm. Small business can't afford the IBMs and Oracles of the world, so if they win, SharePoint for SMBs is doomed. The "big guys" are not set up to handle engagements as small as most small businesses require. Their focus is on expanding scope and ensuring a long-term relationship with plenty of follow-on work. In our experience, small businesses need a clearly defined scope, with limited objectives as to deliverable and cost. They don't have the seemingly bottomless pockets of the enterprise. Every dollar you charge is one dollar less the owner takes home in profit, so they feel it. Small consultancies understand that and are set up to be able to deliver targeted solutions for limited cost. And that's why I'm betting on the little guys.