Category Archives: Cloud

Should Microsoft Kill SharePoint?

This is a pretty sensationalistic title.  Memeburn wrote an article based on word spoken by Gartner Analyst Jeffrey Mann (@jeffmann) at the 2013 Gartner Symposium

Disclaimer: I don’t have access to Jeff’s original words, only his words as reported by the Memeburn article, so there might be some differences in the interpretation.

The article mixes contexts like flammable fuels.

“Hardly anybody likes it” (yet, still 70% of companies see that at lest 50% of their employees use SharePoint at least once a week)

“The problem is that SharePoint is a victim of its own success”  (I’ve never understood how this comment can be applied generally to anything.  Don’t we want success?)

“It’s too big and complex”  (the implication here is that IT Pros are scared of managing SharePoint, and once it is installed it is unusable…)

These points lead to the summary datapoint that drives the fear: “As a result, many people are using versions of SharePoint that are at least four years old.”

ACK! The Horror!  The platform is dead because not everyone updated within the first six months!  AUGH!  Can you hear the anguished cries of IT Pros who don’t understand it when  SharePoint upgrades don’t roll onto server boxes as smoothly as the most recent version of Microsoft Office?  Or that, given the fact that the release cycle was 3 1/2 years in between SP2010 and SP2013, having a version that is 4+ years old at this point is actually the normal state of things?

A second line of reasoning in the article is that SharePoint “is too big and complex” and that IT shops would be better off using an entire range of point solutions to provide specific features instead of one large platform, such as SharePoint. 

Really?  What happens when you want to upgrade all 32 of the point applications that you had to install in order to match what SharePoint provided you? Certainly, all of them will upgrade at the same time so you’ll never have to worry about mismatched versions, right? 

I’ll be the first to stand up and tell a business group that if you only want to do 4 things, then you should use stand alone tools, and SharePoint is not for you. However, for most medium-to-large enterprise that I’ve worked with, the amount of integration and services that are needed to meet business requirements just simply cannot be managed more efficiently with point solutions.  If the organization does not work with SharePoint, they are probably working with another relatively large collaboration platform, from a large vendor.  Point solutions are best for small companies, but not for medium-large.

The third point in the Memeburn article is that Microsoft should kill the on-premise version of SharePoint because Microsoft wants to move everyone to the cloud.  And Microsoft will be the first to tell you that they believe that every employee can work just fine in the cloud.  We have to remember, though, that enterprises are called large organizations because they have a lot of moving parts.  It will take time.  No need to rush.

And then the icing on the cake that just caused me to shake my head.  “The installed base is so large that Microsoft will of course keep supporting it, but upgrades will be slower coming, and users shouldn’t expect the latest or greatest functionality.”

This statement is the most important of all of Jeffrey Mann’s quotes in the Memeburn article, and it is being treated as a consolation point.  Users need to have this last quote etched in their minds, and instead of getting all sensational about “Should Microsoft Kill SharePoint???”, the article should focus on the meat of the news – that is, that your investment in SharePoint on-premise is going to be supported going forward, so don’t do anything crazy, but you should be moving to the cloud as your systems and enterprise software packages and tools allow.  Moving to the cloud needs to be important.

But, please don’t shoot the horse while it is still attached to the plow. 

CloudShare for Demo Environments

I’d like to tell you a story.  One of the software development companies that I’m working with, Ooyala, is building an integration with SharePoint.  In April (2011), we were planning to have the public unveiling of the product at the NABSHOW in Las Vegas.  It is a huge convention, and we had secured a demo kiosk and were planning to get enough of the product developed so that we could illustrate how the final product would work. 

One of our development teams was in Argentina, another development team was in Redmond, WA, and Ooyala has headquarters in Mountain View, CA.  We needed a development and testing environment that would enable all three groups to work together and to share an environment in preparation for the show.

For a couple of months, we had been using a development environment that was provided by  And everything had been working well.  We would bring up the CloudShare environment when we needed to, and share access to it from city to city.

One of the useful features that CloudShare provides is the ability to recreate a SharePoint environment from one a list of starting environments that they provide.  When one of our development teams release a new build, we can recreate a new environment on CloudShare and test the installation and configuration, etc.  It was working very well.

If you haven’t tried out CloudShare yet, you can find them at  Look for the “SharePoint in the Cloud” selection right on the front page.  That page will describe the SharePoint environments that they offer and how you can utilize them.

As we got closer to the NABSHOW, however, something wasn’t quite right.  I was worried about little things, like the URL used for the demo.  We also wanted to share the demonstration version with other potential partners and customers, so we wanted to create a demo URL (i.e. NABDEMO.OOYALA.COM) and have the dev/test environment support that.  I couldn’t find the right way to make that happen for the CloudShare environment that wasn’t located within our data center, but a quick call to CloudShare answered the question.  (They have since cleaned up how the features are displayed so that this particular feature is easier to find.)

The problem that I was running into is one of the features of CloudShare that allows their service to be affordable.  When a CloudShare environment times out due to a period of inactivity, the environment is automatically suspended, and the assigned IP addresses and physical hardware can be re-utilized for other users and to meet additional demand.  Sound very cloud-centric, right?  Well, yes, actually.  However, when the environment would be re-activated the next time someone needed it, the server machines in the environment might be assigned a different collection of IP addresses.  This meant that I might have to keep updating the DNS entries for the URL that I wanted to use for the demo.  Difficult and inconvenient.

But then I learned about a great little feature called “Always-On”.  This costs more per month, but enables your environment to stay up all the time, maintaining the same assigned IP addresses.  A quick call to CloudShare operations, and we had the solution, we had a constant IP
address for the DNS settings, and we were starting to demo using an easy to communicate and an easy to use URL.  I’ve learned, over the years, to never underestimate the importance of having an easy to communicate URL when working with salespeople…

So, long story short, we unveiled the product at the NABSHOW in April – the demo environment was flawless, and we are still using CloudShare as our development environment as we enter into a full Beta stage with the product here in June.What's your video strategy?

If you’d like to learn more about CloudShare, please learn more at

If you’d like to learn how to bring the video capabilities of Ooyala into your SharePoint environment, please send email to

If you’d like to take me to a Seattle Mariners game this summer (Yes, I’m back on the bandwagon!), please send me email –