Giving new life to legacy systems: Tips for campus leaders

Nearly every higher education institution depends on a core administrative student information system (SIS).

Because the SIS sits at the center of so many of the day-to-day operations of managing students, courses, and grades, it becomes extremely important, expensive to operate, and hard to change.

Every software system has limitations, of course, and system administrators soon find they need to either modify the way they work or modify the SIS. Because changing the way people work requires changing human behaviour, changing the software is often simpler and more expedient.

Over time, these changes accumulate. Eventually, the resulting complicated and deeply embedded system can no longer support modern interfaces and new ways of doing business.

At some point, campus leaders find themselves investing in the complex, risky, expensive, and politically fraught process of replacing their SIS in the hope of providing better service to students, improved access to data, and a more flexible technology environment for the future.

It’s too soon to know whether or not the emerging generation of Software-as-a-Service (SaaS) systems will meet the promise of better service and longer-lasting technology, since the long-term benefits are not yet proven.

However, the decision to replace an SIS generates unavoidable costs—primarily financial, but also political—especially at a larger university or university system.

Every higher education leader understands that financial and human resources will always be limited and that the money and energy needed to replace an SIS leave fewer resources to invest elsewhere.

But eventually legacy systems no longer match campus needs, and the drumbeat of “replace the SIS” becomes too loud to ignore.

The California State University (CSU) operates a complex and expensive SIS environment, with a single software system currently servicing 22 campuses (23 by the end of 2021). While these campuses all use one product (PeopleSoft from Oracle), the code base for the system is modified first by the central system office and then by the various campuses, representing 15 years of accumulated changes in some cases.

In this environment, there’s a natural appeal to the idea of tossing it all out and starting over.

However, after a careful review, technology, administrative, and academic leaders decided in 2018 to postpone consideration of a new SIS system, partly because they felt that the current generation of Software-as-a-Service (SaaS) systems was not mature enough to meet institutional needs and that it is too soon to know whether the emerging generation of SaaS systems will fulfill the promise of better service and longer-lasting technology.

In the meantime, the CSU needed to address the demands for digital transformation and improved student outcomes.

With this motivation, we developed a strategy to mitigate this problem. Although there are some special circumstances at the CSU, our overall strategy and tactics can be emulated elsewhere, including at many smaller institutions.

In fact, if these strategies can work at the CSU, they can work almost anywhere else.

Let’s start by considering the ways in which legacy systems are found to be inadequate or suboptimal. The common frustrations include the following six issues:

1. Integration: Legacy systems, designed to work as monoliths, are difficult and costly to integrate with modern SaaS solutions.
2. UX: Dated user experience (UX) design doesn’t meet students’ expectations and hinders staff and faculty.
3. Data: Complex relational databases make it difficult and slow to obtain desired data.
4. Scalability: Older SISs were not designed to scale dynamically using virtual or cloud resources.
5. Outdated models: Assumptions about academic structures—for example, traditional design of terms and degrees—may not match the needs of a modern institution.
6. Product end-of-life: Vendors eventually stop providing software updates, creating security and operational risks.

The CSU has embarked on strategies to address most of these issues. Here’s how.

Integration

Integration refers to the connections between the SIS and other campus systems, including learning management systems, human resource systems, library services, parking and dining systems, and system directories such as Microsoft Active Directory.

The CSU is in the early phase of developing an API that will simplify integration with our PeopleSoft system across 23 campuses by 2021, eventually extending beyond IT departments to include staff, faculty, and even students who want to develop innovative interfaces.

By developing an SIS API, we will greatly simplify SIS interaction and abstract it from the underlying software; eventually, when most or all interfaces are via API, we will be able to change the underlying SIS while minimising the impact on these integrations, thus reducing the cost of a future SIS replacement.

An important positive impact that we hope to realise via our integration strategy is the modernisation of our approach to software development.

Traditional, legacy software development, while it has been successful in many ways, is slow and inflexible, requires a large investment of time and effort, and often cannot accommodate the expected rate of change in a modern institution. Developing more agile approaches may be possible, but this is a difficult transition with the tools available for legacy systems.

Our integration layer will give us the opportunity to train our experienced software staff to use the tools of modern software development. In addition, we create opportunities for a new generation of developers, already accustomed to using APIs, to bring their innovative approaches into our environment.

We can even benefit from the efforts of the many students already familiar with working with modern tools to create mobile and web applications, and we can crowdsource new development where appropriate.

UX

Poor and outdated user interfaces represent another motivator for replacing the SIS.

Based on legacy models of a text-based computer terminal, student information systems have been updated to operate on the web and are just now beginning to provide adequate interfaces on mobile devices.

Because of the computer terminal (aka “green screen”) legacy, users often have to navigate through a long chain of nonintuitive “screens” and complex menus, clicking from one place to another to complete even a simple transaction.

Students (and others) find these screens inscrutable, slow, and hard to use.

While newer SISs generally offer a much better user experience, they still typically suffer from their design as a “silo” within the campus infrastructure. Students will register for classes perhaps 15 or 20 times over their four or five years. Why would they want to “go to” a special system for this purpose rather than having the registration process integrated with other campus functions they may access more frequently?

Many campuses have developed one or more campus apps, typically designed in a “mobile-first” paradigm; with this approach, it makes more sense to integrate key SIS functionality into the mobile app or portal. And the most natural way to create such an integration is through an API.

Hence, creating a comprehensive SIS API supports not only integration in general, but integration in the development of an improved student (and faculty and staff) user experience.

Arguably, allowing access to the SIS via an API is more flexible and “future proof” than choosing a new SIS, which will have embedded within it a model of user interaction that may or may not be consistent with the overall user experience a campus is creating for its constituents.

Thus the power of the SIS API is that it supports both internal integrations and improved user experience.

Data

Users of the traditional SIS have often been frustrated by the difficulty they encounter in accessing data for reporting, analytical, and predictive purposes.

Many campuses have addressed this limitation by creating data warehouses, to varying levels of success. Even a well-designed and implemented data warehouse is expensive to build and operate and tends to lack the flexibility needed over time to answer new questions that were not anticipated when the original data warehouse was designed.

At the CSU we’re developing a newer and more flexible approach, similar to what Vince Kellen proposes here.

A data lake in an Amazon Web Services (AWS) cloud keeps a complete copy of the entire set of updates over a 24-hour period, going back for an entire year.

This comprehensive data store can be used with virtual query tools, such as AWS Redshift and others, to allow users to construct queries to any question that the data can potentially provide an answer for, without requiring data warehouse designers to know in advance what these questions will be.

Modern public cloud tools enable this approach at a large scale and at a manageable cost.

At the CSU, we’re optimistic that this new approach of data abundance, rather than data scarcity, will help reduce the frustration over accessing the data in our legacy system.

Scalability

Scalability refers to the ability to adjust the resources of a system dynamically based on demand.

This is one of the cardinal features of cloud computing, and it fits the usage of an SIS perfectly. The sizing of an SIS is typically based on peak demand, which may be the first day of classes or the last day to make schedule changes.

If an institution’s system contains enough resources to manage all the peaks, then most of those resources sit idle during other times. Cloud computing offers a pay-as-you-go model, potentially offering lower costs and better performance under peak loads.

Because legacy systems were designed before the cloud was developed, they typically were not architected to take advantage of the affordances of the cloud. Simply moving legacy systems to cloud hosting may serve some purposes, but doing so will often cost more than a traditional model and won’t necessarily provide dynamic scaling.

The CSU has chosen a hybrid approach; by moving from a traditional, hosted data center model to a cloud hybrid data center, we have begun to enable certain types of scaling in our environment.

First, the three-tier architecture model used by most legacy systems contains elements that can take advantage of the cloud without major modification.

While the database layer typically operates in a static environment, web servers provide the front end, and these can become cloud-based. In our environment, we are developing a hybrid in which those elements that lend themselves to cloud containers can be expanded up and down dynamically as demand shifts.

In addition, we are adding the dynamic provisioning of test-and-development instances in the cloud. This feature is supported by database virtualisation (see, e.g., Delphix), which enables a small portion of the core database to be replicated in the cloud while most of the data “stays home” in the hosted environment.

This will accelerate system development and testing by allowing for new development and test instances “on-demand” in the cloud without requiring the resource management needed in the past.

In conclusion

The last two issues noted above—outdated models and product end-of-life—are somewhat less amenable to the strategies described above.

To the extent that higher education moves away from traditional models of terms, courses, and credits, the assumptions embedded in a 1990s model of higher education will become progressively obsolete and will not fit the evolving business model of our institutions.

However, based on current trends, we don’t see this change coming to our institutions in a substantial way in the near term. Product end-of-life could make the existing system too expensive and risky to maintain, so it’s a real threat; but at this time we expect to have close to another decade before we hit this wall.

For many higher education institutions, replacing an SIS may become inevitable in the long run.

In the meantime, using strategies to extend its life while eliminating many of its weaknesses can represent good stewardship of institutional resources.

This article has been republished from EDUCAUSE Review under a Creative Commons license.

To better suit the needs of our audience, U2B has shortened the original article and adapted it to our editorial house style.

Readers may read the original version here.