Planning for SharePoint Online Add-in App Fragility

Posted on by

Does your organization allow the use of Add-ins in its Office 365 SharePoint Online tenant? Some do and some don’t, and one of the reasons that some organizations don’t permit them is that they can break unexpectedly. Let’s talk briefly about why that can happen.

Before the Add-in model for developing custom applications for SharePoint, there was what is now called Full Trust Code (FTC) solutions or farm solutions.  These are deployed to SharePoint servers and have complete access to the SharePoint server side object model.  These solutions could customize the SharePoint user experience extensively and let people create very sophisticated applications.  However, Microsoft tells us from their support experience that these solutions were very frequently capable of breaking SharePoint or slowing it down.

As Microsoft matured in its ability to host SharePoint as SharePoint Online, part of Office 365, they created a new application development model for Sharepoint, the App Model, also called the Add-in Model.  This model has all custom code running outside of the SharePoint environment and using modern web standards such as REST APIs and other kinds of web services to talk to SharePoint.  In this model, custom code can no longer break SharePoint.  However, these custom applications rely on the web services that SharePoint publishes in order to work.  Anecdotal evidence that I’ve heard from a variety of SharePoint Add-in Model Independent Software Vendors (ISVs) says that these web services can change without warning.  It’s not supposed to happen that way, but it does.  Ideally, all changes get introduced in a preview version prior to being “generally available” (GA).  What I’ve heard from ISVs is that they have to test the supposedly stable versions of their applications daily and then rapidly remediate problems when the APIs they rely on from Microsoft change unexpectedly.  You can hear CJ on the Microsoft Cloud Show episode 110 talk about this – he wishes Microsoft was better at communicating about their changes.  Microsoft is working on this, and recently released a Change Log for the Graph API, a key API for Add-in development.  However, that’s not the only API that is used for Add-in development.

So the problem persists, and this is how it impacts a business:

  • A business uses SharePoint Online.
  • A business buys an add-in to meet a specific business need.
  • A department or team within the business builds a business process on top of the tools that the add-in and SharePoint Online and Office 365 provide.
  • Then something changes.
Although the add-in can’t break SharePoint, SharePoint can break the add-in.  When the add-in breaks, the business process breaks.
Thought about business continuity lately?  As part of automating any business process using modern web-based tools, you really need to understand the risks you are signing up for.  The latest quarterly uptime stats for Office 365 are published at the Office 365 Trust Center and the uptime percent for 2015 Q4 was 99.98%. That means .02% downtime, or about 8.5 minutes per month, about 1.7 hours per year.  Any Add-in built on top of Office 365 won’t be better than the uptime of Office 365.  Also, an API change may not count as an outage, in which case we don’t have good metrics on how often they occur.
When you are building a business process automation solution on Office 365, or really on any technology, you need to plan for what happens when the technology breaks. Maybe you determine that the impact is low and the occurrence is low, so you just loose some time and money while people take a coffee break waiting for the technology to start working again.  But if it’s high impact, even if the occurrence is low, you need to have a plan and test the plan, and be ready to implement your workaround when the technology fails.
In a midsize to large organization, one reason to not allow end users to purchase Office Apps (add-ins) from within SharePoint is because of the resulting planning and assessment that these app purchases require.  In the end, it comes down to needing to govern the Office 365 tenant, and manage the risk that becoming dependent on any additional functionality involves. Organizations like these make it the job of their SharePoint Governance Council to define a process for requesting and analyzing the use of an add-in.  Such a process allows the council and the IT department to both understand the business impact of purchasing and using the add-in and assess if this is the right tool for the job from an enterprise (and not just departmental) context.
–Michael