 Live from San Francisco, California, the Cube, covering MarkLogicWorld 2015. Brought to you by MarkLogic. Now, here are your hosts, Jeff Frick and Jeff Kelly. Welcome back everybody, we're live here on the Cube at MarkLogicWorld 2015. I'm Jeff Kelly, I'm with my co-host, Jeff Frick. Hey Jeff. We've got Jeff and Jeff for this segment. Keeps it easy for the guests. Absolutely, and speaking of guests, we're joined by Derek Tapp, who's the head of IT Solutions at CABBY in the UK. Hello. Welcome Derek, thanks for joining us on the Cube. Welcome. So CABBY, I'm guessing most of our US based audience won't know what that organization's all about. Why don't you tell us a little bit about CABBY and your role, and then we'll kind of get into some of the things you're doing with MarkLogic and on Structure Day. Okay, yeah, so CABBY's a non-profit organization. We aim to improve people's lives through solving problems in an agricultural environment. So we do things like help farmers in developing countries by providing information to them. So all about long-term solutions, so not just a point solution, but something that's going to help people over a long period of time. You're all. Yeah, so like I said, I'm the head of IT Solutions, so my area's quite a small area, but we work a bit like the glue between what the business needs and what IT can deliver. So we help with some of the larger scales of architectural solutions, provide technical direction and some expertise around that. So I have some business analysts and project managers, so we just sort of try and make sure everything fits together. Interesting. Put a little color around some of the solutions, if you will, that you're delivering out to your, I guess, constituents. What does it look like? Are they applications that a farmer might use or what do they actually look like? There's a big range, because we try, like our end goal is trying to help people like farmers in developing countries. So they have very different requirements to what we use for some of, providing some of our revenue which helps support our projects, which is providing information to academics and researchers. So tools that you'd want to provide to researchers is a very scientific and very heavy information, whereas when you go to farmers developing countries, you're going to want a lot less information, a lot less scientific, a lot more practical advice. And how we get that out to them varies by country as well. So some countries have good smartphone penetration, they have good mobile coverage. Others don't, but we still need to reach those people. So in quite a lot of countries who work, but one of our programs is called PlantWise. So as part of that, we've been training up a network of plant doctors around the world. Now what they do is they'll set up a little store, a marketplace or somewhere else central that farmers come to and they can ask those guys for advice. They can take along samples of their plant, they're having problems with and that plant doctor will help to diagnose it. Now, we can either try and provide information to those farmers themselves or, and this is what is often a better approach at the moment, we just train those plant doctors as well. So we're supporting the plant doctors to support the farmers. And even those farmers go back to their communities, they then help support the farmers that they then work with their families. And that sort of, it's that knock on effect. So is it like timing of crops, how much water, because we hear actually a lot of big data solutions in agriculture where the driverless tractors are going around more of a developed country, but that, you know, how much fertilizer to put, how much water, you know, yield on a particular thing. So you kind of taking that and delivering a little different scale. Yeah, so it's mainly the small holder farmers we target. So it's practice that makes sense to them. So there's no point saying you can take this practice if it's something they couldn't possibly do. So it could be something that's incredibly labor intensive about a machine. They can't afford the machine. So don't offer that suggestion to them. Okay. So it's looking at what practical information we can give them. So it can be around sort of things that would help with the climate. It could be things about using seed, which is more resistant to a disease that's known to be in that area. So it's not a one size fits all. It's what's appropriate to that area. Excellent. So you're a relatively new to Mark logic. Yeah, I understand. So we've had a number of customers on today that have been on with Mark logic for a while. Let's talk with a customer who's fairly new. It's a good opportunity to talk about what was the specific business challenge that you were dealing with. That kind of led you to Mark logic. It's kind of walked us through that journey. But the one main thing is that cabbie is over a hundred years old. So we have a big variety of data internals through the organization. Some of that we can use very easily. Others, not so much, but even between the difference of silos of information we could use easily trying to merge those together is labor intensive. So we've been doing it as a plant wise we have to do that quite a few times. But what we identified is that if we could take away some of those hurdles then we could produce new products easier. So it's more about thinking about how could we use information A of information B rather than say, oh, have we got time to join those things together? So is that ability of Mark logic to ingest lots of different types of data and then minimize the effort to link those things together? So talk about when you were looking for a solution. Obviously you came to Mark logic, but I'm wondering, did you look at some of the other no SQL databases out there? I mean, there's this kind of slew of open source with SQL databases. And then you've got more of the traditional databases that are trying to add no SQL like capabilities. What was it like when you were looking at that landscape and what did you use to kind of evaluate what was the right solution for you? Well, we come from a SQL server background mainly. We have a few other database technologies inside Kaby but mainly a SQL server shop. What we identified fairly quickly is it was a document database flavor of no SQL that was the best match for our use cases. So it was really within that area. We put most of our attention but we were also interested in the graph databases too. So that instantly puts Mark logic sort of up near the top of the heap as it's got both. But even within just the document side, although I liked some of the open source solutions I had concerns about like betting the business on those being available for the next five years and even within short term periods is a disaster recovery good enough for us. So we let's have a number of solutions but Mark logic came out as the clear winner. We'll talk about those enterprise grade capabilities. We hear a lot about that from Mark logic. They kind of market themselves and enterprise no SQL. Thinking about a little bit more about what were the key quote unquote enterprise grade features that were important to you? Well, the two main ones for me is coming from the SQL service shop. When we first started looking around some of the open source ones we were, I wouldn't say disheartened but it was more of a compromise than we thought we were going to have to make. So we knew we were going to get the flexibility to get the document model but we didn't realize up front that we're going to lose things like ACID which to people growing up with SQL server is you take it for granted. So we'd be able to get that back again but we're still having the benefits of the document database and having the graph technology in there as well. That was a big plus point for us. The government grade security that my logic is very hot on to us isn't as a big an issue. Like security is important to us like it's for any organization. That wasn't like a, it wasn't a killer feature for us but being able to reliably recover from any disasters is. We have a relatively small IT team we're supporting products which are important to people. We need those to be available. We don't want to have to have our DVA spending weeks trying to manually rebuild a database. We want things to work and when they don't work to have some realistic way of restoring that data. So let's talk a little bit about the use of semantics. We hear a lot about that at the show today. And we talked to a number of practitioners, customers that are really touting the semantic capabilities to bring together data from a lot of different sources. So kind of getting back into the core use case. Can you provide a little bit of detail around those capabilities and how they're ADU and the building applications? There's a few things we're looking at in that area. There's one application we built in the past as part of PlantWise which we achieved what we needed to via a relational model but it was hellishly complicated. The SQL code to join everything together to get the answer we needed was very, very complicated, very laborious so lots of places there could be problems. But it works, it does a good job. But looking at, if we try to recreate that now using a semantic model it would be a much, much easier thing to do. Because basically what the tool does is say if you've got this problem on this part of this plant in this country, what could it be? And then we provide some images to help people sort of nail down exactly what it is. And that's just a perfect use case for semantic. So let's say that's linked to this, linked to that, linked to this. And it's just a perfect use case for it. So one of our earliest proof of concepts we did was to replicate that in my logic using Sparkle. And as we expected it was a much easier thing to achieve. Going to the future for things that we haven't already got. We track metadata across lots of our data silos already. But the idea of using semantics to link that together is a really interesting thing for us. So in one of our larger description products we have a lot of search capability in there but not so much around browse. And that's something we're looking to improve. And having good quality of metadata and the way you can richly link things together will make that a much better experience for people. So I think the semantics could be strong for us in that place as well. So you talked about using MarkLogic to build products with the data assets that you already had. Now that you've been at it for a little while, I mean is this opening up a lot of new opportunities? Do you see a really robust roadmap of places that you can go where you couldn't go before? Yeah, well we've only just started working on our first formal projects who became customers at the end of January. Okay. Where I'm seeing we've got really exciting avenues we can look at is by combining what we're doing with MarkLogic with our new API-centered design. So we're getting into open link data as well. So by having our internal data in a good state and also linking out to other people's data allowing other people to link to us is those two things together we think is going to be really valuable for us going into the future. Right, because do you aggregate the data from the small farmers then the feedback to the scientific community? So it's kind of a symbiotic relationship. They get wide data set to do their studies and then the data then goes back to the source. Yes and no. Okay. A lot of the data we have is open, it's academic, it's published research papers. That we make available to everybody in various different ways. Okay. The data we get back from the plant clinic, so the clinic's the plant office run, that's sometimes politically sensitive data. So we signed data agreements with those countries about what we can use at data fall. Okay. Because it could be if we release data saying there is this pest in this country that could have trade implications which is bad if they've got that pest but what if that pest wasn't actually there? What if it was a misdiagnosis? There's lots of politics going there. So from a technology point of view, yes we can do that but from a political point of view and our sort of our responsibility to the countries we work in it's a little less clear than that. What we're hoping to work on is as Kaby sort of proves the value of having open data, we're hoping the other countries will see that and then if people like producers and traders see which countries are more open about their data, they'll be more willing to trade with those people. Right. Because if you have a country that says oh we have no plant pest in our country, then no one will believe that. It's like okay that's the official line but no one's going to believe that. Right. Whereas another country says you can see all the problems you've got, that's where we are. Right, now apply your brain power to help us solve those problems, right? Exactly. So in theory it should be a nice positive spiral. Yeah, so there's a lot of complication there and most of it is nothing to do with the IT side. It's politics, it's trade, outside of my area most definitely but it's an interesting thing to be on the edge of. And how many countries do you guys work in? We're working in about 70 countries I'd say. Okay. We have member countries who sort of help steer our sort of direction. We have 48 of those but we're actually active in about 70 countries, give or take. So looking forward, I mean we talked to a number of customers today that kind of started with BarkLogic around one use case and then expanded to multiple use cases. To the extent that you can share, what are you looking forward to in terms of leveraging some of the other capabilities in the platform and really moving forward to kind of your data strategy? But our key focus is just getting a central data store. So it won't necessarily be the master for all of our data but somewhere where we can easily do a combined search across our different sets of data. So that could be stuff we currently hold in relational, could be in documents, could be in access or Excel or whatever because it can be going back like a decade or some of our data. And it's getting that into a form we can use it. When it's there, that's when we can start collecting the different ways we can use the technology. But it's building that core data. And then you can kind of build the top of that. We build that foundation. That's where the main value for us is. So we're short on time but I want to get your impressions of this event here. I mean, there's a lot of folks here. We heard from our last guest that one of the biggest values they get is from hearing stories from other customers, other users. What's kind of excited you that you've heard here today and what's your impressions of the event? I do like the event here because the thing I like about this one, so there is an equivalent in the UK but this one is more technically focused. There's a lot more detail but you also get to talk with the people who actually build the product. And that's what I like about being here. I don't know how many of the my logic engineers are here but it seems to be wherever you turn this one, not too far away. So rather than asking people who maybe they're in sales or support, you're talking to the people who are actually building the product. Hopefully being able to influence that as well. And that's why I find this one very valuable. So the sessions are great. I like the sessions but it's the interaction between the sessions that I actually find more valuable to us. Well, Derek from Cabby, thanks for joining us on theCUBE. We appreciate it. Hopefully we'll see you back here next year at MarkLogic World with theCUBE. So thanks again. Thanks for watching everybody. Stick around, we'll be back with our next guest here live at MarkLogic World right after this.