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

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.

Figure 1: Evolution of Integration Technologies

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

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

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.

Figure 1: Evolution of Integration Technologies

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