Let’s get one thing straight—organizations have been developing knowledge without complex technology, or any software at all, for long before any of us were around. We’re talking about the struggle in adapting to new approaches, both on technical and cultural levels, to create easier, more efficient, and more standardized ways to go on this journey of developing and using knowledge.

If you’ve already put in the hard work to design and deploy a knowledge graph and an engine, designed to solve specific analytical problems for your organization, you’re probably nearing the level of knowledge-generating maturity where you’re thinking about how to iterate on and optimize the processes you’ve already built.

But we want to sunset the idea that optimizing a knowledge graph and engine is all about writing more code. That’s exactly how you build an unmaintainable black box no one truly understands, with the engine is:

• Not scalable to new data streams, as it requires too much manual input and intervention from analysts and knowledge workers.
• Unmaintainable due to the complex and highly specialized codebase.
• Valuable only in the near term, as it can’t keep up with changes in your industry or adapt to new insights or understandings your people make along this journey.

Instead, your goal is to improve the way your organization develops essential knowledge itself, which includes how your people understand the problem-solution space for your industry or vertical. When you solve the technical and cultural hurdles involved in this iterate/optimize stage, you start to codify knowledge—not hard-coded logic—which pays longer-term dividends.

Instead of pondering indecipherable algorithms and boolean logic, your people start to not only make better decisions based on your data but further improve the knowledge graph itself.

It’s an important mind shift because, despite all our recent conversations about the business value of engines, they can’t solve problems in isolation. If you want better insights from your engine, you need to feed it better knowledge.

The technical hurdles to optimizing how you develop knowledge

Too many organizations fall back on developing software because it uses tools and programming techniques they’re far more familiar with deploying and leveraging than graph databases and AI. It seems easier to optimize the engine over surmounting the technical hurdles of consistently creating knowledge with better tooling. Why? Building the required connected data architecture, complete with services that abstract complexity, enable automation, and improve access to a knowledge graph’s data, is no easy task. At a bare minimum, you need the following:

• A graph-based data store;
• A knowledge graph manager, which helps you define, manage, and maintain your knowledge graph model over time through features like dynamic APIs;
• A change data capture (CDC) service to track every time your data is modified or updated and push those changes to relevant knowledge workers;
• Graph-based search that lets people search using natural language, with developer-friendly features like continuous indexing, customizable policy, custom fuzziness, sorting, and composable queries;
• And, optionally, an NLP service that automatically turns new unstructured text data into data to provide real-time insight and continuously update the data model.

Without a clear vision of how to design, deploy, and maintain these services, organizations err on the side of writing code even when they’re aware of the risks.

For example, GraphGrid has been working with a newer client to dramatically improve the substance of their engine and the quality of its output, which we mentioned in our previous post on engines. Their MVP engine, which attempted to recommend multi-decade carbon plans for building owners with large portfolios, was written entirely in code. That means hard-coded logic for building ages, equipment inventories, the physics and math involved in applying new technologies, and more. It was just an MVP, but it was already unscalable and unmaintainable.

Definitely not a long-term solution.

Instead, you need to focus your efforts on optimizing how quickly and easily your team of knowledge workers and analysts can improve the quality of the relationships and context within your knowledge graph. The most direct and fruitful way to achieve this is automatically ingesting new data and refreshing your knowledge graph with new trends without requiring manual intervention.

For example, if you can utilize natural language processing (NLP) to automatically analyze massive volumes of data, then you’ve not only freed your people from time-consuming research or ineffective (and oftentimes inaccurate!) research and discovery process, while also giving them access to a corpus that no single person, or even a team, could analyze manually.

The good news is that you can clear all the technical hurdles in a single flexible and extensible suite with GraphGrid—but more on that in a minute. Let’s talk about culture.

Building a culture of knowledge, not code

The tendency to write more rigid code to better generate knowledge has deep cultural roots as well.

Even after agreeing on the business problem to be solved, many organizations then diverge on how to structure their graphs. They end up with multiple graphs and a handful of conflicting models because they couldn’t align their graph-based thinking to decide how the same types of nodes are related to one another based on who the engine is supposed to help.

In time, as your knowledge workers get comfortable thinking in graphs and you consolidate your models, you’ll undoubtedly start to make novel discoveries. Dream up new initiatives with confident backing from your data. Handle complex projects in a fraction of the time.

It’s tempting to start operating out of the idea that your competitive advantage is the technological foundation you’ve created—your engine—and not the ongoing imaginative effort of your talented people.

Time to shift to an approach where you prioritize your knowledge graph. Technology isn’t the advantage, but rather one of the tools your organization uses for simplifying the feedback loop between knowledge graph -> engine -> analyst/knowledge worker -> knowledge graph. That’s an essential distinction because developing genuinely useful knowledge requires a dose of imagination—knowledge graphs are great for simplifying layered, highly conceptual problems, but their solutions require a great deal of experimentation and tinkering.

The kind of work only people can do.

In our experience, this cultural shift often takes more lift. Making sweeping technology changes might not be easy, but most organizations can see the path through and beyond. Steering an entire operating culture, on the other hand, is the daunting kind of work you often bring consultants in to help with.

The difficult truth is that your people might not be seeing how they should start developing processes around improving your knowledge graph over applying more technology. They might not feel comfortable with building the knowledge itself because they’re too “stuck” in the problem and the existing slate of solutions to think of novel alternatives. Bringing in some outside minds can help unearth new relationships within your existing data or investigate additional data corpuses that the existing engine could make new sense of.

It’s about taking what you now know and feeding that back into your engine to produce even better results again and again—not wasting time on hard-coding more incomprehensible logic into the engine itself.

Make the knowledge transformation with GraphGrid

If you’re working on complex analytical problems and look forward to being able to address them with a constant improvement of knowledge—not additional layers of software in rigid code—then there’s no better starting point than GraphGrid. GraphGrid comes with all the “plumbing” required, a composable suite graph and artificial intelligence, to stand up an automation-driven system to process new data and feed it through your business-driven engine.

You can download GraphGrid for free to quickly lay that technical foundation, which frees you up to start tackling the cultural shifts required to truly develop knowledge, not just more rigid and unmaintainable software.

And if you have doubts about that, get in touch—we’ve helped organizations as complex as the U.S. Department of the Treasury, the National Institutes of Health, and the U.S. Air Force turn their technology and their cultural practices toward developing knowledge graphs that have become crucial to their long-term success.