Tertiary talk


Microservice Architectures: the future of student management systems?

Tertiary Talk - November 2018

Traditionally the implementation and operation of a Student Management System (SMS) has been a complex, expensive, and error prone journey. There have been a number of failures where SMS projects have gone off the rails costing large sums of money and vast amounts of time.

These are what we call "monolithic" systems; they are packaged software containing a number of modules that is sold by a single vendor and present a number of issues such as:

  • The system must be upgraded all in one go. You cannot cherry pick which parts to upgrade, and these upgrades are often as expensive as the original implementation.
  • The system must be scaled as one unit when demands on it are high; for example, you cannot add more capacity to the Student Record module independently of the rest when Course Registrations are underway.
  • An error in one part can bring down the whole system as they share a single runtime.
  • Changes are often slow, hard to achieve and limited to a niche set of skills.

So if Monolithic SMSs present issues, what are the alternatives?

Microservice Architectures offer us one alternative approach based on decentralised, loosely coupled services that each perform a specific task.

  • There is no single point of failure as the independent services are isolated from each other within their own runtime.
  • Being independent, these services can be scaled or upgraded independently which increases the agility and stability of the overall solution.
  • Microservices expose their data via APIs and are typically "headless" - that is they don't have a user interface - but a web interface such as a Portal can interact with them.

In the University context, a Microservice might be solely concerned with Student Data. It has the database of all Students and other Microservices or systems that want the master student data would call it.

So Microservices sound interesting but where do we start?

A great way to dip your toe in the water of Microservices is to create a view of what your data looks like so we know where the boundaries of the Microservices might lie. We call this a Domain Model and it represents all of the data entities that are important to a University. There are many existing Models that University's can leverage to get a head start. One example is the CAUDIT data reference model.

Once we understand what the Domain looks like we can begin to carve it up into smaller parts. These are termed "Bounded Contexts" and each one might represent a single Microservice. With our list of our Microservices we can plot a roadmap for how we might transition to our target state architecture.

I have no interest in building a new SMS, so what's in it for me?

Building a new SMS is probably a bad idea. Moving functionality away from an aging SMS in order to make it less customized or more stable is a great idea. Often organisations aren't creating Microservices in a "greenfield" environment where the solution is being created in the absence of an existing solution. Usually there is an existing Monolith that needs to be replaced or worked with, and our Domain model guides us with a strategy for replacing it incrementally. One common approach is referred to as "thinning out the core." This approach gradually takes functions from the core (i.e. the SMS) and implements them one at a time in a Microservice. Calling systems then rely on the Microservice for that function rather than the SMS. In this way we can incrementally remove functions from the SMS and seek to either retire or to “keep the lights on” the SMS while still being able to innovate using our new Microservices.

Microservice architectures rely on DevOps (an approach that conflates Developers and IT Operations) and all of its practices and tools in order to be successful. It is not enough to merely create a Microservice, we are seeking to actively and incrementally evolve it over time as the business requirements change, or the scope of the Microservice grows. As such we need to ensure that these changes are made quickly with the minimum of risk (we've got a University to run after all). DevOps provides this framework with its focus on small incremental changes that are automatically tested, and deployed rapidly to production environments without much human intervention.

This is a great concept but it will never catch on right?

Microservice Architectures are being rapidly adopted in many major industry core systems. Take Insurance - several of the key vendors in that space are adapting their products to Microservice architectures to meet the demands of their clients and actively promoting them as supporting this approach.

Is now the turn of the SMS vendor?


Deloitte Platform Engineering specialises in the re-engineering of complex core systems into API-enabled Microservices. Reach out for more information.

Did you find this useful?