To bridge the gap and improve the user experience, Deakin decided to build an Applicant Portal to address some of the shortcomings.
In particular, the SMS suffered from certain technical constraints, an inability to deliver the insights expected, a lack of visibility of the progress of student applications, and poor data quality.
An API-led approach was adopted, with the goal of streamlining student and back-office processes, reducing the end-to-end process time, and providing visibility into the entire student lifecycle.
A project team – including a user representative – remapped the user experiences and built the APIs needed to expose functions to the university's back-end systems.
Following the CAUDIT reference model to help ensure the APIs were reusable, the team identified and built 41 APIs, covering areas such as curriculum, student applications, scholarships and contact details. Some 90% of these APIs have already been used for projects other than the Applicant Portal.
The SMS's own API was immature and unsuitable for Deakin's purposes, so the team used MuleSoft to create APIs that trigger custom stored procedures to access the underlying Oracle databases.
The resulting Applicant Portal runs on AWS and proved a great success. Usability testing showed a 260% improvement, the number of users increased by 69%, and 25% more applications were submitted.
Employees in the back office benefited as well. For example, the portal validates data such as addresses, so they no longer have to worry about data validation and cleaning up, and it integrates with Salesforce to reduce the effort needed for lead generation and application lifecycle management.
Deakin now uses MuleSoft to manage more than 150 APIs, which are used by around 90 applications including parking permit management, the university's public web site, ServiceNow workflows, and various faculty-specific applications (eg, to generate lists of students enrolled in particular units).
Great care is taken to build these APIs at the entity level so they can be safely reused.
API security and authentication is policy-based and handled through MuleSoft. Applications must be registered to use particular APIs, which are subject to data use agreements and are under the control of data stewards within the relevant organisational unit.
Deakin University eSolutions integration solutions and design manager Peter Dimovski says he went through "a long journey evangelising an API-led approach," but the outcome was worth the effort.
Some of Deakin's developers initially saw APIs as hurdles, but they now see the advantage of being able to focus on function rather than integration issues.
"It's been really good," he says.