The Best Case for Graph Database: Because It's Time to Solve Your Knowledge Problem

Every single day it gets more and less and more and less but mostly more complicated to conceive, research, plan, develop, build, secure, market, sell, support, enhance, evolve, etc. a product. What starts as two people burning the midnight oil after their day jobs end turns into teams of functions working together and apart to bring solutions to problems to reality. As a startup team snowballs through series A, B, C, D, E, F, G, and so forth, information accumulates. But where does it go? 

The Problem: People as Knowledge Keepers

Individuals are the ones with the most knowledge about a system. These are the people who are systems thinkers by nature or force who are tracking relationships in their heads, pull requests in their repos, and code within their teams. 

What if this was a shared responsibility?

The tech industry has gone through a few attempts to solve this knowledge problem. But we’ve done it with a relational database model in mind. We needed data to be contained. Siloed. Relationships in containers. Just look at the movements of the recent past:

• Agile - Where “self-forming” teams break down the development work into chunks to speed up delivery and create efficiencies. What we did? We shifted testing and QA to developers… while also breaking up efficient teams.
• DevOps - Get Devs and Ops to work better together. What we ended up doing was making Ops folks learn to be Devs.
• DevSecOps - Include Security early and often to reduce bad security practices in code. What we did? We pushed Ops, Security, and Release Engineers closer together.
• Service Ownership - “Code it, ship it, own it.” What we did? Created a cross-functional silo.

What were we even trying to solve?

I believe the problem those movements were trying to solve was and continues to be a lack of context. We were building frameworks but we needed to be building… context. Simple as that. 

Today, writing code is more complex. It’s no longer 100 lines of code to get a feature out the door. To solve this, companies keep moving people into new team configurations from Agile to Service Ownership. With the hope that the size and shape of the team will solve the context problem.

But in the wise words of my fellow co-founder and OpenContext’s CTO, Alice Chen: “The only reason we have things called DevOps and DevSecOps is that we can't see things from different points of view… What they fail to see and what there hasn’t been a tool that shows is that we all want the same group of information just sliced differently.”

In the next section, she shares some important background information about graph databases and how we’re using the technology to provide value through shared context vs. microservice mapping:

What is a graph database and how can it help us gain context?

A graph database is a way of collecting and organizing information that stores both the individual data points as entities as well as the relationships between them to provide a full picture of an entire system. 

Gartner predicts that “by 2025, graph technologies will be used in 80% of data and analytics innovations, up from 10% in 2021,” based on how helpful it is for rapid decision-making across teams and organizations.

Technically, how are relations stored in a graph database?

Well if you want to get more technical, FreeCodeCamp has a detailed explanation of the two types of graph databases, but, simply put for our purposes: Graph databases store information/inputs as nodes and the relationship between the information/inputs as edges.

Graph database vs. relational database: What’s the difference?

The difference between a relational database and a graph database is that in a relational database you need to know all the entities that will become tables in your relational database and how they relate to each other ahead of time. In a graph database, relationships don't have to be known—that's the whole point. The relationships between the nodes in a graph database are an entity in themselves. 

It's the difference between having to design a relational database which requires knowing the whole data set ahead of time versus knowing parts of the data set and learning even more about it from the graph database.

As TechTarget puts it “The most notable difference between the two is that graph databases store the relationships between data as data. Relational databases infer a focus on relationships between data but in a different way. The relational focus is between the columns of data tables, not data points.” 

If you’re just trying to map the knowledge of your company, by all means, use a relational database but if you’re trying to gain context that goes deeper than the surface-level knowledge you’re already aware of, a graph database is the way.

What is a graph database used for?

Graph databases are great for extracting relationships. That’s why most social media platforms and dating apps like Hinge use graph databases to map potential romantic matches based on having connections in common on other social media apps. They can show relationships between things that have no prior knowledge of each other. 

Fraud is another sector that uses graph databases because it’s looking for relationships. It’s often trying to detect suspicious behavior by matching things like a high number of IP logins, for example.

How does OpenContext use a graph database?

If it wasn’t clear from the name, what we’re trying to do at OpenContext is provide context. It’s impossible to achieve context by asking the questions you’re already thinking about. We want to help organizations see with their own eyes what they’ve been missing. 

With a graph database, OpenContext allows product teams across all functions—ops, devs, security, etc.—to input what information they do have access to and uncover all kinds of data about the relationships that exist buried under the surface. From there, the insights can be used to work smarter in every sense of the word.

An Example of Graph Database in Action

Let’s take Stacie. Stacie is a new application developer at Sneakers which broke off from PlayTronics. Stacie wants to understand her team’s code. She’s part of team Whistler but knows that they impact teams Mother, Crease, and Arbogast. Stacie wants to find out who are the subject matter experts, and where the documentation around her code lives. Today, this takes around six months.

In order to identify dependencies without OpenContext’s graph database, Stacie needs to do a lot of research and leg work, for example:

• Talk to folks. She does this to identify who is the owner of the different code paths.
• Identify the subject matter experts related to team Whistler and for the product in general.
• Search for documents probably in multiple locations from Confluence, Notion, Dropbox, Google Docs, and even Slack.
• Read a lot of code to better understand the features she’s responsible for.

With a graph database, we can take the teams to technical stack data and look at different slices. Stacie can see the Whistler code. View a cross-section of the code that impacts Mother, Crease, and Arbogast. Or look at the specific code path she is working on and how it connects to the rest of the technical stack.

Stacie can see a graphical view of the relationships associated with her code and who else depends on it by traversing as many steps through the technical stack as she needs. The Context Catalog becomes a way for the organization’s team to navigate the technical stack whether they have Service Ownership or not. The graph database does not care.

Everyday improvements are an added bonus:

Leveraging a graph database model, Stacie will be able to identify the security owner for her team. Sneakers is concerned about keeping secrets safe. Marty, the head of Security, is her go-to for security questions. As part of the documents for team Whistler, she can track the how and why for Sneakers features, specifically why team Whistler’s security features are key differentiators from PlayTronics CEO, vision.

Let’s take it a little further. 

Via the graphical view, Stacie has noticed that if this one load balancer goes down, three hops away, her team is going to be paged. This gives Stacie the information she needs to write some policies for alerting as well as, more detailed steps in the run book related to when to page team Whistler and why.

Using Graph Database Technology to Move from Monolith to Microservices

When it comes to systems thinking, Stacie can be mindful about tracking architecture changes. Specifically, moving from a monolith to microservices. We all know how challenging that can be. 

With the graph database, Stacie can look at the technical stack holistically. She can also identify which teams are connected and how, and reach out to partner on timing, impact, and level of effort. She understands when to bring in Marty or team leads from Mother, Crease, or Arbogast. 

Further, Stacie can make smarter and more efficient decisions by visually tracking the primary, secondary, and tertiary impact of the code paths during the migration creating a cleaner stairstep from monolith to microservices. 

You won’t know your gaps without a Context Graph.

What users want is a way to traverse the code path, infrastructure, and teams. To do this, you need the fluidity of a graph database to capture those fuzzy pieces around the edges. 

In fact, at OpenContext, we think being able to visualize context from a graph database view allows folks to:

• Identify the cost of breaking up an effective team. Specifically, what are the knowledge gaps associated with moving someone from one team to another?
• Allowing Ops to look at the big picture and see the impact of an infrastructure change or ways to get ahead of performance issues. This happens when they have insight into what’s being built and where it is in the tech stack.
• Empower Security to educate the Engineering organization on how coding practices impact the security of the product and customers.

Bottom Line: The graph database is what drives context. 

The graph database is without emotion. It’s going to show you the good, the bad, and what needs attention now. We believe it’s a Systems Thinkers, Developer, Ops, Security, Release Engineer, QA, and Manager’s, new best friend.