Part 3:
Building the Case for Graph Value

Here's a quick summary of our objective: for the use cases that we identified in the second episode of this series, we would like to offer up some very specific and tangible techniques that will allow us to get very detailed information about the value case for this idea. For this exercise, we are going to assume that you start with a list of "potential use cases", and that you are able to narrow these down onto a shortlist of "most likely candidate" use cases. These candidates will then be explored further with the techniques that we will describe below.

Why is this an interesting use case? Because it will change the way we do things.

Why will it change the way we do things? Because it will enable us to follow a better process for XYZ.

Why will it enable us to follow a better process for XYZ? Because we will not lose as much time doing ABC.

Why will we not be losing time doing ABC? Because the graph will have answered the question in real time.

Why is answering the question in real time important? Because we used to have to wait for a day to have the result back when we were running it on Oracle.

Why did we have to wait for a day when we were running it on Oracle? Because it had to calculate all the links between XYZ's entities at query time with a bunch of join operations.

Ah. There we have it. Suddenly, we have a much clearer understanding of the value that the graph use cases are providing to a particular process that we had identified as a bottleneck use case already.

We want to stress that this is an especially powerful technique but that it can easily be misused. Anyone that has ever had to deal with 3-year old toddlers (who, if you didn't know yet, start EVERY conversation with "Why?") will understand that the "Why question" can be perceived as an intrusive, impolite, unnecessary ask. That's why I think it really helps to set the right expectations for yourself and your team and warn everyone that they will have to play along in this line of questioning to really better understand the value case. It's super powerful but uncomfortable.

We recently had a systems outage in the data center. With our current tools, we had no way to explore the impact of that outage on specific customers, so we spent two days with a team of ten people, pouring over our Excel files. That's where we currently keep the list of customers and the systems that they use. We had to go through all of these files line by line, which made our heads spin. We surely missed a few of the cases, but after 3 days we were able to contact our customers, explain what had happened, and present to them a plan for not to happen again. Frankly, many of them did not believe us - as they thought that it was pretty incredible that it took us this long to react.

In the example above, we highlight one part of a problem that a graph-based configuration management use case would help resolve. All the dependencies between systems, services, users and customers would immediately be apparent in a network, and response time would be reduced to a fraction of the above example. That's a very tangible way of understanding what the value of that graph-based system could bring to the table.

So a simple technique to address this is to ask the owner of the problem/solution, who is impacted by the current and future way of working. Chances are, that in the example of the datacenter outage above, we are not just going to be looking at the IT staff and the Customers that are going to be affected:

• It's also going to generate additional headaches for people like the support help desk (who would get a ton of additional calls over the course of that 3 day waiting period).

• It could also generate more work for the customer service people, who would get more calls and need to spend more time reassuring their customers after the incident.

• And it could just also cost the sales team very dearly, as some deals that were in flight and about to close got critically derailed because of the incident.

• Et cetera, et cetera.

The point here is that by asking for the additional indirect impact that a use case will have on an organisation, we will make the need for the solution even clearer, tangible, and measurable. We want to expand the value case as big as we can, and therefore we want to explore all the potential sources of value in as much detail as possible. Then, for each of these indirectly impacted stakeholders, we can also explore the WHY, peel the onion, and make the details of the value case as specific as possible.

Look for specifics!

When we apply the above techniques, keep in mind that we are always trying to make the Graph Value Case as specific as possible. So every time we ask the "Why" question, every time we try to understand how something is currently being done, every time we assess the impact on the organisation - we always want to try and bring it down to something that we can precisely pinpoint and measure. We want to make sure that the value that we identify is quantifiable so that we can use it to reduce the perception of uncertainty that is all too often guiding people's evaluation process today.

We bring this up because there are two particular misconceptions around this.

First, people often think they are bringing a value case to the table, but it's way too fluffy and unquantifiable. This is often the case when we try to argue the value of a graph project based on things like "easier modeling", "increase flexibility", "better maintainability", etc. No one is disputing the fact these are real benefits and values that you get from a graph project - but they are too unspecific for any boardroom to sign off on a 6-figure project budget for this. This simply will not fly.

Second, a common misconception is that we need to look for monetary measures to understand "what something will cost" or "what it will bring to the top line" of an organization. That, in my view, is plain wrong. It's not about monetary evaluations - it's about making it measurable and therefore less uncertain. It could just be a specific reduction in time. A particular increase in a customer satisfaction metric. A particular increase in prediction accuracy. A shorter lead time. A decrease in hardware service costs. Whatever it is - but it would need to be clear and quantifiable. That's what will make this Graph Value Case tick.

That brings us to the end of this third article about getting to our graph value case. We hope to have delivered some specific help to make this easier for everyone and are, of course, looking forward to discussing this with you. Why not? Maybe we can even try to build a Graph Value Case together?