Graph Databases

Subject - action- object.  That's a sentence, and a sentence is information.

firstName, lastName, city, state, zip.  That's a database table, and a database table is storage, it's data, yet it conceals information.  The only way to get data in is through the structure required by the table.  firstName, lastName, city, state, zip. Fill in the form.*

I had a meeting with Mike Zimmerman the other day at his corporate offices in Columbus.  He said they're facing challenges with their production line.  It wasn't the handling of the orders that was a problem, but having the right parts available at the right time.  Their order quantities vary widely, in a very unpredictable way.  How will he know how to tell his suppliers how many parts he will need on a weekly basis?  This is a challenge.

Put the above data into a database.  You're laughing because obviously you can't.  You'd need a table for Mike Zimmerman's data (who he is, his company, address), another for challenges (challenge, impact, vision of solution), another table to track meetings (when? where? who was there?) and then a labyrinth of joins to link them altogether.

Oh sure, you'd be able to store and track the data, but what can you learn from it? How many meetings were had?  That meetings led to more meetings with more contacts?  How (or why) would you try to get some useful insights out of this data?  What's the useful information in this data?

Let's look at this from a Subject - verb - predicate perspective.  What do we know?:

I had a meeting with Mike
Mike has challenges with production
Mike communicates with suppliers
Production needs parts 

We know a lot about Mike, we know a lot about production, we know a lot about suppliers.  I bet you even started thinking about solutions for our poor fictional Mike.  Because the challenge he faces is interesting and, well, it's fun to solve problems.  Were you thinking he could get his suppliers to come by more often?  Leave more parts behind just in case?  You probably had some pretty creative ideas.

And a database, built on tables and populated through forms... wouldn't.

As you read or write - think, really- you're throwing information into and pulling information out of your brain.  Better yet, your brain is making connections and coming back with insights.  Your brain is a black-box database computing engine with the ability to make amazing connections and suggestions combining data and experience together.  It will automatically try to make use of new information or, failing that, store it for later.

So the input mechanisms of database are fundamentally poor (gussied up forms), and the information it provides is not of too much value beyond transaction record-keeping and aggregate analysis thereof. Big Data and Predictive Analytics solutions are simply looking for correlations to help us better understand what has happened in the past and therefore be proactive for future.  To "predict"an effective course of action.  This has value; knowing that an aging timing belt will fail under certain conditions can help us replace it in time.  But ask any good, experienced engineer, and they'll dunk an o-ring into ice-water to show that it gets brittle.  Thank you Mr. Feynman.

How does a database help someone whose job is to work with information and relationships among them?  It stores it and retrieves it in a structure cleverly pre-defined to hold it.  In other words, it is a reference.

Why are social networks so successful? You're not filling in forms, but you are acting and making relationships (tags, hashtags, favorites, @mentions) and sharing content (links to things of interest, a quote, a quip, a thought.

Why are "Hey Siri," "Okay, Google," and "Alexa," successful?  Because we interact with the computer in a very natural way.  It's easier to throw data into the void than to go to the specific app for that data.  Set my alarm.  Schedule a call with.  Where's the nearest Starbuck's? What's the length of a two degree angle at a radius of three miles?  Seriously, ask Siri.  She does the math.

My career is with enterprise business software in the domain of Customer Relationship Management.  Tools for Marketing, Service, and, relevant to this thought process, Sales.  CRM Sales Force Automation (SFA) solutions are relatively simple: first and foremost, SFA is management tool for listing of and reporting against customers and the sales opportunities the sales departments are pursuing.  Value can be added through transactional processes (actually capturing and executing the orders at the end of the sales cycles) or by effectively divvying up workloads (sales territories, divisions, common customer needs).  But SFA systems are essentially a big, multi-user forecast spreadsheet and historical business log.

Fill in the form.  Help the transactions flow.  Learn from the aggregate.  It's a management tool, with pretty access (phone, tablet, broswer) to help the end users fill in the forms.

How CRM could work: What if we simply threw data into the system ad hoc. No forms.  What if we pulled it out the same way?  What if the system made connections (or suggestions of connections- let's call them insights) for us and showed us things that are relevant and useful, potentially interesting.  And we could signify that they were so.  Source of the data might be solely me, might be different players on the team.

But not just logging a call and the notes of the call, but having a graph database extract through natural language, etc) the subjects, actions, objects, and the meaning of the content.  If I type or speak the paragraph about my meeting with Mike into my phone or computer, the CRM system should parse adn create a meeting, should create a challenge, should link Mike to the meeting and suppliers, should find others

One technical challenge is that we know intuitively who Mike is, what company he works for and that his offices are in Columbus.  We've already processed it.  So later on, when we say "he" or "mike" or "suppliers" we know we're talking about Mike and we might even have some specific suppliers in mind.  How will a system make these determinations?  UI approaches, a review of suggestions to further calrify.  Learning from things.  Or it can store the data and at a later merge Mike who has Challenges (and all the other things we know about Mike) with Mike Zimmerman (and all the other things we know about Mike ZImmerman), effectively improving our knowledge of Mr. Z.  Or perhaps the graph can make the triangualtion itself based on one or two degrees of relationship.  Mike in Columbus with Suppliers... could that be Mike Zimmerman from Columbus with suppliers?  Ask the user!  Siri asks for more clarification.

*Don't you hate filling in forms? Of course you do.  But databases and business systems are transactional systems by nature and depend on the correct data being entered.  You therefore need to fill in a form. You can make it pretty and you can make it convenient, but even "1-click" checkout on Amazon is, fundamentally, filling in a form.