Introducing Knowledge Graphs into Organizations

A little soup is quickly cooked. But if many chefs are working together on a larger menu that will eventually be appreciated by a banquet of guests, good preparation is key. In this article we will focus on the preparation phase and outline what it means to introduce knowledge graphs in a company firsthand and from an organizational perspective:

• When do you know that you need a knowledge graph?
• Assessing the semantic maturity level of an organization
• Overcome segregation and specialization
• The importance of involving the right stakeholders
• Why develop a knowledge graph in an agile way?

The introduction of knowledge graphs into organizations is not necessarily comparable to the introduction of any new technology. It is not just a question of which graph database to use and which tools to use for managing the knowledge graphs. The best equipped kitchen will not cook the best food by itself. Of course, it is important to choose the best technology and equipment, but this is best done following one’s own experience.

The introduction of knowledge graphs is a data management initiative that requires appropriate change management as scaling increases. This means that it must start with the careful planning of goals and strategies. It requires a change in the way of thinking when dealing with data. It requires learning new standards, methodologies and technologies by your technical teams. It requires new skills for the people working on these projects. It is not enough to purchase black box AI or simply hire ten data scientists or data engineers to create a knowledge graph. If the knowledge graph is to become a strategic asset in your organization, then you need to treat it as such.

When do you know that you need a Knowledge Graph?

This question may sound strange, but you should ask yourself before you start. Because a successful implementation of an Enterprise Knowledge Graph is a course-setting for the future. That’s not to say that like in the classic waterfall model you have to plan the implementation meticulously before you start. On the contrary. But it should at least be clear whether a knowledge graph is the right way to solve existing problems.

If one or more of the following aspects sound familiar, you are on the right track:

• You often face the problem of having to translate or rephrase your questions 
  • across languages, because you work in an international environment,
  • across domains, as your departments have different views on things,
  • across organizations, as your partners have their own language, and
  • because the language has changed and things today are named differently than two years ago. 
• You often want to get information out of your systems but you do not succeed because
  • there are so many systems but they do not talk to each other,
  • they all have different data models and you need help to translate between them,
  • you need experts to help wrangle the answers out of your systems, and
  • your experts tell you this is not possible because of the relational data model in place.
• You often can’t identify the right person or expert in your company, so you have to start from scratch.
• After you have completed a project or work, you have often found that something similar already existed. You have often had the feeling that you have reinvented the wheel.
• You always use Google instead of internal tools to find things.

Now might be the right time to think about how to change and develop the organizational culture in terms of access to information and work with information or the development of knowledge. But when people should “go where no one has ever been before”, they also need to be prepared and open-minded. At the end of the day, knowledge graphs don’t just link data, they also link people.

Assessing the Semantic Maturity Level of an Organization

The next step is to take a look at your organization and see how well it is prepared for this change. When assessing the maturity level of your organization, you should again consider two aspects:

Organizational Aspects

Knowledge graphs are traditionally based on the Open-World assumption, which implies that knowledge graphs are never complete. This seems to be a strong contrast to the reality of many organizations and the way they do projects. So if you might find yourself characterizing your organization as “a highly specialized, relatively old industry” that “deals with complex, costly, and potentially hazardous facilities and processes,” you may find it difficult to introduce knowledge graphs and convince people why they should spend time on such an adventure.

If, on the other hand, you characterize your organization in such a way that “we are open to new things and like to learn and explore” and “we deal with complex information and processes are important, but we have also learned to change and adapt when necessary,” then it will most likely not be difficult for you to spark the interest of your teams.

Specialization normally also means segregation into knowledge silos and interfaces to translate between them. A knowledge graph approach means to establish a unified translation layer on top of those silos, so they speak to each other in a common language that is easy to understand and explore. But what happens if people are not used to, or trained, or open to explore and “talk to each other in a common language”? They will not understand or use those systems. Therefore, of course the necessary skills must be built up and simple applications that improve everyone’s working life must be made available as quickly as possible to convince people. In addition, a change in mindset and culture is also required to ensure that employees become accustomed to the following principles:

• Systems are easily extendable.
• Systems can be linked and connected.
• Systems allow us to think/explore beyond silos.

In addition to defining the technologies for linking systems and merging data, the corresponding processes must also be established. After all, you want your people to soon be able to cook from memory without a cookbook.

Technical Aspects

Building an enterprise knowledge graph is an agile thing. It’s alive you have to grow and mature it, and you have to feed it well so it becomes strong and healthy. So it is not a typical project you plan, implement, and then you are done. Rather, we strongly encourage you to develop it in an agile way:

• Starting small and growing continuously based on examples and use cases.
• Trying to show benefit as early as possible.
• Learning from successes and failures and establishing the necessary know-how and skills along the way.  

An enterprise knowledge graph cannot be implemented without support throughout the whole organization. Also SysOps, security and infrastructure have to embrace the change. This is a potential problem because exactly those departments are frequently enemies of change as they have to guarantee stability and continuity of operations. In addition to changes within the organization, new roles/personas with new skills and knowledge should be introduced as well in order to support this transition. In the next chapter we will outline different personas you will typically need to set the stage.

The enterprise semantics maturity model below clearly outlines that the need for a linked data and knowledge graph strategy becomes more evident as your knowledge graph infrastructure matures.

So the success of a knowledge graph initiative strongly depends on establishing the right methodologies and getting important stakeholders on board, i.e.,

• start simple and grow,
• develop your knowledge graph in an agile way,
• build up the necessary skills and roles, and
• understand that it is not a replacement, but an extension. 

Embedding Knowledge Graph Building in a Change Management Processes

As explained in the previous section, the introduction of a knowledge graph is not (only) a technical implementation of a new technology. It must include both strategic and organizational aspects to be successful. It is also a change management initiative because it changes the way your organization works with and values data. In a sense, you could say that data has always been hidden in a complex infrastructure and technology. It wasn’t about data, it was about the technology to store data securely so that in the end, no one knows it exists. 

We remember very well a DMS conference years ago, where a provider used a safe as a symbol for his security level. We understand that security is important for all companies, but there is also another interpretation: “keep your data safe and forget about it, that way everything will be so complicated that nobody would dare to ask if they can do this or that with the data.” Well, the answer is in the middle, and we should think about how we want to handle our data. So make your data a first-class citizen that you can explore through an enterprise knowledge graph, and let technology be the means, not the driver.

As with any change management initiative, you will need to deal with the different phases of the emotional response to change. Realizing that you are in a situation where you have locked your data away for years and when you want to use it, you can no longer access it in a meaningful way, will lead to shock and denial. Here’s what you’re going to hear a lot:

• “But this is how we’ve always done it!”
• “But we can do all of this already!”
• “We can do all of that with [XML|Lucene|SharePoint|…] anyway, so what is new?”
• “Isn’t that what our Big Data initiative is for?”

So you will have to find creative ways to show the value and benefit and convince people to bring them on board.

There will also be frustration and depression when people realize that they have to move and change. Their comfort zone is at stake and change will come. The most important and helpful argument we found in those situations is: “Look, you do not have to throw away anything. You just put the knowledge graph on top of your existing data infrastructure to make it connected and accessible.” That already relaxes most involved stakeholders a bit. If they are involved from the beginning, well informed and also motivated because they soon experience the value of the initiative, they can eventually be convinced to join forces.

Now you are in a critical phase, as you may want to try to make the big change and plan it for the next 20 years. Don’t do that! Experiment in order to make valid decisions based on experience. Learn that experiments are not bad things or even a sign of immaturity, but rather the only chances to learn, to become better, to improve continuously and to develop skills. If all this smells of agility, then it is. “Agile” is everywhere these days. We know that, but we also need agile access to data to make better use of it, so we need agile data management. A knowledge graph project must always be an agile data management project. Knowledge is a living thing that is constantly changing.

So if you’ve done this part right and haven’t forgotten to keep on experimenting, you can start to integrate your findings into your existing productive data landscape and enjoy the change that comes with it. When people realize that they are no longer slaves to data locked up in systems, but masters of a unified data landscape that can create a lot of knowledge in the right hands, they will become more productive and they will begin to think in new directions and discover things that were not possible before.

Read more: The Knowledge Graph Cookbook – Recipes that Work