Looking further into the growing ecosystem of vendors that extend and support Microsoft SharePoint, we get to the question of where ISVs fit when SharePoint is in the cloud.  The short answer, really, is that they don’t.  OK, that’s an oversimplification of course, but there is currently a far more limited role for third parties looking to extend SharePoint if it is run in a shared cloud environment.  And this points to some contradictions in Microsoft’s strategy.  On the one hand, we see a big push around SharePoint as a platform and this growing ecosystem of third parties.  On the other hand, Microsoft is touting SharePoint Online as part of the upcoming Office 365 cloud-based service (to replace the existing Business Productivty Online Suite, aka BPOS), which really has very little support for third parties.

BPOS, which bundles SharePoint Online along with Exchange and a few other services, is currently offered in both Standard and Dedicated versions.   In the Standard version, customers have multi-tenant infrastructure that is shared across customers.  With the Dedicated version (or BPOS D), they have (obviously) dedicated infrastructure, which pretty much traditional application hosting; with this BPOS D configuration, Microsoft is the hosting provider, though this scenario would really not be much different from having another hosting provider run your SharePoint deployment on dedicated servers.  Office 365 will also be made available on either shared or dedicated infrastructure.

There is currently no support for trusted third-party code in the Standard version of BPOS (aka BPOS S), nor will there be in the Office 365 Standard version.  Customers that want to extend their SharePoint deployment with, say, workflow tools from Nintex or imaging capabilities from KnowledgeLake (or any of their own custom code), will have to run their SharePoint deployments on prem or in a dedicated environment, hosted by either Microsoft or another hosting provider.

That isn’t to say that integration with BPOS / Office 365 is impossible — web services-based integration that requires no server-side installs on the SharePoint servers isn’t an issue.  So, for example, Metavis Technologies has migration tools that can move data to / from BPOS without installing anything on the SharePoint servers and so can work with SharePoint as part of BPOS S (and Office 365 presumably).  Similarly, on the Exchange side of BPOS, email archiving to a cloud provider like LiveOffice works via a data export function that doesn’t touch the cloud-based Exchange servers.

Maybe the argument is that orgs don’t want to run more sophisticated content management apps in pure cloud environments.  That may be an ok way to segment the market today but it will be limiting in the future.   One of the advantages Microsoft has today over an upstart cloud player, like Box.net for example, is the growing ecosystem of extensions that can help fit SharePoint into a broad array of use cases.  But these aren’t there in the cloud. If Box (or another player) could grow and support an ecosystem in the cloud (and support custom code and in-house developers), it might get some advantage; this is the strategy SpringCM has been attempting, with some, limited success, with its platform approach to ECM in the cloud.  Salesforce has also been more aggressively building its social software offering, Chatter (see recent acquisition of Dimdim as case in point).  This doesn’t meet a plethora of content management requirements yet but is potentially competitive to SharePoint as a social software service for internal use.

There are clear limitations to the approach Microsoft is currently taking with the SharePoint ecosystem and BPOS / Office 365 and it seems this will be something that Microsoft will have to ultimately address if it wants to be serious about offering SharePoint as cloud services.  This isn’t the only issue that might keep organizations away from the Standard version of Office 365 (i.e., how much SharePoint functionality will it include and how often will it rev?), but it could be a big one.