So what is this newfangled apps model anyway and why do I care? (part 1)

Hiya

I’ve been meaning to write about the topic of the apps model of SharePoint 2013 for a while now, because it is a topic I am both fascinated and slightly repulsed by. While lots of really excellent material is out there on the apps model (not to mention a few good rants by the usual suspects as well), it is understandably written by developers tasked with making sense of it all, so they can put the model into practice delivering solutions for their clients or organisations.

I spent considerable time reading and researching the various articles and videos on this topic produced by Microsoft and the broader SharePoint community and made a large IBIS map of it. As I slowly got my head around it all, subtle, but significant implications begin to emerge for me. The more I got to know this topic, the more I realised that the opportunities and risks of the apps model holds many important insights and lessons for how organisations should be strategically thinking about SharePoint. In other words, it is not so much about the apps model itself, but what the apps model represents for organisations who have invested into the SharePoint platform.

So these posts are squarely aimed at the business camp. Therefore I am going to skip all sorts of things that I don’t deem necessary to make my points. Developers in particular may find it frustrating that I gloss over certain things, give not quite technically correct explanations and focus on seemingly trivial matters. But like I said, you are not my audience anyway.

So let’s see if we can work out what motivated Microsoft head in this direction and make such a significant change. As always, context is everything…

As it once was…

I want you to picture Microsoft in 2011. SharePoint 2010 has come out to positive reviews and well and truly cemented itself in the market. It adorns the right place in multiple Gartner magic quadrants, demand for talent is outstripping supply and many organsiations are busy embarking on costly projects to migrate from their legacy SharePoint 2007 and 2003 deployments, on the basis that this version has fixed all the problems and that they will definitely get it right this time around. As a result, SharePoint is selling like hotcakes and is about to crack the 2 billion dollar revenue barrier for Microsoft. Consultants are also doing well in this time since someone has to help organsiations get all of that upgrade work done. Life is good… allegedly.

But even before the release of SharePoint 2010, winds of change were starting to blow. In fact, way back in 2008, at my first ever talk at a SharePoint conference, I showed the Microsoft pie chart of buzzwords and asked the crowd what other buzzwords were missing. The answer that I anticipated and received was of course “cloud”, which was good because I had created a new version of the pie and invited Microsoft to license it from me. Unfortunately no-one called.

image

Winds of change…

While my cloud picture was aimed at a few cheap laughs at the time, it holds an important lesson. Early in the release cycle of SharePoint 2007, cloud was already beginning to influence people’s thinking. Quickly, services traditionally hosted within organisations began to appear online, requiring a swipe of the credit card each month from the opex budget which made CFO’s happy. A good example is Dropbox which was founded in 2008. By 2010, won over the hearts and minds of many people who were using FTP. Point solutions such as Salesforce appeared, which further demonstrated how the the competitive landscape was starting to heat up. These smaller, more nimble organsiations were competing successfully on the basis of simplicity and focus on doing one thing well, while taking implementation complexity away.

Now while these developments were on Microsoft’s radar, there was really only one company that seriously scared them. That was Google via their Google Docs product. Here was a company just as big and powerful as Microsoft, playing in Microsoft’s patch using Microsoft’s own approach of chasing the enterprise by bundling products and services together. This emerged as a credible alternative to not only SharePoint, but to Office and Exchange as well.

Some of you might be thinking that Apple was just a big a threat to Microsoft as Google. But Microsoft viewed Apple through the eyes of envy, as opposed to a straight out threat. Apple created new markets that Microsoft wanted a piece of, but Apple’s threat to their core enterprise offerings remained limited. Nevertheless, Microsoft’s strong case of crimson green Apple envy did have a strategic element. Firstly, someone at Microsoft decided to read the disruptive innovation book and decided that disruptive was obviously cool. Secondly, they saw the power of the app store and how quickly it enabled an developer ecosystem and community to emerge, which created barriers for the competition wanting to enter the market later.

Meanwhile, deeper in the bowels of Microsoft, two parallel problems were emerging. Firstly, it was taking an eternity to work through an increasingly large backlog of tech support calls for SharePoint. Clients would call, complaining of slow performance, broken deployments after updates, unhandled exceptions and so on. More often than not though, these issues had were not caused by the base SharePoint platform, but via a combination of SharePoint and custom code that leaked memory, chewed CPU or just plain broke. Troubleshooting and isolating the root cause very difficult which led to the second problem. Some of Microsoft’s biggest enterprise customers were postponing or not bothering with upgrades to SharePoint 2010. They deemed it too complex, costly and not worth the trouble. For others, they were simply too scared to mess with what they had.

A perfect storm of threats

image  image

So to sum up the situation, Microsoft were (and still are) dealing with five major forces:

  • Changing perceptions to cloud technologies (and the opex pricing that comes with it)
  • The big scary bogeyman known as Google with a viable alternative to SharePoint, Office and Exchange
  • An increasing number of smaller point solution players who chip away at SharePoint features with cheaper and easier to use offerings
  • A serious case of Apple envy and in particularly the rise of the app and the app marketplace
  • Customers unable to contend with the ever increasing complexity of SharePoint and putting off upgrades

So what would you do if you were Microsoft? What would your strategy be to thrive in this paradigm?

Now Microsoft is a big organisation, which affords it the luxury of engaging expensive management consultants, change managers and corporate coaches. Despite the fact that it doesn’t take an MBA to realise that just a couple of these factors alone combine as a threat to the future of SharePoint, lots of strategic workshops were no doubt had with associated whiteboard diagrams, postit notes, dodgy team building games and more than one SWOT analyses to confirm the strategic threats they faced were a clear and present danger. The conclusion drawn? Microsoft had to put cloud at the centrepiece of their strategy. After all, how else can you bring the fight to the annoying cloud upstarts, stave off the serious Google threat, all the while reducing the complexity burden on their customers?

A new weapon and new challenges…

In 2011, Microsoft debuted Office365 as the first salvo in their quest to mitigate threats and take on their competitors at their own game. It combined Exchange, Lync and SharePoint 2010 – packaging them up in a per-user per month approach. The value proposition for some of Microsoft’s customers was pretty compelling because up-front capital costs reduced significantly, they now could get the benefits of better scalability, bigger limits on things like mailboxes, while procurement and deployment was pretty easy compared to doing it in-house. Given the heritage of SharePoint, Exchange and Lync, Microsoft was suddenly competitive enough to put Google firmly on the back foot. My own business dumped gmail and took up Office365 at this time, and have used it since.

Of course, there were many problems that had to be solved. Microsoft was now switching from a software provider to a service provider which necessitated new thinking, processes, skills and infrastructure internally. But outside of Microsoft there were bigger implications. The change from software provider to service provider did not go down well with many Microsoft partners who performed that role prior. It also freaked out a lot of sysadmins who suddenly realised their job of maintaining servers was changing. (Many are still in denial to this day). But more importantly there was a big implication for development and customisation of SharePoint. This all happened mid-way through the life-cycle of SharePoint 2010 and that version was not fully architected for cloud. First and foremost, Microsoft were not about to transfer the problem of dodgy 3rd party customisations onto their servers. Recall that they were getting heaps of support calls that were not core SharePoint issues, but caused by custom code written by 3rd parties. Imagine that in a cloud scenario when multiple clients share the same servers. This means that that one clients dodgy code could have a detrimental effect on everybody else, affecting SLA’s while not solving the core problem Microsoft were having of wearing the cost and blame via tech support calls for problems not of their doing.

So with Office365, Microsoft had little choice but to disallow the dominant approach to SharePoint customisation that had been used for a long time. Developers could no longer use the methods they had come to know and love if a client wanted to use Office 365. This meant that the consultancies who employed them would have to change their approach too, and customers would have to adjust their expectations as well. Office365 was now a much more restricted environment than the freedom of on-premises.

Is it little wonder then, that one of Microsoft’s big focus areas for SharePoint 2013 was to come up with a way to readdress the balance. They needed a customisation model that allowed a consistent approach, whether you chose to keep SharePoint on-premises, or move off to the cloudy world of Office 365. As you will see in the next post, that is not a simple challenge,. The magnitude of change required was going to be significant and some pain was going to have to happen all around.

Coming next…

So with that background set, I will spend time in the next post explaining the apps model in non technical terms, explaining how it helps to address all of the above issues. This is actually quite a challenge, but with the right dodgy metaphors, its definitely possible. 🙂 Then we will take a more critical viewpoint of the apps model, and finally, see what this whole saga tells us about how we should be thinking about SharePoint in the future…

thanks for reading

Paul Culmsee

8 Comments on “So what is this newfangled apps model anyway and why do I care? (part 1)

  1. Regardless which way you put it, the underlying problem is that the community doesn’t know how to do something, whether that is maintaining SharePoint, building solutions for it, or applying it to the right situations.

    Microsoft’s solution is to change all the parameters and ask everyone to learn everything all over again.

    I’m constantly reminded of the Dilbert “let’s reorganize!” strips.

  2. Since we haven’t gotten to the apps model yet lets put that aside and save it for later posts. Given where they found themselves, what would your strategy be to address the above 5 threats if you were Microsoft? Whether their execution succeeds or fails is not the question. What I hear you saying here is they are asking too much of their customers and partners, creating change fatigue. So given that, what do you think their strategy should have been?

  3. I’m not sure whether you think my argument had anything to do with apps, but it hasn’t, so yes, let’s leave that for later.

    As for what my strategy would be, I don’t have the information Microsoft has so I can’t make a good call on what they should do. Nor is it sensible to require that in order to evaluate the validity of my argument.

    Let’s say someone suggests to you that kicking small dogs is a great way to become filthy rich and someone disagrees with this, saying “clearly, kicking small dogs isn’t going to get you filthy”. Would you require of the last posted that they should know how to get filthy rich before you accept their argument?

    Changing direction every three years is not a good way to move forward. Saying that does not mean I should know or be demanded what their best approach to moving forward should be, and frankly, I don’t know because I lack the information to know.

    If you look at the history, however, you can clearly see that the repeated direction changing hasn’t lead Microsoft anywhere. In 2003, we were asked to use HTML and JavaScript to customize SharePoint. Now, the latest and greatest thing is, guess what, to use HTML and JavaScript to customize SharePoint.

  4. Your example is kind of pointless because I laid out the issues in the post and what more information do you require to be certain enough to determine a strategy? At what point are you certain enough to take action? In my mapping life I do a lot of strategic planning work and I have mapped many teams have to determine a path forward with incomplete information yet they have to do *something*.

    So basically, your point is “I am allowed to throw stones based on the result of decisions made years ago, even though I – with the benefit of hindsight – can not name what I would have done any different”. That’s fine – I won’t argue with that anymore because to do so would invalidate 50% of bloggers.

    Then you go back to the change thing which you made in your first comment. So then let me give you a topic for your blog because with this question Microsoft have no more information than you. Write a post about what Microsoft need to do to address the issues you outline. Who knows? next time they do planning/strat they might turn your ideas into a KPI.

  5. Paul,

    I’m sure you realize that making a good decision requires significant insight. I can say “Well, they should have done X” but Microsoft may perfectly well sit on information that makes X completely impossible. Without knowing much about the decision making process or the information they have available, it is impossible to say what is a better decision.

    That doesn’t preclude calling out a bad decision and the way that SharePoint is now fundamentally changing and alienating more and more of the core community, it is clear that at least one and probably more bad decisions has been made.

    I’ll entertain your requirements, though, with the above caveats in mind.

    “Changing perceptions to cloud technologies (and the opex pricing that comes with it)”
    “The big scary bogeyman known as Google with a viable alternative to SharePoint, Office and Exchange”
    “An increasing number of smaller point solution players who chip away at SharePoint features with cheaper and easier to use offerings”
    “A serious case of Apple envy and in particularly the rise of the app and the app marketplace”

    All of these aspects speak of one thing only; increased competition. However, the problem is that the competition comes in areas where SharePoint isn’t even contending and never has, namely in loosely coupled components tied together by ad-hoc APIs and features.

    To put that into an easier analogy, if Chrysler comes out with a better car, should bicycle manufacturers start thinking about putting engines and satnav on their bikes? Of course they shouldn’t. Bikes are competitive in completely different areas than cars and turning bikes into engine powered vehicles turns away the existing customer base.

    Microsoft’s problem is that everyone owns a bike. You can’t really sell more bikes, so they need to start selling something else, and in this lies my proposed solution.

    Build something else. SharePoint is doing just fine; it has a vibrant community that continues to bring value to clients. It has proven its value and customers have bought it for what it is. It should be maintained for what it is, not turned into something different.

    “Customers unable to contend with the ever increasing complexity of SharePoint and putting off upgrades”

    Again, this is not a problem that is solved by replacing the product with something different. It is solved by fixing the issues the product has.

    This is a recurring issue that Microsoft is not alone facing; products need to be constantly evolved to add new features so that you can sell a new version. This, however, is a sales and marketing issue, not a technical one. With a fixed amount of resources, Microsoft needs to prioritize between adding new features and fixing or improving existing features.

    The latter does not sound ‘sexy’ in terms of sales and marketing; would you pay again for another copy of the same product, knowing the only thing you get are fixes for what you’ve already paid? A lot of people would, but it is a very different sales strategy (often called annual maintenance plans) that Microsoft has never had for such products. In fact, this is the strategy they are moving towards with Office365; you don’t buy O365, you ‘rent’ it, paying continuously for upgrades.

    So, as much as I’d like to say that they should have sold SharePoint with a maintenance plan in the past, it is not a solution you can apply after the fact.

    What they should do now, however, is stop putting engines on bicycles. Bicycles work fine; improve them as they are. Fix the squeaky chain, make more comfortable seats, put a rust inhibitor on the metal. Don’t try to turn it into a competitor for cars by turning it into cars and trying to convince people that cars are so awesome now.

    .b

  6. Bjorn

    Thanks for taking the time to make your comments and rising the challenge to make some sense of an incomplete picture.

    So first up I take issue one of the competition comments. You made a contention that just because SharePoint is tightly coupled and google services are loose, that they are different and therefore not in the same play-space. If you are a developer than I agree, but do you think anyone else will care? “Oh wait, this is loosely coupled, so I better do my email, file collaboration and chat elsewhere” rings pretty hollow. This argument is weak and the argument of “SharePoint is just fine” reeks of groupthink. Kodak at one point might have said “yeah film is just fine” too and going back to your earlier loosely coupled example. “you see digital cameras and film? nah completely different things”.

    As for the add features vs fix problems, on that I agree and it is tricky balancing act that I don’t know the answer for either. But comparing google tool for document, email and real time collab to SharePoint’s offering for document, email and real time collab as a bike vs a car really isn’t useful… Be careful with your metaphors as I explain here: http://www.cleverworkarounds.com/2009/03/24/a-warning-on-tame-metaphors/ SImple, mechanistic analogies might seem helpful but can mislead too.

  7. Changing direction every three years is not a good way to move forward. Saying that does not mean I should know or be demanded what their best approach to moving forward should be, and frankly, I don’t know because I lack the information to know.

  8. These smaller, more nimble organsiations were competing successfully on the basis of simplicity and focus on doing one thing well, while taking implementation complexity away.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.