>> They are disruptive technologies. And if you think about the disruption that's happening in business, with IoT, with OT, and with big data, you can't get anything more disruptive to the whole of the business chain as this particular area. It's an area that I focused on myself, asking the question, should everything go to the cloud? Is that the new future? Is 90% of the computing going to go to the cloud with just little mobile devices right on the edge? Felt wrong when I did the math on it, I did some examples of real-world environments, wind farms, et cetera, it clearly was not the right answer, things need to be near the edge. And I think one of the areas to me that solidified it was when you looked at an area like video. Huge amounts of data, real important decisions being made on the content of that video, for example, recognizing a face, a white hat or a black hat. If you look at the technology, sending that data somewhere to do that recognition just does not make sense. Where is it going? It's going actually into the camera itself, right next to the data, because that's where you have the raw data, that's where you have the maximum granularity of data, that's where you need to do the processing of which faces are which, right close to the edge itself, and then you can send the other data back up to the cloud, for example, to improve those algorithms within that camera, to do all that sort of work on the batch basis over time, that's what I was looking at, and looking at the cost justification for doing that sort of work. So today, we've got a set people here on the panel, and we want to talk about coming down one level to where IoT and IT are going to have to connect together. So on the panel I've got, I'm going to get these names really wrong, Sanjeev Kumar? >> Yes, that's right. >> From FogHorn, could you introduce yourself and what you're doing where the data is meeting the people and the machines? >> Sure, sure, so my name is Sanjeev Kumar, I actually run engineering for a company called FogHorn Systems, we are actually bringing analytics and machine learning to the edge, and, so our goal and motto is to take computing to where the data is, than the other way around. So it's a two-year-old company that started, was incubated in the hive, and we are in the process of getting our second release of the product out shortly. >> Excellent, so let me start at the other end, Rohan, can you talk about your company and what contribution you're focusing on? >> Sure, I'm head product marketing for Maana, Maana is a startup, about three years old, what we're doing is we're offering an enterprise platform for large enterprises, we're helping the likes of Shell and Maersk and Chevron digitally transform, and that simply means putting the focus on subject matter experts, putting the focus on the people, and data's definitely an important part of it, but allowing them to bring their expertise into the decision flows, so that ultimately the key decisions that are driving the revenue for these behemoths, are made at a higher quality and faster. >> Excellent. Well, two software companies, we have a practitioner here who is actually doing fog computing, doing it for real, has been doing it for some time, so could you like, Janet George from Western Digital, can you introduce yourself, and say something from the trenches, of what's really going on? >> Okay, very good, thank you. I actually build infrastructure for the edge to deal with fog computing, and so for Western Digital, we're very lucky, because we are the largest storage manufacture, and we have what we call Internet of Things, and Internet of Test Equipment, and I process petabytes of data that comes out of the Internet of Things, which is basically our factories, and then I take these petabytes of data, I process them both on the cloud and then on the edge, but primarily, to be able to consume that data. And the way we consume that data is by building very high-profile models through artificial intelligence and machine learning, and I'll talk a lot more about that, but at the end of the day, it's all about consuming the data that you collect from anywhere, Internet of Things, computer equipment, data that's being produced through products, you have to figure out a way to compute that, and the cloud has many advantages and many trade-offs, and so we're going to talk about the trade-offs, that's where the gap for computing comes into play. >> Excellent, thanks very much. And last but not least, we have Val, and I can never pronounce your surname. >> Bercovici. >> Thank you. (chuckling) You are in the midst of a transition yourself, so talk about where you have been and where you're going. >> For the better part of this century, I've been with NetApp, working at various functions, obviously enterprise storage, and around 2008, my developer instinct kind of fired up, and this thing called cloud became very interesting to me. So I became a self-anointed cloud czar at NetApp, and I ended up initiating a lot of our projects which we know today as the NetApp Data Fabric, that culminated about 18 months ago, in acquisition of SolidFire, and I'm now the acting CTO of SolidFire, but I plan to retire from the storage industry at the end of our fiscal year, at the end of April, and I'm spending a lot of time with particularly the Cloud Native Compute Foundation, that is, the opensource home of Google's Kubernetes Technology and about seven other related projects, we keep adding some almost every month, and I'm starting to lose track, and spending a lot of time on the data gravity challenge. It's a challenge in the cloud, it's a particularly new and interesting challenge at the edge, and I look forward to talking about that. >> Okay, and data gravity is absolutely key, isn't it, it's extremely expensive and extremely heavy to move around. >> And the best analogy is workloads are like electricity, they move fairly easily and lightly, data's like water, it's really hard to move, particularly large bodies around. >> Great. I want to start with one question though, just in the problem, the core problem, particularly in established industries, of how do we get change to work? In an IT shop, we have enough problems dealing with operations and development. In the industrial world, we have the IT and the OT, who look at each other with less than pleasure, and mainly disdain. How do we solve the people problem in trying to put together solutions? You must be right in the middle of it, would you like to start with that question? >> Absolutely, so we are 26 years old, probably more than that, but we have very old and new mix of manufacturing equipment, it's a storage industry, and in our storage industry, we are used to doing things a certain way. We have existing data, we have historical data, we have trend data, you can't get rid of what you already have. The goal is to make connectors such that you can move from where you're at to where you're going, and so you have to be able to take care of the shift that is happening in the market, so at the end of the day, if you look at five years from now, it's all going to be machine learning and AI, right? Agent technology's already here, it's proven, we can see, Siri is out here, we can see Alexa, we can see these agent technologies out there, so machine learning is a getting a lot of momentum, deep learning and neural networks, things like that. So we got to be able to look at that data and tap into our data, near realistically, very different, and the way to do that is really making these connections happen, tapping into old versus new. Like for example, if you look at storage, you have file storage, you have block storage, and then you have object storage, right? We've not really tapped into the field of object storage, and the reason is because if you are going to process one trillion objects like Amazon is doing right now with S3, you can't do it with the file system level storage or with the blog system level storage, you have to go to objects. Think Internet of Things. How many trillions of objects are going to come out of these Internet of Things? So one, you have to be positioned from an infrastructure standpoint. Two, you have to be positioned from a use case prototyping perspective, and three, you got to be able to scale that very rapidly, very quickly, and that's how change happens, change does not happen because you ask somebody to change their behavior, change happens when you show value, and people are so eager to get that value out of what you've shown them in real life, that they are so quick to adapt. >> That's an excellent-- >> If I could comment on that as well, which is, we just got through training a bunch of OT guys on our software, and two analogies that actually work very well, one is sort of, the operational people are very familiar with circuit diagrams, and so, and sort of, flow of things through essentially black boxes, you can think of these as something that has a bunch of inputs and has a bunch of outputs. So that's one thing that worked very well. The second thing that works very well is the PLC model, and there are direct analogies between PLC's and analytics, which people on the floor can actually relate to. So if you have software that's basically based on data streams and time, as a first-class citizen, the PLC model again works very well in terms of explaining the new software to the OT people. >> Excellent, okay, would you want to come in on that as well? >> Sure, I think a couple of points to add to what Janet said, I couldn't agree more in terms of the result, I think Maana did a few projects, a few pilots to convince customers of their value, and we typically focus very heavily on operationalizing the output, so we are very focused on making sure that there is some measurable value that comes out of it, and it's not until the end user started seeing that value that they were willing and open to adopt the newer methodologies. A second point to that is, a lot of the more recent techniques available to solve certain challenges, there are deep learning neural nets there's all sorts of sophisticated AI and machine learning algorithms that are out there, a lot of these are very sophisticated in their ability to deliver results, but not necessarily in the transparency of how you got that, and I think that's another thing that Maana's learning, is yes, we have this arsenal of fantastic algorithms to throw at problems, but we try to start with the simplest approach first, we don't unnecessarily try to brute force, because I think an enterprise, they are more than willing to have that transparency in how they're solving something, so if they're able to see how they were able to get to us, how the software was able to get to a certain conclusion, then they are a lot happier with that approach. >> Could you maybe just give one example, a real-world example, make it a little bit real? >> Right, absolutely, so we did a project for a very large organization for collections, they have a lot of outstanding capital locked up and customers not paying, it's a standard problem, you're going to find it in pretty much any industry, and so for that outstanding invoice, what we did was we went ahead and we worked with the subject matter experts, we looked at all the historical accounts receivable data, we took data from a lot of other sources, and we were able to come up with models to predict when certain customers are likely to pay, and when they should be contacted. Ultimately, what we wanted to give the collection agent were a list of customers to call. It was fairly straightforward, of course, the solution was not very, very easy, but at least on a holistic level, it made a lot of sense to us. When we went to the collection agents, many of them actually refused to use that approach, and this is part of change management in some sense, they were so used to doing things their way, they were so used to trying to target the customers with the largest outstanding invoice, or the ones that hadn't paid for the longest amount of time, that it actually took us a while, because initially, what the feedback we got was that your approach is not working, we're not seeing the results. And when we dug into it, it was because it wasn't being used, so that would be one example. >> So again, proof points that you will actually get results from this. >> Absolutely, and the transparency, I think we actually sent some of our engineers to work with the collections agents to help them understand what approach is it that we're taking, and we showed them that this is not magic, we're actually, instead of looking at the final dollar value, we're looking, we're calculating time value lost, so we are coming up with a metric that allows us to incorporate not just the outstanding amount, or the time that they haven't paid for, but a lot of other factors as well. >> Excellent, Val. >> When you asked that question, I immediately went to more of a nontechnical business side of my brain to answer it, so my experience over the years has been particularly during major industry transitions, I'm old enough to remember the mainframe to client server transition, and now client server to virtualization and cloud, and really, sales reps have that well-earned reputation of being coin-operated, though it's remarkable how much you can adjust compensation plans for pretty much anyone, in a capitalist environment, and the IT/OT divide, if you will, is pretty easy to solve from a business perspective when you take someone with an IT supporting the business mentality, and you compensate them on new revenue streams, new business, all of a sudden, the world perspective changes sometimes overnight, or certainly when that contract is signed. That's probably the number one thing you can do from a people perspective, is incent them and motivate them to focus on these new things, the technology is, particularly nowadays is evolving to support them for these new initiatives, but nothing motivates like the right compensation plan. >> Excellent, a great series of different viewpoints. So the second question I have again coming down a bit to this level, is how do we architect a solution? We heard you got to architect it, and you've got less, like this, it seems to me that that's pretty difficult to do ahead of where you're going, that in general, you take smaller steps, one step at a time, you solve one problem, you go on to the next. Am I right in that? If I am, how would you suggest the people go about this decision-making of putting architectures together, and if you think I'm wrong and you have a great new way of doing it, I'd love to hear about it. >> I can take a shorter route. So we have a number of customers that are trying to adopt, are going through a phased way of adopting our technology and products, and so it begins with first gathering of the data, and replaying it back, to build the first level of confidence, in the sense that the product is actually doing what you're expecting it to do. So that's more from monitoring administration standpoint. The second stage is you should begin to capture analytical logic into the project, where it can start doing prediction for you, so you go into, so from operational, you go into a predictive maintenance, predictive maintenance, predictive models standpoint. The third part is prescriptive, where you actually help create a machine learning model, now, it's still in flux in terms of where the model gets created, whether it's on the cloud, in a central fashion, or some sort of a, the right place, the right context in a multi-level hierarchical fog layer, and then, you sort of operationalize that as close to the data again as possible, so you go through this operational to predictive to prescriptive adoption of the technology, and that's how people actually build confidence in terms of adopting something new into, let's say, a manufacturing environment, or things that are pretty expensive, so I give you another example where you have the case of capacitors being built on a assembly line, manufacturing, and so how do you, can you look at data across different stations and manufacturing on a assembly line? And can you predict on the second station that it's going to fail on the eighth one? By that, what you're doing is you are actually reducing the scrap that's coming off of the assembly line. So, that's the kind of usage that you're going to in the second and third stage. >> Host: Excellent. Janet, do you want to go on? >> Yeah, I agree and I have a slightly different point of view also. I think architecture's very difficult, it's like Thomas Edison, he spent a lot of time creating negative knowledge to get to that positive knowledge, and so that's kind of the way it is in the trenches, we spend a lot of time trying to think through, the keyword that comes to mind is abstraction layers, because where we came from, everything was tightly coupled, and tightly coupled, computer and storage are tightly coupled, structured and unstructured data are tightly coupled, they're tightly coupled with the database, schema is tightly coupled, so now we are going into this world of everything being decoupled. In that, multiple things, multiple operating systems should be able to use your storage. Multiple models should be able to use your data. You cannot structure your data in any kind of way that is customized to one particular model. Many models have to run on that data on the fly, retrain itself, and then run again, so when you think about that, you think about what suits best to stay in the cloud, maybe large amounts of training data, schema that's already processed can stay on the cloud. Schema that is very dynamic, schema that is on the fly, that you need to read, and data that's coming at you from the Internet of Things that's changing, I call it heteroscedastic data, which is very statistical in nature, and highly variable in nature, you don't have time to sit there and create rows and columns and structure this data and put it into some sort of a structured set, you need to have a data lake, you need to have a stack on top of that data lake that can then adapt, create metadata, process that data and make it available for your models, so, and then over time, like I totally believe that now we're running into near realtime compute bottleneck, processing all this pattern processing for the different models and training sets, so we need a stack that we can quickly replace with GPUs, which is where the future is going, with pattern processing and machine learning, so your architecture has to be extremely flexible, high layers of abstraction, ability to train and grow and iterate. >> Excellent. Do you want to go next? >> So I'll be a broken record, back to data gravity, I think in an edge context, you really got to look at the cost of processing data is orders of magnitude less than moving it or even storing it, and so I think that the real urgency, I don't know, there's 90% that think of data at the edge is kind of wasted, you can filter through it and find that signal through the noise, so processing data to make sure that you're dealing with really good data at the edge first, figuring out what's worth retaining for future steps, I love the manufacturing example, I have lots of customer examples ourselves where, for quality control in a high-moving assembly line, you want to take thousands of not millions of images and compare frame and frame exactly according to the schematics where the device is compared to where it should be, or where the components, and the device compared to where they should be, processing all of that data locally and making sure you extract the maximum value before you move data to a central data lake to correlate it against other anomalies or other similarities, that's really key, so really focus on that cost of moving and storing data, yeah. >> Yes, do you want the last word? >> Sure, Maana takes an interesting approach, I'm going to up-level a little bit. Whenever we are faced with a customer or a particular problem for a customer, we try to go over the question-answer approach, so we start with taking a very specific business question, we don't look at what data sources are available, we don't ask them whether they have a data lake, or we literally get their business leaders, their subject matter experts, we literally lock them up in a room and we say, "You have to define "a very specific problem statement "from which we start working backwards," each problem statement can be then broken down into questions, and what we believe is any question can be answered by a series of models, you talked about models, we go beyond just data models, we believe anything in the real world, in the case of, let's say, manufacturing, since we're talking about it, any smallest component of a machine should be represented in the form of a concept, relationships between people operating that machinery should be represented in the form of models, and even physics equations that are going into predicting behavior should be able to represent in the form of a model, so ultimately, what that allows us is that granularity, that abstraction that you were talking about, that it shouldn't matter what the data source is, any model should be able to plug into any data source, or any more sophisticated bigger model, I'll give you an example of that, we started solving a problem of predictive maintenance for a very large customer, and while we were solving that predictive maintenance problem, we came up with a number of models to go ahead and solve that problem. We soon realized that within that enterprise, there are several related problems, for example, replacement of part inventory management, so now that you figured out which machine is going to fail at roughly what instance of time from now, we can also figure out what parts are likely to fail, so now you don't have to go ahead and order a ton of replacement parts, because you know what parts are going to likely fail, and then you can take that a step further by figuring out which equipment engineer has the skillset to go ahead and solve that particular issue. Now, all of that, in today's world, is somewhat happening in some companies, but it is actually a series of point solutions that are not talking to each other, that's where our pattern technology graph is coming into play where each and every model is actually a note on the graph including computational models, so once you build 10 models to solve that first problem, you can reuse some of them to solve the second and third, so it's a time-to-value advantage. >> Well, you've been a fantastic panel, I think these guys would like to get to a drink at the bar, and there's an opportunity to talk to you people, I think this conversation could go on for a long, long time, there's so much to learn and so much to share in this particular information. So with that, over to you! >> I'll just wrap it up real quick, thanks everyone, give the panel a hand, great job. Thanks for coming out, we have drinks for the next hour or two here, so feel free to network and mingle, great questions to ask them privately one-on-one, or just have a great conversation, and thanks for coming, we really appreciate it, for our Big Data SV Event livestreamed out, it'll be on demand on YouTube.com/siliconangle, all the video, if you want to go back, look at the presentations, go to YouTube.com/siliconangle, and of course, siliconangle.com, and Wikibond.com for the research and content coverage, so thanks for coming, one more time, big round of applause for the panel, enjoy your evening, thanks so much.