A template for digital transformation in the Post COVID World
Until COVID hit the world, many business leaders wanted to invest in technology to drive their businesses, yet the reality did not reflect this ambition. Technology remained in the side lines, with IT teams spending their time to manage updates to existing software systems, apply patches and perform often tedious and money guzzling manual interventions.
COVID has made it evident with many examples that technology is the fast lane on which functions across the business should be driving on. Universities are no exception. Old software must make way to new API-led architectures to improve student and faculty experiences. It is no longer sufficient to just rewrite the Web User Interfaces, and record classes to upload to content delivery platforms. Nor is it sufficient to have a Drive location where documents, spreadsheets and PowerPoint presentations are stored and shared.
Universities in the UK rank among the best globally, and attract students, researchers, faculty and other staff from around the world. These institutions can offer an example to the rest of the world by adopting new technology systems that are secure, open, intelligent and continuously improving. The business and technology leaders must also get ready for faster changes to evolving technologies due to the democratisation of the Internet.
Many universities have SITS, which is an on premise student records management system. The data is stored in a cluster of databases. Some universities have data access through a Web Services layer on top of the database. Applications in such architectures are tightly coupled and making any change is going to be challenging. Exposing the data over the internet is going to be difficult. There would also be additional issues with scalability, availability and response times.
Today however, it is expected that the data is shared through dynamic mobile and web content and also with external vendors beyond the premises of a University server room. Business processes change frequently and hence the product changes need to be applied at pace. An API-led approach would easily address such issues and requirements, liberating IT teams from outdated tasks and helping accelerate the business transformation of Universities.
The architectural approach below showcases an API-led connectivity template based on MuleSoft’s Anypoint Platform, that enables hybrid, multi-modal learning and teaching experiences.
As can be seen in the diagram above, from a technology perspective, the APIs (microservices) are split into three layers to support loose coupling, reusability and domain-led integrations across the enterprise’s systems. These are logically grouped as System APIs, Process APIs, and Experience APIs.
System APIs connect to the underlying Systems of Record (Salesforce SaaS, Workday, Databases etc) and expose data in a canonical JSON format securely. Any changes to the Systems insulate changes to the layers above. Furthermore, the System APIs become highly reusable as the application network organically develops.
Process APIs serve to connect to multiple System APis, orchestrate, transform and enrich data.
Experience APIs are specific to the consuming channel (Web, Mobile, Devices sending data etc). These APIs support the authentication, authorisation and data format of the consumer application. By doing so, the application security and isolation is taken care of.
MuleSoft provides a unified platform to develop and deploy APIs in Cloud, Hybrid (Runtime Fabric) and On-Premise. Universities can choose the option that best suits them. MuleSoft is a low code platform that has a wide range of prebuilt connectors that make it easy to connect to Cloud or On-Prem back-end systems (Databases, SaaS apps, File Systems, APIs, B2B etc) which in turn improves the speed to develop and thereby increase time to market (TTM).
In the template above, the APIs are scoped based on “domains” and “subdomains”. This makes APIs agile, reusable and easy to discuss with the business teams. For example, a set of “Student Web Experience” APIs can be exposed to Web Application developers which will make the journey of a student smoother. The Process Layer can orchestrate connections to Salesforce to get student information and course details from Course Plan systems to service data for the APIs. Similarly, a set of APIs can be deployed for teaching experience where the course content comes from media content in Dropbox, and assessments from the Blackboard LMS application.
The channels of communication (Email, SMS) and payments can be considered as horizontal use cases that apply to many stakeholders (students, faculty, non-staff, vendors etc) within the University. The APIs for these systems can be designed, developed and published as common assets on Anypoint Exchange from MuleSoft. Various web and mobile applications that can serve students, university administration, and third-party vendors would be able to consume these APIs to make financial transactions. It would thus be possible to allow multiple payment methods (Card, PayPal, ACH Wire etc) online and physically which can improve the user experience. For simplicity, the template has the Communications and Payments Process APIs as being used by only a couple of end user apps, but these can be cross cutting across the business functions.
In terms of security, access controls can be set up using OOTB policies available from MuleSoft within the various layers of the APIs. Data can be secured using the industry standard practices through HTTPS 1.2, encryption methods, and OAuth2. Identity Providers such as Azure AD and Okta can be leveraged for enforning the authentication and authorisation as defined by the security policies of the University.
For successful translation of the template to reality, the University must train its IT and Business staff in Agile methodology and deploy relevant tools. The technical teams must use CI/CD in order to rollout smaller features (APIs) on a two-week sprint cycle.
Data from current systems can be migrated (either one time or on functionality basis) to the new systems. For example, faculty data, as it would be a smaller dataset, can be exported to Workday and the use cases involving teaching can be handled using new MuleSoft APIs. For other cases, MuleSoft can be used to route requests to either the legacy system or the new backend application depending on the business case (APIs will get alumni/historic data from legacy and data for current students from Salesforce). The Strangler Design Pattern is best suited for such purposes.
While it appears that there is a crisscross between APIs, the design helps the faster plugin and plug out of APIs depending on the business requirements. New services can be added with ease by incorporating CI/CD best practices.
To find out more about implementing an API-led architecture utilising WHISHWORKS’ frameworks and templates for Higher Education, give us a call, or email us at email@example.com
Other useful links: