APIs are the primary means of integrating SaaS, but that’s not your only option. It’s also possible to take a more traditional approach to integrating SaaS, as application and integration veteran Dinesh Chandrasekhar describes in a recent post.
Chandrasekhar is now the senior manager of Global Product Marketing at Software AG, but he’s also spent the past 16-plus years working in application architecture, integration and implementation across various vertical industries. (Full disclosure: I write for Software AG’s vendor-neutral site, B2B.com, which focuses on supply chain and other B2B trends.)
Strategic Integration: 10 Business-Building Tips
In a post for the company’s Reality Check blog, he suggests that the best way to prepare for the modern challenges of managing both cloud and on-premise applications is to create an application integration strategy.
I’m always pro-integration strategy, but what I found interesting about this is the focus on “applications,” and in particular, the idea that an enterprise application strategy includes extending into the cloud. That significantly changes his recommendation list over what you typically see, in part because application integration requires more of a focus on architecture.
In other words, this is not a quick-fix list, but something you’re really going to have to pursue as a long-term strategy.
For instance, the second step he recommends is creating a decoupled architecture, known as a pub-sub or Publish-Subscribe architecture. His example relies on an ESB to handle the integration.
“By tightly binding data and applications silos with one another, you are only complicating the architecture more,” Chandrasekhar writes. “A decoupled architecture is one where one application is agnostic of another application’s presence or preference of connectivity.”
He also talks about moving to a service-oriented architecture, which is a well-known way to make connecting with services faster and easier.
But what I found most interesting were his fourth and fifth recommendations — use canonical data models and use design patterns — which are what I would consider very traditional enterprise strategies. So I decided to ask Chandrasekhar to clarify whether these approaches would also work with SaaS.
If you’re on the business side and, like me, have heard the term “canonical data models” but have never been really clear on how they help with integration, then this will be helpful. Chandrasekhar’s explanation is one of the best I’ve seen for explaining this, so much so that I’m going to quote most of what he wrote on that:
“When you are dealing with two or more complex or large data structures, you will see that you are spending a good chunk of time in mapping the same set of fields or writing custom logic to same field that is named in different ways in different data sets (e.g. FirstName, FName, Name, CustomerName etc). Canonical will act as the flat representation of the superset of all data fields in your integrations. Applications will then connect to the canonical instead of creating new data structures every time they need to be connected with a new system. System-level changes can be easily accommodated with this approach.”
It’s easy to see how that would work with on-premise apps, where everything is under your control, but what about SaaS integration? Chandrasekhar responded by email that, yes, canonicals will work with SaaS applications.
“Any endpoint that has to be integrated will require a document model with appropriate input/output fields,” he wrote. “This structure may not look the same as your other endpoint to which this has to be integrated, even though most of the fields may mean the same (e.g. FName = FirstName = CustomerFirstName). So, having a canonical in between helps in resolving such conflicts much easily and also, in making changes later on in an easy manner.”
He added that design patterns — another one of his recommended steps for application integration — could also be great for SaaS integration, but require more caution. That’s in part because design patterns that work for on-premise integration may not work for integrating on-premise to SaaS.
He also pointed to another piece he’d written explaining latency issues and the fact that SaaS charges are based on the number of service invocations you make within a month. So when implementing any integration, you’ll need to measure how often you access the SaaS application, or it could cost you more than you anticipated.
