There are few more challenging industry topologies for integration than a higher education institution. Even more so than a commercial enterprise, a campus is like a small city when it comes to services, infrastructure, data requirements, etc. It has the full scope of HR and financials use cases, coupled with all of the administration and services (often heavily regulated by governmental oversight) of the student lifecycle and learning management, recruiting, marketing and sales, supply chain management. Many institutions even generate and provide their own power and other utilities!
And just like in any enterprise, all of the systems that manage all of those business units and processes need to operate together. Seamlessly. (Well, that's the ideal, anyway.)
Traditionally, this meant a spider web of point-to-point integrations that connected Application A to Application B, Application A to Application C, Application B to Application C, ad infinitum (and, for campus IT staff, ad nauseum). Whether that is through nightly data loads that replicate and move data between solutions, or more contemporary mechanisms that either move payloads transactionally in real or near-real time or even transiently without replication, exposing data on demand and for the duration it is needed to complete a business process, that translates to a huge, and hugely complex, effort to create and maintain these required interactions.
And make no mistake—these interactions are required. Data MUST be able to flow freely across the enterprise. Service level expectations have progressed rapidly in this era of web-based consumer-oriented experiences, and end-users (administrative or student) don't care where the data lives or how it gets from point A to point B, only that they can complete their task quickly and easily.
So how do we rationalize and enable the integrated campus ecosystem?
Standards are a good place to start. Whether those are technical standards and non-proprietary methodologies like the use of REST or SOAP in service oriented architectures, or industry standards like those from IMS Global and the Postsecondary Electronic Standards Council (PESC) in the Higher Education space, standards allow us to apply a consistent pattern in integration methodologies, facilitating the ability of all of the solutions in the topology to talk to each other.
But a lingua franca opens up the channels, it doesn't untangle the spiderweb. To do that, we need something that gets away from point-to-point integrations, that allows us to "black box" each system while still allowing the free flow of information between them.
This is where an interesting new category of solutions comes into play. To the increasingly familiar acronyms SaaS ("software as a service") and PaaS ("platform as a service"), add iPaaS: Integration Platform as a Service. Where PaaS solutions essentially provide development tools, toolkits, and environments in a cloud-based subscription model, iPaaS does the same for integration: it provides a cloud-based solution that shifts deployment and maintenance to the vendor while leveraging increasingly standardized integration methodologies to allow customers to rationalize their integration topology.
Oracle's Integration Cloud Service (ICS) is a good example of the growing capability and popularity of iPaaS solutions and how they help simplify the integration challenges on campus by abstracting the artifacts of integration.
ICS, for example, starts with the concept of an adapter, essentially a code library that defines in an agnostic fashion an endpoint (independent of any solution it might be used to connect to) for an external solution to talk to ICS and vice-versa. ICS includes general technology adapters, like the delivered REST adapter that simply "understands" REST and therefore can be used to connect ICS to any solution that provides or consumes REST services; this means that any solution that can talk to one of these technology adapters (REST, SOAP, FTP, File, Database, etc.) can play.
Or adapters can be "bespoke" or solution specific, whether at a suite level (for example, a Peoplesoft adapter that simply interrogates a Peoplesoft application instance to expose underlying web services/APIs); or at a solution level, like the forthcoming Campus Solutions adapter, which will expose specific business entities and business processes and transactions to allow for an easy, wizard-like experience in defining an integration.
These adapters, then, are used to define a "connection," a specific instance (including URL or other deployment-specific information) of an adapter. At its simplest level, this model means that each solution participating in the integration really only needs to be able to talk to ICS; ICS then handles the process of closing the loop between the solutions. (Of course, if you are trying to get Application A to talk to Application B for a particular transaction—say, publishing and mapping some data between the systems—you have to ensure that whatever connector you're using for Application A exposes the data you need for Application B. ICS is powerful, but it's not magic!)
ICS closes that loop through an integration or integration workflow. As with most iPaaS solutions, that means a drag and drop visual interface where you select an integration pattern (simple data mapping to service orchestration), select the actions and data mapping you want to occur, and you're ready to go. It's that easy! (Or, it can be—you can also create more complex integrations and use scripting tools if you want to or your requirements demand it).
What does this mean for integration on campus?
It means that for those 80% or so of integration use cases that are straightforward, like publish/subscribe patterns or simple service orchestrations, ICS can provide the ability for "citizen developers" or non-specialized line of business users to create and maintain integrations, often while dropping the required person-hours to build that integration from weeks to days or even hours, and freeing up senior or specialized IT staff to focus on other mission-critical undertakings.
And ICS's cloud deployment model means we may even be able to deliver not just adapters, but actual pre-defined integration workflows, so that all a customer needs to do is define the connection particulars, and the rest is already taken care of. From there they can modify, enhance and extend as their campus ecosystem requires. Delivered, supported integration—that's the goal.
Integration on campus has been a challenge from the earliest days of the use of enterprise software. We've made it (mostly!) past the era of printing out a spreadsheet from one application and typing that information into another application. We're making our way through the "nightly batch" phase, and the growth of standards and the introduction of new solution categories means we're actually poised for a generational step forward in making data truly interoperable and transparently portable.