Part 1:
Why the Quest

Podcast transcription can be found over here.

It's been a while in the making, this. Together with a number of my like-minded friends and colleagues, we have been talking about the topic of the "Value of Graphs" for a very long time. I remember writing a "Neo Technology" whitepaper back in 2012 together with Andreas Kolleger, where I was trying to explain that "graphs mean business", and where I was exploring the "business value of graphs" in terms of "Ability, performance, cost and flexibility". Nice try. But in hindsight, I think I got the topic backwards. I wanted to demonstrate that these wonderful graphs had some kind of value, but I did not know exactly what it meant and how I should be approaching it. That's why, this time around, I want to take a better look at this topic again, and share some of my practical learnings with you.

So what are we going to do? We are going to go on a quest together. The destination is "Graphalue" (pronounced grɑːfæljuː or grAfAl-yoo), and a clear reference to the mythical land that brings the value concept together with the technical concepts of graphs. This quest is not going to be too long, but not too short either. We want to think this through, together, so we are going to create a number of articles and podcasts episodes about this topic, and that way we'll piece together the different components of this journey.

But before we get going, let's start with WHY?

Why do we need this "Quest for Graph Value"?

After having wrestled with this topic for so many years, I feel like there are a thousand reasons for starting this quest, and for thinking about the value of graphs. But there is one reason that, in my opinion, stands out.

Graphs are everywhere, and that is a blessing and a curse.

Graphs, as a data structure and a concept, are so widespread, it's really kind of wild in many ways. I can look at almost any problem, in my professional world, in my civilian world, in my social context, in my family, literally everywhere, and consider it as a set of entities and relationships that I could really easily structure as a (property) graph. We have made lots of laptop-stickers that claim that (graphs)-[:are]->(everywhere), and they really are. You can use graphs for everything and anything, but is that always a good idea? Is it valuable to use graphs for all of the world's data problems? Do the benefits of using graphs match up to the cost of doing so? That is the core question that we are trying to answer here. That is the "graph problem problem": what portion of the ocean of problems out there, is best solved using a graph way of thinking, a graph way of storing data, and a graph way of processing data? What problems are effective "graph problems", then?

I believe that the "graph problem problem" is best solved by thinking about value. It clearly depends on the value that we can deliver with the solution to that problem: if that value is superior to what we could deliver by using other / older techniques, then we have a graph problem. If the value is inferior to other / older techniques, then clearly we should stick with what we had and continue down that path for as long as possible. So that's one great reason for trying to better understand graph value - but there are actually two other contextual reasons that I would like to highlight.

Graph Value for mankind

The first reason why the Quest for Graph Value is important has everything to do with how we operate as human beings when we adopt anything new (a new practice, a new technology, a new setting, anything new…). To talk about it, I really have to refer to some literature that you should really have sitting on your nightstand. Books like Thinking, Fast and Slow by Daniel Kahneman and The Undoing Project: A Friendship That Changed Our Minds by Michael Lewis (about the magical friendship between Daniel Kahneman and Amos Tversky), and of course summary articles like Wikipedia's Prospect theory page. These writings have been my guide and mental framework for my core daytime job, which is to be building businesses that are selling Enterprise software - and their core thematic is very relevant for the Quest for Graph Value.

Here's the thing: the writings above are all about a fundamental trait of human beings, with regards to how we make decisions under uncertainty. We all know that humans have long been portrayed as semi-rational, and we have all witnessed the flaws in that predictable (ir)rationality, but the fact is that scientists have come to realise that the way we make decisions when faced with uncertainty is incredibly peculiar - and predictable. This is super relevant for people that need to understand and appraise the value of graphs: when you try to do so, you are almost always going to be faced with significant amounts of uncertainty. You think you have a hunch, you suspect, you assume that graphs will be valuable for you - but you won't know for sure until you actually have it implemented, right? There's uncertainty! It could go wrong! For lots of different reasons!

And that is fundamental here: we know, from scientific - so this is NOT up for debate - research, that human beings will always make specific errors in their appreciation of a situation in circumstances of uncertainty. Specifically, when confronted with uncertainty around costs and benefits, humans will

  • Always overestimate costs

  • Always underestimate benefits

This is easily illustrated in the sidebox of this article.

If that is the case, then the uncertainty around the value of graphs could be a huge problem for us graph enthusiasts. Because of this uncertainty, even the surest "bets" on graph technology could remain untaken, as we would always, structurally, irrationally but effectively, underestimate the value of the implementation of graph technology. Always. Because we ARE humans, and that's how we deal with uncertainty. There is no way around that - we will need to live with it - and on our Quest for Graph Value we will attempt to do so.

Sidebox: what would you choose? Prospect theory at work.

What COST would you choose:

  1. 95% chance to lose $10000

  2. 100% chance to lose $9499

(answer: most people would choose option 1, which is irrational - and demonstrates that we overestimate costs under uncertainty)


What BENEFIT would you choose:

  1. 95% chance to win $10000

  2. 100% chance to win $9499

(answer: most people would choose option 2, which is irrational - and demonstrates that we underestimate benefits under uncertainty)

Graph Value for, by and with IT practitioners

There's a second piece of context that I think we should address head-on: the fact that the value of graphs currently is most often best understood by technology practitioners, and rarely well communicated to non-technical stakeholders.

What do we mean by that? Essentially that our graph conversations will, and should start out as technical conversations - but they really should not end there. Let's try to explain that a bit.

First: graph value usually starts with practitioners, due to the technical nature of "graphs". The value of graphs for many different parts of life and business seems very obvious to many people, but specifically, this is the case for people that have been faced with the limitations of other approaches in their daily jobs. These people are usually information technology practitioners - people that think in code, algorithms, tables, SQL statements, and clustering topologies. These technical folks, usually darn well realise the pros and cons of other data structures and understand that in a world that gets increasingly connected, and implementation of a data infrastructure that is tuned to connectivity, ie. based on graph structures, could be incredibly helpful. But here's the rub: their perspective is a technical perspective, not a "business" perspective that is understandable or appreciated by people of different, non-technical backgrounds and skillsets. The technical value does not necessarily translate into non-technical value - and therefore it is difficult to argue the investment case for it.

Secondly, and kind of a variation of the previous point: we should also recognize that great technologists are increasingly important in a modern enterprise. Data is the new gold, and technologists determine the art of the possible for many business decisions. Therefore, technologists have a disproportionately large say in many decisions that are very much at the core of people's lives and businesses. This is only deepened by the fact that the world is still acutely being confronted with a shortage of technical staff. So as a consequence we really don't have the opportunity to talk about the business value of technology, for example, the business value of graphs, without making sure that the technology practitioner is on board. We can't just wine & dine our way to a graph project with the CIO of an organisation - we need this to be a bottom-up process, so to speak, which will need to get buy-in at all levels of the organisation.

Third and last: technologists are not always best placed at making the bridge between the technology world and the business world. It takes a special skill to bridge this gap - and it requires skills that technologists do not always have or even should have. We want our technologists to be focused and excel at making technology decisions - but that often goes at the expense of being able to perfectly communicate the logic behind their decisions, especially if that logic is non-technological, and for example, monetary. This is of course something that will change over time - but today we should assume that the technological value that the technologist sees so clearly before him, does not necessarily get communicated to business stakeholders in an understandable way. We need to think about that. The classical example for me is the fact that technologists argue the case of graphs based on the "flexibility" that it will bring them - and the business product owner responding that there is no flexibility budget in the project. Sound familiar?

So the conclusion, for me, is that we need a better, more structured way of finding graph value. Once we have that, we need to get better at building the case for graph value. Once we have the case, we need to get better at presenting the case for graph value. And then, when we have all our ducks in a row, we need to get better at delivering the graph value. That, I believe, is what truly will be moving the needle.

So that's the Quest that we are starting here. We will develop a number of articles, podcasts, and presentations on these topics that we hope will be useful to everyone. And as always, it will be a true Quest - a journey that we get to enjoy, together. So if you have any questions or comments - please feel free to reach out and connect! That's what we do this for!