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.

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.

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.

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.

Hyperbole aside, the move has really been seamless, and the BPOS service is living up to the promises made by Microsoft. But just as one data point does not a trend make, one good experience by an SMB doesn't mean everyone should follow our lead. Just what makes Software-as-a-Service a compelling option? 

Here are my top five reasons for making the move:

Cost predictability: In spite of my love for technology, I cringe every time we outgrow a server. The nature of the consulting and software business is that you get growth spurts, cash flow in and out don't always align, and having to perform an unexpected upgrade can put a big dent in your budget. With SaaS, I know what my costs will be. If I run out of space on SharePoint Online, it's only a few dollars extra a month to get some more. If we bring on temporary staff to work on a project, it's just a few dollars a month for email, and we get to cancel them when our subscription renews. My budget can handle a few extra dollars a month; it chokes on thousands to purchase new hardware or software. Will SaaS cost me more over the long run? Maybe, but predictability has value too. 

Easy upgradeability: Besides the cost issue mentioned above, there's a time and effort issue with upgrades and expansions. Evaluating, ordering, installing, and migrating data to a new server is not trivial. Besides the active time spent on it, the time it takes from decision to readiness for use can be weeks. On BPOS, I can expand our server space and add 10 new users in 15 minutes with a handful of clicks.

No maintenance: I've spent many a night and weekend in data centers. Keeping up with patching servers, upgrading software, and troubleshooting hardware failures used to be a small but meaningful portion of my time. Now it's not. Microsoft does it. I like that. It's also nice to know that we'll get the latest version of the software automatically, rather than having to spend a chunk of change on new licenses and upgraded hardware ourselves. 

Everywhere's an office: We don't have a VPN in our office. Rather, we have one but it's never been reliable enough to depend on. So our servers are trapped behind our firewalls. That's arguably a good thing, from a security perspective, but makes working outside the office a bit inconvenient. To compensate, we try to anticipate the data we might need while we're out, and copy it locally. This, as you may imagine, creates a whole host of problems, from synchronization issues to security concerns. We don't have that problem anymore. Anywhere we can get online, we have access to our email and files. It makes getting ready for a client site visit a breeze, and we don't have to worry about being unable to get our hands on a piece of information ASAP. We're still looking for a feasible solution to host our development environments online, but one step at a time. 

Security: A lot of folks are concerned about data security in the cloud. People have been hacking into Internet sites for as long as there's been an Internet. And if anything, it's only going to get worse. But I look at it another way. I know, without a shadow of doubt, that Microsoft has better security experts and technology safeguarding my data than I do in my own data center. I also know that their disaster recovery capabilities are better than mine, their data center power and network connections are more robust than mine, and their security policies and procedures are better thought out and implemented than mine. Sure, I'm a smaller target, so the heavy duty hackers aren't going to waste much time on me, whereas I'm sure every hacker on earth is trying to get through Microsoft's defenses, but I still think they're in a better position to safeguard my data than I am. "Security through obscurity" is not a strategy; having rooms full of really smart security guys figuring stuff out is.

That's my short list. I'm not suggesting that everyone's priorities are the same as mine, but I don't think I'm unique when it comes to running a small business.

Lest ye think I'm a starry-eyed cheerleader, I will say there are concerns when you jump into the cloud. There will be outages. There will be times when support will be slow or lacking. There are features you can't get online that are available in the on-premises version of the software. Sometimes things will go wrong and you have no idea why, because there are many more moving parts and players involved than if you just have the server and networking gear in the next room. 

My answer to those concerns is to say that I understand them, I accept them, and I've tried to address them. But I'm not going back unless things change for the worse in a fairly significant way. The tradeoffs are just too good.