Digital Twin and DigitalKin

(00:06:49.04)

Chris:
Okay, that's great background. Thank you, Henry. In order to understand what we've done, I thought it'd be helpful to just walk through some of the concepts and that we're using. Because some of these are gonna sound fairly new to some of you. So let's start with a data mesh. So this is an emerging data architecture pattern, which is really the kind of antithesis of a data lake. So the idea with a mesh is that it's domain based. So in effect, we kind of look at various domains within the business like sales, marketing, casting, and the data sources within these then effectively treated as products. So we bring the technical team and the business together. And they can own that bit of data as a product. That's quite different from having a central data lake where everything is dumped in there and it's owned by IT. The great thing about this pattern is it can sit on a modern data platform, it can evolve, but in effect, each domain within the mesh then becomes the single version of the truth for that data and because it's treated as a product, it can serve other domains in the mesh or other applications. And we can grow and iterate on this. So effectively an incremental way of creating the lake rather than dumping everything in one place.

So the next thing we'll talk about a little is a knowledge graph. What's great about those graphs is in some ways, they need no introduction, because we all use a knowledge graph every day. And when we use Google, Google uses a knowledge graph to describe things when you go and search for a person, place, company, something like that. You're effectively interrogating Google's knowledge graph. So what we have done is we have overlaid on all this graph on top of our data mesh, and that allows us then to make connections between things, which otherwise would not be there. So we can, in effect, take a list of engineers that skills request for resources and we can infer connections between those, using a good graph without anybody having to actually hard code or manage those connections.

Let's talk a bit about the actual tech stack, before we get into the depths of the architecture itself. So this is massively oversimplified, but just to give you a sense of how all of these different layers come together. The very bottom, if you like, the kind of data foundation. So these are systems of record things like salesforce.com; interaction systems, like G Suite and Slack. We then overlay a data mesh on top of that, so those systems are the domains within those systems that map to the business become nodes in the mesh. We then use Elasticsearch to create a dynamic Knowledge graph across the mesh. And Slack then allows us to create an interface based around natural language processing, a bot if you like, to interrogate the graph and drive some of these questions and automate interactions that we've been talking about. So Henry, from your perspective, looking at this on the business side now across the kinetic, what are the benefits? Or what are some of the benefits of this kind of solution?

(00:10:11.07)

Henry:
So the benefits of the solution are quite infinite to where we can take it. From a business standpoint, we will begin to gain many efficiencies by increasing the productivity of our team across several regions and locations, resulting in huge cost savings. Transforming tasks that let's say, took someone 30 minutes, and perhaps executed repetitively in their organization, to just a few seconds with just one question in slack. Moreover, it will allow us to decentralize some tasks that perhaps have been centralized in our back office, operational staff increasing the speed of which things are done. Additionally, driving data compliance and adoption. Often it is difficult to make the right decisions when the data quality isn't reliable or across multiple systems. And, typically it's related to the experience of the tool we have where the experience creates too much friction to get or enter data for the user. So you're having to spend hours to get data compliance. Using something like Slack is what everyone's used to, and not having to sign in to yet another solution or system to enter information or get information makes it frictionless to the user increasing adoption and data compliance. It also provides a competitive advantage for our business, as an organization to be able to work in real time with achieving what they need instantaneously in such a fashion that you didn't even notice that technology was there. Eventually we will become predictive, which is where ultimately I want to take it.

Chris:
Okay, that's great Henry. Great background, thank you. With that, let me now hand over to our colleague, Don Johnson, who will take you through how this thing actually works.

(00:12:00.02)

Don:
Thanks, Karl. Hi, everyone. I am Don, and I'm a Technical Principal at KNC Create. I'm excited to walk you through what Dhyaanesh and myself have been working on. Don't you think the data mesh and knowledge graph are cool technologies? Well, we agree as well. This is brand new, and we are still working through the kinks and enjoying every minute of it. And although initially I was skeptical about the design requirements of the data mesh, the distributed nature of the data and treating data as a product has democratized our data at Kin + Carta.

Dhyaanesh:
Sounds really exciting. Before we get into that ask me some questions. Imma introduce myself, I'm Dhyaanesh. I am a Technical Analyst at Kin + Carta Create, and I shall be asking Don a few questions as he walks us through his architecture of the data mesh that we've created. So now onto the good stuff. So Don, how is this data architecture different from a traditional architecture? And can you touch base on what the shared benefits of the data metaphor?

Don:
Yeah, glad you asked. Well, traditional enterprise architecture has a monolithic data store with centralized data pipelines. This monolithic data structure is generally siloed off and usually consists of data engineers and data scientists. This often leaves the data team of an organization frustrated and lacking the business knowledge to truly understand the data. This new architecture is about liberating the data and building out agile teams which consist of data engineers and data scientists working alongside the software engineers and designers.

Dhyaanesh:
Could you delve a little deeper on what the different components of this architecture are?

Don:
First we start with the core domains. These domains are the fundamental truths of the business. In our case, to name a few, we have profiles, skills, connections and client accounts. Without any of these domains our business could not run. If you look at the diagram, next one up is the drive domains. These are built from combining the core domains to model higher level concepts in the business. One such drive domain for our business as experts, which is drive McCord domain, profile skills, and connections and defines who an expert is in our organization. Finally, on top of the data mesh is the business applications. This is where all the value efficiencies are built. And essentially, we're building our Digital Twin. But this picture is not quite complete, as we're also leveraging a new technology, Elasticsearch new explorer API, what's cool about this is Elasticsearch builds a graph of the data you ingest into it behind the scenes. This has led to many interesting connections among the core domains.

Dhyaanesh:
Interesting. You mentioned solving problems at kNC. So what are some specific issues you're trying to solve using this architecture.

(00:15:12.02)

Don:
I'm currently at KNC. We have several tools such as Salesforce, Slack, Google directory, GitHub and small improvements, which contain much of the same information but serve different purposes, as well as takes a significant amount of work to search each system separately, and coordinate the information to drive insights. But after several internal research initiatives, the biggest problems identified was staffing. Staffing requires a lot of coordination of matching employees interests, skills and experience to our clients interest, desires and technology.

Dhyaanesh:
Could you give us a little insight into what the current tedious staffing process is and how having a data mesh improves that?

Don:
Yeah, absolutely. As it stands today, our staffing leads have to navigate through multiple different data sources in order to staff a single role. Skills and interests are sourced from Salesforce. Availability from another app in Salesforce, and global location is found in Slack. Project history comes from another Salesforce app, and contact information from Google directory. This is to staff a single individual. Imagine having to compare all this data from different tabs in your browser for multiple candidates to find the one suited for a role. This process is clearly not scalable, and it's something we need to explore in order to help the company grow. And now imagine having the employee participate and keeping their own data up to date. There is a better, faster, and fewer decision way and now it's time to showcase our first iteration, a solution and the concept of bringing these two pieces together. Dhyaanesh, do you want to do the honors and demo our DigitalKin bot?

Dhyaanesh:
Yes, of course. Let me jump to our conversational bot. All right, everyone. So this is DigitalKin bot, we've created as an initial solution at our attempt to solve the tedious staffing problem. I'm gonna trigger a Salesforce alert that will enable the bot to respond.