Omicron Llama

Coding all day, every day.

Supporting Office 365 Customisations

So it seems that people are beginning to bear the ugly side of hosting solutions on a hosted platform (that you don’t own) – and that’s having the platform updated without being informed!

This is all well and good, because the features that Microsoft control are continually being tweaked, and if they don’t work as expected the onus is on them to fix it.

But when us Partners come along and tweak things further, sometimes things can break. A good example of this recently was documented on Marc Anderson’s blog: http://sympmarc.com/2014/01/23/office-365-update-changes-display-name-on-required-fields/

So, when we’re managing support to our customers on Office 365, how can we mitigate the fallout of this?

Well, thanks to Cory Peters, there’s a way we can get the version number a specific tenant is running on: http://corypeters.net/2013/07/getting-the-product-version-for-sharepoint-online/ (He forgot to mention that you must visit the magic URL from the top of your web application).

https://.sharepoint.com/_vti_pvt/buildversion.cnf

With that key piece of information that you get from there –

Record this version number in your go-live handover/completion documentation.

Certified working with buildversion:

Now when your client’s customisations suddenly start breaking (after your warranty period) you can make reference to this version number and see if it has changed for your client’s tenant.

How you handle this is up to you. For example, in the cost that you compile for your support contract, you could allow X number of days for investigation due to ‘undocumented updates by Microsoft’ (basically, broken functionality caused by changes in the buildversion).

Another thing to do is to inform your customer that some functionality that you build may fail due to Microsoft updates – as long as you somehow clarify what part of your solution could break in future updates that you would need to rebuild/rework (e.g. “All lists will work fine, but this form where we have validation might need to be tweaked if it stops working”).

You don’t really want to end up stiffing your customers (“hey, MSFT broke it, but I’ll fix it for your at our full day rate, like it or lump it!”) – well you could but you better be good at customer service, otherwise you put yourself AND Microsoft in a bad light.

These are early days so it will be interesting to see how other Partners will be handling this rather “Agile” approach to platform stability!

2 thoughts on “Supporting Office 365 Customisations

  • This, my good sir, is a pile of sticky wickets.

    Sadly, we can’t treat this as something all that new. Software vendors in general – Microsoft specifically with SharePoint – have been breaking software with updates as long as there has been software. And implementors have been playing catch up ever since.

    Sure, in certain circumstances, with updates like Service Packs (SPs) or Cumulative Updates (CUs) we can decide when to apply them. But that doesn’t mean they won’t cause problems.

    The discipline of software development is ever-changing. We’re heading toward an age of continuous improvement and automatic updates. That’s great because we’re always getting new and improved (we hope!) functionality. The down side of those benefits are issues with existing code and functionality.

    To me, the days of fixed bid, warranteed software development need to be over. We’ve seen enough examples of that approach failing anyway (I think I read a statistic like 72% of efforts failing somewhere, but I could be dreaming).

    Our customers don’t care *why* something breaks – they want it to work. Someone needs to fix it when it breaks, and that takes resources which cost money.

    The relationship between us vendors/consultants and our customers has to be built on mutual trust. We need to own up when our code breaks and explain why. We also need to be fairly compensated when we fix those issues. If we charged a lot up front, we should sometimes eat those costs. If we can trace the issue to a change from Microsoft, it should be open for discussion.

    Remember that “partners” often steer clients to The Cloud, selling it as a panacea for all current ills. We need to own up when that decision seems like a shaky one.

    All that said, Microsoft needs to get a *lot* better at offering “services and devices”. They are having a lot of growing pains on both fronts. Testing and quality needs to be far, far better than it currently is. They are working on it, but in the meantime we’re stuck in the middle.

  • Monzer Hijazi says:

    I understand the benefits. However, I do think that there is room for better communication from Microsoft when updates are coming and what they might be changing. I would rather give my client a heads up that something is coming rather than having to put out a fire.

    Salesforce is good when it comes to updates, they have an “Updates” page and give you the ability to quickly create a copy of your current eniornment to use for testing and install the update. That way you can address these changes and manually hit the update button. Salesforce gives you a set amount of time to install the update or they do it for you. I don’t think that following the same technique would be too tough.

Leave a Reply

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