LTI/Best Practice/Issues for Service Providers

From ceLTIc wiki
< LTI/Best Practice
Revision as of 03:51, 18 September 2014 by Admin (talk | contribs) (Version from the original PDF document)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

This section discusses issues relevant to hosting providers seeking to deliver a service using a tool provider application.

Service level agreements

One of the benefits of LTI is that is enables applications to be shared across multiple tool consumers. These may belong to the same institution, or be servicing institutions from across the globe. A consequence of this is that, as the service provider, it makes it difficult to predict service levels when the load from other customers can impact the quality of service being delivered. It may take experience of the application and infrastructure which can quickly adapt to changing loads to ensure that customers are satisfied.


Whilst running a single instance of an application for multiple customers has efficiency gains in terms of maintenance and support, it would normally also mean that every customer must use the same version. Moreover, any move to a new version will be at the same time for all users. Whilst it might be technically possible to build an application such that a single server could continue to run multiple versions, with each customer upgrading independently, the cost of doing so may outweigh the savings of using a multi-tenanted environment and no examples of such an approach are known. In fact, products like Canvas show that institutions are willing to accept cloud-based solutions and have the upgrade cycle dictated to them by the supplier.


Since a single instance of the application may be supporting multiple customers, a backup of the application (source code and database) will not easily enable an individual customer to have their state restored to a particular point in time. Nor is it straightforward to provide a customer with a backup to access separately; for example, for performing analytics or when moving to a different service provider. In this case, tool providers should consider implementing import and export functionality for individual tool consumers; this could even be made available to anyone launching with the System Administrator role.

You are not allowed to post comments.