>> Live from Washington DC, it's theCUBE, covering Inforum DC 2018, brought to you by Infor. >> Well, good morning. Welcome back here on theCUBE. We are live in Washington DC, at Inforum 2018. You can tell, Infor's 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 Soma." Soma Somasundaram, who's the CTO at Infor. Soma, good job on the keynote stage this morning. Thanks for joining, appreciate that. >> Yeah, and yesterday. >> Yup, yup, thanks. >> So, talk about a couple of new products, one launched, 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, you know, we have, you know, 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're constantly driving new innovation. So, some of the innovation, there's 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 called Infor OS. As part of Infor OS, we continued to release new things. You heard today, we released something called Infor Go. As the name might suggest, the idea is that you as an employee in one of the customer organizations, you want to have, easily go to the app store, download something called Infor Go, it automatically is configured for your role. It gives you, if let's say you're a salesperson, 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, you know, 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, right? When you are selling and servicing an excavator, and you are a dealer of moving equipment, you want to know what kind of configuration installed, 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, which just went beta this morning. It's all built on the exact same platform, with Infor OS, 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 wanted to talk a little bit about the platform. So last year, after Inforum 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 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 then 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 a platform, in 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 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, and are integrated out of the box, they all seamlessly work together, with single sign-on. That would be a normal expectation as a customer, I would think, but unfortunately, the market's not going that way, right? 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, you know, user experience, which is developing a hook and loop. So we have all of the controls, whether it's a dropdown box, or a grid control, or date 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 you need, that the software needs to access for any function that you're building, correct? >> Exactly, yeah, yeah. >> 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 built 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 an acquisition, tucked into 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 Birst, which sits on top of the data lake, and I can go on. So that's really what we're doing with Infor OS. It's really, that's very, very important. It's not like your 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 as 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 all those data and supply chain connection points that you have access to, Birst, the analytics, which was in acquisition last year, and then the Coleman AI completes the stack. My question is, as it relates to, for instance, Birst, 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 is it just kind of bolted on? >> No, you know, so, everything has to be done with the conscious way of design, right, so it just doesn't happen by itself. So, Birst is a fantastic world-class analytics platform, right? They as a company built a world-class platform that allows for department analytics, so if you're 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 Birst as the visualization layer is how we are exposing it. So to that extent, Birst 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 the single sign-on, so it actually surfaces within Ming.le, within the homepage of a purchasing manager or whoever, and that's work, that's what we did. >> So you essentially re-platformed it. 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 Infor's 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. You know, microservices, and containers, and all of that 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 Infor developers are doing to create this modern platform? >> Yeah, so, first of all, you know, we are all about applications, right, 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, right? Can we out-spend AWS, in terms of building a cloud infrastructure? I don't think so. >> No way. >> No one can. And 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 Open Graph, of trying to find people who are connected to each other, data inside the data lake is connected, right? Sales order is 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've 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 in a 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. It's the same APIs that are used in Coleman, for our digital assistant, or chat bots. 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, in 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? >> Absolutely the case, yeah, and by the way, we know that the world is heterogeneous, right? I would love for a customer organization to just use Infor 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 this 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 Infor that they're running in their ecosystem, you need to be able to embrace that. So this architecture actually allows for that. >> So it's 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-Infor application, right, so like, Salesforce for CRM, right? I would love for the customer to use Infor CRM, 'cause we think we are very competitive, but if they are running Salesforce, and they don't 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 Infor OS and the layer to be able to deal with that kind of hybrid deployments. >> Technically, what's the enabler there? Is it just sort of an API-based framework, or... >> 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-Infor system. As long as you're talking, you know, you go to United Nations, if everybody there has a headset, to really translate what anyone is saying, versus if everyone speaks English, well, world would be wonderful. >> But they spoke English yesterday. (John laughs) >> I got one more, I got one more geeky question. Anytime I get the head of engineering, you know, the CTO-- >> You love this. >> We love to get into it. The audience eats the stuff up. >> Yes. >> And we love the business talk too. But, I've heard a lot about multi-tenant architecture. My friends at servers now make a big deal about multi-instance, saying, oh, and I don't know if it's, if it can't fix a feature kind of thing, or if there's really, you know, 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 know, 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 farm 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 farm, 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 agile, and we can bring innovation faster to the customer. >> So when you go from monthly to weekly, to daily, to hourly, to minutely. 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. >> Okay, and then, you've got to engineer, you know, the security, and other factors. Thank you for that explanation. >> So, I always like to get back to, at the end of the day, you know, 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 the chance to take it to others, and use them as examples? >> Yeah, so, fundamentally, I'll be remiss if I don't start with the 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? Like for example, if you're an ice cream plant, you pay by part of a carton, you don't pay for the gallons of milk you get, right, so, does the software understand that? Right, if it 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 for us. That's why we call it last man 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 an acquisition target into 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 on a piece of paper and sent it around. >> Same thing with decision support. There was like, three guys, two guys in the company who knew it. 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 set up. It doesn't work if you have three people who understand how to do BI, you know, two people who can create work flows, and I always like to use this example of this website called ifttt.com. I don't know if you'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, right? Why is it that you have to go to 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. We're talking about software robots here, essentially, to replace sort of 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, right? What I mean by that is when something happens, an event happens in an application, a 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 give an easy example. How often, like, there are people reporting to you, I do, and we get expense reports that people submit. First of all, I don't even look at them, 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 externalized 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 is 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 can, you know, is not technical, who can use it, and then maybe some kind of orchestrator, to be able to actually effect 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, yeah, I'll go to them 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 work, is the right for certain, then deploy that, and when you say deploy, it automatically creates an API, and allows for use anywhere. 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. 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. >> Your expense report, or approval example, and there are many, many others, so, are great, thank you for great. >> Soma, 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, appreciate it. >> I don't think you need it, though, I think you've got your, your act together really well. >> And your hands full. >> Yes, you do. A lot going on. All right, back with more here. We're live in Washington DC. You're watching theCUBE.