Data Portability and Application Interoperability – what is all the fuss about?
Two terms get thrown around carelessly: data portability is moving data between environments; application interoperability is systems actually working together via APIs. The point that gets missed is that data never inter-operates directly, only through applications. That makes the DMP the central nervous system that lets fragmented mar-tech plug and play without brutal ETL and mapping work.
In the currently intricate data landscape (I urge you, please spare yourself from checking Big Data 2016 chart!), I’ve found that there are two extensively used terms, which are typically misused or misunderstood - Data Portability and Application Interoperability.
For context, let’s set the scene by defining both terms and have a clear delineation between the two:
Data Portability - refers to the ability to seamlessly move, integrate, interlink or transfer data easily from one database, storage or cloud environment to another. Portability describes the extent to which the data can easily be ported between different infrastructures and operational environments.
Application Interoperability – in cloud computing, is the ability of diverse systems and applications to work together i.e. inter-operate. Most common implementation of Application Interoperability is the utilization of Web Services/Interfaces Development, which is mostly known as API (Application Programming Interface). Applications are software programs that perform functions related to business problems; in DMP realm we might refer Lotame Cross-Device or ‘Look-a-Like’ (Optimizer) products as such.
Based on how it’s defined above, it is evident that Data Portability enables re-use of data sets across inter-operable applications. In other words data components inter-operate via application components rather than directly, thus allowing us to debunk the myth about Data Interoperability as it simply doesn’t exist. There are no “data interoperability” interfaces in cloud computing, as data inter-operates only via applications!
From theory back to reality, in a DMP world, Lotame is architected to be as liquescent as possible by embracing SaaS methodology, which powers data portability rather effortlessly. By design, it’s not just enabling the re-use of data sets across different cloud applications (i.e. from SaaS CRM to SaaS BI Engine via active DMP pipes) it is also adding value by enriching, profiling and extending the information.
Why should we care about Application Interoperability?
At Lotame, we face data portability and application interoperability questions on the daily basis. Allow me to give you real-life example for customer X (name is omitted for privacy reasons).
Suppose that X uses a SaaS product for a Content Management System (CMS) which is currently ‘plugged’ into Lotame DMP for dynamic content personalization and real-time content recommendation purposes. The customer data held by the SaaS product may be crucial to the enterprise’s operation. How easy will it be to move that data to another CMS solution? In many cases, it proves to be very difficult. The structure of the data is often designed to fit a particular form of application processing, and a significant transformation is needed to produce a data set that can be handled by a different product. To address this very problem, we always refer to interoperability of the DMP being a ‘central nervous system’ which allows it to plug & play different SaaS products available in the MarTech ecosystem, without going through hideous data transformation processes (ETL) and myriad of mapping exercises. While DMP becomes piping and glue for application interoperability, it also offers the following benefits:
- Businesses can bring together applications and systems across an enterprise, irrespective of vendors (an open marketplace for evergrowing fragmented technology landscape)
- Multiple systems can be linked together to share information in a real-time manner, delivering time-sensitive information to those who need it, from advertising targeting to content personalization.
As we’ve been discussing SaaS models quite extensively, it’s only logical to cover the foundation of all service models – SPI.
What is the SPI model?
SPI is another three letter acronym (Ad/Mar-tech loves them!) for the most common cloud computing service models: Software as a Service, Platform as a Service and Infrastructure as a Service.
These models can be described as following:
| Model | What it abstracts | Public ‘cloud’ example |
|---|---|---|
| Software as a Service (SaaS) | Complete abstraction outsourced from the organization; applications are hosted by a vendor and made available to customers over a network, typically the Internet. | Live, force.com and Lotame |
| Platform as a Service (PaaS) | Abstraction of underlying hardware, software and application resources; delivers operating systems and associated services over the Internet without downloads or installation. | Windows Azure Service and Google App Service |
| Infrastructure as a Service (IaaS) | Abstraction of underlying hardware resources; outsources the equipment that supports operations — storage, hardware, servers and networking components. | Amazon EC2, Rackspace Cloud and GigaSpaces |
In conclusion, I would encourage everyone to challenge any SaaS vendor to make sure that they truly embrace Data Portability and Application Interoperability such that data and applications hum a symphony together rather than being disjointed and siloed pieces of information, neither of which can generate insights or actionability.
It is evident that multi-channel marketing programs need shared intelligence and automation to optimize each interaction in real time, with intelligent orchestration powered by an independent and media agnostic DMP, while Data Portability and Application Interoperability is the corner stone of its foundation.
Happy Data mining!