“History is not just the evolution of technology: it is the evolution of thought.” – James Redfield
In our last article we discussed two trends in the evolving higher education ERP landscape
We also discussed several related challenges.
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.
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:
Type of Integration
2. Stored procedures
2. Stored procedures
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.
Integration technologies have been around since the 1980s. In an interesting article , 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.
Figure 1: Evolution of Integration Technologies
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 .
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 . 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 . 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  and was neutral to the communication layer such as HTTP, SMTP and TCP.  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.
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 . The philosophy behind REST is that services are based around resources that clients need to interact with . 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.
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  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 .
While there are several iPaaS products available in the market today, we believe they suffer from three shortcomings:
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.
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.
B. Ibryam, "The next integration evolution - blockchain," 5 February 2019. [Online]. Available: https://tcrn.ch/2WJILph.
IBM, "SOA (Service-Oriented Architecture)," IBM Cloud Education, 17 July 2019. [Online]. Available: https://www.ibm.com/in-en/cloud/learn/soa.
F. Doglio, "The Evolution of Systems Integration," DZone, 30 August 2018. [Online]. Available: https://dzone.com/articles/the-evolution-of-systems-integration.
RedHat, "What is REST API?," RedHat, 8 May 2020. [Online]. Available: https://www.redhat.com/en/topics/api/what-is-a-rest-api.
Gartner, "Gartner Glossary," Gartner Inc., [Online]. Available: https://www.gartner.com/en/information-technology/glossary/information-platform-as-a-service-ipaas.