The SharePoint Toolbox Series – Futureproofing

One of the often touted virtues of Software as a Service delivered via the Cloud is always having the latest release of whatever you may be using. That does sound pretty cool… I mean, who wouldn’t want the latest and greatest? Not only are you getting all the cool new features, but you are also getting bug fixes, security updates, speed enhancements, and there’s one more… uh gimme a sec… oh yeah… all your stuff broken. If you ask any IT professional working for a mid to enterprise sized business what he fears most about cloud, a frequent answer is “upgrade control”.

Picture this: You have deployed SharePoint Online for your organization. You were smart and hired a professional SharePoint development firm to help you get the most out of the solution. You did not however, hire Forceworks, it’s okay, it happens. Anyway, after a short while you decide that it is time to start pushing the envelope a bit and have your developer do some tweaks. “I would like when someone uploads a new document to have information automatically placed here, and here”. No problem, and without question your developer pulls out his JavaScript toolbox and whittles out a little piece of code and presto… works like a charm. Emboldened, you pass your developer a laundry list of automated functionality you want added.

Over the next few months your SharePoint starts humming and you can’t believe you ever ran your business without it. You start telling all your associates, clients, friends, your mom, your neighbors how smart you were to have made the move to SharePoint and how well you guided the deployment and they all look at you like you are the smartest person in the world.

You come into work one day and see a notice that Microsoft is about to launch one of the updates that they promised would now start arriving at a pretty good clip. You are giddy with anticipation about new features you can add to your mix so, as soon as you are able, you push the button to upgrade and Wham, your world comes to an end. Suddenly nothing works. Your employees are blasting you emails about their inability to work. Your developer says “I’ll look into it”. You start thinking “How could Microsoft have screwed me over so badly?”, SharePoint sucks, this is a disaster! Finally your developer gets back to you with great news, it can all be fixed and it will only take a few weeks and a 5 figure change-order.

“Wow, SharePoint really sucks.”

Could the above scenario really happen? It can, and it does. Does SharePoint really suck? Nope, it is still the incredible tool you thought it was last week. So what went wrong? Your developer grabbed the wrong toolbox.

“No way, my developer has been working on SharePoint projects forever, this is clearly Microsoft’s fault.” No, it isn’t, it is you and your developer’s fault for not understanding the nuances of the cloud. The biggest nuance being continuous updating. Back in the old days, last year, things were a lot different. Before SharePoint went online (and the same can be said for Dynamics CRM Online), if you wanted to utilize either of these technologies, you bought a server, or rented a hosted one, installed SharePoint or Dynamics CRM onto this server on-premise, deployed it, and it would sit there and run forever. When upgrades became available, it was pretty easy to say “If it ain’t broke, don’t fix it” and stand pat. You could scab on all the custom code you wanted. If you did consider an upgrade, after getting a price to rejigger all the custom code, you quickly rationalized that old, but reliable, was the better choice. And you could do that. You could literally drive that SharePoint car until the wheels fell off. Not so in the cloud.

Like it or not, you will be upgraded, and on a fairly regular basis. After spending all that money to fix everything last time, pushing that upgrade button is gonna feel like the President might as his finger hovers over the Armageddon button. “Is this gonna blow up my world again?” So you decide “I just won’t push it”. Unfortunately the upgrade is inevitable, Microsoft has just given you a little bit of ability to delay it for a short while so you can pay your developer a buttload of money to make sure everything will work when your forced upgrade happens.

Okay, I am starting to depress myself as I write this, but in typical “happily ever after” fashion, this story (I know this post has turned into a story) has a happy ending. Here’s the problem. Javascript is an awesome, and fairly simple code to use and master, which is why it is staple in so many developer’s toolboxes. To a JavaScript developer, every customization issue looks like a nail, and JavaScript is their only hammer. Not to pick on JavaScript, every hardcore developer has their code base (hammer) of choice that they pull out to solve any problem. The problem is that SharePoint does not give a shit about your custom code. So when an update rolls out, it obliviously smashes through your deployment, crunching all this foreign code to bits. How do you prevent this?

You must respect the SharePoint

In fact, you must completely bow to it, or suffer the consequences. In the myriad of broken deployments we are called on to fix, we continuously see custom foreign code built to replicate native capabilities. You simply cannot ignore the enormous toolbox of native functionality and plop your Javascript toolbox on top of it and start wailing away. I get that your developer may know his preferred code base like the back of his hand, but activating this shortcut to really understanding how SharePoint works, is gonna cost you… a lot. If you play nice with SharePoint, it can be your best friend. You should also be wary of the third-party addon market, for the same reason. Many of these bolt-on products suffer the same foreign code faults. The good news is that it is not your problem to fix when the inevitable upgrade rolls out. The addon developer has to brunt the cost of rejiggering before you are upgraded, and every now and then this does indeed go off without a hitch. While it is tempting to get immediate access to some awesome third-party capabilities, you could be, and probably are, building a house of cards.

Screw it, I’ll just go on-premise and keep control

Moving in the opposite direction of the rest of the world, is also known as going backwards. There is a reason cloud is so popular, actually several. Not the least of which is cost.

This does not account for the initial costs of hardware, licenses and configuration just to get you to the point where SharePoint Online starts.

SharePoint Online may be the second most important product Microsoft has built for your business after Windows.

Properly deployed, SharePoint Online WILL revolutionize your business. You must thoroughly understand, and respect the SharePoint Online toolbox, and only reach for custom foreign code when you find yourself in a business critical “Can’t get there from here” position. Assume that any foreign code introduced will break on updates, and be prepared for the time and expense of tweaking or completely re-writing it. If you minimize, or eliminate foreign code, your life with SharePoint Online can be blissful. Ask your prospective developer about how they approach customizing SharePoint and if their knee-jerk response is to pull out their foreign code toolbox, run the other way.

The post The SharePoint Toolbox Series – Futureproofing first appeared on Steve Mordue MVP.

Original Post https://stevemordue.com/the-sharepoint-toolbox-series-futureproofing/?utm_source=rss&utm_medium=rss&utm_campaign=the-sharepoint-toolbox-series-futureproofing