Know more, sell more. That’s the bottom-line when looking to introduce graph databases into the enterprise.
Graphs are well-known for uncovering bad guys in instances of fraud, waste, and abuse. Now let’s use the language of graph nodes, edges, and properties to find, nurture, and keep customers.
Graphs are visually-leaning database technologies that can take us beyond the coveted 360-degree customer view. By exposing hidden, blind and unknown connections and data relationships, graphs open up new vistas and paths to deeper…and broader customer knowledge and insight.
But before downloading the first graph database and visualization tool that Google finds for you, here are 10 things to know…and do before transfiguring enterprise system data into an enterprise (aka commercial) graph.
1. Always keep business purpose in mind: to create and keep customers
Speedy performance and scalability are the most touted benefits of graph databases. They are important and all, but when developing, utilizing, and experimenting with graphs for the enterprise, continually ask, “Will this meaningfully impact how we create and keep customers?”
Consider, for example, what a graph can do to better inform customer engagement and marketing decisions, identify high-value target accounts, guide selling and marketing actions, anticipate customers’ behaviors, understand buyers’ journeys, and predict purchases or even defections. Better yet, look for how a graph can help to discover new pockets of customers and recommend products.
We also want to avoid succumbing to our natural tendencies to do things as they have been done before. In the words of Aaron Levie, focus on how things can be done.
Ask how can graphs help us do what we can’t already do to create and keep customers and resultantly boost revenue? The answers will help lead the way to successful graph adoption.
2. Seek to put connections and data relationships you can’t see now in plain sight
When I started hearing the catchy term “dark data” move from IT conferences to TV commercials, it was a cue that something had gone mainstream. For sure there’s plenty of dark data to be illuminated, but there’s even more in the way of dark connections to be discovered.
Take the highly desired 360-degree customer view. Instead of gaining a complete picture, we mostly suffer from tunnel vision. Hidden, blind, and unknown connections impair our peripheral awareness.
We need to see around corners and bends, go below the surface of new-fangled data lakes and peer beyond the horizon of immediate and near connections. A graph database helps do just that.
Graphs let us cut through the fog of data relationships and break through the circumferential boundaries imposed by 360-degree customer views, revealing extensive dark connections. But to pull this off, we have to close the gap between the way we know things from our enterprise systems and the way things actually are…multiple epistemologies versus a single ontology.
3. Emphasize connections; that’s where the value is
We are told to be “data-driven” and to have a data strategy. Well, that’s not enough. We equally need to be connections-driven, have a connections strategy, especially if we intend to benefit from all the latent value in data. [Updated 04/30/2017]
Connections are important for going from data and information to knowledge, insight, and wisdom. Connections created in context are as important as data itself. In fact, the information, knowledge, and wisdom we derive from connections spawn more data.
Who knew so much knowledge, insight, wisdom, and even more data can be had from an unimaginable number of connections, many of which aren’t even obvious? But here’s the catch.
Graphs are thought to be schemaless. Not so. We mistake their well-known plasticity for having no schema.
Turns out, an enterprise graph’s schema resides in ontology. Ontology gives nodes, connections and their respective properties the required meaning and nuance – the oomph – to inform customer engagement and enrich customer insight.
But in the end, it’s about connections. Graph connections provide customer knowledge and insight beyond what customer data integration alone can deliver in the form of a 360-degree customer view.
[New Thought added 03/26/2017: Here’s one possible reason we have so many “single versions of truth”. We could all be working with the same or different information and data, but if we connect it differently in our heads, we get, well, different versions of the “same” truth.]
4. Model an enterprise graph primarily around engagement personas
When envisioning enterprise graphs, use engagement persona as the framing context to weave nodes and edges together. Engagement persona and other context factors, such as location, time, channel, device and product usage, purchase requirements, and the like, jointly make the enterprise graph a fountain of customer knowledge and insight.
The typical inclination is to model engagement persona as an edge. After all, the goal of a graph is to traverse connections. But there are several compelling motivations to abstract, reify and canonize engagement persona as a node.
First off, an enterprise graph should mirror source system schema, which inherently dictates engagement persona, such as customers and suppliers, as entities.
Second, each engagement persona likely has different sub-contexts with widely different connections to other parties and data relationships.
Lastly, reifying engagement persona will increase the number of connections, opening up opportunities for richer analysis and greater customer knowledge and insight.
If we do not set up engagement persona as a node, an enterprise graph would muddle, not model, who we transact and interact with and who we engage transacts and interacts as.
Christopher Poole says “identity is prismatic; there are many lenses through which people view (interact and engage) you.” Web designers call these separate lens or polymorphisms – interaction personas.
Here are the two main identity issues regarding enterprise systems.
First, campaign-to-cash transactions and interactions frequently involve multiple parties with different engagement personas.
Second, the parties we engage as customers are also sometimes suppliers, partners and whatever else. For each of these engagement personas, a party may have different sets of connections and data.
To fully know persons, organizations, or groups as customers, we need to know who else is involved in their interactions and transactions. We also need to know them in all their engagement personas, not just as a customer.
We must model an enterprise graph as if it were a “Facesbook”. That’s the only way to close the existing model-reality gap.
Enterprise systems are fundamentally flawed. They typically only cast a single reflection of the persons, organizations, and groups we engage in transactions and interactions.
This contextual isolation has misled us to model a person or an organization in an enterprise system with only one engagement persona as, say, a customer or a supplier. An enterprise graph lets us separately connect a party to many engagement personas and corresponding connections and data relationships.
5. Visually model and strategize a graph, i.e. nodes and edges, out loud
Graphs require visual thinking. That’s why simply scribbling or doodling a coarse graph on a whiteboard is all you really need to get started.
Sunni Brown, an expert on visual literacy, says “doodling is to make spontaneous marks to help yourself think.” This makes doodling the ideal visual language to, well, noodle an enterprise graph and to explore and communicate information, knowledge, and insight contained within graph vertices (nodes) and edges.
But here’s the amazing part. What you doodle is pretty much what you get.
Working graphs are near spitting images of their white-boarded doodles. That’s one reason business users are attracted to graphs.
Doodling graphs on a whiteboard, or even a bar napkin for that matter, engages and enlightens business users. They can readily see how persons and organizations are connected to anything by their engagement personas, not just by their context-independent legal name, social security number, or federal EIN.
Compared to creating a relational data model, white-boarding a graph is fun and productive. So much so, get ready to pass around the dry-erase markers and hand out some sketch pads. [New Thought added 05/17/2017: Both technical talent and business users need to sit alongside each other to pull off an enterprise graph.]
6. Exploit enterprise system schemas to construct a graph around contextual identity
Turns out we can take advantage of the operational and contextual isolation of existing enterprise systems to create a full-blown “Enterprise Connectome”.
Using enterprise source system schema to dictate contextual identity is key. We can define contextual identity as the combination of a nonfungible party – person, organization or group – and its fungible engagement persona, e.g. customer or supplier.
Connections forming a graph are often ad hoc, making the creation of something like an enterprise connectome at scale a huge, if not insurmountable challenge. Enterprise systems by design are purpose-built around engagement personas, serendipitously providing a way to transform relational table rows, columns and joins into a graph structure modeled around contextual identity.
For example, a CRM system is narrowly constructed around accounts and contacts. Similarly, HR systems are all about employees. Meanwhile, AR systems are modeled around ship-to and bill-to parties and contacts. And AP systems are defined by suppliers and supplier contacts.
When a party is in multiple systems and has different engagement personas in each system, a graph can re-present (sic) one party with multiple engagement personas. As a result, we can view a person or organization that we engage with through different lens – customer, supplier, and employee – all at the same time.
7. Connect, don’t combine data from multiple sources
Mention integration and we normally think of combining enterprise data from different sources. Integration, however, means something totally different when working with graphs.
Forget the notion of combining with graphs. Connecting is what graphs do.
“Combining” more closely suggests merging. Graphs don’t merge. They connect. And if we make connections without regard for a person’s, organization’s, or group’s differing contextual identities, we risk context collapse, resulting in “Picasso-esque” 360-degree views.
First off, keep in mind we are trying to fit a rectangular peg (a relational table row and corresponding columns) into a round hole (a graph node). Then there’s the Harry Houdini act where we transfigure table joins into graph edges – connections.
After that, we complete other node and edge transfigurations, including synthesizing portions of the graph according to specific connection rules that help reconcile duplicates. Know this; when dealing with engagement personas a duplicate means something completely different.
“John Smith” behaving as a customer in one system and as a supplier in another is not a duplicate. The data relationships are more “connectorial” than combinatorial.
Ultimately, an enterprise graph allows us to connect necessarily diverse enterprise data from multiple disparate sources and reveal immediate, near and distant connections around multiple contextual identities. Poly-identity parties are commonplace, and for each contextual identity, the party can have a different set of connections and data relationships.
As you would expect, this is all much easier said than done, but it is doable and worthwhile to try. We even use existing enterprise system records “as-is” – sort of – to avoid logically disturbing anything about the data. In this way, data provenance remains fully traceable.
8. Experiment first, ask questions later
These days, acting on any idea without a “use case” is daunting in a risk-adverse culture. But that’s the proposition here.
Unfortunately, jumping into a new technology without benefits in hand makes most managers and executives skittish, if not squeamish.
To alleviate the unease, position a graph as a tool for generating a use case. If nothing else, you will get points for creativity even if some see your use case as a hope and a prayer.
You can also resort to a Proof-of-Concept. But here’s the problem with a PoC. It implies we already have a concept in mind.
If you do, great, but many times we don’t have a clue. Either way, always work with real, immediately available enterprise data.
For example, accounts and contacts, opportunities, campaigns and whatnot in CRM is a good place to start searching for connections, even if we don’t know in advance what that will bring. The data is handy and there are loads of insights to glean from a graph just using CRM data.
After stuffing a graph with gobs of CRM data, just start sifting through nodes and connections to see whatcha got. It’s amazing what questions will jump out at you.
Pick a few, say, five promising questions and go for it. Then let new answers drive new questions, inferring yet new connections and creating a chain reaction.
For StarTrek fans, think of “going for it” as “a five-week mission to explore strange new connections and data relationships, to seek out new insights and new foresights, to boldly go where no user has gone before.”
But don’t be surprised if your GraphTrek delivers immediately usable insights and real benefits, making it more than a PoC, even if less than “production”.
9. Visualize and analyze connections to explore, explain, enlighten and engage
I first bumped into graphs five or six years ago and was astonished by how much information they exposed with just simple searches and visualization. But it doesn’t take a seasoned data scientist to realize the latent potential of a well-thought out query or algorithm. So keep a quant nearby.
Graphs naturally communicate stories about connections. But great storytelling requires context and knowing that customers and other members of our ecosystems, not inanimate data, are a story’s heroes.
That’s why modeling a graph around contextual identity is so vital. We interact and transact with lots of characters who make great stories with their different and multiple engagement personas, relationships, associations, and connections.
But keep in mind that while relationships, associations, and connections seem synonymous, they tell different stories. Graphs can help out with all three.
CRM, for example, was created to support relationship building and management, but CRM isn’t great at displaying connections between people, and between people and things. This makes graphs a green-field opportunity for CRM. They can assist with both interpersonal relationship-building and edge and network analysis.
Similarly, graphs reveal unobvious connections, which can help out in areas like market segmentation and individual targeting. From these connections, we can work out associations that enable us to form clusters and communities of connections.
Meanwhile, machine learning promises to offer support in the way of inferring more, new connections, providing even greater knowledge and insight. And while we are not yet at the point of pre-cognition with Minority Report-like foreknowledge, we can use graphs in combination with ML to predict and prescribe customer purchases.
Stories written around graph connections can range from snippets to sagas, from something akin to Dr. Seuss: Oh, the Places You’ll Go to War and Peace and everything in between. Determining which way to go largely depends on your audience and purpose.
Salespeople, for example, might prefer fresh tidbits of customer insight delivered as punchy audio “postcards from the ‘edge’”. An analyst, on the other hand, would expect meatier marketplace dossiers.
10. Use graphs to complement, not replace existing relational enterprise systems
The underlying relational databases at work in enterprise systems can’t handle complex and deep network connections among persons, organizations, and groups with different, multiple engagement personas. Lots of times, we can’t even make or find connections between parties in the same system.
On the other hand, graphs can’t perform in ways relational enterprise systems can to facilitate transactional and interactional events. And even if graphs could, we can’t feasibly expect to rip out and replace enterprise systems anytime soon.
In our increasingly interconnected business ecosystems, we need both relational and graph database capabilities. Now that we are completely comfortable with social network sites like LinkedIn, we similarly seek to know if and how the parties we engage are connected.
Graphs are not an alternative to relational databases for most organizations, at least at this time. They are, however, a powerful companion technology.
Let’s think more in terms of a snap-on gadget – a “portkey” of sorts – that enables, for example, CRM users to explore and visualize a customer’s “Big Connections”. The deeply-informed engagement and insight a graph affords doesn’t have to come with an unreasonable expenditure of time, money, and resources.
You may recall from Harry Potter, a portkey “is an object enchanted to instantly bring anyone touching it to a specific location”. The proposition here is to create a nonfictional capability that brings anyone clicking somewhere inside, say, a CRM account or contact record to that customer’s connections and corresponding data relationships.
Over time we can extend a portkey to traverse an entire enterprise graph or connectome, not just a single system’s connections. Once there, we can then search, visualize and analyze a customer’s contextualized connections to other parties in the complete ecosystem.
By modeling enterprise graphs around contextual identity, we can create functional graph shards from CRM, AR, AP, and other systems. Neuroscience researchers label these shards “connectivity motifs”.
Each functional connectivity motif is a collection of immediate and nearby connections we can call “cliques”. A clique corresponds to a single enterprise system schema and is another term adopted from neuroscience.
Conclusion: Binge Graphing
The words of J. Robert Oppenheimer come to mind when considering an enterprise graph. “Genius sees the answer before the question.”
The genius of a graph is that its connections provide answers to questions that have yet to be asked. And the more questions we ask, the more new answers and questions arise.
To tap this genius, though, we have to piece together nodes, edges, and properties in ways that better enable enterprises to create and keep customers. But here’s the paradox with that. We can’t create and keep customers by focusing just on them, even though that’s exactly what we are often told to do.
We can’t fully know customers without knowing their immediate connections to other parties to transactions and interactions and how they are distantly connected to other people, organizations, and groups.
The whole process of connection-viewing is mildly addictive and can lead to binge graphing, explaining why we are so vested in the number of connections and followers we have on, say, LinkedIn or Twitter. We are somewhat defined, if not measured, by our connections. Similarly, we can define our customers by their contextualized connections.
Enterprise systems and their relational databases, in particular, fail us in this regard. They aren’t inherently designed to support and expose connections, and certainly not connections based on contextual identity.
But the contextual isolation of enterprise systems does provide a benefit. It allows us to construct a meaningful, nuanced enterprise graph and close the model-reality gap by connecting diverse enterprise system schemas.
For additional reading, check out this companion article: The Enterprise Graph: Hunting The ‘Edge’ Of Customer Knowledge.