Presentation Summary
We’re going to talk about some project themes that make sense when you’re going about developing a graph project. We’ll dive into the the business problem and discuss the specifics of the business problem.
We are going to cover manufacturing quality, how graphs apply to that problem and how this helped us get some business value through performance improvements and new capabilities. We’ll also talk about the evolution of our graph model. We will discuss where it started and where it’s going.
We’ll discuss how Boston Scientific, how we extract insights from the graph, and then we’ll talk a little bit about additional use cases in future projects like the new Hume platform.
Full Presentation
My name is Eric Wespi. I work at Boston Scientific, my co writer is Eric Spiegelberg from GraphAware. We’re going to be presenting on this manufacturing quality use case that we’ve implemented at Boston Scientific.
Boston Scientific
Wespi: I work at Boston Scientific. My entire career background has been in manufacturing and process engineering. Previously I was at Intel. I lead a data science team that works on a number of different initiatives. My background is in manufacturing and then applying analytics to the manufacturing environment.
Boston Scientific is a global medical device company. We make a lot of different therapies that are aimed at making procedures less invasive and have better outcomes for patients.
There’s a wide variety of products that we make, including pacemakers, stents, artificial heart valves, lots of different things for diagnostics and a lot of things to make us all better. We’re a global company with offices all over the world. We also are integrated in terms of development, design, manufacturing and sales.
GraphAware
Spiegelberg: I’m a senior consultant with GraphAware. I’m based in Minneapolis which is where I’ve spent the last 18 years being a Java software developer and architect. I primarily work with web-based software making use of the Spring portfolio.
I’m a member of GraphAware. We are a consulting company focused on all things graphs. We focus on consulting, training, software development, and all things focused on Neo4j.
We develop our own open-source and commercially available tools, frameworks, and products. That includes over a dozen modules that integrate with Neo4j to provide advanced functionality out of the box.
We’re a Neo4j solutions partner, and we’re a globally-distributed organization. We have team members in the United States, throughout Europe, UAE, as well as Australia.
Before we dive into Boston Scientific and how they use graphs to analyze their supply chain, we’ll talk a moment to just give a little background on how Wespi and I found ourselves presenting this topic. Then we will discuss three themes that have emerged from Boston Scientific’s project.
Background
Spiegelberg: Wespi and I met at GraphConnect New York 2017. He happened to come into the booth, and we had a great conversation about graphs. We discovered that we both lived in Minneapolis, and we decided to get together and discuss opportunities to work together at the following conference.
This was a great opportunity, because it fits the pattern of GraphAware. We like to deliver what we call high-impact consulting, where we transfer our deep and broad extensive experience with Neo4j to our clients to position them to be successful with their graph projects.
Focus on the Business Problem
We’ve got a couple of themes that have emerged from the Boston Scientific project. The first theme is to focus on the business problem.
The analysis of Boston Scientific’s supply chain is nothing new. In fact, they’ve been doing this for years. The improvement of this analysis has recently fallen to Eric and his group, so they embarked on finding new methods and new technologies that could improve the output of the analysis. Tasked with finding alternatives and improve the methods, they set out to find a solution.
As technologists, it’s not uncommon to go off and fall in love with a new shiny object or a new technology. We do this and think to ourselves, “I love this, and this is what I want to work with. Now how can I apply it to my business problem?”
Wespi and his group have actively rejected that mentality and have made a conscious choice to stay focused on their business problem. This has allowed them to maximize the business value that’s been gained by Boston Scientific. This is the business driving technology and not the technology driving the business.
Use the Right Tools
The second theme of our presentation is to use the right tools for the job.
We are not here to try to convince you that a scalpel is superior to a chainsaw or vice versa. The right tool for the job is directly dependent on your use case as well as a whole range of factors that are specific to your organization.
What we are here to tell you is that in our experience, Boston Scientific’s adoption of Neo4j has been a classic case study in using the right tool for the job.
Keep It Simple
Our third theme is to keep it simple.
Boston Scientific recognizes that their business problems are complex enough, and they don’t need to make their life harder by adopting a heavyweight, cumbersome process or technology.
They did not want to have to hire dedicated, specialized staff with exotic skills and specialist skills whose sole purpose was then to feed the technical machine. In doing that, you’re not gaining any value for your business; in fact, you might be doing the exact opposite.
That’s not to say that Boston Scientific’s problems are easy, because in fact, they’re really difficult. However, it is the adoption of a simple solution that enabled unlocking the value in their business that otherwise was hiding in plain sight.
At GraphAware, we work with a wide range of customers and clients across the globe, and we think this gives us a vantage point to observe trends and patterns across the graph community. In working with Boston Scientific, they’ve been a case study in graph adoption.
As I’ve said, they started with a business problem. They discovered graphs, they started exploring it, and ultimately, they decided to get serious and vet the technology. This vetting the technology is a critically important step, because this is where the quantum leap happens. This is where an organization goes from merely being a passive observer of the graph community to being an active participant.
This vetting of the technology is typically embodied by an organization getting their own and actual data into Neo4j. This is a critical step as well, because it forces the organization to evaluate the design decisions and build out their model. From there, they’ve got the data in a graph, allowing them to write Cypher queries, the query language of Neo4j, and those Cypher statements add business value and allow them to gain experience in adopting Neo4j.
At GraphAware, we think we add a lot of experience and expertise in this area, and our goal is to work with clients to help them accomplish their goals, to accelerate their timelines, and ultimately, to improve the quality of the deliverables.
Boston Scientific’s Business Problem
Wespi: Let’s go ahead and dive into Boston Scientific’s use case.
Boston Scientific is a global company. We’re also pretty highly vertically integrated.
We develop medical devices and we produce them. When we manufacture these we often start with very raw components. We’ll start with a resin or metal, and we’ll turn them into these complex devices. That means there are lots and lots of steps involved, and through the nature of starting with these raw materials, there’s a lot of batch processing involved, for many of our products.
With batch processing and with complex manufacturing chains, we have multiple teams. These teams are aligned based on the technology that they’re using, the process technology they’re using and many devices use multiple technologies.
Multiple teams in different countries are involved and because of that, it means we have non-standard analysis methods. We’ve discovered that when there are non-standard analysis methods and you have a bunch of engineers working on the same problems in parallel, a lot of times, things end up in Excel. That’s kind of the root of the problem we’re trying to solve. All these things end up in Excel, and we end up doing a lot of manual spreadsheet manipulation.
We have our supply chain mapping.
You can imagine a finished good product. We make a batch of some device. Imagine there’s a hundred of those devices, and that’s a finished good, then we do some testing.
After we’ve finished making these things, we do some testing and we might have a failure of some test. One of those products within the batch failed. We want to investigate that, we go and look and see what went into that finished good.
That product batch consists of a couple different batches of some components, some sub-assembly, 75 from one batch, 25 from another batch went into that 100. We don’t know which one was a failure. Then there might be some other kind of component that fed into that for the final step where we create that finished good.
Further upstream, we have other parts going into this and that are also mixing batches and going into this value chain.
Now, I’ve explained this a bunch of times to people, and it’s always a struggle to explain a batch processing manufacturing process to people that aren’t in that world. We came up with an analogy for a batch processing use case, and we’ll refer to that as we keep going. The tastiest analogy I could think of was cookies.
Use Case: Cookie Batch Processing Analogy
Let’s say we’re making a batch of cookies and we want to sell these cookies. They’re delicious cookies. They’re going to sell themselves; they’re amazing.
We make all these cookies, and before we sell them, we taste one and one of them doesn’t taste very good. Now, if that cookie doesn’t taste good, we want to figure out why it doesn’t taste good.
In that cookie production, we have batches of frosting and dough – maybe there are multiple batches of dough involved. Then making that dough, we have different cartons of eggs going into that, as well as different bags of flour going into dough.
If a cookie doesn’t taste very good, how do we know what caused it to not be good? It impossible to say which egg went into the cookie, or which combination of eggs went into the specific cookie that I tasted, because of all the mixing and baking going on.
If I understand that relationship and quantify that relationship, I am able to understand over time. We build more and more cookies and make more and more batches, we understand probabilities and assign blame based on that. Our goal here is to understand where in the supply chain something might have happened in making a cookie that didn’t taste good.
Performance Improvements
Spiegelberg: Boston Scientific has gained business value by adopting Neo4j. Let’s go through a couple of areas where that’s the case.
The first area we have gained business value by adopting Neo4j is in performance improvements. The query times of their analytical process has dropped substantially, and this has increased the overall efficiency and helped streamline the entire analytical process.
This is a very good thing. Everybody loves performance improvements. The faster something happens, the better.
Interestingly, in Boston Scientific’s experience, the largest value that they’ve gained isn’t coming from performance improvements; instead, it’s coming from non-functional areas.
These no-functional areas include the simplicity, the explainability, the white-board friendly nature of graphs and the end result is that the data is much more accessible than it otherwise was.
Let’s take a closer look at the graph that same graph. This is the portion of Boston Scientific’s model that we’re allowed to publicly discuss.
We’ve got a blue node, which is a top assembly or a finished product. In our analogy, this is the cookie, and then the cookie is composed of parts, our green node. Green nodes have a recursive relationship back to them self. This is what lets there be dozens and dozens of parts composing one top assembly.
Boston Scientific has a very rigid QA process, so they taste every cookie, and if they decide that it doesn’t taste good, they can assign a failure to it and relate it back to the top assembly or cookie.
Seeing our graph up here on the screen, our graph is actually incredibly simple. It’s so simple, it would be easy to overlook the fact that what’s being presented here is a life-saving medical device. Boston Scientific sells millions upon millions of these a year.
In terms of the simplicity of the graph, what is just three nodes and three relationships is actually a complex medical device composed of dozens of parts manufactured by Boston Scientific from raw materials.
When you think about the data that’s generating underneath, in terms of their process, the end result is millions of finished goods and billions of parts, resulting in billions of relationships generated annually.
While the model is very simple, it’s the capture and the ease and efficient navigation of this data. These relationships add tremendous value. As for explainability, because the model is so simple, it’s easy to read, write, understand, and therefore, it’s easy to explain to somebody else.
At Boston Scientific, everyone involved with the project across the whole spectrum, maybe from business stakeholders to their technical implementers, are able to understand what they’re talking about, because they’re all speaking the common language.
For those same reasons, these graphs are incredibly easy to draw on the whiteboard, and this allows team members, when they’re discussing actual production problems, to jump up at the whiteboard and draw graphs using the production data. Not only does that have its own advantages, but what’s being drawn on the whiteboard accurately reflects the way that the business understands the problem, the way the technical team understands the problem and the way that the data is actually organized at the system level.
Speaking of data accessibility, we’ve done some research, and we’ve found some surprising statistics that we’d like to share.
The first one is that it’s estimated that 90% of the world’s data was generated in only the last two years. It’s also estimated that that pace of generation is only going to increase.
It used to be the case that if your business had data, that in and of itself was a competitive advantage. However, based on statistics such as this, it’s easy to conclude that the world is awash in data, and so if everybody has data. You having data yourself is no longer simply a competitive advantage. With that being the case, what is a competitive advantage?
We think the competitive advantage is knowing how to go from merely having data to having wisdom from the data. We found this image that we love from David Summervill. We think it tells a very compelling story.
The message is that data alone isn’t power; it’s wisdom from the data that’s power. This wisdom comes from the data’s insights and connections and being able to navigate them efficiently, effectively and reliably so that you are able to act. It’s this competitive advantage today that is the goal of Boston Scientific’s adoption of Neo4j.
New Capabilities
As we’re talking about areas where Boston Scientific has had business value gain, we first covered performance improvements. Then we covered these non-functional areas. The third area is in new capabilities that they’ve gained from adopting Neo4j.
Two of those examples are shortest paths and variable length queries. An example of shortest path would be if we started on the left and we wanted to go from node A all the way to node J on the right. However, we’d like to do that in the shortest and smallest number of hops possible.
This is actually a very common problem across a wide range of industries, including shipping, logistics, transportation, financial industries, networking and so on. The utility of the shortest path is actually incredibly useful to have in your business.
An example of variable length queries would be you may have a particular query that you want to run. You could pick node F, and using a variable length query, you can constrain or expand the amount of data that’s under analysis from N to M hops away, where N and M may be one to five, 15 to 55, or 100 to 155. It’s the ability to constrain or expand that data that’s under analysis that is very powerful.
Interestingly, both shortest path and variable length queries are actually very difficult to solve. This is because the size of the dataset grows. It is by no coincidence, these two problems are also strengths of a graph database like Neo4j.
Shortest path example
Let’s go through an example of how Boston Scientific is making use of a shortest path. To set the stage for that, this is a simple Cypher statement.
