Mid-Year Resolution

I am starting to get tired of the term "integration."

This may sound very strange to those of you who are my colleagues and business associates, so let me explain.

My primary technology focus for the past five years has been on a Web product that we (at my employer) have always characterized as "integrating" with our CRM product.  This made a lot of sense to me at the time, before I really understood the core architecture of the Web product and its database.

However, a term that my dear friend and business associate recently used woke me up.  What I work on is definitely NOT data integration.  It's data singularity.

This is a key difference to which I fear many organizations pay little attention.  The concept of singularity essentially derives from the existence of one, a single, data model or set.  The concept of integration, on the other hand, infers a mashup of two sets which may talk back and forth to a limited degree.

Why do I say that integration is limited?  Why, because when two data sets exist, there is always a potential for disconnect - for a failure to communicate.  In real life, though two people marry, with their personalities, life goals, and hopes for the future incredibly in sync, there still exists communication breakdown, inability to candidly discuss difficult topics, and a potential for individual growth that can forever change the relationship.  Likewise, two data sets, two systems with matching elements storing the "same" data always provide an opportunity for this same communication breakdown.

It is with this thought in my mind that I will attempt to purge the term "integration" from my technical discussions, and replace it with "singularity."

From a technical perspective, it is First Prize when a single record exists to represent a constituent/customer/client relationship.  There are so many channels in which we "exist" - and so many situations in which users expect consistency (bank & bank Web site, zoo front gate & monthly newsletter, Brand name catalogue/Web site/store/daily eMail/Max Azria should be calling me directly at this point), that constituent expectations run high.  It is with this in mind that we must consider that a communication breakdown between systems can be crippling when a relationship is at stake.

So, a short list of what I consider and advise when talking data "singularity":

1. Consider the audience.  To reap the benefits of data singularity, you must market them.  In essence, for data to be a usable resource, it must be dynamic, and only with the constant growth and change of the data (because of behavior, response, activity, etc.) can you effectively use it.  Therefore, the audience must be continually cultivated and pruned to respond.

2. Consider the endpoint.  This is the most dynamic consideration point - with a single source of truth, you have the ability to analyze, grade, and respond to any data element.  Therefore, it is important to understand that metrics and analysis will change, but to also understand that you must begin with at least a short-term way to measure performance.  Without concrete goals, the ROI of the singularity is not definable.

3. Consider the upkeep.  Make sure that you have the manpower to act on providing relevant, targeted information.

4. Consider the hardware.  Ensure that you or your service provider can service the ongoing requests.

Now, who's "single and ready to mingle"?

Comments

[Steve Kennedy]

I realy appreciate this post. Made me stop and think for sure! Thanks!

[Jay garcia]

Heh. I feel the same way about the term "portal", which is waaaay over used!