Recently, knowledge graph project leaders from Merck KGaA, Bosch, and Deloitte sat down with knowledge graph expert Mike Atkins for a lively discussion of their vision for knowledge graph technology and how they are translating that vision into reality within their own Digital Twin, Regulatory Data Fabric, and Operational Resilience initiatives. With a focus on sharing pragmatic topics and real-world lessons learned, the discussion focused on the strategic vision and transformational potential of semantic graph technology. The panelists share tips for getting started, selecting a first use case, and best practices knowledge graph implementation.
Panelists
Mike Atkin, Managing Director, Content Strategies (moderator)
Joerg Werner, Director R&D Data Vault Office, Merck KGaA
Vinod Surendran, Senior Manager, Deloitte
Dr. Felix Lösch, Head of Cluster Internet of Production, Robert Bosch GmbH
A transcript of that discussion is provided here:
Felix, why did your firm decide to start using knowledge graph technology?
(Felix) A couple of years ago, we asked whether semantics can help the way we are dealing with data at Bosch. We had a large number of data sources and different departments working on data, starting to build applications and apply AI to make use of the data, but one piece was somehow missing: how to get an integrated view of the data, and to become much faster in the data preparation tasks. We spent roughly 80% of our time on data preparation and integration, and only 20% on the analysis. We asked ourselves will this scale and meet our future needs? That's really what started our journey into Knowledge Graphs. This was originally for our research activity but now it has become an initiative where more people are learning about and seeing the potential of knowledge graphs. At this point we are over that initial education and pilot phase and are moving into more mainstream use of the knowledge graph technology at Bosch.
Joerg, is it kind of a similar story that we're talking about an integration, dealing with the inter-connectivity across processes challenge?
(Joerg) We are highly regulated, so our journey started mainly in response to requirements around regulatory reporting. We were driven really by external authorities and pressure to be more compliant going forward. It was clear that our database centric approach couldn't help us anymore because we needed to work with a large number of external control vocabularies and other external resources. We are using knowledge graphs to manage all of that and to put data, rather than databases, in the center. We started this journey roughly three years ago and are also well past the pilot phase and are now working to convince others to join us.
Vinod, how does this compare to what’s going on in the financial industry?
(Vinod) In general financial services organizations have built up large collections of artifacts, driven by regulations, such as lineage information, as well as technical, business and system metadata. IT and data leaders have started to see knowledge graphs as a way to make this data come alive by connecting this kind of the metadata information with operational data. Using this connected data, you can do new types of problem analysis and resolution. For example, when you see an issue in a system, you can do real-time impact analysis, like how will those issues impact, say, my regular report generation or my profitability management. That kind of analysis can be possible only through knowledge graph where existing artifacts can be joined across multiple metadata sources. This has been the latest trend we've been noticing in the financial industry.
Let me follow up and mention BCBS 239, which basically said you have got to go fix your infrastructure. Financial services institutions all have big problems with fragmentation that has kind of naturally evolved but they have to fix it to be able to do aggregation and scenario-based analysis. Are you suggesting that that message has resonated in some of the clients that you're talking to and they are starting to understand this idea of infrastructure?
(Vinod) Absolutely. It's not an easy puzzle to solve, especially since most of the landscapes in banks and the financial institution are massive, and they go through multiple ops, just to generate a report. So when the regulators ask what an institution is doing with a given instrument level they quickly realize they can't really solve this with a database kind of a solution. They need a more powerful tool, and knowledge graphs are one of the top choices for that.
Felix, what are the central capabilities that you see from graph that make it appealing in the context of the conventional infrastructure that had already exists within Bosch?
(Felix) So I see this integrated view as a very powerful thing. It's this abstraction from the underlying data sources, enabling a decoupling of the data sources themselves. If you have standardized, or are using semantic models, like ontologies, with multiple data sources, then you can build applications on top which can be reused across different use cases and business units. As an example, we are currently working on a standardized manufacturing data model for Bosch, which is used throughout the entire company at different business units. Currently the business units have all different data sources and different data models, but the power of the graph technology is to really map the underlying data sources towards that standardized model and then have standardized applications on top. That's one huge benefit of the technology. Another is that it really helps to ease the communication of the different people dealing with the data, so managers can look at the data, or domain experts can look at the data, and they understand what they are talking about, without having to know all the details of the underlying data sources. This greatly helps to reduce the complexity involved with data management tasks.
So for all of you, where are knowledge graph capabilities most aptly applied and, the reverse, where is it not appropriate to be using Knowledge Graph as opposed to a conventional relational infrastructure?
(Joerg) Yeah, I'll take you up on that. We always hear this discussion in our company about the silos and this argument to get rid of silos. But we have a lot of well-established systems and they are there in order for us to address compliance and other regulations. These systems do an excellent job, and I would never suggest we get rid of this kind of regulatory information management systems. Likewise, with the types of signal detection systems, that we use for example for our security and safety systems. No, they are there for a good reason and they should not be replaced with a knowledge graph. Where a knowledge graph comes into the game is as Felix said - as an abstraction layer. So for instance where might we have pharamacovigilance data showing signals that we want to combine with regulatory data. The horizon for that type of cross-silo integration is really big; there is so much you can do there, connecting data points, leveraging company knowledge, and bringing more value by connecting data in this abstraction layer. In the end it's not really the knowledge graph alone, but what can you put on top of it and then the ability to make that available to the machines and people who are willing to understand and then use this abstraction layer.
It’s really a huge benefit: instead of ripping and replacing our infrastructure, you're basically just mapping it up together so that it works with the existing applications that are already in place.
Vinod, can you summarize where we are from a technology perspective? What's required to get buy-in from the CTO and the CIO's office, that are responsible for the infrastructure of the organization?
(Vinod) Leaders want to see a direct business impact, and in the case of financial institutions regulation is one of the key areas where they can really leverage Knowledge Graph. They are being mandated to improve regulatory compliance and knowledge graph is part of that. The second comment I would make is that to make a knowledge graph happen in a financial service organization, you need a catalyst - a CTO or a CIO or even a CEO - who will say "Hey, this Knowledge Graph is a solution that we need to implement." That leader then helps bring in a team, do a quick POC, and push it through. I think, that's one of the critical steps that we have seen – having that strong leader.
(Felix) I would add that I think a knowledge graph project needs this critical mass to be successful. It's not a technology that explains itself to the people, so you have to really show people the value of it, with simple examples that they are able to understand. And it's good to start small and then scale up and say, "This is the first use case that we have." What we did is have people like, catalyst people in the business units that themselves are convinced of the technology to spread the word and drive education. But we also involved our central data strategy team, and they are also now going in the direction of using semantic data models. So I think it's different pieces and as well as several convincing sessions to the CTO in our case, to make that broader initiative happen in the company.
Joerg, in your mind, what does it take to move it from experiment to operational infrastructure?
(Joerg) First of all, start small with specific use cases. In our case we were driven by regulators which helped us get started with a clear use case. The challenge is if you're dealing with knowledge workers with a specific type of scientific knowledge, they don't care too much if they have to work with a database or a Knowledge Graph. Often people lack the data literacy to understand the differences. You have to start with what is the value for that person from data perspective? Then, "Okay, if they understand what is the value of the data perspective, why is the graph better than anything else?" But you have to be positioned in the shoes of another person. They want to do their job, and they don't care too much if it's a graph or a database. So that's where you have to hook in and say, "How? Where's the benefit for you and how you can trust us to achieve your goals with this new approach." We still have work to do articulating this message: “How can we bring more value to the table, help people understand what they will get with this technology, and allow them to see how they will get to their goals faster?" So that's how we try to bring them in.
How have Knowledge Graph capabilities evolved and why should the CTO have confidence now in where we are as an industry, where Cambridge is, as a data vendor?
(Felix) We are at the second wave of the semantic technology. The first wave began with the semantic web in 2020. The tools have matured since then. Today you can process large knowledge graphs on reasonable h/w. One key is that vendors have implemented a lot of clever technology there to make that happen. Also, they have added a lot of what is needed – modeling tools, a good user interface, and combining graph with analytics. All that helps to make that building a knowledge graph much more practical today. In the past, you had a graph database and some semantic modeling tool, and you had to cobble that together. But now that is offered in a platform fashion by the vendors. You have a lot of capabilities – like connections to the data sources, modeling, mapping and blending tools, and last but not least the analytics on top of the data.
It is a huge step forward.
(Joerg) Yeah, I would agree completely with Felix. Over the past two years we have done a lot of work loading a lot of data and building the models – so that is all very good and very stable. But it is still heavy work to model all the data. It is a fairytale to think that tools and maybe AI will make that easy. It it still hard work to partner with the business and build the model.“ That said my wish list for Cambridge Semantics for Anzo is maybe if they can find ways to make it faster to understand the data and build the model and map it.
Felix, you mentioned a Club of the Willing, inside your organization, to get people to recognize the problem and to embrace the art of the impossible. Could you explain what that was in your organization and where you think it's headed to?
(Felix) We started with a small research activity and one use case, and then we brought that to a larger audience. We developed this idea: let's start this Club of the Willing, to attract more people to it. We had several meetings where we showed the technology and our first use case, and then people started to think, "Ah, can I use that in my business unit? In my area?" Through our different functional areas, mainly with the business digital officers, it has been quite fascinating to see that people are, across business unit, across department, willing to actually contribute to that discussion and work, so now everybody is profiting from it. One group might pursue a use case that then other business units can make use of. When another group brings in a different use cas, it allows for an exchange of ideas. This helps to drive the adoption of the technology forward. People get all the information they need about this new technology and then we add trainings on top to train them because it's obviously a completely new technology. People are used to relational databases, but they don't know necessarily what a graph is, what an ontology is, what RDF is, and how you actually have to use that technology to build up your use case. So that's what we added. And now it works quite well.
What did you do right, and what would you do differently, if you had just to start over?
(Joerg) In terms of things that went well, we started small, and are slowly expanding. And in terms of what would be differently: We would bring more training and more data literacy in the beginning to the people so that they could really see what is in for them to use data in a knowledge graph rather than a traditional database
(Vinod) I agree with Joerg: Start small with a specific use case and expand that further. What we would do differently: initially, we were all about selling the new technology, to the business, and we soon realized, nobody cares. We learned to stop selling the technology and start selling the output and the value you are going to generate.
(Felix) I think what we did right, was we started small and scaled it up. I think we did a very good job, with our “Club of the Willing” so, more and more people are now interested, are working with the technology. What would we do different? Involve our central IT a little bit earlier, to have the platform ready, because it took quite some time to convince them to actually offer this as a service now, inside Bosch, and people, ask immediately if you have this as a prototype installation, and show it to them, they ask, "Yeah, is this a service I can rely on? I can build my use case on?" So we would start earlier with that one. Yeah.
Felix, you mentioned the training objective within Bosch and that there are people lining up to be trained on how to use and how to take advantage of that, could you elaborate on what's going on?
(Felix) Yeah, sure. So, we sat down because people started to ask always the same questions. So, we really anticipated kind of a training journey starting with small training, then one-day training, then two-day training, hence on training, explaining, it's kind of a mix between what is a Knowledge Graph, why should you use that technology, why is it better in some sense than other technologies for specific use cases, and then hands-on training on creating your Knowledge Graph, creating your first model, onboarding data, mapping data and so on, and this is a key, and I think we have trained more than 150 people now at Bosch, in the technology, so they can at least start to use the tool and work with it. It's still a work in progress and not necessarily sufficient to do their use case, but we support them in a consulting manner when they want to tackle their use case.
