 The Cube at IBM Impact 2014 is brought to you by headline sponsor IBM. Here are your hosts, John Furrier and Paul Gillan. We're here live in Las Vegas for IBM Impact. This is Silicon Angles The Cube, our flagship program. We go out to the events and extract the signal from the noise. I'm John Furrier, the founder of Silicon Angles. I'm my co-host, Paul Gillan. And our next guest here is Gal Shahor, with Distinguished Engineer, Chief Architect for WorkLite. Welcome to the Cube. Thank you. So Paul and I were talking on our intro about the mobile policies on everyone's focused attention right now. Talk a little bit about WorkLite before we get into the mobile discussion. What specifically are you doing there and what is the product and how is it being discussed here at IBM Impact? So WorkLite is really a platform that developers use to develop mobile applications. Now we're not talking about games. We're not talking about simple productivity applications. We're talking about enterprise applications. Now what does it mean? It means security. It means tight operations and being able to know what's wrong for your users. It means integration to backend data. It means very efficient deployment of applications and management of the access. So those things are not coming as part of the mobility tool kits that developers are using today. And this is really what WorkLite is providing. Those enterprise things that people need when they serve the applications, either for the customers or internally. It sounds so easy. You know, mobile apps, get a little MongoDB, throw a database behind it. Piece of cake, right? Not really. Come on. So first of all, I agree. It sounds easy. There are 600,000 applications in the app store, right? Anyone can do it. Right. Anyone can do it and very few can do it right. Okay. Very few can get a really high-graded application. Very few can do it with a limited set of resources. Very few can do it with high levels of security. This is really what we're doing, right? You want to make sure that nobody steals the identity of your users. You want to make sure that when there's a crush, when there's an issue with your application, you turn on the flag, you start to collect logs from the devices so that you can pinpoint what's wrong, connectivity to the backend. You want to make sure that it's easy, that it's fast. Anyone can create an API. We actually optimize the access to those APIs. So this is really what we're doing. And what we're doing is really an enterprise scale. So you can actually have 200 million users. We'll do it for you. You can have 1 million users. We'll still do it for you. And we'll do it for you in the meaningful price, right? I mean, you don't want to throw many, many, many administrators, developers, DevOps folks, and so on. That's what we do. Many mobile apps basically duplicate to some degree the function of a website. People do the same things with them that they would do with a website. They look up information. They order products, transactions. What is different about working with the mobile client versus just working with a browser? So first of all, those applications just duplicate what the website is doing are really bad applications, meaning they don't give the user what the user is looking for. So it's not the right experience. It's not, and that's where it starts, right? Unlike the browser, the browser is only working on your large desktop, right? With the large screen, with really good connectivity. A mobile application needs to operate disconnected. A mobile application actually runs on your device and gets installed there. With the website, you can always refresh the browser. With the mobile application, you cannot. The mobile application is installed on your device, not moving anywhere. So things like knowing what happens in the application, things like knowing what's bothering your users. Nobody knows that unless you start to find out, look around what's going on in the app, try to bring it and connect it to your server. If you need to manage the versions of your app because there's a bug, there's a security hole in some version, you cannot do it. In a website, you can do it easily. So those are the things really that make a difference. How can I work with my user that has his really tiny device, want to have the best experience, I want to know what bothers him, I want to manage the application for him, I want to operate the application for him and I really want to do it on a very large set of devices. So it's Android, it's iOS, it's Windows Phone, but you know it's not just one type of iOS. Even in iOS, you have fragmentation. You have different versions of iOS in different Geos, you have different sizes of iPad, different sizes of iPhone, not to mention the fragmentation in Android. So the fragmentation, the disconnected nature, the always installed, you cannot force the user to change anything nature, is what differentiates the mobile device from the website and it starts with the experience and then it continues from there. So you've just outlined an enormous number of factors that impact how you would build an application with a mobile device. Can you provide to work like in software enough guidance to help your customers to make intelligent decisions given all those factors, how do you do that? So the answer is we do not provide, we provide some guidance, but at the end of the day we also provide skills. And what happened is that IBM works with a very large number of customers. We get to find out about a very large number of successes and misses. And at the end of the day this is all getting fed into the product and then into the customer. And I can give you several examples. So what's wrong in connecting to the backend? How can people make mistakes? So initially many of our customers just took their website, the website has less services, right? So they went, took their mobile application, took someone that knows Objective-C and told them, look, go just access those less services. Now performance was poor because the rest services were not optimized for mobile. Security was poor because now there are many ways that they will not talk about how you can break into this type of communication. And we came in, we improved on that and we solved that. So we come up with the best practices that customers can work with and that gets them 80% of the way. The other 20% in many cases is hard work. And what we're talking about is really a development cycle where you develop, you deploy your application, analyze the responses, find out what's wrong either operationally or from an experience perspective and then improve again. All that obviously with testing, with auto testing so that you can actually know that you release something that works and with the ability to report issues from customers. And that's really what we give in work-life. I mean, it's a lot of hard work but when you make it, it works for you. Talk about SoftLayer and how that plays into the work-life strategy. SoftLayer gives you a very robust cloud infrastructure that's global, that has high reliability, response time reliability. What does that add to work-life to make it a more appealing option? So we like to say that mobile drive the cloud and mobile need the cloud, okay? It's being, having a cloud on your side is really important to our customers, really important to us. Because at the end of the day, you want to deploy your mobile backend on a scalable server in a very agile way. And SoftLayer gives that to you across the globe. Now, before the software acquisition, we had ways to provide agile deployment to our customers. But customers really want the ability to go to the cloud, have a different expense model, have a much better agility. And what we do today is we have work-life deployed in SoftLayer. We have two ways to deploy work-life in SoftLayer. One is using something that we call a pattern. You take the work-life application, you just throw it into a pattern engine, and the pattern engine will compose you a deployment on SoftLayer. So think about McDonald's, right? You come in and you say, I want number one, number two, number three. Somewhat similar. Don't really need to know what's going on. Just throw the software in and a cluster is deployed to you. Now that's one option. Another option is to say, wait a minute, I'm a chef. I want to make my own dish. And then you go to SoftLayer, you allocate virtual machines, you put work-life on those virtual machines, or maybe on real hardware boxes, and you operate that environment yourself. So two different options on the public cloud, really good scale, really good results. And that's what we do today in SoftLayer. And probably not to come in the future, but it's really about engaging with our customers, see what they need, what they want, and then improving on what we have right now. So, and if we're talking about the cloud, we also have, you know, Bluemix, right? So I got to ask you about the scale piece, because obviously I just tweeted out there that this is not for your average startup, this product, work-life. I mean, it's pretty expensive. You're talking about system Z integration, right? Looking at some of the things. Well, it's not expensive. So here's the thing. If you don't need systems, if you don't need the integration, and I won't say it's expensive, but... It's a relative term. Yeah, but it's definitely more for the enterprise. I agree. Yeah, I mean, I'm doing, I'm a startup, I'm bootstrapped. No, you start up your bootstrap. What we advocate for you is probably that you go and use Bluemix, right? Now, if you look at work-life, very high-end functions in terms of security, in terms of... Like for a retail customer, right? Someone who's in business, they already have a lot of back-end stuff. Right, right. This is a development platform for those guys. Right, and the operational platform for those guys. I agree. And if you start up, you probably want to start with a premium set of services, like those that you have in Bluemix. You want to start with a platform as a service. You go, you take your back-end, you throw it there, it runs for you automatically. You can actually now start to do push notifications with the cloud. You can store data in the cloud. You have native SDKs, mobile SDKs, that get you started really quickly. So if you're a startup, I would say that's where you should go. You guys look at Amazon, obviously. You look at Amazon. A lot of people go there because it's easy to get up and running. But as a business, that's one that wants to go to mobile. They're looking at a variety of solutions that say, oh, we can just turn your app into mobile. Is mobile a rewrite? I mean, how do you deal with the... Variety of vendors out there saying, oh, no, I got the mobile app platform for you. You can put a wrapper around it, put a skin on it, web response, bootstrap. I think that... I mean, it's not as easy as that. It's not as easy as that. It's not at all as easy as that. Now, the reality is that for most of our customer rewrite, it's not an option. We have customers that invested millions in the website. Right? And now what? So I invested $5 million in my website and it's gone. Not an option, right? So what we do with them is really work with what they have right now and see how we can fit that into the mobile world. Some of it is we have a way in WorkLite to load your website into WorkLite such that you can actually have a mobile application, but significant parts of the mobile UI are loaded from your website. So that's one option. If you go and you use something like screen scrapping technology, you know, hey, I'm going to look at your website and take pieces and make that into it. That's mishmash. Very rarely work. That's collugy. But sometimes if you want to get the absolute optimal results, rewrite. So give me an example of a large-scale customer where you guys have rolled this out that you had success with and or the hot market areas that you guys are doing well in. Like, is it certain verticals? Is it certain use cases? Oh, yes, yes. So let's start with, you know, a large customer. So Minister of Railroad in China. Okay, so think about it. China, railroad, hundreds of millions of users. Okay? So we have... That checks the scale box. That checks the scale box. Now we can talk about verticals where we do well. So obviously banking, financial services, how we like to call it. Many of them are really strong technology companies. Okay? I mean, we look at banks. We don't think about them as technology companies. Many of them are. And they go after the customers very aggressively. So we have a very large number of banking customers who do very well there. And insurance customers do really good there. And retail customers and so on. And you know what? You'd expect that. If you look at the type of, you know, applications that you look, that you use. It's retail, right? It's your banking. That's normally what you do. So we do very well on those. We have also other verticals. That's probably our sweet spot. Gal, I'm wearing a Fitbit on my wrist. And I'm sure it's the first of... Just one of the earliest of a flood of devices that we will see mobile devices will have to interact with. What kind of support are you providing for that in work life? More importantly, how do you anticipate products, architectures, yet not created yet that mobile apps will have to interact with? So that's a fascinating question. So this is your interested device. My device is on the glass. Okay, meaning Google Glass. So these are all fascinating. All the wearables are really fascinating. And it's really a market infancy. We start by testing the worker. Okay, we're not standing outside. We're stepping inside, creating small applications. Work with leading customers, trying to understand what are the requirements. Now, you look at Google Glass. Initially, many of us were thinking, well, Google Glass is for consumers, right? Wrong. Many customers are coming and saying, hey, we want to use it for our employees. We want to use it so that they'll be able to look at something, take a picture of it, know what's going on, and so on. So what we're doing really is, we work with a select number of customers, try to understand the requirements, try to understand what's important for them, try to do small POCs in the lab, and then expand from there. It's a fascinating market, right? We all expect it to be huge, and we're looking at it very closely. You keep saying, working with customers, and it sounds like there is a lot of manual labor involved here. At this point, you're trying to understand the market. You're working a lot one-on-one with customers to help them get through their applications. This must be an expensive market for you to serve. It's expensive exercise, but I don't know any other way. Okay, if you want to help customers, we need to talk to them. You need to find out what the problems are, and that's where IBM is really strong. Working with our customers, understanding the market, understanding where the issues are, that's how we do it, right? Now, I can come in and say, okay, Google Glass, create some SDK, and so on. Will it be really good for my customers? I have no clue, but I have customers that come in, they're leaders, and they tell me, hey, I have this use case. How am I going to do it? I'll take a few people and say, let's work on it together. Let's see how we solve it for you. And from those types of exercises, we can actually create a useful product for our customers. That's how we improve do work, by the way. Yes, what will you be doing with the companies that produce these devices, these wearables, and these sensors? Is part of your strategy to work closely with them so that the customers don't have to do the integration work? So the answer is yes. At the end of the day, yes. But even before that, it will need to be let's work with the customers and find out if this is really an issue. Okay, is this an issue for the customer to take the Google Glass SDK and embed it in the application? If it's not an issue, hey, it's easy for them. Let's help them or it's hard, right? Let's make the hard things easy for them. If something is easy, we need to do it as it is and we go to address the hard part. That's our philosophy, normally in IBM, any work life. Do you find that that currently most of the business that you're getting, most of the work life applications are being built for external use or more for internal use? Well, it's really not, it's not most, it's really 50-50. We have many customers that employ work life for what we call B2C, right? We have a strong consumer application or several strong consumer applications and they use work life to operate them and to develop them. We have a different set of customers and sometimes the same customers that have tens of internal applications and the number is growing and they use work life to serve the internal customer. So both and both have really interesting use cases. From the consumer use cases you get requirements such as I really need the best experience. I want to wow my customers. From the enterprises that serve their employees you get, hey, I have this security need that I need to solve. Hey, I need to connect to all those distant decades. How do you help me? So those types of things and I think that we excel at both. And you mentioned security. We know that with all these different mobile OSes coming out there, security vulnerabilities being introduced by all of them. Is that a problem that you're going to try to solve or is that the OS producer's problem? It's actually a collective both, really. So when you have a security issue let's look at how to live for a second. It's across the globe. Okay, it's not one place. And it's solved by a very large number of teams. And what we're trying to do is to provide layers of defense in IBM. It's not just to apply. It's not just the security access for mobile. It's not just a company such a trustee that finds out about malware and fraud. It's not just MAS 360 that manages the application. It's the collection of those. These are layers of defense. And no, it's not just about the device manufacturers because they did not write the applications. The people that wrote the applications will go and introduce bugs. So we will scan the applications try to find out the security holes. Right? We will go and secure the APIs on the backend so that they'll be protected. A long list of those things that needs to be created and the mobile OS vendors are not solving those and cannot really. They're outside of the reach. IBM is certainly not in the mobile app development business. You won't be selling your own apps outside of something like the conference app here. How should people think about IBM as a mobile partner? IBM actually does several things. IBM gives you cloud infrastructure to run your backend of your apps. IBM gives you middleware so that you'll be able to easily create your applications so that you'll be able to easily operate your application. And then IBM gives you consultancy services. When I'm saying consultancy, it can be a very large set of consultation. It can be really sharp technical folks that get into your shop and help you out. Get you up and running with strategy. It can be business folks that help you out, try to see how mobile can help you. Or can be really developers that can help you out. And then you'll have a application for you. Now, we also have teams that develop apps, but it's not really the final application. They go, they show you the application to tell you, is that good for you? No. I need that to be fixed. I need that to be modified. They'll go modify the application for you. You have your app. So IBM really gives you software product, cloud product that you can use to have your application created for you. Now, we also have a product solution that brings in application, but that's not a very large part of what you do. So it's really a partner for creating the apps. Kyle, I want to get you the final word. I know we're coming up on this segment here, but I want you to tell the folks out there in your own words, why is at this point in time really important for IBM Impact and mobile, and around this enterprise-grade mobile environment. And we talked about earlier about not being that trivial. What's the big takeaway right now here at Impact for mobile? I think the big takeaway for mobile Impact is that A, mobile and cloud connect. B, in order to create the first great mobile experience, what you really need to do is not just create your mobile widget that runs on the glass. You really need to optimize your backend. You really need to be able to quickly modify your application and redeploy it. You need to be able to manage it and redeploy it to find out what your users are doing. That integration of DevOps capabilities, cloud services, analytics, and so on. Those are things that we can bring in in IBM and quite frankly nobody else can. Backend is really important. That's the big takeaway. Backend is 70% of the time and money that people are spending on the mobile application. Great. Thanks for coming in. Really appreciate it. Mobile's hot. There's a lot of nuances in mobile. I mean, Heartbleed highlights it. You know, you're seeing all the security challenges, enterprise-grade, backend support for agile application development. That's the future of DevOps and the enterprise. Thanks for sharing your commentary with us and your opinions. We appreciate it. This is theCUBE. We'll be right back with our next guest after this short break.