Why Young Developers Don’t Get Knowledge Graphs
Business is booming these days for graph databases–maybe it took COVID to show us how connected everything is–and that’s good news for Franz, which develops a semantic graph database called AllegroGraph. Just the same, you won’t find CEO Jans Aasman spending much time convincing developers of a certain age to use it.
“If you live in our world of semantic graph databases, I only talked to people over 35, 40,” Aasman tells Datanami. “I never talk to young developers.”
The problem with younger developers, he explains, is that they’re usually interested in using the graph database to build point solutions to solve specific problems, as opposed to creating a wide base of knowledge that can not only solve a specific problem, but be used with future solutions too. Plus, building point solutions exacerbates the data silo problem, he says.
“In our community of the semantic graph databases, literally everything is about integration and making sure that everything can interoperate,” the Franz CEO continues. “And there’s not a single young programmer that cares about that. Seriously. You’re young, you want to do a fun project, your managers are saying, in three months I need this thing done. You do whatever you want to do. Well, they get it done. And then you have new a data silo.”
There’s nothing wrong with using a “cool graph database” to solve a problem, he says. When dealing with connected entities, graph databases–including the two big categories of graph, entity and property graphs–are powerful and elegant tools to traverse those connections and to extract value from them (although Aasman also had some pointed words for property graphs, too).
“There’s nothing wrong with that,” Aasman says about using a graph database for a one-off project. “It’s just from a bigger perspective, do you want to keep getting get more and more of these point solutions, or do you want to have one taxonomy for your entire company? Do I care about that I have a uniform description of every business object in my company? What is a customer? What is a credit card? What is a charge on the credit card? What is a business line?”
Once those descriptions are defined according to W3C’s Resource Description Framework (RDF) standards, the semantic graph database can do wonderful things via SPARQL, the query language used by AllegroGraph and other RDF stores. Aasman mentioned a recent project to collected data from 20,000 clinical trials, along with patient data, to ascertain possible treatments for COVID long-haulers. It’s also working with Montefiore Medical Center, which uses AllegroGraph as the underlying data lake for its Patient-centered Analytical Learning Machine (PALM) solution (click here to read Franz’s solution brief on PALM).
“Once you’ve [defined your terms] and you adhere to that, you can make different applications,” Aasman says. “As long as you use the same word for the same thing, it’s very easy to bring them together.”
The world is catching on to the utility of graph databases, as evidenced by industry leader Neo4j’s $325 million round of funding last month that valued the firm at $2 billion, as well as TigerGraph’s $105 million round earlier this year.
The continued investment in cloud graph offerings (AWS’s Neptune, launched in 2017, and graph features in Microsoft Azure’s CosmosDB, which debuted in late 2017) also points to the growth of graph, as do the addition of graph capabilities to multi-model NoSQL databases (Redis, ArrangoDB) and the rise of sundry smaller commercial products and open source projects, like Cambridge Semantics, Stardog, Dgraph, and Ontotext.
The graph database market will be worth $5 billion in five years, according to a report issued today by Markets and Markets. The group said sales of RDF databases are expected to grow quicker than LPG (or labeled property graph) databases “due to its capability of focusing on the information that is organized in a subject-predicate-object relationship. The healthcare and pharmaceutical companies and government statistics agencies are increasingly adopting the RDF graph databases.”
Graph databases are no longer a well-kept secret, and are in the process of becoming mainstream, if they aren’t already.
“When we started 14 years ago, I was just one step ahead of my customers, and I had to explain graph,” Aasman says. “I never have to explain graph anymore. Never, ever. That’s done.”
AllegroGraph is seeing action across industries, including healthcare, aviation, and banking. The capability to function as an event store in addition to a semantic graph database (Franz calls it an “event knowledge graph”) gives customers the capability to understand not only what the current state of something is, but how it came to be that way.
There is high demand currently for so-called “360-degree” customer views, and AllegroGraph fits the bill.
“Whether you’re in a big bank and someone wants to take a loan, normally the bank person would have to look in 10 database to see if they’ll trust you to give you a loan, or whether you’re in a call center and you’re calling for the 50th time the same customer for another client, you really want to see, in one go, what do I know about this customer? What did I learn in the previous years? What is the willingness to buy? What is the tech stack that they have?
“All the things, and instead of going through all these different databases, CRM systems, it would be awesome if you just had that presented to you in a very easy way,” he continues. “The same thing for patients. What do I know about this patient? Instead of getting 1,200 pages of text, you get a really good summary of everything there.”
It turns out, there aren’t many system architects in the under-30 crowd who are being asked to build such systems. In Aasman’s view, that’s not a knock on the underaged, just a reflection of the reality that only a certain amount of scar tissue and experience can truly prepare a developer to tackle the immense difficulty that IT complexity poses to organization.