I'm Conor Rocher. I work for Dutch

Trucks North America. And one of the

things that I wanted to talk about today

is how we used Neoforj's underlying

graph technology to address some of the

challenges that we had in separating our

business from one entity into two

entities back in 2021.

So one of the challenges that we had as

an organization is the integration

between those two divisions in

essentially all of our application

framework and architecture. So if we're

going to separate a large conglomerate

that has integrated applications on each

side into two separate entities, how do

we do so in such a way that we don't end

up bringing down one entity or the other

when we completely sever that

connection?

So every business has documentation.

Everybody is aware of what happens when

you save documentation. How effective is

that documentation a month from now or

two months from now or 3 months from

now? Nowhere near as effective as it was

when it was initially committed

certainly. And when it comes to

discovering what an application does,

you first have to understand where you

were and the things that have happened

since that time that brought you to

where you are. There are lots of

different ways to do this. A traditional

way for our business might be to bring

in a swarm of contractors to essentially

attack the issue and provide us with all

of the data that essentially defines

where we are now. The problem with that

is it takes time and it's subject to

somebody else's interpretation of what

an application does. When you bring in a

contractor, they're familiar with all of

the businesses that they've worked with

up until the time that they've come into

your business. it doesn't necessarily

mean that they understand how your

applications work because their approach

to it their vision of it is based on

their prior experience. So the value of

what they're presenting is only useful

in so far as you take that into context.

In other words, it's not going to be how

you view your applications. It's going

to be what they discovered about your

applications. and you're going to end up

with something that is somewhere between

the a year outdated documentation and

where you actually are. But when you

make that final cut and you have now two

completely separate businesses, you have

a challenge. If you've missed anything,

say there's an SMTP batch that goes off

from a particular application that goes

out once a week and the contractors

didn't catch that. That happens to be

critical for supply chain. it won't take

very long before that supply chain comes

to a screeching halt.

So I was kind of introduced to Neoforj's

technology in 2021. I was looking for a

way to present data to our management

team so they could view the

relationships between data and what that

highlighted for the business. It wasn't

this particular use case. It was right

before we started the separation

process. It was for just some other, you

know, challenge that we had as a

business. And the technology at the

time, it did help us identify

relationships between things that we

didn't think were related. But it wasn't

until we really started getting into

this process of separation that we

really needed to take a look at what is

really happening with our applications

and how are they related to other

applications within our business. and in

particular how are they related to

applications with the business that

we're going to split off from

that was a big challenge for our

organization and we thought about it and

we thought about it chat JPT came out

large language models started to

proliferate and we started thinking can

we use this technology along with Neo4j

to essentially do what we would have

hired those contractors to do

great idea. We started looking into it

and what I discovered over, you know,

the years leading up until now is that

we didn't know what we didn't know about

a lot of things within our organization.

Once we finally built that graph, we

created an ETL pipeline that essentially

takes all of our network traffic,

everything that happens within our

enterprise architecture.

We have a tool called extrahop that if

anybody's familiar with that, it's

essentially

a wireshark component tied into a tap

that you deploy throughout your

enterprise architecture and then it

aggregates and pulls those into flow

records as opposed to something like

just a standard pcap from a wire share

capture which is useful but something

that takes quite a bit more effort to

evaluate and it's tactical. It's not

strategic. So that's where we started

looking into using large language models

to help us identify how can we really

surface all of this application

information and that's exactly what we

did. That ETL pipeline samples every 5

seconds it pulls in 2400 flow records

and it does this consistently every

single minute of every single day.

Now this provides us with something that

you can't get from contractors, you

can't get from internal employees. It

provides you a real time relational view

once you transform that into a live

graph of your business. Because at the

end of the day, it doesn't really matter

what your business says that they do to

their customers. You can have as many

mission statements as you want. You can

have as many boardroom meetings as you

like. None of that really matters

because what defines a business is what

the business does. That's how the public

will view you. That's how your customers

view you. And that's how you'll be

remembered

as we move forward temporally with the

graph that defines now everything that

we do as a business.

And what we discovered was enlightening

to say the least. There were

applications that were using SMTP to

send batches that weren't even

associated with documented applications.

There were SSH jobs that were

essentially running via automated

scripts that were kicking off proxies

that sent backups to servers that were

managed by the company that we split

from. None of these were documented.

None of these were identified. And they

were all critical in their own right. So

when it came time to complete the

separation, which happened earlier this

year, all of these one-off cases were

identified, categorized, and sent off to

the various teams to ensure that no

matter what happens, we now have a full

view of everything that we need to do

before we cut that cord. And when we did

cut that cord,

any of the issues that we had were not

related to

our understanding of our architecture

because we now had that understanding.

And as we continue to iterate on this,

we extended the the temporal window from

5 days to 12 days.

And you know using sampling theory you

can take a look at any sufficiently

large data set and if that data set

essentially performs the same types of

activities all day long. So an SMTP

server does what it does. It sends

batches of email again and again and

again and again all day long. Anybody

who's using an automated process, it's

going to do the same thing. So it's a

perfect fit for sampling theory. And if

you take a look at sufficiently large

data sets, sampling theory tells us that

ultimately if you can capture 1% of the

traffic, you have an architecturally an

organizationally relevant model of what

you're doing, which then correlates with

who you are as a business. If you can

get that above 3%, now you have an

operationally equivalent model of what

you are and what you're doing as a

business. We managed to get 6%.

And Neoforj's ability to absorb all of

those transformations with the Aura

product that we purchased has just been

phenomenal for us. So we were able to

push well past the boundary that creates

operational equivalence from a

relationship perspective. And now we use

this tool every single day. Not just for

its intended purpose, but I have

architects, I have engineers, I have

application owners coming to me saying,

"Can we get access to this solution?"

Because from what we've seen so far, all

the documentation that we have in say

service now for example that represents

our application portfolio, the

documentation isn't

accurate. But with this tool, we can use

that as a starting point to map out

everything that the applications do.

Now everything that we need can be had

simply by going to Neo4j Bloom and

dragging and dropping the various nodes

and then tracing the path out from

there. That's great. That's amazing.

That does a lot of amazing things for

our business. But there's one challenge.

How do I give this to somebody in

finance? How do I give this to somebody

in HR who says

I had an employee who was working with

these systems they left for whatever

reason we never heard from them again

and now we don't really know what they

were doing so how do I ask about this

person or is there somewhere I can go

and just map that out now if I were to

give someone who essentially works in HR

or finance with no experience with IT

access to Neoforj Bloom it's certainly

better and giving them access to the

query window and expecting them to know

cipher,

but they're still going to become

overwhelmed pretty quickly.

So to iterate on this technology, what

we did is we have um an AWS

relationship, we have a VPC and the

global business for Daimler Truck AG

approved access to the anthropic bedrock

models from Claude, you know, 3.5 when

we first opened it up. now Sonnet 4.5

and Opus 4.1 and now Haiku 4.5. So we

have access to all of those components

and what I did was essentially find an

MCP first framework

because the critical component in

integrating artificial intelligence with

any business is not creating a million

chatbots or having a document repository

and having the chatbots point to it with

a simple rag interface. Sure, you can do

that, but that's not going to get your

business where it needs to be, and

you're not going to really realize the

true potential that these technologies

bring to the business. So,

what I did was I deployed an interface

that looks like chat GPT or cloud

desktop or any of those solutions. It's

just a chat interface. But now bringing

our data, our business data to the large

language model, not just one set, not

just two sets, all sets. That's where

the real value is. So when you have not

just one graph, you have a graph from

sales, a graph from marketing, a graph

from design, a graph from engineering,

and you bring all those pieces together.

And now you bring in a graph from

service. It has all of our warranty

claims. and you put a large language

model like sonnet 4.5 in front of it and

you ask it simply take a look at all of

our recent warranty claims correlate it

with all of these data sets and tell me

why they've increased. Now you have

something that's immensely powerful that

can drive your business forward, can

highlight relationships that you never

would have seen because again, you don't

know what you don't know. In business

today, most of my experience has been

you have a group that does this, you

have a group that does this, there's a

group that does that. And they do

interact because they have to, but

they're not integrated. Interacting and

integration are two different things.

The integration component is the most

important piece because once you're

fully integrated, you understand how

everything that your business does

relates to everything else that your

business does.

This is what you generally refer to as

market advantage. The more you know your

business, the better your business is

going to perform.

And that's what this technology allows

us to do. Ultimately, at the end of the

day, if you don't know what the changes

that your design team just made, how

those changes impact the product that

you're selling or the production process

associated with that product,

you can estimate what that impact is

going to be from a customer perspective.

Are the customers going to be interested

in the solution? Are they is it going to

encourage them to turn their vehicles

in a shorter time frame? so that we can

roll more product or are they

essentially going to ignore it or are we

actually going to force them to move to

possibly a competitor because we didn't

understand something about the way that

they interact with our business. Now you

don't need to ask those questions, bring

in contractors and have meeting after

meeting after meeting to discuss them.

Now you go to DTNA chat. You simply ask

it. We've made these changes in the

design profile of our latest vehicles.

Tell me what you think. Open-ended

question. What you think? Correlate that

with all of these other data points, all

these other graphs that we've deployed.

And then present me an executive summary

that I can take to our seale team.

That is a real thing. It's happening

right now. And all you need to do is

essentially create the frameworks that

allow these systems to pull that data in

from all of those data sources.

And moving back to kind of Neoforj and

their graph technology directly,

when I was asked by a number of

different teams, well, why don't you

just use SQL or, you know, why don't you

use MongoDB or something of that nature?

There's a very specific reason for that

because when you think about the value

of something,

you know what is the epistmiological

import of a thing

and you start to look at it and you

start to think about it, you realize

pretty quickly that it's not the thing

that matters. It's the relationship that

that thing has to other things. That's

what defines knowledge. That's where

meaning is found. And our business

discovered pretty quickly that the way

that we'd been doing things before

actually hides that meaning underneath

relational tables that don't surface

anything other than here's a

transaction. Well, great. How do I

relate that to literally anything else

in our business? And you can bring in a

consultant to try and do that. The

better way to do that

is to take all of that data and turn it

into something that surfaces those

relations. And that's essentially what

Neoforj is. It allows you to take

everything that your business is,

everything that you do, and surface how

that impacts everything that you will

be. And that's the most important aspect

of prognosticating anything for a

business. If you don't know who you are,

how can you accurately predict who

you're going to be?

So that's the power of this technology.

That's what it allows us to achieve for

our business.

Ultimately, there's a lot of different

ways that you can approach this. There

are lots of different AI tools out there

in the market today and we've looked at

many of them.

uh from an agent orchestration

perspective, you can look at you know

like Zapier or make or you know N8N but

ultimately what it comes back to is

always you can orchestrate anything that

you want but if you don't understand

how the data that you're orchestrating

is correlated with the rest of the data

that is your business it isn't going to

improve anything. It's just going to add

complexity and create a scenario where

you essentially buy a product. It has a

great selling and marketing team to

approach here's how it will help your

business. Here's how you could

streamline all these processes,

but they're not really addressing the

challenge.

And the the challenge is knowledge,

meaning

how do we surface this? And it starts

with understanding the relationships

between all of the things in your

business that you didn't think were

related at all.

And that's where this technology allows

us to really advance everything that we

do. We got our first taste of it

with using extrahop to build a

relational graph that represents

everything that we are as a business.

That helped us separate into two

organizations. Originally it was just

Daimler AG. Then it became Daimler truck

and Mercedes-Benz car. And we did so

without any impact to either business.

Then the question became how do we

identify firewall challenges? This is a

problem that literally every business

has.

It consumes a significant amount of time

and at the end of the day we have this

siloed mentality where you have the

firewall team or the network team,

right? or the hosting team and you have

to get those teams to correlate.

But now since all of our firewall data

is sent up into Splunk, we can do the

exact same thing that we did with our

network data

and that we can take all of those all

those logs and turn them into a

relational

temporally accurate experience of what's

actually happening with all of our

firewalls. You can do this with your

load balancer data and which is what we

are. We use F5s and we have the same

scenario where we have all of our data

up in Splunk and we've used it to

identify where a specific 500 error came

in. Say you have a customer who's

connecting to your site and for example

they upload a JSON file of some business

process.

somebody else comes in, picks up that

role, and they send a JSON file, but it

doesn't the naming convention doesn't

conform to the accepted rule on the

application's back end. So, when they

use it, they get a 500 error, but they

don't use it every day. It's usually the

person who's always done it. Maybe

they're on vacation, maybe they have

sick leave, who knows? But this other

person comes in and they do it their way

and you get the bunch of 500 errors and

it fails. This person likely has some

other role in the organization. So they

just kind of brush it off and leave a

note for the person who usually does it.

How do you identify what's causing that

problem?

If you don't have the ability to

visualize

what happened yesterday compared to what

just happened 5 minutes ago and how they

differentiate, there's no way you're

going to be able to surface what the

actual problem is.

You can bring in a team. You can dig

into it certainly, but why do that? Why

not just have a graph that shows you

everything you need to know, every

transaction, and just use your words? we

have a problem with a 500 error on this

particular F5. Can you just what is it

and how do I fix it?

And at the asking maybe a minute, 2

minutes later, depending upon how long

it takes the MCP server to return all

the queries that Claude sent to it, it

comes back and it says, "Oh, here's your

issue. the format for the name for the

JSON file that's being inserted doesn't

match the standard format that's

generally being used. So, you're getting

a 500 error. If you want to fix it,

here's how you go to do it. And here's

the real trick. So, that's great. The

next step, the next iteration for this

is not, okay, um, I have to go talk to

the application owner. Let's get in

there. Let's fix the code. or we'll just

go talk to this person who fills in

occasionally and tell them, "Hey, this

is not the right format. You need to use

this format." That's okay. But what if

what if the model responded back with

the problem? Here's the challenge. Would

you like me to go fix it for you?

Here's what I think we should do.

Give me the go-ahad and I'll just go

make that happen right now. That's the

vision. That's the future.

of software as a whole, not just in our

organization,

but when we think about how we use large

language models today, how I use them

for the past maybe two years, it was

only in the past 3 or four months when I

kind of switched to a different

paradigm.

We use large language models to help us

build software. Great.

But that's not the vision. That's not

the future.

The future is the large language model

is the software. It can reason about

itself. It can have discussions about

itself. It can respond to you when

there's a challenge. It can tell you how

to improve software. It can manage that

software's life cycle because it

literally is the software. And using

agent orchestration platforms, you can

tie that into everything that you do as

a business. And you can integrate that

with Microsoft Teams or Slack and

essentially run your entire software

empire right from your phone

with the integration touch point such

that anytime there's

a new graph that you load up and maybe

there's an error that comes back from

Neoforj every so often the model will

notify you tell you how it can be fixed

and you can even set it up in such a way

that let's say the API changes in a new

version of we'll use case extra hop and

we can now enrich the data that we were

pulling out from layer 3 perspective

with layer 7 data. the model can

proactively go out something's changed

in the API here's a way that we can

actually improve the data in the graph

that you currently have and then you

don't get a development team together

the model just says would you like me to

do that for you and then you just say

yes or no and then it runs through maybe

a QA or a dev environment that you've

given it access to it tests it out you

take a look at maybe a test graph that

you have just to review the changes in

the architecture and if everything

aligns you push it to production not by

redeploying and going to GitHub and

doing a git poll and all those things

you just tell the model I like it build

it and then you go back to coffee or

lunch or whatever you're doing so that

in my view is the future of the

technology and Neo4j's graph structure

is the foundation that surfaces the

knowledge

right the epistmiological truth

to the model so that the model can help

you drive your business forward in ways

that were never possible until now.

Thank you everybody for your time. I

hope you enjoyed the session. Uh please

enjoy the rest of the conference. Thank

you again.