ERP in Higher Education: The Evolution of Student and Finance Systems Integrations

Pankaj Sharma April 21, 2022

ERP's Payments

“History is not just the evolution of technology: it is the evolution of thought.” – James Redfield

Background

In our last article we discussed two trends in the evolving higher education ERP landscape

  1. Higher Education institutions will shift from single-vendor student and finance systems ecosystems to hybrid multi-vendor best-of-breed ERP ecosystems.
  2. Adoption of cloud and ultimately SaaS architectures will gain a lot more traction over the next three years.

We also discussed several related challenges.

  1. Proliferation in the number of student and finance systems integrations.
  2. Bridging business process gaps.
  3. Non-uniform technology stacks and integration methods.

In this article we talk about how Transact is meeting these challenges head-on by creating the next generation of integration technology, that simplifies our integrations and enables our clients to meet these challenges with dexterity and confidence.

All about the Experience!

Transact has a range of products that help clients, the school and its staff, meet the needs of its customers – students, parents and alumni. With our secure payment processing, integrated payments, campus ID (credential-based access) and campus commerce applications, we provide centralized solutions that enrich the academic journey of a student. Our goal is to make it simple and seamless for students to buy, pay and securely access campus resources.

All of this is made possible by the robust integrations built into our product lines. Our integrations span three flavors of campus ecosystems, summarized below:

 

On-Premise

Cloud Hosted

SaaS

Type of Integration

1. API-based

2. Stored procedures

3. Batch

1. API-based

2. Stored procedures

3. Batch

1. API-based

2. Batch (limited)

 

Most flexible. Can be customized at every level.

Moderate maintenance and lower implementation costs.

Lowest maintenance and implementation costs.


The current generation of Transact integration software is robust and high performing, processing and posting billions of dollars in student transactions each year. But as the higher education technology landscape shifts from On-Premise to SaaS and Cloud-based models with ongoing demand for greater flexibility, we know we must take the next step.

To put this in context, we’ll look at the history and evolution of integration technologies, many that are still in use today.

Evolution of Integration Technologies

Integration technologies have been around since the 1980s. In an interesting article [2], Bilgin Ibryam says, “There isn’t a year when certain integration technologies became mainstream; they gradually evolved and built on top of each other.” This evolution coincided with the move from monolithic multi-function applications to distributed specialized applications as shown in the timeline below.

 

Evolution of Integration Technologies

Figure 1: Evolution of Integration Technologies

Data Integration

The earliest forms of system integration were focused on data exchange (file transfer, common database and Electronic Data Interchange (EDI)). Compared to modern real-time functional integration, asynchronous data exchange protocols are relatively simple and straightforward. Data providers and consumers can be separate and distinct processes, implemented using independent technology stacks. Data exchange is still the most prevalent form of systems integration, not only in higher education but across industries

Functional Integration using Remote Procedure Calls

Remote procedure calls (RPCs) were one of the first methods used to implement functional integration between applications. RPCs evolved into sophisticated standards-based architectures including COM, DCOM, CORBA (Common Object Request Broker Architecture) that made integrations language and platform agnostic to an extent [4].

Service Oriented Architecture and Web Services

Starting in the early 2000s, the next evolutionary step was the development of Service Oriented Architecture (SOA) that provided design patterns to make service components reusable via interfaces [3]. The idea was to define standard interfaces that encompass both functional and data integration so that the invoker/client can execute a discrete business process [3]. These services were enabled by technologies such as Simple Object Access Protocol (SOAP). SOAP leveraged the XML specification created by World Wide Web Consortium (W3C) to create a protocol that was independent of the program model used [4] and was neutral to the communication layer such as HTTP, SMTP and TCP. [4] It allowed applications to discover services and associated service provider (similar to searching a phone book), get a description of the associated service and then construct the SOAP message to exchange data with the service provider.

The REST Architectural Style

Beginning around 2010 and driven by the desire for simpler integrations, Representational State Transfer (REST) architectures started gaining traction. REST introduced the concept of constraints that enable the transfer of the state to the caller or allow the caller to specify the desired state for a particular resource. REST is simpler to implement than the SOAP protocol which has specific and detailed XML messaging requirements [5]. The philosophy behind REST is that services are based around resources that clients need to interact with [4]. For example, to gain access to a person’s demographic information, the URL would be constructed as http://<domain name>/persons/123456. Here “persons is the resource and “123456 is the resource identifier. Similarly, using the same construct an authorized application can update or delete a person’s demographic information from another system. REST is the preferred architectural style for integrations today.

Bringing it All Together: iPaaS

With the proliferation of integration technologies there emerged a need to easily connect multiple applications utilizing different integration methods. To address this need, the concept of an Integration Platform as a Service (iPaaS) was introduced. Gartner defines iPaaS [6] as, “a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual or across multiple organizations.” These platforms provide a range of capabilities including API management, messaging and events, event stream processing, application and data connectors, protocol mapping and more [1].

While there are several iPaaS products available in the market today, we believe they suffer from three shortcomings:

  1. They are built for large enterprises.
  2. Few include any pre-built integrations for Higher Education.
  3. The platforms are built with a “technology first” mindset.

These are the specific shortcomings that Transact has taken up as a challenge. We are building a modern, scalable platform that embodies a “business first” mindset. In the next article, we will discuss Transact’s approach to integrations and our newest platform: Transact Exchange.

References

[1]

Gartner, "Critical Capabilities for Enterprise Integration Platform as a Service," Gartner, 21 09 2020. [Online]. Available: https://www.gartner.com/en/documents/3990730/critical-capabilities-for-enterprise-integration-platform.

[2]

B. Ibryam, "The next integration evolution - blockchain," 5 February 2019. [Online]. Available: https://tcrn.ch/2WJILph.

[3]

IBM, "SOA (Service-Oriented Architecture)," IBM Cloud Education, 17 July 2019. [Online]. Available: https://www.ibm.com/in-en/cloud/learn/soa.

[4]

F. Doglio, "The Evolution of Systems Integration," DZone, 30 August 2018. [Online]. Available: https://dzone.com/articles/the-evolution-of-systems-integration.

[5]

RedHat, "What is REST API?," RedHat, 8 May 2020. [Online]. Available: https://www.redhat.com/en/topics/api/what-is-a-rest-api.

[6]

Gartner, "Gartner Glossary," Gartner Inc., [Online]. Available: https://www.gartner.com/en/information-technology/glossary/information-platform-as-a-service-ipaas.

Pankaj Sharma

Pankaj Sharma

Staff Product Owner, ERP Integrations
Pankaj Sharma is the Staff Product Owner, ERP Integrations with more than 20 years of experience in the higher education vertical in a variety of roles that include ERP implementations and software development. The only thing he is more passionate about other than his job is Star Wars

Pankaj Sharma

Pankaj Sharma

Staff Product Owner, ERP Integrations
Pankaj Sharma is the Staff Product Owner, ERP Integrations with more than 20 years of experience in the higher education vertical in a variety of roles that include ERP implementations and software development. The only thing he is more passionate about other than his job is Star Wars