Architects: SharePoint is a Platform, Treating it as only a Service is a Mistake

Last week my friend Andrew Connell wrote a rather provocative post titled Developers: SharePoint isn’t a Platform, SharePoint is a Service. In it he makes some persuasive points and advises people to move their front end development out of SharePoint. In this post I’d like to deconstruct a few of his points and explain why I think his advice in this regard is not very good.

The Past Product Engineering Failures at Microsoft Happened

A large portion of his post concerns the undeniable fact that Microsoft has offered a series of customization models for SharePoint over the years with varying degrees of success. I agree with just about everything in this section.

There has been a series of models from the SharePoint team, and, in some respects, Microsoft has shown a shocking lack of integrity as a vendor and business partner in the way they cavalierly advised customers to do things certain ways only to later say ‘whoops! We changed our minds’. Taken from a certain angle it’s almost unforgiveable.

On the Other Hand

I think everyone can agree that web technologies changed greatly between the births of 2003 and 2013. Office 365 was impossible in 2003 simply based internet speeds. Over the span of a decade, the medium (web) changed quickly and often in surprising ways. To that, add Microsoft’s adventures in rich internet applications (Silverlight) and the emergence of cloud technologies enabled by practically ubiquitous and fast internet connections. Is it surprising that Microsoft has tried to change SharePoint development to account for these things? Is it surprising that some of these were failures?

Just the same, it is possible to migrate solutions originally created for SharePoint Server 2003 to SharePoint Server 2016. Some migrate with little effort and sometimes it is so hard that it isn’t worth it. However, consider that the vast majority of other Web platforms you could buy in 2003 no longer exist as actively developed products. Then, ask yourself: how many of them allow you to take what you did in 2003 and move it with zero effort to their current version? Do you have anything in your current Web development stack that worked in 2003? Are there any that didn’t have some disruptive breaking change between then and now?

Getting $5 of Value from your $10 Purchase

A simple truth in software development is that the less a piece of software depends on other software, the better. This is always offset by the fact that depending on other software makes it faster and cheaper to build systems. Paradoxically the development experience can be much more pleasant even if it takes longer because as a developer you get much more freedom and you don’t have to deal with the quirks or restrictions imposed by the makers of the platform.

Naturally, faster and cheaper pretty much always wins. The users of the software still expect ‘better’, but it is a ‘better’ from their perspective: better at helping themselves do what they want to do. They don’t care how it gets built.

Deliberately tying a solution to a platform makes sense when you can trust the platform to stick around long enough and when the costs of depending on the platform are offset by a sufficiently positive return on investment over the life of the solution. One of those costs is that the implementer will often be more expensive than a generalist because they have to not only understand the set of development technologies and the customer’s requirements, but also understand the design and uses of the platform. In exchange it is expected that the implementers will leverage the platform well enough that the cost of the implementation will still be lower than building a custom solution. If not, it should be true that the total cost of ownership of the system over its life will be lower by using the platform than if it was custom.

If neither of these turns out to be true then the project is a failure on a certain level.

A model where SharePoint becomes a service to custom standalone systems significantly changes SharePoint’s value proposition because it is a deliberate decision to assume the dependency on SharePoint and all of its costs while simultaneously rejecting a big chunk of the features that you can use to offset the costs of ownership. Presumably your solution will still need things, like a user interface, that you could have gotten mostly or even completely from the platform. Perhaps a less expensive web developer could build those for you, but no matter what the hourly rate is, you still built something to use in place of something for which you’ve already paid.

This is a Design Problem

One thing Andrew and I agree on is that a good customization should be as isolated as possible and that a good design should actively address this concern. I think there are times when it is appropriate to treat SharePoint as a service. IQApp Central is a standalone provider hosted solution. It exists outside of SharePoint because we thought the design was most appropriate. On the other hand, add-ins like Instant Practice Manager, the Board of Directors Site, and IQApp Parts are integrated into SharePoint sites and fully integrate the platform. The previous few posts touch on how we isolate AngularJS and Boostrap in IQApp Parts so check those out if you are interested. Keep in mind that this is by no means the only possible way to isolate integrated functionality.

A Note on Patterns and Practices

Andrew says that he thinks Office 365 Dev Patterns and Practices is an example of trying to have your cake and eat it too. I say that it is actually the first time the SharePoint team has made an effort to directly engage and meet customers’ needs with regards to real world scenarios in quite some time. I dare also say that had the program existed the sandbox model would have never been born and the initial forms of the cloud app model would probably have looked very different from what we actually got from Microsoft. I recommend that you check out this post from Vesa Juvonen and decide for yourself if they are serious or not.

This is also a Trust Issue

At the end of day this is also a trust issue. Do you trust Microsoft not to make changes that cost you time and money if you integrate with their platforms?

You shouldn’t! I can guarantee that they will do things to make your life harder at some point in the future.

The same is true of any vendor that offers platforms with a long life span. It doesn’t matter how big they are. Times change and software has to evolve. Sometimes they will make a hash of it. Sometimes the vendor will screw up so badly it will even kill the platform.

If you trust Microsoft to avoid wrecking the bus, then acknowledge the potential bumps in the road and exercise defensive design, but wring every last dollar of benefit you can get out of the platform in the meantime. Moving everything outside the platform is not the way to do it.

If you don’t trust Microsoft to avoid wrecking the bus, that’s OK too, but move on. You are building custom solutions. Surely you can do better and more cheaply than SharePoint as a data and file storage service!

–Doug Ware

7 thoughts on “Architects: SharePoint is a Platform, Treating it as only a Service is a Mistake”

  1. My view in these opposite perspectives is somewhere in the middle (he, I’m Dutch). In the past, the SharePoint community regarded and applied SharePoint as a 1) functional, 2) development and 3) deployment platform.
    The first still holds, for me it is ridiculous to eg not utilize the OOTB DMS features if you have SharePoint at hand in your company.
    The latter 2 however have changed: we can still use SharePoint to “build upon”, but we must not do that anymore by deploying to SharePoint infra. So for development, less to even no more regard / utilize SharePoint as platform in favor of services model; and as deployment model the SharePoint farm is in future-proof sense an absolute no-go.
    Note that also on functional level, Microsoft can unpleasant surprise with functions before strongely advocated, have disappeared in the next version. This is ao the result of the long design and development timespans for SharePoint as product itself. The bare essence of SharePoint 2010 was designed even before the year 2007, 2013 before 2010?
    In the IT world that is an eternity, the world is completely different.
    That is one of the charmes and benefits of online products, it enables SaaS providers (Salesforce.com, Microsoft, SAP, …) to respond in much shorter timeframe to new IT possibilities and changed market requests.

  2. Good post, Doug. I agree with you. If SharePoint is just a service, then it is a very bad one: a non-relational system of tables that, weirdly, are called “lists”. Its the other parts of the platform, including the built-in authentication as well as the UI, that make it something special. That, in the end, is what end users value about SharePoint. That’s what they are paying for.

  3. Great post Doug! I started reading this thinking it was a rebuttal but think we’re actually much closer in mindset than you may think. One thing I do want to point out is that I don’t think it’s an either-or choice in the sense “do you trust Microsoft or not” when you choose where you want to build.

    I trust Microsoft, but I am going to pick the right tool and platform for the task at hand. My point was to get people who seem to think about building for SharePoint as the default choice all the time when a new project comes up to rethink that. I see way too many “SharePoint developers” who when posed with a challenge always go straight to building something on top of SharePoint when it does not always make sense. Does it bring value to the project you’re working on? Then use it… but to use it doesn’t mean you have to build on top of it… I simply prefer to build outside / beside it and have hooks into it as it makes the project easier to develop, test, deploy, scale and manage going forward.

    -AC
    @andrewconnell

  4. Doug between you and AC the points are very well expressed. I’ve been kicking around the service vs. platform discussion ideas, and I guess where I am at is this. SharePoint certainly can be looked at in general as a platform (but this view more gravitates towards on-prem imo) or a service (this view more gravitates towarwds O365 imo).

    However, starting to look at them as a DEVELOPMENT platform OR service is where it starts to become more problematic. SharePoint SaaS is a tightly coupled platform with software available in the cloud. Then the progress in O365 seems to be going towards what I suppose could be described as a PPAAS/PSAAS – productivity platform/software as a service. But a contained one. And that term doesn’t exist yet.

    One thing more recently SharePoint doesn’t seem to be whether or not your view is plat-formy or service-y is on the CIO’s radar for appdev projects. As a collab Saas or product – sure. As a ERM replacing Filenet – sure. But as an appdev entity to use as a basis for building solutions, it currently has less to offer even than in the past. There is a path. Build what you want – provider hosted and tie in to authn/z of SharePoint. (I actually like this path for quick corporate authn/z in an app for O365) Build client-side limited solutions in javascript (which is where I’m playing around mostly currently). But this path forward is very limited and won’t draw people to go this route on projects.
    All the “you got your chocolate in my peanut butter” service/platform communication is NOT a high level supportable path forward for the CIO and will pretty much delay further investment in the approach.

    SharePoint, however, does not “suck”.

    There are several prevalent movements to make it not so. Jeff Teper returning will IMO help product vision not get lost. Aspects are being re-tooled. MS has talented folks there. I saw Jeremy Thake’s post on the Office Angular generator – a great open source step by MS dev team.
    Perhaps more of the product space can be carved out and exposed in that fashion. The PnP team with Vesa, Wictor, and so many others in github.com/OfficeDev is advancing the product and options for dev alongside.

    I actually think some time will improve all this. Things are gravitating towards good open source citizenry, design, and resource use. I saw at least one v- contributor to some of the repositories in OfficeDev.

    So is it a platform or a service?

    I guess the answer is it depends. SP for me from 2003-2007 was a content collab repository. I used a separate wiki because it didn’t have one early on. From 2007 – 2013 it was a platform to gain me advances in building solutions. Now it seems to be gravitating back towards a content repository more for me anyway.

    What does this mean for me?

    More work with the revealing module pattern in javascript and less work troubleshooting the FIIM service ;).

Comments are closed.