It seems my post, Developers, SharePoint isn’t a Platform, SharePoint is a Service created a bit of a stir and discussion. That’s good… discussion is always good! You can see the dialog that was started by checking out the comments at the end of that post.
Doug Ware has a good “rebuttal” to my post in his Architects: SharePoint Is A Platform, Treating It As Only A Service Is A Mistake. I put “rebuttal” in quotes because while it seemed like a rebuttal, to me we’re not really that far off.
Some of the things I said in my post were taken a bit too literally. Make no mistake… I’m not taking anything I said back; I stand by what I said. However I think a little clarification might help. When I say it’s a service, I’m not referring to a service in the sense of data series like Azure SQL Databases or Azure storage or AWS S3 or AWS RDS… some seemed to think I was saying that’s where you put your relational data. Uh… no… no way!
Another thing - the main point in my post a few weeks ago wasn’t to say “SharePoint sucks” as some folks seemed to like to grab ahold of. In no way is that what I was saying or how I feel. Some people said “so looks like AC is done with SharePoint”… there was even a dialog or two on Facebook where some put words in my mouth that I effectively called the Add-in model for SharePoint as good as dead. I have to say, some of it was pure comedy to me telling me what I said and what I meant when the words weren’t on post… I just needed some popcorn to sit back and watch the show.
So What Did I Mean?
When I call SharePoint a service, I mean you use SharePoint for the services it provides to support your application, not to use SharePoint is the core of your application. It was a bit of an extension to the post I wrote a few months ago: Office 365 is a Development Platform: ePaaS. I’m talking about using the services that SharePoint, and Office 365 for that matter, are strong at. User profiles, workflow, document management, collaboration… all that stuff. I wasn’t saying you should look at SharePoint as a service in the sense of comparing it to other platforms like AWS or Azure. SharePoint is not designed as a platform to host your custom applications. It’s primarily built as a collaboration product and we figured out how to, with Microsoft’s assistance over the years, to build custom applications and run them on top of SharePoint
Hold up, you just called Office 365 a platform!
Yes I did… it was a bit of a play on words… both that post from a few months ago & from a few weeks ago. When I say think about it as a service, I mean conceptually. I’m not being literal. I thought that was pretty clear from both posts. It was to many folks, but to those who were a bit confused and took me literal, hopefully you understand now.
My point in my post a few weeks ago was to talk directly to developers who today seem to gravitate straight to SharePoint when a new development project comes up. For too long I have watched developers who have been working in SharePoint for many years gravitate to building on top of SharePoint when they have a new project. My fist point: use the right tool for the right job. My second point: as a developer, you can find much better places & options to build your project on - it’s hard to manage, scale, deploy & test many other ALM or development related things I highlighted in that post.
It isn’t that I’m saying SharePoint development sucks or their development / deployment models are bad or flawed… they might be depending on the solution you’re building but in other cases they might be perfect. It depends! I trust Microsoft, but I am going to pick the right tool and platform for the task at hand. Does SharePoint 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.
It All Boils Down To This
As a web developer, I choose to not build on top of SharePoint because it is easier for me to implement a CI process, test my application, set up automated deployments, put forth a good ALM process… all of those things are easier to implement when I don’t build on top of SharePoint than when I build an application outside or beside SharePoint. If I’m going to use something within SharePoint, I’ll consume it using services.
Is there something wrong with SharePoint? No, it just isn’t built to host applications. It always feels like a bolt-on addition.
I choose to not customize my SharePoint UX by making changes to the CSS or master page. Why? Because of the cat and mouse game we play with Microsoft - when are my changes going to be overwritten by something they did in Office 365?
Is there something wrong with the Add-in model? No… there’s nothing wrong with it. If you have customizations you want to get into your SharePoint environment it’s the best option. However me personally, I don’t like using it to deploy application customizations. It’s hard to automate and proprietary. I personally love the model so many platforms support now where you deploy using Git or set up a webhook where your platform will pull from a Git repo.
What About My SharePoint UX Customizations?
This was a common thing that came up. Many people asked “what about those times my customers want me to change the CSS or master page in SharePoint?”
This mindset that I’ve shared here does not work with customizing the UX of SharePoint. I get you have demands to customize the UX in SharePoint. I just do everything in my power to avoid it. I see it as a minefield. Microsoft has been as clear as they could be that they want you doing as little of this (or none of this) as possible. My outlook: why try to compete with that? It’s just making life hard.
What About Client Web Parts, Add-in Pats or SharePoint Hosted Add-ins?
This came up quite a bit in the comments. There’s nothing worng with these things and they actually follow my train of thought quite well. A client web part / add-in part / app part… all of these things are simply artifacts in SharePoint that are windows into something running elsewhere. Out of the box they are usually IFRAMES surfacing some other web page. Maybe you’re using the PnP AppScript Part… it’s still the same thing - a window into something running elsewhere.
What about SharePoint Hosted Add-ins? I like these a lot… but I’m not building on top of SharePoint. Yes, I am using add-in model to deploy my customizations, but it’s the only & best option to get it into SharePoint. Once there, SharePoint’s only job is to serve up the files… my application runs entirely within the browser as a client-side application.
So the SharePoint Add-in Model (aka: App Model) Isn’t Dead?
I said it above, but to be clear: the SharePoint Add-in (aka App Model) is not dead, dyning, flawed or bad; it is the best option for getting your customizations into SharePoint when they have to live in SharePoint such as SharePoint Hosted Add-ins, client web parts, etc.
In my last post I talked about how we’ve gone through many different deployment models from farm solutions to sandboxed solutions to add-ins… and what next? People seemed to take away from this that I was saying you can’t trust Microsoft. That’s not what I’ve said.
To me what it shows is that we’re seeing things constantly morph over time with each version. Does technology change? You bet… but to see deployment models change when they aren’t addressing things that are important to many custom deployment models (again, the ALM, CI, testing discussion)… that’s what gets frustrating to me. Will we have another model? History shows that’s a safe bet to make. Each one has been so very different from the last one that I get why it’s hard for customers to really buy into a new one.
But My Customer / Boss Says We Need to Build on SharePoint!
Ah… this came up a good bit in the comments. Here’s how I see this discussion - when I get hired (or if I’m an employee at a company) and I get asked to do something that I see issues with, do I just keep my mouth shut and do it anyway?
Personally, I don’t. I think that if you’ve hired me to do some work for you, you didn’t hire someone to bang away at a keyboard and give you some running bits in a few days / weeks / months. I think you hired me for my experience.
If I get asked to build something in SharePoint, I’m going to have a discussion with my customer saying “look, is this really the right way to do it?” First let’s identify what we want to do, not how we’re going to do it. Then let’s look at the options in front of us. My job is to not just sling some code around, but it is also to educate and work with you collaboratively to come up with a great solution.
Summary
Hopefully by now you can see what I mean when I say treat it as a service and not as a platform. In addition, hopefully you’ll see this train of thought I’ve shared in these two posts as an opinion and insight into how I approach development / customization with SharePoint. Is it for everyone & every project? No… that’s painting with too broad a brush… but it’s the default stance I go to when I look to customizing or developing on SharePoint.
