Posted by Rob Koplowitz on February 6, 2013
In collaboration, there are cloud vendors, on-premises vendors and hybrid vendors. Here's the thing; hybrid vendors are not really cloud vendors. What do I mean by that? Let's look at two different applications that both run as part of Office 365; SharePoint and Yammer. SharePoint is hybrid (Microsoft will happily allow you to choose between an on-prem or cloud) and Yammer is pure cloud. In many respects they are similar; both run in Microsoft run data centers, can be purchased on a subscription basis, are fast and easy to provision, provide automated upgrades, put reliability and security in the hands of the vendor, etc. Lots to like about running an application in the cloud.
Here's where they are not alike. A pure cloud vendor is fundamentally better positioned to gather requirements and deliver new functionality faster. Let's take a look at a new release process might work with a product based on a traditional product software develop approach, like SharePoint:
- A business planning cycle determines new requirements that are critical to market success
- A product planning cycle determines which features and functions are technically and economically feasible to build within the development cycle
- Engineering builds a new release of the product
- The product code goes through multiple release stages to get market feedback and test the stability of the new features and functions
- The product becomes GA (generally available)
- Rinse and repeat
This process can take a while. If we think about SharePoint releases (2001, 2003, 2007, 2010, 2013) it's about three years. Now, if you have a cloud version you can release incremental functionality into the cloud on a more regular basis but substantial improvement are generally tied to major releases. Ultimately you can only manage so many versions of software and can't be too out of sync with your on-premises users. So, the on-premises version essentially becomes an anchor that drags on how quickly you can introduce significant new functionality. So, even if the vendor is closely and accurately following market trends to guide the product, users may have to wait several years to get the cool new stuff. And the dynamic can work the other way as well. Once a new feature is added users will likely have to live with it for three years. A real stinker can take up valuable screen real estate for a long time even though no one wants it there.
Let's take a look at how the process might work with a pure cloud approach to development, as practiced by Microsoft's latest acquisition, Yammer:
- Build and introduce new feature or functionality
- Evaluate user reaction to the new feature by releasing it to a controlled subset of users
- If users like it, keep it, if not, pull it
This process can execute over the period of weeks or months and there is only one code base to worry about, since it all runs from vendor controlled data centers. The end result is a better opportunity for the vendor to gauge the value of new features and functionality based on real-world production environment feedback and a delivery model that allows that new functionality to get into the product fast.
None of this is anything new. So, why bring it up now? In our latest SharePoint adoption survey we discovered that while IT remains satisfied with SharePoint, satisfaction among business users softened from the previous year. When asked why they were dissatisfied responses included "We're not seeing the level of adoption we expected" - 54%; "Users don't like the SharePoint experience"- 51%; "Users prefer other tools, such as email" - 41%.
All of this indicates an opportunity to provide a better experience and newly acquired Yammer offers a model to do just that. So, if you're Microsoft, do you begin to make bigger and bigger bets on Yammer? Do you make it the core of your social strategy going forward? Do you extend more and more core SharePoint functionality through the agile Yammer interaction layer? Sounds good, right?
Here's the rub. While all of this sounds great, it means Microsoft would take a dependency on some key functionality that would be available only in the cloud. As in, "You can't have anything in the cloud ever? Oh, then you can't have this cool new stuff". Microsoft has used the catch-phrase "All in" to describe their commitment to the cloud. Up to now, they have not been all the way "all in". "All in" means being willing to turn your back on some portion of your addressable market to take full advantage of the benefits described above. It means burning the boats so there is no way back, only forward. And this is a conversation that is likely taking place right now because business and product planning for the next version of SharePoint must be well underway.
The data above is sited above is only a small part of the overall survey that fed a new document from John Rymer and myself. While I took the opportunity to use the data to tee up a provocative subject, the document is really focused on some key findings including:
- SharePoint is still a favorite among IT with 81% running the 2010 version and 68% planning to upgrade to 2013 within two years
- Only 8% plan a full deployment in the Office 365 cloud, but an additional 26% will move to a hybrid cloud, on-premises deployment
- 91% do not yet have a SharePoint mobility strategy in place
Forrester clients can access the full report here: