Part 2:
The Map to
Graph Value

Podcast transcription can be found over here.

Who's got the graphiest idea?

In the previous article, we talked about our Quest for Graph Value, that magical land sometimes referred to as Graphalue, where graphs are everywhere, and people live in peace and happiness. We talked about the necessity of going on that quest, the necessity of establishing a clear value case for our graph-based data strategies, and our intention to take this quest very seriously. That's where we are now.

The next part of this journey, then, is all about exploring our route to Graph Value. How can we find the value case that we are looking for in graph data strategies? We really should make a plan and draw out a map for this journey. After all: "Thinking in maps" (see the article by Anne-Laure Le Cunff) is a complete graph application in and of itself, so why not apply it to this journey as well. Maps are graphs, and therefore, we just love them by default!

The objective of this map then is to first find a route to Graph Value by finding the specific use case, for your specific organisation and for your specific team, that is going to yield the greatest possible "return" on your graph investment.

So the question that we are going to try and answer here is simple: How do we find that totally fantastic and utterly awesome graph use case? How can we identify that gazillion dollar idea? Let's explore that.

Domain expertise matters

The first thing that we will highlight is, quite obviously perhaps, that your domain experts probably already know what that highly valuable graph use case is.. Whether they are working in your marketing team, your research department, your IT group, your fraud analytics team, your cybersecurity team, or… whatever team you could be most interested in - they probably know their business area better than you think, and they probably have a lot of expertise and experience in finding and identifying the bottlenecks and data challenges that exist in that domain.

Also, these domain experts usually can look at their industry colleagues and draw inspiration from some of the fantastic examples that you can find online. Places to look are the Neo4j use case website, the Video library, the Case study library or the Resources library. I personally also really like the conference content like the Nodes 2020 online conference, the Graphtour content, and the older GraphConnect videos from GraphConnect 2018, GraphConnect New York 2017, GraphConnect Europe 2017, GraphConnect SF 2016, GraphConnect Europe 2016 and GraphConnect 2013. There's just so much to draw inspiration from.

Finally, I would also like to mention that very often, you can actually inspire people to find new sources of graph value by connecting the dots and illustrating how different subject matters are actually not that dissimilar as you might think. For example, I was able to illustrate that already a couple of times in the past by explaining that recommender systems are very similar to contact tracing applications, or by highlighting that fraud detection and contact tracing are also very similar to one another. You can use techniques from one domain, and apply it to another domain quite easily - all of them are just another graph model that you can work with.

In summary, you can very often get your initial ideas for Graph Value from your domain experts. Whether you do that through structured interviews, reference visits, case studies, or event overviews is entirely up to you - many roads lead to the same: a use case full of graph value!

Graph-powered creativity

If your domain experts cannot give you the first batch of interesting graph use cases, you should not despair. Chances are, there are still a fair number of ideas out there that could still yield the graph value that you are looking for. However, discovering them could mean a bit more work and require some specific creative processes to find them.

At Neo4j, we have seen this in action so many times - and we have implemented a specific service offering to help clients in this process. We call this the Graph Innovation Lab offering. It's a simple workshop-style activity and service that allows you to work with the best people, technology and methods to uncover these fantastic graph opportunities. Creativity plays a critical role during this process and is incredibly important to foster in the right environment.

Many would argue that creativity is actually in and of itself a very graphy process, as you associate subsequent ideas to one another in a very connected fashion. However, we also know that creativity is easily squandered, and will disappear from any conversation at the earliest opportunity. That is why it is so important to make sure that you respect a few simple rules in the process of finding creative use cases on your Quest for Graph Value. We'd like to mention a few brainstorming tips that may prove helpful.

Brainstorming could very well be one of the oldest tricks in the book for creative processes. Most would agree that it is often very successful, but equally easily annihilated. Who has not been in so-called brainstorming exercises that were failing as they became hindered by the past, overly judged before they were even adequately spoken, poorly facilitated, or prematurely ended before the best ideas had been allowed to come forward? I think most business professionals have seen this more than once.

This is why we highly recommend that on our search for valuable graph use cases, you use a couple of straightforward frameworks & techniques.

A classic mistake is often to think that a brilliant idea comes out of just one idea. You know the picture of the great thinker and the light bulb moment. So instead of trying harder to get to one perfect idea, just let go and create as many as possible. We got plenty of time to select and remix the ideas. A great example of this methodology is the classic double diamond from the design council. Using diverging and converging thinking.

Split the brainstorming into different explicit phases, where you first create ideas, then document these ideas, and only at a later stage - when all ideas have been freely surfaced - proceed to the prioritization phase.
Always ensure that your brainstorming exercises are appropriately moderated. Let someone with knowledge facilitate the process to avoid ending up in endless discussions, judging and other pitfalls. The facilitator is not part of the brainstorming team - he or she is solely responsible for making sure that the effort yields as many great ideas as possible. Think of a conductor of a classical orchestra.
6-3-1 is a great reminder to summarise this. Out of ten ideas, six are pure crap, three are lukewarm, and one is brilliant.

In summary: please allow for creativity, while coming up with ideas for great graph use cases. The best suggestions will come floating up above - and will make our Quest so much easier.

Graph experience matters

The reason for leveraging this kind of graph experience is pretty simple, not unlike other high-tech domains adopted for the first time. We just know that "Graph thinking" is quite different from how most information technology professionals have been trained, and most certainly quite different from what most people are used to. Like with most novelties - this just takes some time to get used to. Something that is very clear is how much we traditionally learned how to think in tables, and to get the graph epiphany moment, one has first to unlearn the old. Unlearning is not about forgetting. It's about the ability to choose an alternative mental model or paradigm, compared to learning where you can add new knowledge to the existing, and it works.

But as you get more comfortable with graph thinking and the possibilities with this technology, it becomes second nature. Once that has been achieved, people will usually love graph technology, as it is much more intuitive and flexible than what we have known in other data universes.

Our friend Mark Needham once drew this picture of a "graph adoption curve". As you all can see, it is very similar to the Kubler Ross change curve, illustrating the initial difficulties that people often experience, the hurdles that they have to overcome, and the eventual love and understanding that they can later achieve. This is why graph experience really matters.

Of course, we are not recommending that you let the graph experts do the thinking for you. That's always a bad idea and will lead to a use case that will be poorly supported by the rest of your organisation. But experience does matter - and can be quite a useful tool on our Quest for Graph Value. If you find this interesting may we suggest you spend some time reading up on the story of Fold. It's an online puzzle video game about protein folding. It is part of an experimental research project developed by the University of Washington, Center for Game Science, in collaboration with the UW Department of Biochemistry.

A perfect combination of a new perspective, deep knowledge and a process to facilitate it harnessing the power of the network.

Agility ftw!

Last but not least, and clearly one of the most important tips that we can give you on this Quest, is to remain agile, at all times, during this journey. Chances are that you will not get it right, the first time. It's very likely that you will make some mistakes on this journey - just like you would expect to make these on an expedition to a new and uncharted territory. The key, then, is to have a mindset that is able to change and adapt along the way.

A very useful tool to achieve this is really to think about the recent methodologies in software engineering that think of the software development process not as a waterfall process, but as a series of iterations. The whole principle is centred around the idea that you need to repeat the problem-solving process several times in order to truly achieve meaningful results. That's how big software systems get built today, and that's also how you can identify and articulate the most valuable graph use cases for you and your team. Remember, just as Alfred Korzybski wrote: ”The map is not the territory, the word is not the thing it describes. Whenever the map is confused with the territory, a 'semantic disturbance' is set up in the organism. The disturbance continues until the limitation of the map is recognized”.