Here's the transcript of our conversation:
RVB: 00:00:03.330 Hello everyone. My name is Rik. Rik Van Bruggen, from Neo4j, and here we are doing something really exceptional on this podcast. We're recording it with someone who has actually been on the podcast before. And that's Jesus Barrasa, from Neo4j, actually. Hi Jesus.
JB: 00:00:20.714 Good morning. Hi, Rik. It's great to be with you again.
RVB: 00:00:23.700 Yeah, yeah. It's great. The last we had you on, I think it's like a year or two ago, and that was a great experience. And I thought there's so much stuff going on, there's so much stuff happening, also, in your role within the Neo4j that it would be a good topic to talk about it a little bit more. Is that okay for you?
JB: 00:00:45.586 That's perfect, yeah, because it's-- yeah, as you say it's more than two years ago. It was actually shortly after I joined and yeah, things have moved since, yeah.
RVB: 00:00:53.338 Absolutely. So, let's talk about that. I mean people kind of know who you are, or they should read up on the previous podcast, but you've been with Neo4j for like two, three years. You were a field engineer before, and now you've got a new role heading up a telecoms practice within Neo4j. Tell us more about that. What is that?
JB: 00:01:15.216 That's right. Well, yeah, exactly. So I spent a couple of years with a field team getting a first-hand experience with on how our customers and our users, in general, were getting value out of the Neo4j. But for the last, yeah, five, six months, I've been asked to focus on the telco industry, and I think it's an interesting approach. I mean it's basically to take a vertical industry-oriented approach, instead of the traditional transversal one we were always talking about our general use cases like recommendations, fraud analysis, MDM, Customer 360. But we thought there was some value, because our customer base is growing and we're building some quite deep knowledge on certain industries, and we thought there was value in trying to capitalise that, because we saw the number of problems in this, I'm now talking about specifically the telco industry. And we believe that there's a lot of value to be extracted out of that, and that's what I'm doing. So I'm focusing on the telecoms and, yeah, it's been really exciting and I've been enjoying it for--
RVB: 00:02:27.791 Absolutely.
JB: 00:02:28.227 --the last few months.
RVB: 00:02:29.553 You've got quite a bit of experience in this, right? I mean, you've been working in or for telecom operators for a while, right?
JB: 00:02:37.640 That's right, yeah. Well, I think what I do bring to the table is this probably unusual combination of a reasonable, terribly good understanding of the telecoms industry from previous experiences. And also a lot of experience on the graph side. So I think the combination of the two is what makes me probably an acceptable candidate to take this role. But yeah, that's right.
RVB: 00:02:59.179 I would not agree-- could not agree more. Yes [laughter]. So help us understand why is this such a good fit for telecoms industry? I mean, obviously, in my simple Flemish mind, it's basically telecom operators manage networks and using a network-oriented database is probably a good idea. But help me understand, why is it a good idea for telecom operators to look at a graph database?
JB: 00:03:26.481 Well, there is that, of course, that's probably the most obvious one, but it doesn't stop there. So yeah, sure. I mean, modelling networks in a graph database is just-- I mean, should be a no-brainer, to be honest. I mean, for anyone who has experienced the real pain of trying to kind of shoehorn a complex network topology in relational world will know what I'm talking about. So it's really kind of the natural way of representing networks. But not all the companies in the telecom space do necessarily manage networks. I mean, that's a big part of them. There's all this that basically, for example, I'm thinking here of equipment providers or maybe software companies that manage more services. But still, services are becoming more and more complex, and services are composed of elements and sub-elements, and these elements depend on infrastructure pieces. So the thing is, again, this complex environment, again, is a perfect fit for a flexible database like the graph. I mean, so, it doesn't stop at the because I mean I don't know if we have chance to talk about some of the use cases that we find in this space, but there's so many of them that do fit naturally with the graph database like in Neo4j.
RVB: 00:04:44.450 Can you give me an example? Can you give me an example of one or two use cases that you think are a great fit here?
JB: 00:04:50.050 Sure, absolutely. Let's start with the first one, with the obvious network topology modeling. So as you know in Silicon Valley, networks typically multi-layer. So you have your physical components that carry logical connections, these logical connections are subdivided into other logical connections that ultimately carry service and support customers. Every level is a network but then it's like putting multiple networks on top of each other, and that becomes really complicated. And one particular case is dependency modeling, so being able to make explicit what depends on what in order to answer simple questions like, "Who's going to be affected by this planned outage? We're going to upgrade this piece of equipment, which of my customers do I have to notify?" Or the opposite one which is like, "I have a number of problems going on simultaneously, and there must be a cause for all of them." It can't be that all of my customers in that region are complaining about something, and all happening at the same. And so again exploring this network of dependencies, to try and find out or at least shortlist the candidates for explaining all these simultaneous failures. This is, I would say, it's at the top of our list, the whole dependency modeling, and service assurance, I would say service assurance is the name.
RVB: 00:06:16.790 But then what kind of domain does that typically fit in? I know that in operators there's like these OSS, BSS, those types of acronyms are often used, is this where this fits?
JB: 00:06:32.286 Yes. This would be typically an OSS one. OSS for operation support systems, is basically the systems that are used to manage the networks, so they're typically used by network planners, by service designers, by operations teams people in the NOC. So it's more the technical side than the network management and that's where this one falls, the service assurance problem is guaranteeing continuity and quality of service and being able to troubleshoot the network when problems appear. So that's probably the first that I think of. There's another very interesting one which is probably more on the BSS, which is the business and support systems like the applications that support the more customer facing activities, like billing or the management CRM, And it's interesting because it aligns with one of the most popular these days, which is the idea of knowledge graphs. So a lot of our customers in the Silicon space are building their own knowledge graphs to support the incident management solutions. So if you think your remedy whichever incident management solution you use, it's all about getting tickets when a customer calls with a problem, and then the ticket follows a flow, and it gets handed over between teams until it's solved. But this idea of extracting the information, either in a manual or in an automated way, information about description of the problem and being able to map it against a concept, topics, and these topics against documentation of previous experiences to be able to build in a graph. All this experience, all this knowledge in the domain that can help accelerate the solution of a ticket, to my mind is a very nice precursor of this knowledge graph use case that we're seeing these days and is becoming so popular. In our customer base in telecoms, they've been using for quite a while now, so it was nice surprise to see that.
JB: 00:08:32.439 So that would be another one, more in the BSS side of things. But there's plenty of others. I mean, these days especially here in Europe we're all affected by GDPR and telecom companies are no exceptions. So compliance around GDPR, being able to modulate a lineage, be able to track what confidential information about what your customer is stored; that's another case. That's not exclusive on telecom but also affects telcos and which else? There's--
RVB: 00:08:59.870 There's so many others, right? And I think the cool thing here is that you clearly have-- you speak the language of the telco [laughter], and you understand how this could fit, right? So I'm hoping that that will really help our users make that mapping as well, right?
JB: 00:09:18.109 I hope so, yeah. And sometimes it's our job to because we know that graphs that were bigger and bigger and there's a lot of interest, but still quite new technology for some of the-- for a lot of people. And it's our job, as I was saying, to try and explain them, "We know you have this problem, and we've solved this problem for other companies like yours, and that's the solution." So it's our job to sometimes give them these ideas and yes, sometimes that, of course, requires as much as possible to align with the language and the vocabulary used in the industry. So that's what we're doing in telco but we hope to export to other verticals as well.
RVB: 00:09:57.521 Well, I saw you present some of these a couple of weeks ago and at that time I was really struck by the way you presented it, because you talked about the feelings of a relational database [laughter]. How does the relational database feel when it needs to do all the drawings right?
JB: 00:10:20.741 Yeah, well that's right. Yeah. I always like to, especially when it's an early morning talk, to try to capture the audience attention with-- it's kind of a joke, but it's true right? So the example that I used was precisely about dependency modelling. And even in the simplest scenarios of trying to model dependencies, it becomes really cumbersome and really hard to manage and to maintain and to query. And I broke with the simplest example how easily that can be done in a graph and how-- yeah, come back to this kind of funny [idea?] that's how a graph database, sorry a power relational database would feel in fields when they are trying to solve a graph problem and generally--
RVB: 00:11:04.977 Yeah, yeah, yeah. Yeah, yeah. It's all about this indirect independencies, right? I mean the direct dependency is, everyone knows about those. And it's easy for any database to look those up but as soon as you need to go into the indirect dependencies, that's when the big headaches start to form, right?
JB: 00:11:24.673 That's right. That's right. And this area is huge in telecoms. As I was describe before the multi-layer nature of services and networks makes it a key element, these indirect dependencies. It's not just troubleshooting side of things as I was mentioning, but even when planning, when designing, I mean you have to create a connection, a VPN between two sides for a company and you have to guarantee diversity. You have to make sure that there is no single point of failure that there's two completely independent channels to guarantee that if one goes down, service still have continuity of service. And this sounds like a very simple and intuitive problem can be a very complex one, based on the fact that they might be indirect and sometimes not very visible dependencies. And that's what graphs made explicitly make clear and you can do in a very efficient way. So that's [crosstalk].
RVB: 00:12:13.979 So [inaudible] I mean we got a few really nice customers doing this already right? I mean I'm thinking about people like Cisco or Telia or even Ericsson, Nokia, those people are all using Neo4j, but how do you see this evolve? What was the future look like for the graphs in the telecom industry? Any perspective on that?
JB: 00:12:35.562 Well, I just hope I mean not only hope but I'm convinced that will keep growing and the more we make it public and we make it clear that we've solved the problem and that there are companies that are successfully solving it with graphs, the more they are going to want to try and get the graphs experience as well. My expectations is that it should be a no-brainer. It should be in the same way when you have to store a form to the database and then present it to produce a report. You would say, "Well that's tables, that's relational," you would say, "I have a network to manage, I have complex services to manage that is a graph." So that's my expectations and that's what I think graphs should be.
RVB: 00:13:16.694 And then we'll just start calling you king of telcos and graphs something like that right [laughter]?
JB: 00:13:23.055 Or the emperor? Or something like that?
RVB: 00:13:25.143 Emperor [laughter]. Yeah. Exactly. All right. Well I mean what we'll do with the transcription of the podcast, we'll put a bunch of links to material that you've been working on. And if there's any telcos out there listening to this podcast then I'm sure they will be able to find you. It's actually really, really a cool solution, I think, and a cool approach. Bringing a lot of domain expertise to Neo4j users and making it easier for them to kind of adapt the wonderful world of graphs, right?
JB: 00:13:57.854 Absolutely. We're looking forward to hear from all of you and definitely help you because, as I say, that should be a no-brainer for you, I mean that's graphs are the solution for telecoms problems.
RVB: 00:14:09.621 Fantastic. Thank you so much for coming online [inaudible] [laughter]. What's your name again [laughter]? Thank you for coming online and doing this call with me and I look forward to seeing you soon at one of our events.
JB: 00:14:26.555 Sure. Thank you very much. It's been a pleasure like always. Thanks man.
RVB: 00:14:29.226 Thanks man. Bye.Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!
All the best
Rik
No comments:
Post a Comment