The iPaaS model is emerging as a key technology in the move toward next-generation enterprise IT, allowing higher education institutions to better integrate, manage, and maintain services and applications on campus and in the cloud.
Next-generation enterprise (NGE) IT focuses on applications, architectures, and sourcing strategies that increase an organization's agility and scalability, while also improving its cost effectiveness and analytics. As higher education institutions move toward NGE IT, they inevitably confront the need for a system-wide integration approach that lets them connect on-premises systems with each other and with their growing stock of cloud-based applications and services.
Integration platform as a service (iPaaS) is a suite of cloud services that address this need. The iPaaS approach lets you develop, execute, manage, and integrate on-premises and cloud-based applications and services. It also lets you quickly respond to requests for point- and cloud-based solutions that require integration with existing systems, such as back-end enterprise resource planning (ERP) and data warehouse systems. Finally, iPaaS lets you view all of these connections in one place and thus facilitates better long-run planning.
In August 2017, we participated in an EDUCAUSE Live! Webinar focusing on the strategic aspects of iPaaS. Among other things, we discussed how to evaluate iPaaS vendors, as well as early implementation issues and considerations we identified based on our experiences implementing new iPaaS solutions at Boston University (BU) and Ithaca College. This article summarizes our discussion and offers an overview of how iPaaS can help institutions more easily realize NGE solutions, as well as achieve their broader institutional goals.
iPaaS Overview
We hear much these days about various cloud-based as-a-service offerings provided by vendors rather than built and managed in house. These include infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). IaaS vendors provide hardware and compute resources, such as virtual servers, disc, and memory, to client organizations so they don't have to buy them and install them in their local data centers. Likewise, SaaS vendors let clients use rather than buy applications such as customer relationship management (CRM) software.
With PaaS, rather than purchase, install, and maintain a platform on which to build your own applications or integrations, you find a vendor — such as Microsoft Azure — to provide that platform as a service. iPaaS is a class of PaaS for application and data integration.
In essence, iPaaS lets you connect anything to anything, in any way, and anywhere. So, its primary capability is flexibility — it lets you get from cloud to cloud, from cloud to on-premises, and from on-premises to on-premises. A strong iPaaS solution thus has a versatile set of communication protocols; prebuilt application connectors, such as E-Business Suite or Salesforce for SaaS products; and various data formats so that users can map and transform different types of data. Further, data quality, routing, and orchestration are important to integration flow development and life-cycle management tools.
Why Choose an iPaaS Solution?
Many institutions leverage a variety of heterogeneous technologies to tackle their integration challenges, primarily using a point-to-point integration approach. This approach does not scale, however, and can lead to exorbitant maintenance effort and costs.
Some technology suites — such as ERP and student information systems — offer a native integration platform that handles all types of integration needs related to the particular suite, but they are not necessarily suited to enterprise-wide integration for various reasons.
At Ithaca, for example, the business intelligence team uses an integration tool provided directly by one of its application vendors, but the licensing prices made deploying that tool at a larger scale unrealistic. Similarly, BU considered using its ERP vendor integration platform, but the team found that, while it worked very well within the ERP environment, it didn't make sense when connecting to external systems or rolling it out enterprise-wide. Both Ithaca and BU thus decided that an integration-focused company was the best choice for their institutions' larger goals.
Moving to an iPaaS solution offers many benefits, particularly in relation to NGE aspirations. iPaaS can help your institution modernize from legacy systems and applications, and offer robust data integration and greater flexibility and agility in building those integrations. By moving solutions off-site, you can do more with less, including supporting a smaller IT organization that focuses on brokering rather than developing services.
Finally, iPaaS can dramatically improve efficiency and reduce the maintenance entailed by the "spaghetti" matrix of point-to-point integrations. According to Gartner Group, for every dollar spent on an enterprise application, organizations spend four to five dollars adapting and integrating that application. Further, Gartner reports that 35 percent of all IT spending goes to integration.1
Initiating iPaaS at Boston University and Ithaca College
As the following two examples show, while the state of integration at higher education institutions varies, it typically includes a tangle of systems and services and various methods for integrating them.
Boston University
Figure 1 shows BU's existing integration architecture. At the top are cloud-based services that the university is leveraging as it increasingly moves applications and functions off-site. The bottom layer represents on-premises systems, including legacy systems and target systems, that are hosted in BU's data center. As the middle section suggests, many different technologies and platforms currently enable integration. This creates inefficiencies in management and maintenance, and thus increases costs.
Figure 2 shows BU's target architecture, which aims to achieve a more centralized, unified integration approach using iPaaS as the central component of its integration platform. The plan over time is to move additional services and applications to the cloud and further simplify the integration landscape, leveraging iPaaS to enable connectivity in all configurations (on-premises to on-premises, on-premises to cloud, and cloud to cloud).
The BU team's vendor evaluation process was fairly standard: it began by doing research in various areas and reaching out to other universities to find out how they were approaching iPaaS. BU then issued a formal RFP, providing its functional and nonfunctional requirements to core vendors and reviewing their responses. The requirements included the ability to connect to key applications and technologies; communicate in various protocols; map and transform data; route and orchestrate integrations; enable API management; and provide tools for development, deployment, and support.
This process produced a short list of vendors that the team invited out for onsite demos and discussions. From this process, it identified a top choice and a backup based on product features and their fit within BU's technology and organizational vision. Following a successful proof of concept with the top vendor, BU moved forward and implemented the iPaaS solution; it is currently leveraging the iPaaS in support of several strategic Information Services and Technology initiatives.
Ithaca College
Figure 3 shows the existing integration state at Ithaca College, which includes numerous and somewhat tangled interdependencies between enterprise applications and third-party solutions. Like BU, Ithaca's plan is to create a centralized integration hub with iPaaS solutions acting as the gateway between both on-premises systems and cloud and on-premises systems (see figure 4).
Ithaca began its vendor-evaluation process in a conventional way with outreach and research aimed at understanding the market and its players. It also contacted three major universities with existing iPaaS solutions to learn from their processes and experiences. Ithaca's goal was to get feedback on each institution's selection process, implementation, and level of satisfaction with its selection.
Institution 1 had been using its iPaaS tool for almost a year, and team members shared their experiences in implementing and using it. They went with an all-cloud implementation of the product, eliminating the need for any server maintenance or costs on their part. They were satisfied with their tool choice and said they had not encountered any integration needs that it was unable to accomplish.
Institution 2 team members offered an in-depth look into integrations they had developed using the tool they chose. They said they were happy with the product and that it was simple and straightforward to use. Although their development staff had been reduced, the iPaaS tool let them keep up with demand. The team recommended a careful study of iPaaS tool licensing models concerning connections moving forward. This turned out to be a deciding factor for Ithaca in the end.
Institution 3's team members were satisfied with their selection, but said the tool required a higher level of technical knowledge than other tools they evaluated. They also discussed their tool's licensing model, which was based on the number of virtual cores needed.
At that point, rather than issue an RFP, Ithaca brought all three finalist tools out for onsite demos, which included an overview of the products and a demonstration of how they could be used to meet the use cases Ithaca had provided ahead of time. This narrowed the list to two finalists. The team then spent considerable time with each of these vendors to better understand their distinct models and pricing structures.
Functionally speaking, both products demonstrated what a good iPaaS tool should be: easy-to-use, with a wide range of transfer methods and protocols, and a simple drag-and-drop interface. However, as evaluation and comparison discussions progressed, the decisive factor boiled down to the vendors' pricing and licensing models. Both tool vendors worked with Ithaca on pricing, but each had expansion costs that could be incurred as the school's needs grew. Because of this, Ithaca chose its vendor based primarily on long-term cost predictability given the licensing model. It began implementing the solution in May 2017, moving ahead slowly and with careful planning. Ithaca currently has 20 iPaaS integrations running in production.
Key Considerations
As the above examples show, most organizations want to integrate many different types of protocols, data formats, and applications into a cohesive architecture. The first key requirement of a suitable iPaaS is therefore to provide connectivity to core applications and technologies. Universities should assess whether an iPaaS includes connectors or adapters to access their on-premise and cloud applications and data repositories using the appropriate protocols (such as HTTP and FTP) and data formats (XML, JSON, and so on). Also, different iPaaS vendors may have different connectors, especially when dealing with legacy technologies.
The second key requirement is ease of integration. At most universities, IT staff members are skilled in broader areas, such as business analysis, quality assurance, and basic development, rather than being integration experts who do hardcore development. Organizations thus need a tool to help them achieve relatively easy, efficient development without placing huge demands on IT staff.
Although not essential, API monitoring and management is another factor to consider. Some iPaaS products have it baked in, while others offer it as an add-on. Master data management and data standardization capabilities are also helpful. Here again, some vendors offer this along with routing and orchestration, while others do not.
Finally, if an institution is struggling with efficiency and the ability to develop integrations or connect different systems in a timely way, iPaaS might help solve those problems. A solid data governance strategy will allow an organization to reap additional benefits from its iPaaS, but the lack of such a strategy will not necessarily preclude the benefits an iPaaS offers organizations.
Evaluating Vendors
iPaaS became a notable marketplace presence around 2011, and major players quickly emerged. The market has been growing steadily ever since, fueling the emergence of challengers for industry leadership in the iPaaS market, as well as visionaries and niche players. Following are a few of the key issues to consider when evaluating iPaaS vendor options.
Experience
First, it's important to weigh the trade-offs on iPaaS vendor experience in the on-premise integration space versus experience in the cloud. Many integration vendors are well-established on-premises, but are just now moving to the cloud. As a result, they might be less mature than vendors born in the cloud and in iPaaS. That said, the focus on iPaaS for vendors born in that space is often cloud-to-cloud integration.
BU's chosen vendor lacks deep experience in high-volume extract, transform, and load (ETL) situations. The team is thus in the process of determining whether to use its existing platform for its high-volume ETL at the data warehouse level or work with the iPaaS vendor to build up its capabilities in that space. As this example shows, rather than finding one specific rule set around iPaaS, each vendor is likely to have strengths and weaknesses in different areas.
Performance
Vendors take various approaches to dealing with high-volume latency issues. Some offer on-premises solutions; others offer off-site solutions; and still others take a hybrid approach, providing a lightweight on-premises component to deal with cloud latency issues. Both BU and Ithaca College chose vendors that offered a hybrid approach because it mirrors the organizations' own mixed on-premises/cloud models.
Although iPaaS vendors ensure high availability and redundancy of services, having a central integration point creates a challenge regarding the availability around the up-time and service windows of integration points. Organizations must carefully consider and plan for this potential issue.
Security
Although moving data to the cloud naturally gives rise to security concerns, vendors often provide better security than is possible for most campus data centers. Research here should focus on key security layers and ensuring that vendors cover them all. For example, Ithaca College's chief security officer was involved in the vetting process to ensure potential vendors were SSAE 16 SOC 2 Type-1 certified and that none of the school's data would reside on the integration platform.
The campus network infrastructure is also essential to secure implementation. Ithaca, for example, had invested heavily in its network infrastructure to ensure full redundancy out to the internet. The speed of its connections, its firewalls, and its security profiles were all in place prior to moving to cloud solutions. The ability to connect the iPaaS platform to your back end in a secure way is another crucial security factor.
BU's information security team has a well-defined set of policies, practices, and data classifications, and thus had clear rules for data storage, data transport, and data processing going into the vendor evaluation process. Most of the vendors it contacted could accommodate all of the university's needs and properly secure data based on its existing policies.
Costs
Another key consideration is long-term pricing. In addition to the standard onsite costs for software purchases and support staff, there may be server costs for hybrid architectures (onsite and cloud). iPaaS subscriptions for higher ed are billed annually and range from approximately $70,000–120,000 and up, depending on the features.Typically, there is also a one-time implementation cost.
Most vendor pricing structures start with a base price that covers operational expenses. Cost differences typically arise when you add services, features and, in some cases, additional software.
Ithaca Collegefound that its three finalist vendors all had different licensing models, and none offered an official higher education pricing model. One vendor, for example, licensed according to the number of virtual machine cores, while another licensed by the number of endpoint connections. The vendor Ithaca ultimately chose had a licensing model with a base price that included robust core functionality and offered add-ons as prebuilt integration packages for a wide variety of ERP, SaaS, and social media solutions, as well as other technologies.
Navigating pricing and licensing models is a challenge, as is finding a model that both offers the needed value and is affordable. That said, the potential increases in efficiency can be considerable. Already, for example, Ithaca is seeing a 75–95 percent increase in integration-development efficiency. Also, staff reductions are another likely source of savings. For example, one institution Ithaca spoke with reported that the university had reduced its original IT staff of five to two integration developers.
Another iPaaS advantage is the increased robustness of the support model. At Ithaca, integrations were typically one-offs built by individual developers, making it difficult for anyone other than the original developer to support the application or service. The iPaaS solution has a standard format and model, which Ithaca expects will be easier to support and maintain moving forward.
Onsite Issues
On campus, implementing iPaaS creates challenges in terms of analyzing and integrating existing systems. It also alters the role of IT departments and how they operate.
Legacy System Integration
As figures 1 and 2 show, both institutions had their share of spaghetti integrations to contend with — as well as decisions about what to do with legacy integrations. At Ithaca, a big topic of discussion initially was whether or not it made sense to go back and rewrite old integrations with an influx of new integrations coming. The team ultimately decided to rewrite only when it made sense — such as when an old integration was causing problems or recurrent maintenance issues. In some cases, it does make sense to redevelop existing applications and services to integrate with the new solutions, but the team's primary focus is on moving forward with new SaaS solutions.
BU faced a similar situation, intensified by the fact that it was already engaged in a major program to move off its legacy student systems based on Natural and ADABAS. The spaghetti in BU's case is the thousands of point-to-point integrations between systems, often using the same data set, which creates serious challenges both for maintenance and for understanding where data is going and how it's being managed. In the long run, BU aims to use iPaaS for all of its integrations; for now, it is focusing on the student systems and (like Ithaca) any existing integrations that are problematic.
Required Skills and Staffing
The transition to iPaaS can affect your IT staff considerably in terms of both required skills and team size. Most university IT departments are staffed by skilled application developers, and the move to an iPaaS model changes the focus from application to integration development. In a way, IT staff members become service brokers rather than service providers. As such, the skills that staff members need can vary.
Some iPaaS vendors trumpet their products' ease of use and advertise them as requiring IT skills at the more basic "citizen integrator" level. Examples might include the ability to write simple SQL or understand basic file types. That said, the Ithaca team has already seen some cases beyond what a functional user could address. Generally, iPaaS support skills include an advanced knowledge of SQL; an understanding of XML and various formats and protocols, including connection protocols; and, in some cases, experience with JavaScript.
BU views a range of skills, including integration experience, as essential for its IT staff. It has an architect tasked with understanding different integration patterns and working on higher-end issues, such as ensuring that the university's integrations use a common schema and a canonical model pattern. The team intentionally chose a tool that developers who weren't necessarily hardcore software engineers could manage, while also realizing that higher-skilled staff members would be needed to establish integration patterns and platform components that the less-skilled developers and citizen integrators could leverage.
Given the changing skills required, alterations in team size and composition are likely at most institutions. The Ithaca team has been open with its staff from the start about the new direction and the skills required to support it. Such a change won't suit all developers or their envisioned career paths. Further, given that a key iPaaS benefit is that it requires far less onsite support, smaller team sizes are inevitable.
At BU, the IT department has long been evolving toward more centralized integration competence. Initially, its team focused on ETL operations with data warehouses. It then evolved to doing ETL between applications. It is now developing a larger strategy around application and data integration with iPaaS as the central component and has hired an associate director to lead that team. That person, along with the university's integration architect, will support BU's vision of a more centralized university integration capability.
In-Progress Lessons and Emerging Paths
Although both schools are in the early days of iPaaS, particular lessons have begun to emerge.
The first relates to habit and mindset. At Ithaca, shifting the mindset to the new iPaaS solution is a process; new integrations and integration-related needs arise regularly, and the team sometimes gravitates toward the old way of doing things — that is, writing custom scripts to handle integration — not least because the new solution was brought in to solve specific issues.
Increasingly, however, team members have begun to consider the iPaaS solution with each new integration need as it arises. In the process, they are finding the solution to be highly flexible; as a result, potential uses for iPaaS are coming out of the woodwork in ways they never anticipated. Similarly, many use cases are beginning to arise at BU, and the team is realizing that its iPaaS solution can replace ETL tools it has been using for years.
Second, both BU and Ithaca plan to standardize around a set of common models in the integration layer. So, for example, as student data comes through, it will automatically conform toa common student data model, regardless of the source and target systems. Using common models will increase agility in developing integrations, as well as improve integration effectiveness.
Finally, it is clear to both institutions that iPaaS is a key enabling tool for NGE IT. Although discussions continue throughout higher education about how to define NGE and its key characteristics, the answers beginning to emerge emphasize interoperability and integration. Data will be critical, as will its flow between systems, and it will be cloud-based. Many different applications and services will need to interact. Hyperpersonalization — for students, faculty, and staff — will also be important. All of these characteristics depend on the free flow of data between disparate systems, which is where iPaaS comes in and shines.
Note
- Keith Guttridge, Massimo Pezzini, Paolo Malinverno, Kimihiko Iijima, Jess Thompson, Eric Thoo, and Elizabeth Golluscio, Magic Quadrant for Enterprise Integration Platform as a Service, Worldwide, Gartner Group, 2016. ↩
Robert Graham is Executive Director of the Information Services and Technology organization at Boston University.
William Liddick is the Interim Director for Engagement Implementation at Ithaca College.
David Weil is the Chief Information Officer at Ithaca College.
Jeffrey Newhart is a Solutions Integration Developer at Ithaca College.
© 2018 Robert Graham, William Liddick, David Weil, and Jeffrey Newhart. The text of this work is licensed under a Creative Commons BY-NC-ND 4.0 International License.