The Evolution of Technology Integration

The Evolution of Technology Integration

Context integration is the future of system to system interaction. By prioritizing relevance, customer needs and jobs-to-be-done, context is the reason to operationalize big data. 

Definition: Context integration is the instantaneous combination of information and process integrated at a point in time, location, to the right person, on the right channel and on the right device.

During the past 20+ years, the way in which system and/or application integrations have been conceptualized has not really changed all that much. Sure, it is possible that I am being overly simplistic, but up until now, there have been only two types of integrations process and data. Yes, the protocols have changed, APIs, REST, SOAP - pick the acronym, and designs changes (spoke and hub, point-to-point, bus,etc.,..). However, what is often assumed is that a person will make the determination as to why a particular data element is on a screen, or not. Now, there is too much data, too much information it is time to refine the process.

Data Integration

Data movement in one direction is the easiest (not always easy, mind you) type of integration. Yes, there are nuances, but overlooking these nuances puts the complexity on the low end of the spectrum. One directional data integrations are typically read-only (or a copy). For example, taking data out of an operational system and putting it into a reporting system (I am not talking about transforms just yet). If you desire the data more quickly, say real-time, slide the complexity to the right a bit. Want to be able to write/update and have this reflected in the source system; bidirectional, slide the scale bunch more to the right.

Action item: we need to progress from data integration to information integration, there is too much data, people need information.

Process Integration

Process integration often require detailed use cases, user scenarios and can often be quite complicated. Process integration is best described by old school triggers. Something happens in system A, but the users on System B need to be both alerted, they need to do something and hey need to know what to do. Too often, this type of integration ‘channel jumps’ and the recipient receives an email, text or page in order to go take some action, in some other core system. These types of integrations take place in everything from sales, to support, operations and marketing, as well as everything in between.

Similar to the data integration conversation, when it is one direction and the originating system does not need to be notified upon completion, complexity is reduced. Now, if there are multiple process flows in the secondary system, and each is complex and the originating system needs to be aware at each stage (think credit check, for example), slide the complexity scale a bit to the right some more.

Action item: We need to move beyond the task list of things to do, to being told what to do, how to do it and when to do - why? only if asked.

What does Context Integration Look Like?

As stated above, context integration is information plus process, it is real-time, but may or may not be bidirectional. What I mean is that communication is bidirectional, but it might not be operating on the same data. Delivering the right information to the right person at the right time is hard, just start by sliding the scale way way to the right. For starters, there is now a third system involved within each integration scenario, the analytics engine. Breaking it down further:

  • Information equates to ‘what’,
  • Process equates to ‘where’ and ‘how’;
  • Context equates to ‘why’, as-in ‘why is this important to me, now’?

In order to accomplish this feat, we need more insight. We need to spend a bit of time translating data into information, processes into specific tasks and actions and help the user to understand why something is displayed or being done. In a very real way, right time information may also be considered to be proactive, as expectations are low in this area, but changing rapidly.

The two primary systems and their users need intelligence, something that has been done by humans, until now. The possibilities are awesome, the complexity enormous, the risks, very real. The intelligence comes from the aggregation of social data, combined with filtering, analysis and direct (ie predictive) insights. The salesperson wants more than just new information, he/she wants the question they forgot to ask - don’t only tell me something new, suggest what I should do.

The following are just some quick ideas, there are so many more and if you would be willing to add your own, I would appreciate it!


Example - Sales

  • Data - The CRM (SFA) application has a copy of purchase and/or case history, maybe event data, purchase history and company financial information
  • Process - The Marketing Automation System responds to a visit by a lead to landing page a task is created to make a call or send an email
  • Context - The intelligence platform creates a set of tasks, based up information from Linkedin (say through InsideView integration) that certain people are active on Linkedin and have changed jobs, company purchase history and trends are used to suggest tone of message and 3 independent tasks are created. If the CRM system notes the user is accessing information on an iPhone, the tasks are delayed a few hours, as the emails and tasks are better done on a larger screen. Tasks and reminders are created and scheduled.


Example - Service

  • Data - The Contact Center has account service history, household purchase history, number of claims displayed on the screen (or a couple clicks away).
  • Process - Add to the above, notifications of device recalls, health alerts, community posts, credit checks, invoice verification, payment verification, (think billing and finance).
  • Context - In financial services, think fraud alert. For example a user social check-in in New York and credit card use in Paris. In travel, make agents aware of weather or flight delays, tell client new flights are booked. Help systems should be product and location aware as well as being proactive.


Example - Customer (Me)

(There are too many customer examples to count, feel free to add your own)

  • Data - Give me access to my account information through a portal or smart device
  • Process - Notify me of potential fraud, account balance issues, credit issues, ask and wait for response. If an application is incomplete, point me to the place to complete it. If a doctor or hospital is too busy ask me if I want to reschedule.
  • Context - Notify me of weather on my travel route, give me options: car; a new route, plane; a special number or email address, finance; tell me my bank account is low before the rent check is due. Tell me to watch out for an issue, before I have it - the customer side of proactive support.