Back at DX Summit 2015, information scientist Seth Earley presented a many-layered, mosaic-tiled diagram depicting the multitude of vendors whose applications and services contribute to a complete software platform. The job of organizations’ IT departments, Earley stated, was to construct a kind of bridge using those tiles.
Integration has been perceived like a mortar between bricks, or like the commas in my sentences — small, but very noticeable, connections chaining together components that may or may not belong together. But in the modern era of data centers and PaaS services, where more and more applications and functions are being delivered by developers on-site, it’s becoming less and less clear which components are supposed to be glued together, and what parts are doing the gluing.
“I think enterprises have always struggled with, but also always been comfortable with, the idea that integration is a necessary evil,” said Matthew Baier, COO of integration platform provider Built.io, in an interview with CMSWire.
The 'New Way'
Baier makes the case that, historically, the task of integration had largely fallen upon IT professionals in larger enterprises, primarily because the major platform vendors — especially with sales and marketing software — did not provide integration as a service themselves. Only larger enterprises have the skill sets and knowledge bases on hand to be able to fill the gaps that these vendors left open.
But now that integration is being enabled “-as-a-service” through cloud-based platforms, by firms like his (including competitors such as newly re-privatized Informatica and Dell’s Boomi), not only is integration becoming feasible in more mid-sized organizations, but the monolithic applications they integrate now have renewed value.
“Now, all of a sudden, my CRM and my marketing automation systems are connected and talking,” said Baier, assuming the role of a CMO. “That’s exciting, because it enables new use cases — not just making things more efficient, but doing things in a new way.”
The “new way,” for any modern application, should involve the use of APIs (or application programming interfaces).
Sometimes the abbreviation “API” itself gets in the way of its own good idea. An API is a term, or a set of terms, that represent the communication vocabulary of an application. Any other application, or even any other Web-based front-end, can utilize the application if it can communicate using that vocabulary.
Applications designed to be interoperable use APIs. Most business applications in use today are not.
This is why integration is an issue rather than a built-in feature that we don’t even have to write articles about. Any integration tool has to utilize, or even invent, a strategy for making “legacy” applications that can’t communicate, share their data with the modern world.
The simplest way to go about this, from an integration tool’s perspective, would be to list all the fields in all the tables in every database, and let the user pick and choose those fields to produce a composite record that can be mapped to an API function. Simple to do ... hard to accomplish.
Building Blocks
Any integration tool that wants to retain its customers has to apply a different approach.
Built.io’s latest effort at such an approach is called Flow. In principle, Flow represents data as progressing from being locked away in a database, to being usable by a real-world app or function.
This is a bit different, conceptually speaking, from trying to break data free from the clutches of one application just to relocate it into the clutches of another. Built.io is betting on the notion that businesses want to do something with that data, not just plug it into another monolith.
So the graphical flowchart makes a new set of assumptions, including that the data in question has an unusable state (on the left) and a usable state (on the right). In the middle are applications and services that may serve as conduits between the two states.
The end state — the usable data — is represented by something practical, like an SMS message, a tweet, a file in Dropbox or even a WordPress post. The conduits may be services that generate queries on behalf of the legacy application, such as Salesforce CRM.
Learning Opportunities
Webinar
Mar
29
The CX Commute vs. the CX Joy Ride
Is your CX traffic holding up your customer's journey?
Webinar
Mar
29
Is Your Microsoft 365 Data Recoverable? How to Survive the IT Hotseat When Data is Lost
See why MIcrosoft recommends third party backup
Webinar
Mar
30
An Optimized Customer Contact Strategy Combines Transparency and Intelligence: The State of Outbound Communications
Learn from the Neustar-commissioned Forrester Consulting study on challenges and solutions for contact centers
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
Selecting the useful data effectively generates the template for the query. So Built.io Flow leverages the user’s capability to specify how she needs the end state data to work, to give her a drag-and-drop approach to selecting the tools that address those needs. Those tools include what Built.io CTO Nishant Patel called “pre-built connectors,” many of which his own company found itself creating for its own purposes.
Those connectors include filters that give users the opportunity to add complex logic. That’s important, Patel said, because many of these legacy systems are business process management applications, where automating the process of taking relevant actions based on input data, was supposed to have been the whole point.
“Our tool provides the ability to do simple-to-complex logic between these systems,” said Patel, “on top of the data mapping.
“Typically, Built.io Flow makes it really easy because all of the connections are already there — just drag-and-drop, and you’re connected to these systems. Then your job is to create this workflow, and whatever business process you have, you’ll want to implement it as this workflow.”
Merging Traffic
COO Matthew Baier added this: “The data integration conversation, and the application integration conversation — which used to be separate — are merging.”
Triggering a process that sets up a WebEx conference call or a Slack message, for example, between specific members of a team, based on logic gleaned from a query into an otherwise locked-tight application, is entirely possible with Flow, said Baier.
“You’re now changing the context of that process,” he said. “You’re now making those integrations available in your enterprise collaboration tool. So now, you can be in Slack, in the context of a conversation of setting up a meeting, and instruct Slack to book a conference room.”
CTO Patel revealed that this triggering of services can extend a major step further, along the right side of the chart: literally by sending a question from Slack to the natural language processor of IBM’s Watson.
“In Flow, that’s just an API call to Watson,” said Patel, “and we’ll write all the business logic around it. Watson will reply, and we’ll send it back into Slack.”
In such cases, said Baier, “the integration is invisible and you’re not having to deal with it. I think those are the kinds of changes to the business processes we’re seeing — they were [already] enabled at the technology level, but it’s the context that makes them powerful.”
For More Information:
- Discussion Point: Who’s in Charge of Integration?
- What Do You Call the Integration of Slack and Skype?
- DX Digest: Mark Grannan on Digital Experience Integration
Title image of a water-filled canyon in Greenland by Ian Joughin, licensed under Creative Commons
