Part 5:
How to make sure we achieve Graph Value

In the previous articles, we talked about why it's necessary to be very explicit about the graph value case (part 1), the techniques that we could use to find and build the value case (parts 2 and 3), how to present the value case (part 4), and now we will talk about the way the rubber actually hits the road - and how we can help make sure that that value actually gets delivered to the graph users.

Much of what we are going to talk about here is not necessarily about graphs or graph projects - it could just as well be about any other kind of innovative technology out there. But still, it makes sense to pause and reflect about this - as mistakes are all too often made in this phase - and then the entire value case that we have so painstakingly built could still just disintegrate. So let's talk about this.

Second, the way to do that is to start small, and expand from that initial minimal use case outward, once you have demonstrated the initial value case. "The best way to eat an elephant… is in bite-sized chunks!" goes the saying - and that's also true for graph innovation projects. Walk before you run, and take it from there. Success will breed success, and the flywheel will turn all the more powerfully once you have got it to spin at full speed.

Lastly, we believe that this is best summarized in contrast between "traditional" IT development methodologies (the "waterfall" models that take you from analysis, to design, to development, deployment and maintenance in sequential steps) and the modern, "agile" methodologies. From the initial quick value case that we mentioned above, we should iterate and accelerate. It's a much better methodology that leads to higher quality software and better buy-in from the business stakeholders. It's the way forward for graph projects, for sure.

First, I think it's important to understand that there is always, ALWAYS, more than one way that you can technically achieve your objective. So, therefore, we believe that a key recommendation is to not burden the project with unnecessary technical uncertainty. Don't choose a programming language/development toolset that you have never used before - go with something that you and your team know and are comfortable with.

Second, I think it is vital to truly learn from the mistakes of others - and hire experts' expertise for expert topics. Yes - we all know that given enough time, resources and opportunity to fail, you could very much figure it all out yourself and not require external assistance. But that's not the most thoughtful way to do things: it really helps if you can sidestep fundamental problems with the help of someone that has done it all before, instead of losing valuable time in trying to proudly and frustratingly solve everything yourself. In the case of a graph project, that would often mean that you could ask specialists from Neo4j for a few days of assistance - because it will actually be cheaper that way.

Thirdly, when working with specialist partners, be mindful about the way you structure the engagement. The temptation will often be to ask for some kind of a fixed price commitment from the partner, but we believe that this is actually against the interest of all parties involved. In innovative - and, truthfully, more uncertain - projects like graph projects, it really is not that easy to "lock and load" on a fixed specification that would determine the ins and outs of the entire project. Again, it's actually against the interest of all parties involved: as a customer, you want to have the ability to change the "specification" when required. As a partner, they probably also don't want to charge you the "uncertainty fee" that pads the project cost to ensure some kind of profitability. Therefore, it makes a lot more sense to structure the project with agility, agree on commitments and deliverables for every iteration, and pay for the project cost on a time and material basis. It's better for everyone.

How to deploy - on prem or in the cloud

One more, and definitely not the least interesting or important topic in this article about ensuring that we achieve the graph value that we set out to achieve, is the question about deployment. Like with so many Enterprise software tools these days, graph infrastructure (including graph databases, graph data science libraries, and graph visualization solutions) products are available in different forms and with additional capabilities, requiring careful consideration - as they can clearly impact the graph value outcomes.

The first thing to consider is "to cloud or not to cloud". Essentially, there are many different ways to install and host a graph infrastructure server, with varying degrees of control, flexibility, and cost. Let's take a look at some of the options. The first option is to run your graph infrastructure on your current data infrastructure environment, in its own virtual machine or container. This offers you ultimate control and flexibility but will require more "manual labour" and expertise on your part. On the opposite side of the spectrum, the second option offers you the possibility to host a graph infrastructure "as a service". You set it up and forget about the details - all you get is a database endpoint somewhere on the internet for your application to integrate. And then thirdly, there is also a "halfway" option, with which you can actually have control over your environment, in a "Cloud Managed Service" setup offered through manual contracting.

All of these three options have clear pros and cons that will need to be considered. Things to consider are, for example:

• The operational, server management expertise that you want to build up, or not - in the cloud or elsewhere

• Security requirements, based on the sensitivity of the data that you will be working within the graph system

• Costs and commercials of the graph deployment system that you are considering - in terms of hardware, software and staffing

In our experience, it's often pretty clear what the right option looks like from a high level - but that will still require you to create a synergetic relationship between you and your partners and vendors on this project. The huge advantage that we see, nowadays, however, is that all graph vendors typically are very highly motivated to make your project successful, as they know that the subscription based deployment models require them to make you get to graph value - or else the deployment will likely fail and the subscription will cancel.

With that, we have come to the end of this part about getting you to graph value - and we are ready to finalise the discussion with one more concluding part. Looking forward to it.