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!