Enterprise Knowledge is a dedicated knowledge management consultancy that was co-founded by COO Joe Hilger and CEO Zach Wahl in 2013. The company has grown to 50 employees, and been recognized in the Inc. 5000 list for the last 2 years.
Hilger recently spoke with DBTA about the importance of knowledge graphs as part of a larger enterprise information strategy and why the technology is now in the spotlight as a critical piece in the information management puzzle.
Tell us about your company Enterprise Knowledge.
Hilger: What we do is help—typically large—organizations, either private or public organizations, both in the U.S. and around the world, make better use of their knowledge and information. We started with knowledge management strategy work, helping organizations to make better use of and protect their knowledge assets. That grew into building out a technology wing that did enterprise search and content management and other KM-related technology implementations. And then in the past few years, we started to see the power of knowledge graphs and got excited about it and started a practice that's focused on AI and knowledge graphs.
Is there a clear trend that you're seeing as far as the use of knowledge graphs?
Joe Hilger: There are about three or four different situations that we're finding. The most common one is when companies have rolled out a data lake to support their BI infrastructure. Now they have all the data in one place, but they still don't know what it is, or where it is, or how it relates to each other. These organizations have typically done some research and started to understand that knowledge graphs can help identify those relationships—and, in fact, take what has historically been transactional data and information and map it to something that better aligns with the business information needs.
And the second use case?
JH: Scenario two is when organizations build enterprise search and need to be able to tell people about the information they need because it is not enough to just create a better search experience. Sometimes customers and employees need to be pushed information at the right time. And so in that case, using the same technology stack, we've built what we call recommendation engines.
And the third?
JH: The third scenario is when organizations come to us because they have data and information everywhere and can't manage it. The approach was: Get a document management system and migrate everything there over the next 3 years and eventually you'll have something you can manage. The new approach is putting a knowledge graph on top that points to all the data in all the different locations and provides a single place to find that content, data, and information—even though it's managed in five, six, or even 15 different systems. Those are three of the big stories that we're hearing.
And then, actually, a fourth situation is when someone comes to us and says, "I was told I have to build a knowledge graph, or I have to do AI. Could you help me? I don't even know what it is." That story comes up more often than you'd expect.
'If I'm building bridges in Colombia and ... I'm also going to build a bridge in Venezuela, the computer doesn't see a direct relationship between Venezuela and Colombia. They are two different countries. In a knowledge graph, they're both given attributes that say that these countries are the same distance from the equator.'
What do knowledge graphs provide that was missing all along?
JH: Companies are coming to knowledge graphs because they've looked around and seen that Google is betting its entire infrastructure on knowledge graphs. Microsoft with LinkedIn is doing knowledge graphs. Microsoft's entire new infrastructure of O365 is knowledge graphs. Everywhere people go, they're hearing knowledge graphs solve problems. They don't yet know why, but they just know the big vendors are using it. That is actually one of the common drivers.
But the other side of the equation is that knowledge graphs do three things very well, particularly in the data space, that you didn't have before.
Number one is mixing structured datasets with written information. Remember, knowledge graphs are very good at identifying relationships between things and because they do that well, you can say, "Here's this dataset that I have that I build off of and here's an article that adds context to it." If you think about organizations that are trying to make a lot of use of their data, it's not just about data; it's about data and content.
A second driver has to do with being able to map information. I don't like to think of it as a dataset or a data store. It's a map that sits on top of your datasets. If you think about how most of your data is captured, it's captured in a format that aligns with quick and easy entry for your transactional systems. It's not captured in a format for reporting purposes. There's a lot of time and money spent doing ETL, but ETL only works so well. You want to map out how the information should look so that the model of what it is better reflects the way the business thinks about it.
And then, lastly, and we've gotten to do some fun work around this path: People want to start asking questions and getting answers. It's not enough to say to your IT person, "Hey, could you write me this SQL query and get me this report?" That's OK, but it's not good enough. We've had some organizations tell us they want their executives to be able to get information back. Because knowledge graphs store information in the form of subject, predicate, object, they're storing three values, which is basically how things are related to each other. And because they store it that way, when it's time to have people ask questions and get answers, knowledge graphs do a great job of allowing for a much more AI-centric, conversational way of asking for information, which decentralizes the ability for people to get data and information because you don't need that IT person to help you.