Why EKG POCs Fail

And five ways to demonstrate value and get to yes

A lot of enterprise knowledge graph (EKG) proof of concept projects fail. For our purposes “fail” means that the POC does not result in a sale of software and/or a long-term services contract. Many POCs succeed technically, but still fail to convince buyers to open their checkbooks. We may apply the Anna Karenina principle here: failure is based on any number of specific problems that doom the whole project. Some common points of failure I’ve seen: 

– Installation and interconnection take so long that the POC never gets to the stage of showing value (and thus convinces the prospective buyer that the technology is either immature or too costly). 

– The prospective customer cannot adequately support the project with even basic IT services for data access, security review, and the other necessities of enterprise environments. Often this means that the business unit trying out an EKG needs access to data owned by another unit. Hilarity ensues and time is wasted. 

– You’ve avoided the data access problems by working with mock data, but the results do not translate into a valid “solution” for business buyers, who are equipped to evaluate results not methodology. 

– For expedience, the POC is working with a subset of data or mock data and, while the potential value is clear, it’s also evident that major investments in data quality will be needed to realize any value at scale. 

– The potential value of an EKG is indistinguishable from other technical approaches.  An EKG’s value proposition increases with the variety and complexity of the data that needs to be integrated or analyzed–efforts that are hard for humans to accomplish at scale.  So, setting the bar too low for a POC may be faster, but counterproductive. 

– The potential customer doesn’t have the expertise to manage an EKG on their own, and they don’t want to invest the time and resources to onboard yet-another-technology stack. Related: the bigger integration vendors don’t have the expertise to support EKGs either and smaller EKG specialty vendors may have the skills but not the depth to fill in the gaps or support over the long term. 

– The terms “graph,” “knowledge graph,” “semantic layer,” and “data fabric/mesh,” have no set meaning in the marketplace, leading to a confusing array of competing and overlapping claims for very different technologies. This makes it more likely that the prospective customer has chosen the wrong tool and, when it fails, they associate the negative impression with all graph-related products. 

I could go on.   

The Successful POC 

OK, so what’s the upside? Successful POCs, in my experience, share the following five qualities and avoid common pitfalls.

1. The POC is not a “tech evaluation.” Beware of a proposal in which an IT or R&D team is looking for solutions the business hasn’t asked for. Doing “the same thing but slightly better” is not a winning strategy. This is true even if the IT or data team can say (rightly) that “if we adopt this tech, we can apply it to so many areas.”  Sometimes that pitch works, but not often enough. Vendors and buyers are guilty here. Vendors often go into an engagement selling a fancy toolbox when the buyer just wants the lights to work. And buyers are often just kicking the tires on new tech with no interest in purchasing. This is a common trap in which even technically successful POCs don’t result in a sale.

2. The POC is not a test of interoperability. Installing a new piece of software in a complex enterprise is no joke. But it’s also a solvable problem. If the perceived benefits clearly outweigh the costs, then all those issues will get resolved. But they won’t get resolved in a POC whose goal is “to see if this product/technology works in our environment.”  Here’s a tip: It’s not going to in a POC. Enterprise environments are a notorious mix of old, really old, and avantgarde tech. So, find ways to scope the project so that value can be demonstrated regardless of integration issues. Conversely, vendors should make it easy for prospective customers to evaluate interoperability and security concerns before a POC starts.

3. The POC has a defined deliverable output that is understood by business users. That is, the value must be demonstrable to the people who consume and make decisions based the data. The deliverable can be a report or a dashboard or some other usable output, but it must be understood by the non-technical teams or it’s not going to get funded. The more urgent the need for said output, the better. Even LLMs—where the potential ROI looks clear—suffer from poorly defined business goals. Or, dirty little secret, the goal is to get rid of an entire department of people and replace them with more automation. Almost no one says this plainly up front, even internally.  But it becomes clear when enterprise teams that should be cooperating aren’t playing along because their interests are not aligned with the project.   

4. The POC has just enough scale. It is true that modern EKGs and other graph-based technologies can handle 10s or 100s of billions of statements, provided enough processing power, storage, and memory.  But many successful EKG installations aren’t really “enterprise” in the sense of, say, company-wide email. EKGs are often employed as a business-unit-level solution, which still can be quite large, but not really “enterprise.” EKGs really aren’t always able to handle multiple transactions from multiple teams without a service layer to control access and manage resources. The size of the data is less important than the frequency and complexity of the read/write operations. Understanding the scale and scope of the immediate need and the requirements for adding more capacity later is very important to business buyers.  After all, they are going to spend a lot of time and effort on a totally new tech stack that better be worth it for the bottom line. It’s fine to know that the buyer will eventually need a new vendor to scale up later. It is not fine for them to realize they’ll need an entirely new technology to support growth. If IT and the business can see that cliff coming, they’re not buying. 

5. Finally, approach matters.  EKGs use ontologies to organize information.  But ontologies are not needed to recreate your database as a graph. That seems counter intuitive, but ontologies create a digital model of a complex world—an existing process, industry, system, ecosystem.  The logical connections between “things” in that real world is exactly what your relational database doesn’t understand.  If we’re spending a lot of time creating objects out of table columns, we’re probably not getting to the actual value of graph technology that differentiates it from all the other tools in the enterprise. So, a focused ontology that provides context to which existing data can be mapped is the approach most likely to demonstrate value.