Overview

Background

Application Programming Interfaces (APIs) are reusable connectors by which one IT system can access data or functions provided by another. 

The University’s central IT systems are a valuable source of data.  There is considerable demand to make this data available via APIs to user-facing systems such as MyEd, to school-based systems, and to innovative projects. Currently, there is no easy or standard way to access our data. When staff and students look to produce innovative new projects, they often end up having to use CSV files, or static data, which is very limiting. ​Innovation is stifled by these limitations.

From the current strategy of harmonising the University portal and web site, to access to open data and the ability for schools and departments (including those within IS) to rapidly and consistently develop applications, it is clear we need an implemented strategy for consistently delivering data in a robust, secure manner.

An internal IS innovation project, API004, developed a number of microservice APIs that would, if deployed to production, provide programmatic access to central University data. This technical work has been successful. It includes a security framework (based on OAuth2), technical standards (using JSON and REST), and documentation (using Swagger). 

This service will establish an authorised API service, which is an API which one must first authenticate to use, and which then authorises each action based upon who is attempting that action. In computing, authentication is the act of proving who you are; authorisation is deciding what you are allowed to do. For example, an authorised API for Learn (not part of this project) might be a web API authenticated with EASE and might have a getGrades() function. To use getGrades(), one must first authenticate (provide a username and password or else already have an EASE cookie). After that, a lecturer could call getGrades() and fetch all of the grades for all courses where he or she is an instructor (but not others). A student using the same function could only fetch their own grades.   

Scope

1. This project will put in place the associated service management and production support framework, so that APIs delivered by the API004 Innovation Project can be fully supported.
2. This project will deploy one of the APIs created by API004 into production as an operational service.
3. The API to be deployed will be Events Booking.  A second API (to be determined based on business priority and cost) may also be further developed and deployed if project budget allows for this - Student Systems, Library and IS Alerts are potential candidates.
4. The project will deliver time-bound enhancements to the Events Booking API as required. The amount of effort for developing functionality is strictly limited.
5. Service Management and Production Management will take on support of the OAuth2 service implemented by the WEB010 project.  This OAuth2 service provides the authorisation functionality for the APIs and this project will provide clear documentation for service owners and API users describing how this is implemented.
6. The project will consult the LMP006 and WEB010 projects regarding APIs that have been created for those projects using the same technology framework.  If the data owners agree, it should be possible to make those APIs generally available using the new service management framework (although this would be outside the scope of this project).  Otherwise, those APIs will be maintained as part of the specific systems for which they were developed.
7. The project will build an API-specific environment onto a VM.  The project will determine whether this and future APIs will be deployed to existing VMs or whether dedicated VMs are preferred.  

8. A small business analysis task will be undertaken with Student Systems to gather any requirements for the API framework that would be needed before releasing a generic API for student data, in particaular in relation to security and authorisation.  The project will not cover general requirements gathering for a student API, just those requirements that may require enhancements to the core service or infrastructure.

Out of Scope

1. Deployment of microservices outwith the selected operational area.
2. Development of additional APIs (the expectation is that a funding bid to the Digital Transformation fund will be made to support future development of APIs if required)
3. Delivery of OAuth2 server (this will be delivered by WEB010)

Objectives

Deploy one API microservice into production that will assist the selected operational areas in the execution of day to day activity. 

Deliverables

Deliverable 1: A (generic) service for Enterprise Data Services (Must)

Deliverables

1. Document describing support arrangements
2. Service Level Agreement
3. Operational Level Agreement
4. Web page describing the services
5. Application & Data Architecture Document
6. System Description Document
7. Technical Architecture Document
8. Change process which includes description of how new APIs are added, API version management, and the API lifecycle process
9. Handover to support activities / configuration of UniDesk as required
10. Security framework model documentation and usage guide.

Deliverable 2: Infrastructure for Enterprise Data Services (Must)

Deliverables

1. Puppet script for building per-API environments.  These environments will be deployed on existing VMs.
2. [OAuth2 server - this will be delivered by WEB010 and is listed here for completeness but is a project dependency only]

Deliverable 3: Service 1 (Events Booking) (Must)

  Deliverables

1. Production environment
2. Time-bound improvements to API (as required)
3. Deployed service
4. Supporting documentation (supporting documentation for the specific API)
5. Sign-off from Service Owner

Benefits

The existence of APIs will allow us to separate user interfaces from the underlying IT systems, creating a joined-up user experience that is focussed on the user’s needs rather than asking them to sign in to multiple different systems.  Accessing data from common APIs will make sure that data is used consistently across multiple applications, and ensure that data is accessed in a secure, controlled, and auditable manner.

Success Criteria

The project will be deemed successful upon delivery of one live service in production, with processes for support, and communication to potential users.