Skip to content

Why integrations should not to be left to engineers

April 26, 2018
Markku Alikoski

When data exchange between systems, a.k.a. integrations, are made visible and brought to every user’s toolbox, the whole organization will benefit.

Traditionally system integrations have been handled by kind of a rather secretive, esoteric and whimsical gentlemen’s club, with members engaged in strange rituals and fond of cryptic acronyms totally obstructed for the uninitiated (I’m being nasty now). When a negotiation turns to whether to use soap or solve the problem restfully, it’s easy to leave the boys babbling with themselves. This should never be done, though (for the uninitiated: read on to see what we’re talking about).

Modern data systems are modular, consisting of many different components from multiple vendors.  All decent systems have good, well documented APIs (Application Programming Interfaces) and it’s thus rather easy for a skilled programmer to create connections between different systems. Selection of the integration model should never be left for engineers only, instead the business should have a driving role in decision making.

Below my ponderings of three different integration models:
1. Point-to-point integration

The easiest way to connect any two systems is the so-called point-to-point integration, a black box. The data transfer is typically implemented using SOAP or RESTful protocols. It’s called a black box because there’s no conventional (graphic) user interface, instead the code resides hidden on the integration server.
”Because every programmer has his/hers personal handwriting style, changing integration vendors may be difficult”
Even if the program is well documented, its functional logic can be hard to comprehend for any non-technical persons. Even the smallest changes always require consulting a systems developer. Because every programmer has his/hers personal handwriting style, code written using an ancient programming language may be hard to read by anyone else. Changing integration vendors may thus be difficult.  On positive side these kinds of integrations are in general paid once on delivery. Sometimes a small monthly hosting fee is added, if the solution runs on vendor’s servers.
2. Middleware integration

In middleware integration model data transfer is implemented using an external solution specialized for connecting systems. In its simplest form integration is described using a drag-and-drop workflow based graphic interface, where different boxes represent various data sources and processes. High-end middleware solutions can be very expensive and are licensed on annual basis. As a rule of thumb if a program is easy to use, its features are limited. The more sophisticated environments always require good programming skills. The main benefit in using a middleware is that there usually exists a large base of skilled, certified users abroad.
​”The best solution is build the integrations into the systems used”
3. Integration as a part of a system

The third and in my opinion the best alternative is to build the integrations directly into the systems, as an integral part of its toolbox available for users. This kind of integrations require deep understanding of user experience (UX) and sophisticated user interface (UI) design, because the goal is that the users themselves can build their own processes using the building blocks provided. When designing the toolkit, it’s pivotal to do it together with everybody involved, i.e. representatives of sales, marketing, analytics, technology and corporate partners.

This may take a couple of extra workshop days, but as a result there will be a wider understanding of common goals, means at hand, how to utilize and combine various tools provided in the toolbox. Involving users representing different levels of expertise improves the quality of the system, as stated in Linus’s Law: given enough eyeballs, all bugs are shallow.
​Image below illustrates an integrated campaign flow utilizing features of five dedicated systems, that are: Eloqua marketing automation system, Salesforce CRM, e-Shop, licensing server and Twilio SMS service. The campaign is implemented using the Campaign Canvas toolkit of Eloqua with 3rd party and custom build add-ons.

  1. CRM integrated segment retrieves all customers with software license expiring exactly three weeks from today.
  2. Email send listing all expiring licenses with Call to Action (CTO): link to e-shops renewal page.
  3. Wait step: has renewed?
  4. Email order confirmation with installing instructions
  5. Retrieving of license keys generated by the licensing server
  6. Delivery of license keys to end-user via SMS
  7. Updating CRM order entity linked to customer account
Markku Alikoski