Fill the form, and we'll contact you! X

Thank you!!x

Message sent

Contact us@

26.4.2018 - 9:20 Markku Alikoski

Why integrations should not to be left to engineers

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



Drivers to Success
Energized Programs
Marketing Ecosystem
Marketing Technology
Persuasive Content
Synchronized Martech
blog comments powered by Disqus
About me

Modernin markkinoinnin taustalla on huikean monimutkaista järjestelmäarkkitehtuuria, jossa tieto viuhuu järjestelmästä toiseen liki reaaliaikaisesti. Vaikka koneisto on kimurantti, sen suunnitteluperiaatteet eivät sitä ole. Modernit tietojärjestelmät rakennetaan paremman asiakaskokemuksen varaan, ja yksi automaation tehtävistä on helpottaa asiakkaan, markkinoinnin ja myynnin arkea. Näistä asioista kirjoittaa Markku.

Vapaa-aikansa Markku viettää 11-vuotiaan tyttärensä varttumista seuraten. Markun harrastuksia ovat ruuanlaitto, viinit, musiikki ja pelaaminen.

Modern marketing is underpinned by tremendously complex system architectures where information transfers from one system to another almost in real time. Even though the machinery is somewhat tricky, its design principles are not. Modern information systems are built to improve the customer experience. One of the tasks of automation is to facilitate the everyday life of the customer, as well as marketing and sales. These are some things that Markku writes about.

Markku, spends his spare time with his 11-year-old daughter. His hobbies include music, good cuisine and wines.

More from the writer