…Contextual Identity, Graph Databases and Connection Integration in CRM
The enduring purpose of a business is indisputably to create and keep customers. That bedrock was first famously laid down by Peter Drucker and Theodore Levitt sometime around the 1960s or ’70s.
But here’s the paradox.
…Contextual Identity, Graph Databases and Connection Integration in CRM
The enduring purpose of a business is indisputably to create and keep customers. That bedrock was first famously laid down by Peter Drucker and Theodore Levitt sometime around the 1960s or ’70s.
But here’s the paradox.
Fixating on customers is not necessarily the best way to improve customer growth, engagement and customer experience. Yet, CRM software vendors say to do just that.
SalesForce, for example, promotes creating an “Internet of Customers” and becoming a “Customer Company”. Oracle, Microsoft and other CRM vendors tow a similar story-line around being customer-focused.
There’s another, counterintuitive argument for how to create and keep customers. It advocates creating an Internet of Not Only Customers and becoming a Connections Company.
Consider really good networkers, like one guy who calls himself a “People Collector” for his knack to connect with others, not just customers, to build his business. Some might prefer to call him a “People Connector,” but no matter.
Networkers like the People Collector are successful and admired because they are awesome at creating connections. Their ability to create connections…with not only customers…is what counts.
An Internet of Not Only Customers reflects a deeper and broader Pascalian reality. We cannot know customers unless we know all their possible identities and connections to others. Similarly, we cannot know an entire network without knowing the individual parties comprising the network and their many identities and corresponding connections.
…Poly-Identity Matters
Businesses engage individuals, organizations and groups in all kinds of contexts, not just “customer”. That’s why web developers call them “Interaction Personas”. (Added 04/26/2017)
For example, go to the home page of just about any health insurance company. Based on how the typical home page or menu bar choices are designed around interaction personas, we can surmise health insurers have interactions and transactions with various constituents, including plan members, employers, brokers, consultants, providers and families. (Updated 04/26/2017)
In many business situations even a single transaction or interaction frequently involves multiple parties in different roles, not just “customer”. Consider a simple car rental. The driver may be an employee of a company paying for the rental car that was arranged through a third-party corporate travel service.
More complexly, a single party can play different roles in different transactions and interactions. Take a university. A person can be a student, an employee, an alumnus and a donor, all at the same time. The university cannot know the individual…and his full network without knowing all his identities.
Edgar Morin and others refer to multiple contextual identities as Poly-identity. Poly-identity, it seems, is the norm, not the exception.
That’s right. A partner or supplier may also be a customer. Even an employee can be a customer. All sorts of poly-identity possibilities exist.
And here’s the challenge. For each contextual identity a party’s data relationships and connections differ. They are dynamic, constantly changing and reshaping the Internet of Not Only Customers.
…Two Looming CRM Requirements
CRM software is not engineered to readily support a single, poly-identity party behaving in multiple roles when each role has its own set of context-dependent data relationships and connections. To cope, organizations perform complex data stunts that show two or more necessarily replicated “account” records, each corresponding to a different context, actually represent one party.
To pull off this unitas multiplex, SalesForce and their pals at Oracle and Microsoft have to deliver CRM applications that are:
1. Context-aware to gain a panoramic, continuously mutating and expanding view of poly-identity parties, including their data relationships and connections to other constituent parties across multiple contexts.
2. Graph database-like to represent, navigate and analyze deep FOAF (Friend-of-a-Friend)-type connections (just like, say, LinkedIn) among participants in an Internet of Not Only Customers, and provide the needed mutability to simply and quickly model dynamic, context-aware party connections.
Without these two capabilities, businesses cannot optimally create and keep customers. Sticking with the status quo is simply not an option for a business to effectively construct an Internet of Not Only Customers and become a Connections Company in their operating universe.
…The Specter of Context Collapse
Two things happen without context awareness and graph database capabilities: context-collapse and connections to nowhere. First, let’s explore the implications of context collapse.
Context collapse results from the ill-fated attempt to gain a so-called single version of truth. For the most part, existing CRM software can’t handle a SVOT beyond one context. In fact, SVOT is unattainable, if not a myth altogether, without context integration.
Consider an organization that is both a customer and a supplier. It’s a fairly common poly-identity scenario.
For example, take this announcement from SalesForce: (Added 4/26/2017)
After countless implementations as a strategic partner making other customers successful with Salesforce, Accenture chose Salesforce as its CRM solution (for)… 25,000 users.
We can even reasonably presume that Accenture is also a supplier of services to SalesForce. (Added 4/26/2017)
Most businesses have multiple, separate systems to accommodate transactions and interactions related to these poly-identities. One system focuses on the party in the context of a customer while other systems address the same party in the supplier and partner contexts. (Updated 4/26/2017)
Integrating data from these disparate systems to get a panoramic view of the relationship with that party in both roles produces context collapse if no attention is given to identity or context integration.
The leap right to data integration without regard for poly-identity persons, organizations and groups becomes an exercise in fitting together different truths about the party. The view of all corresponding party information looks “Picasso-esque”, and businesses are unable to share data for streamlining operations and gaining coherent views of information for analysis and decision-making.
…Connections To Nowhere
Traditional CRM software is not particularly adept at rendering a complete picture of context-dependent data relationships and connections among parties forming an Internet of Not Only Customers. At best they can only frame a partial view, and even then only in one context.
This is where graph databases could come in handy. They enable users to explore distant regions of a single, complete network and expose potentially valuable connections in an enterprise IoEverybody.
Querying and analyzing connections in a whole network provide nuggets of usable and valuable insight, reveal correlations, present answers to yet unasked questions and help predict unforeseen occurrences. That’s a lot of new, untapped value in enterprise data.
I am not suggesting that CRM software substitute a graph for a relational database. Instead, on-premise, cloud and hybrid CRM software need to strike a balance between being relational and graph-like, because each database technology has its advantages. According to some, that’s why “Not Only SQL” is a backronym standing for NoSQL, which includes graph databases.
The envisioned graph database capabilities should be context-aware and context-adjusting because connections among parties, like the data about the parties, are context-dependent. So, for example, parties that are both, say, customers and suppliers, not only have different data relationships for each role (aka engagement persona), they likely have entirely different sets of connections in each role. (Updated 04/26/2017)
…Using Graph Databases For Context and Connection Integration
Check out the following diagram. It utilizes graph database modeling concepts to illustrate party and role nodes and connections in an enterprise software company’s ecosystem. Observe that a party may have multiple contextual identities with connections to different parties in other roles.
Constituencies in the software company’s ecosystem can include:
- Customers who are organizations that purchase and install their software
- Partners who are consultants and system integrators recommending and implementing the software at customer sites
- Users who are individuals that utilize the software at customer organizations
- Suppliers who provide goods and services to the software company
- Contacts who are persons employed at customer, partner and supplier organizations and groups
- Employees who work for the software company
- Members who belong to the software company’s user group
Collectively, all these parties form the software company’s Internet of Not Only Customers aka IoEverybody. Conventional CRM applications, however, fail to recognize that at any given moment any party can behave in several roles at the same time.
Persons, organizations and groups in all contexts are important to the software company even if some contexts don’t involve a purchase transaction per se. However, businesses using CRM applications just to engage and support customers can only gain a partial view of connected parties.
…Zooming In and Out On An Enterprise IoEverybody
For the most part, the extended network forming an enterprise IoEverybody is hidden from view, if it is at all viewable, in existing enterprise systems. To see what I mean, consider this diagram.
Ideally, businesses want to represent a poly-identity person, organization or group and the respective connections to other poly-identity constituents and corresponding transactions and interactions. Why? So they can traverse the deep, context-dependent connections that exist among all the parties that make the business thrive.
In enterprise applications like CRM, we typically only see a cross-section of connections among parties to transactions and interactions and then only in a limited number of contexts. These fragmented connections pose a significant integration challenge, especially when:
- An enterprise system is unaware of connections among constituent parties in other systems
- Connections are differently defined in other systems
- A single party has different contextual identities in different systems.
If you think data integration is difficult, wait until you try connection integration with poly-identity parties. This requires an entirely new thought process and framework.
We essentially have to take the set of connections a party has in one context and the set of connections that party has in another context and piece them together. This is not exactly a walk in the park, especially when the entire network exists as fragments across multiple systems.
In today’s enterprise technology landscape, no one application realistically represents the entire network. Bolting on graph database capabilities may offer a quick, low-cost and effective way to re-use existing enterprise data, achieve context and connection synchronization, and generate a single, unified view of connections among poly-identity parties scattered about different systems.
…Conclusion
The primordial purpose of a business is to create and keep a customer. Intuitively, we seek to focus on customers.
But a contrary view proffers establishing an Internet of Not Only Customers and becoming a Connections Company. We cannot know customers unless we know the identities of all participants, especially poly-identity parties, and their connections to other poly-identity parties in transactions and interactions. Toward this end, CRM software fails businesses in two ways.
First, conventional CRM data models only abstract parties in two contexts: “Accounts” and “Contacts”. Accounts typically represent organizations or companies exclusively in the customer role, and contacts are people affiliated with the account in a generally nondescript role.
CRM is not designed to accommodate poly-identity parties where a person, organization or group may have multiple roles in different transactions and interactions.
Second, CRM software is not purposed to traverse and analyze connections forming an extended enterprise IoEverybody. Ironically, the relational databases that power CRM software are only practical for uncovering the immediate connections to an account or contact.
Out-of-the-box, CRM software is largely incapable of rendering complex, network-type connections that expose relationships among the different parties and their corresponding roles in transactions and interactions. And in those instances when CRM software can depict extended connections, they are often missing connections and contexts managed in other applications.
To overcome these disabilities, businesses need CRM software to be 1.) context-aware and 2.) graph-database-like. With these added capabilities, businesses become connections-powered, context-oriented organizations riding an Internet of Not Only Customers.
Since the separate roles of poly-identity parties are commonly managed in different systems, context and connections integration are an additional consideration. A new framework and thought process are required for pulling together data relationships and connections to other parties and representing an enterprise IoEverybody.
