Graph databases are a technology in which the relationships between data are as important as the data itself. Graphs make feasible social networking, recommendation engines, and any other process where you need to navigate from one thing to another. While there are plenty of technical and business reasons to adopt graph databases in your product, in this post I will focus on how graph databases affect the ability to develop your product in the first place. That is: how graph database technology facilitates an Agile approach to product development.
The essence of an Agile approach is that a cross-functional and self-directed team, responding to changes in the market and their customers, can deliver value at a predictable pace over time. The use of a graph database can facilitate this.
Deliver Early and Continuously
Imagine you’re sitting down with your customer, members of your scrum team, and any other stakeholders to map out the context of what you will build. Perhaps your whiteboard looks something like this:
This is all the team needs to create and begin to populate the database. Literally within minutes, even during the meeting itself, the team can demonstrate some working (if not releasable) code that might look like this:
This ability to quickly move from concept to code allows the team to demonstrate their vision of the product so as to receive feedback in a timely fashion and adjust accordingly.
Adapt to Changes
Change is a constant in product development: markets change, new customers are wooed, existing customers need enhanced features. And when the team demonstrates what they’ve built so far, feedback will provide additional sources of change. Whatever the case may be, the team needs to embrace these changes so that the work they produce has value.
This welcoming attitude is not easy with every technology. Changing the data model in a classic relational database is enough to give any member of the dev team gray hair. It requires an experienced database architect and a fair amount of time. It is not something you do on a whim.
With a graph database, there are no changes that need to be made to the existing database when the model changes. Of course, you’ll have to add new or update current data, but that’s moving forward.
Anyone Can Do the Work
As I just detailed in the previous section, making changes in a relational database frequently requires specialized work that very few people can do. If your team does not have a database architect or that person is off on vacation, you have a serious blocker.
With graph databases, however, just about anyone can make changes. The query languages used by graph databases, such as Cipher for Neo4j, are simpler than SQL, the language used by most relational databases. The underlying structure of a graph database is also much simpler. In a typical relational database, the data for a single object could be spread across multiple tables and the data in those tables filled with non-intuitive IDs and/or blank cells; that makes it difficult for a human to read and make sense of.
The Case for Graph Databases
The case for using graph databases can be very strong:
- The technology: When you need faster query execution
- The business: When the relationship between things is more or as important than the thing itself
- The process: When you need to accommodate a changing and/or unknown environment
If these ring true for you, then it’s time to look into graph databases.