Graph Databases for Enterprise Architects

Today, I had the opportunity to do a short webinar where I tried to articulate why I think that a graph database like Neo4j really can contribute to a better Enterprise Architecture. I'd like to take some time to explain that here on the blog as well. I think there are three big reasons why Graphs are Good for the Enterprise Architect, so let's go through them and I will try to illustrate it with examples.

Time to market

A modern Enterprise Architecture, these days, should enable quick business decisions. If business managers want to react to competitive threats, or better still, want to seize a new business opportunity, the architect’s response cannot be that “he can deliver that in 12 months from now”. That may have been ok in the past, but it’s not anymore. Agility is key, and being to implement modern-day functionality like social network integration, real-time recommendations, real-time fraud detection - just to name a few examples - needs to be quick.

One of the key things that a graph database brings to the table to enable short time to market is the excellent fit with these domains. There is a natural fit between these very interconnected domains and a graph representation. There is no need to translate back and forth from the domain into the relational storage paradigm, and that alone cuts down implementation efforts by an order of magnitude. Complex operations like pathfinding, recursive questions, complex pattern matching or deep joins - all of the above are much simpler in a graph database than in any other model - thereby enabling shorter time to market for the enterprise architect.

Here's a short demo illustrating how the Enterprise Architect can achieve shorter Time to Market:

Flexibility

We all know the cliché: “the only thing constant is change”. And we have all lived its reality: in the fast moving business world that we enable with our enterprise architecture, we have to be able to act quickly, react to changing circumstances, and be flexible in the way that we react so that we can learn, adapt and improve our performance. In the enterprise architect’s world, we have adopted things like “Agile” development methodologies for a reason: we understand that in the fast paced business environment, our IT systems have to be equally fast paced and able to adapt. IT systems can no longer feel like a straitjacket - they have to allow our business processes to evolve and adapt, in a flexible way.

Graph databases allow for that flexibility. Developers don’t have to spend valuable time trying to model what they don’t know, have the ability to grow their data models as their understanding of the problem domain grows, and can flexibly work with their data structures in many different situations. This in itself, is a huge added value to any enterprise architect who is tracking the constant change around them.
Here's a short demo illustrating this Flexibility:

Operational performance

In the same way that graph database often “enable” certain capabilities for specific use cases as described above, they just as often offer a very significant performance improvement over existing technologies. Some query patterns - like the deep/recursive join or the pathfinding operation - require an enormous amount of hardware/software horsepower in the traditional relational database world in order to deliver the results in a timeframe that users would accept. And even then, we all know cases where the query performance would become brittle and unpredictable under load.

This is where graph databases can really help. The same queries that were causing constant headache in the relational world, would predictably run like a breeze in a graph world. That’s a fantastic trait for an enterprise architecture that business managers can rely on. The fact that it will probably cost them less in terms of hardware and software - is of course a nice bonus that we should not underestimate. Everyone understands the benefits of a sound architecture - but when it actually saves money, business managers will really start paying attention.

Here's a short demo illustrating this operational performance:


I hope that I have made my point clear about this added value of Neo4j for the Enterprise Architect. If you have any feedback - please let me know.

All the best

Rik