 Live from Washington DC, if the Cube. Covering Inforum DC 2018, brought to you by Infor. Well good morning, welcome back here on The Cube. We are live in Washington DC at Inforum 2018. You can tell Infor is just over the shoulder here. We're on top of the show floor looking down and a lot of buzz, a lot of activity out there. Good to be a part of that excitement here in DC. I'm John Walls along with Dave Vellante and we're joined by, he said just call me Selma. Selma Sanderam, who's a CTO at Inforum. Selma, good job on the keynote stage this morning. Thanks for joining us, we appreciate that. And yesterday. Yeah, thanks. Talk about a couple of new products, one launch, one in beta. Why don't you go ahead and tell our audience a little bit about that, about what you're bringing to the marketplace now. Yeah, so we have, as I mentioned in today's keynote, we're all about product innovation and we're engineers. Charles is an engineer, I'm an engineer and we were constantly driving new innovation. So some of the innovation, fundamentally, we want to build what I would call a shared services platform that all of our cloud suites can utilize. There's no need for each of the applications to go reinvent the wheel to build a middleware or a data lake or an API layer. So we built a shared services platform which is what we call Inforum OS. As part of Inforum OS, we continue to release new things. You heard today, we released something called Inforum Go. As the name might suggest, the idea is that you as an employee in one of the customer organization, you want to have easily go to the app store, download something called Inforum Go. It automatically is configured for your role. It gives you, if let's say you're a sales person, it gives you access to CRM data to curate your pipeline. It gives you access to employee data because you're an employee of the organization. Gives you ability to file expense reports because you're a traveler, you get the idea. So in a role, you don't want to be dealing with 20 different apps, it's just one thing. You just go in, one sign on, you get access to everything you need. That's one announcement we made. That's on the technology side. And on the functional side, we launched a new CRM this morning. And the idea there again is that we're in the CRM business not to build a horizontal CRM. Our idea is you build anything you do must be industry specific. When you are selling and servicing an excavator and you are a dealer of earth-moving equipment, you want to know what kind of configuration you sold, what kind of accessories I can sell to this farmer, what kind of terrain they're operating on. That is industry specific. So to us, that is important. That's what we're doing with CRM. We built it on obviously our own platform, technology platform, multi-tenant running in the cloud. But the main differentiation is industry, right? So that's something we announced. We've been on building a next-generation HCM suite, which we talked about a lot yesterday. The final piece of that is payroll, which is important. So that payroll just went better this morning. It's all built on the same exact same platform within 4OS, multi-tenant, and it's highly extensible. So that completes our HCM suite on a unified platform. Those were the announcements we made today. So I wonder if we could talk a little bit about the platform. Last year, after Inform 17, I wrote a blog post and I put up the strategy and technology stack and I kind of missed the OS underneath, so we'll come back and maybe of course correct that. But one of the problems with enterprise software, especially suites, is there are a lot of cul-de-sacs. You go down a road and then you hit a dead end and you have to come all the way back and if you want some other function, you have to go down and come all the way back and it's a very frustrating user experience. So I'm inferring that what you guys have done is try to address that and other problems with a platform approach. So platform, my view, beats products. So maybe talk about platform and what that means to you guys and then I would love to get into the sort of conceptual and actual stack. Yeah, so it is what should be common sense in my opinion that if you buy a HCM suite from a provider of software, you buy a ERP from that same provider. You buy travel and expense application from the same provider. You would think that they all have the same user experience. They would all are integrated out of the box. They all seamlessly work together, but single sign on, that would be a normal expectation as a customer, I would think. But unfortunately, the market's not going that way. Everybody's got their own, even within one company, you have multiple products, they don't work together well. Our idea is that if you buy an industry cloud suite, you must feel like it came from Infor. It all should have one single user experience. It all should work together as an integrated suite. It should all be sharing data for analytics and so on and so forth. So that is the whole idea behind building this Infor OS. So Infor OS has got several services underneath, starting with user experience, which is developed by Hook and Loop. So we have all of the controls, whether it's a drop-down box, or a grid control, or a dead picker, they all behave exactly the same way. Whether you're in CRM, or HCM, or inside a purchasing application, they all work the same, right? So starting with that, then you go- So if I can interrupt, so the Infor OS has the core services that the software needs to access for any function that you're building, correct? Okay, please. So it's user experience, then you have integration, we have one integration layer called ION, and ION supports both an API layer. If you want to build a mobile app, you need APIs into the software. So build a lot of APIs into our applications. Those are exposed through a single gateway. There's one way to get into Infor applications through this API layer. We built that as part of Infor OS. We also built Coleman, which we announced last year. Coleman depends on two things. One, a lot of access to data, so I can crunch and do machine learning, and a lot of access to APIs. So what if you could create a requisition talking to a device versus having to open up a form, right? To do that, you need APIs. If you can order Domino's Pizza from home using Alexa, why can't you do that at work? So we built this framework for those kind of things. So it's got APIs, it's got Coleman, it's got Data Lake. So all of this data is in one place, so you can build analytics. We have Burst, which sits on top of the Data Lake, and it can go on. So that's really what we're doing with Infor OS. It's really very, very important. It's not like you're Intel inside kind of thing. Without Infor OS, Infor apps don't work. So if I can, if you bear with me, just to conceptualize the stack, the OS is at the bottom layer, and then you've got your micro vertical functions is sort of the next layer. And then the cloud, which is really AWS, is the cloud infrastructure. Then you've got the GT Nexus, essentially the network commerce platform. So there's all those data and supply chain connection points that you have access to. Burst Analytics, which was an acquisition last year, and then the Coleman AI completes the stack. My question is, as it relates to, for instance, Burst, that was an acquisition. So you have to bring that in and do some engineering work to make it fit into the stack. Is that right, or does it just kind of bolt it on? No, so everything has to be done with the conscious way of design. So it just doesn't happen by itself. So Burst is a fantastic world-class analytics platform. They have a company built a world-class platform that allows for departmental analytics. So if you're a sales, working in sales, or working in marketing, you can go bring your own data, you can do analytics. It's great at that. At the same time, it's great at Enterprise Analytics, where you have all of this data in one place, you harmonize the data and do that. As a platform, it's a fantastic platform. But we're about delivering content on top of that platform. So we need to bring the network data, like you said. We need to bring the industry data. We need to bring the employee data from HCM, bringing it all together and exposing that using BI Burst as the visualization layer is how we are exposing it. So to that extent, Burst was connected into the data lake. And it sits on top of the data lake, leverages that data. We built a semantic layer, which reflects the model of data that we have in the data lake. So yeah, it does, and we have to get a single sign-on so it actually surfaces within Mingle, within the homepage of a purchasing manager or whoever. And that's work. That's what we did. But you essentially replatform it. But so of course, part of the due diligence is how challenging it's going to be to do that, how fast you can get that to market. But this is complicated. It requires a significant engineering resource on in-force part. We talked about this a little bit at the analyst meeting last year, the industry analyst session. Couple things. One is the integration and exploitation of AWS cloud and all the services there, the data pipelines and the services there, but also modern software development. Microservices and containers and all that other good stuff. Can you talk about those sort of two dimension and any other points that you'd like to emphasize in terms of the things that in-force developers are doing to create this modern platform? Yeah, so first of all, we are all about applications. So we're not building databases. We're not building our own data centers. We're not building our own operating systems. We're a business software application company. Our belief is that if you try to verticalize and try to innovate on every single layer of what you do, it stifles innovation. Why not embrace industry's innovation? Can we outspend AWS in terms of building a cloud infrastructure? I don't think so. No way. No one can. So it's important to focus on what you do best and leverage innovation that's coming in outside the four walls of Infor to embrace that to deliver what the customer requires. So what we really did is we took the AWS services and we encapsulated them into our application. So when the application does disaster recovery, it's actually AWS services, right? When we call Elasticsearch, we're using AWS services there. We use DynamoDB for graphing the data in the data lake, much like Facebook works on OpenGraph of trying to find people who are connected to each other. Data inside the data lake is connected, right? Sales service connected to a sales person. It's connected to a customer. Customer is connected to returns and so on and so forth. So we've done those kind of things. So we built a layer above the web services of AWS to actually create hooks into the application that leverages that. And we built our application itself sort of a microservices architecture. Granular APIs is a better way to describe how we did it so that those granular APIs can be used in a digital project to create your own mobile app or it's the same APIs that are used in Coleman for digital assistant or chatbots. All of those things require clear thought in terms of design, how you expose the functionality and how you expose data and that's what we did. Yeah, so as a developer, an engineering organization having access to those primitives, those granular APIs gives you what, greater flexibility? If the market turns, you can turn more quickly. I mean, it's more complicated, right? But it gives you finer grain control, is that fair? It is absolutely the case, yeah. And by the way, we know that the world is heterogeneous. I would love for a customer organization to just use info for everything, nothing else, right? But that's probably not realistic. So we built this to be able to work in a heterogeneous environment. So creating APIs and having these loosely coupled architecture allows for that to happen. Ultimately, the customer has a choice. We obviously have to work to earn their business but if they have other things outside of info that they're running in their ecosystem, you need to be able to embrace that. So this architecture actually allows for that. So wait, it's okay, the architecture, but if you're saying if I'm a customer and I want to run in the Google Cloud or Azure, technically, at least in theory, you can support that. But do you actually do that today or is that sort of roadmap stuff? Technically, you could do that, right? But we obviously leveraged a lot of AWS services in our stack. What I meant to say in heterogeneity is that if you run a non-info application, right? So like Salesforce for CRM, right? I'd love for the customer to use it for CRM because we think we are very competitive. But if they're running Salesforce and they want to replace that, we need to be able to work in that environment where it's running in a different cloud. It's running in a different architecture. So we built InfoOS and the layer to be able to deal with that kind of hybrid deployment. Technically, what's the enabler there? Is it just sort of an API-based framework? It is API-based framework. It's also got federated security built into it. It's got the middleware understands, Ion understands that data could come from a non-inforced system. As long as you're talking, you go to the United Nations if everybody has a headset to really translate what anyone is saying, versus if everyone speaks English, the world would be wonderful. They spoke English yesterday. I got one more geeky question. Any time I get the head of engineering, the CTO. You love this. We love to get into it. Your audience eats this stuff up. We love the business talk, too. But I've heard a lot about multi-tenant architectures here. My friends at ServiceNow make a big deal about multi-instance, saying oh, and I don't know if it's, if it can't fix it, feature it kind of thing, or if there's really additional value there, but the claim is it's more secure. Multi-tenant, I think, conceptually is certainly more cost-effective. What's your take on sort of multi-tenant? Why is it important? Maybe discuss the security levels that you guys engineer in, your comments. Yeah, yeah, if you have something that you can call it a feature, you can, like you said. But our belief is that multi-tenant architecture allows for faster innovation, easier update to the customer, to keep them current. And you think about having thousands of individual instances that you have to update on a weekly basis, because we will get to a weekly update. We are currently doing monthly update, and we get to a weekly update that requires a natural act to create automation to be able to update all of them. I mean, there's, you know, you could argue which is really more pure, but multi-tenant architecture for us is one single application server form that is able to work for different tenants, understanding their configuration, their business process, and operate the way they want it to be operated, but it is running in one single form that we can update as frequently as we need, without obviously causing disruption. So that is, I think, is a good design scenario. Having said that, we actually isolate the data of a tenant, right? Because you could have a scenario where all tenants' data is in one database. We don't do that, we actually insulate tenants so that data is not permeable. You can't go across tenants. So, we think that this is an elegant way to architect and keep it at jail, and we can bring innovation faster to the customer. So when you go from monthly to weekly to daily to hourly to minute-ly, every customer comes with you, whereas in the multi-instance world, you actually have to plan for it. You've got to plan the migration. You're maybe N minus one, or maybe even N minus two if that's supported, and it's more disruptive. That's correct. And then you've got to engineer the security and other factors. It's a great thank you for that explanation. So, I was about to get back to the end of the day, what are folks doing with what you're providing them, right? So, in kind of like your new services world, your new product world, what are some of the more, I guess, unique ways in which your customers are putting these great tools that you have to work for them that you would like to use as kind of the poster child of success, and say, you know, we're providing this new value and these new enhancements, and give you a chance to take it to others and use them as examples. Yeah, so fundamentally, you know, I'll be remiss if I don't start with industry, right? So, it may not be very sexy, but ultimately, if I'm in a food and beverage industry, I really need to have a piece of software that understands that, right? So, like for example, if you're an ice cream plant, you pay by butterfat content. You don't pay for the gallons of milk you get, right? So, does the software understand that, right? If you don't, then you have to work around it, right? So, it may not sound sexy, but that's important to us, right? So, customers deploy without customization is very, very important to us. That's why we call it last mail functionality. But if you flip to the technology side of things, I think that we're just scratching the surface in terms of what users want to do with Coleman. Coleman Digital Assistant, for example. Like I earlier said about placing a requisition talking to a device. I think our idea is that every single employee of our customer organization should be using technology. Typical ERP, as it was deployed 20 years ago, only power users used it, right? Other people wrote in a piece of paper and sent it around. Same thing with decision support. It was like three guys, two guys in the company who knew it and you had to go ask them to build a cube for you. Exactly, that doesn't scale, exactly. And we're living in a very diverse, global sort of setup. It doesn't work if you have three people who understand how to do BI. Two people who can create workflows. And I always like to use this example of this website called ifttt.com. No, they've tried this or not. It literally stands for if this, then that. If I can go and describe something and if this happens, then do that. Why can't we do that in enterprise software? Why is it that you have to go to stand, knock on the door of IT to do it? So our idea is to bring that level of innovation so we can innovate, our partners can innovate, customers can innovate, we don't step on each other. I got to ask you about a topic that we've heard a lot about this week is robotic process automation. And you guys have essentially intimated, or at least I've inferred, that you've got quite a bit of capabilities in that regard. There's a lot of software robots here essentially to replace humans doing mundane tasks or maybe augment humans. What is the capability that you have with RPA? Is it something that you're shipping today and I have some follow up questions, if I may. Yeah, so we built Ion when we started building this years ago. We built it with the notion of build it on a data-rich architecture. What I mean by that is when something happens an event happens in an application, the sales order is taken or it's updated. Give me a full copy of that document that anyone can understand, right? That is a foundation of what you need to be able to externalize things like RPA. So we have access to the document as things happen. That's point number one. Point number two is that we built the Coleman AI platform, which we talked about earlier today. That actually leverages that workflow as points in the workflow to be able to go and do AI-based services that are hooks that are there in the workflow. So where human beings need to intervene, I'll give you an easy example. How often people reporting to you, I do, we get expense reports that people submit. First of all, I don't even look at them, right? Michelle looks at them. And do you think she opens and actually looks at how much somebody spent for dinner? No, you just push the button and approve. Why are we doing that, right? Why can't a robot figure out, is there something that looks not quite right? Then flag it versus having to do this mundane work. So why can't Coleman do that? That's the way we've done it. And it's because we have a workflow engine, we have the API architecture, we have an AI platform. It's easy to wire these things together and having data externalize allows us to do that. So in looking at the RPA market, there's several companies out there and a lot of software companies, many of which are very, very complicated. You can't get your hands on the software. There's some or maybe one in particular. It's easy, you download it, and it's low code or even no code. So I would imagine I'm envisioning some kind of studio for a user like myself who is not technical, can use it. And then maybe some kind of orchestrator to be able to actually affect what I want done to get done. Is that something that you're shipping today or how do I do it as a user? And is it low code or no code? As an end user, if you are trying to figure out a algorithms to deploy, then obviously you need a data scientist, okay? So that part of it, we have a platform that is available for the data scientist to be able to go look at the data, curate the data set, allow them to deploy different algorithms to figure out which one yields the right result and then deploy that. And when you say deploy, it automatically creates an API and allows for use anywhere, right? From an end user standpoint, like I said, this ifttt.com, you should be able to go in and say, set up your own alerts that if I see, if you see, you know, X, Y, Z happen, let me know. Or if I see X, Y, Z happen, you know, do this, right? So that part of capability exists in the platform, right? So you can't completely replace data science and everything with the real end user doing it. But if you package the services in such a way that an end user can actually pick and choose and deploy, that can be done today. You're an expense report or approval example. And there are many, many others. So great, thank you for that. So thank you for the time too. We appreciate that. Thanks for dropping in and again, great job on the keynote stage and wish you success down the road here. Thanks a lot. I don't think you need it though. I think you've got your act together really well. Thanks. Yeah, you're hands full. Yeah, she do. A lot going on. All right, back with more here. We're live in Washington, DC. You're watching theCube. All right, can I move it? They'll tell us.