 Hi, this is Dave Vellante. We're back at SAP Week at EMC 42 South Street in Hopkins, Massachusetts. EMC has brought in about 200 of its customers and some of its partners, including SAP. We're here with Mike Harding, who is a senior architect. He was on Project Propel. We love to call this the dog food segment. Because we're talking about SAP, it's sort of a high level senior executive crowd. We like to maybe call this drinking your own champagne, Mike. So thanks for coming on. I appreciate your time. Absolutely. So you are the senior architect technical lead for the whole Project Propel. So talk a little bit about the scope of what your efforts involved in that regard. Really what we're trying to do is take an SAP, let's say, heterogeneous application stack and figure out the best way to make it run on top of a VBlock. So SAP, as we know, has a series of products from their old ABAP-based applications to now the Java-based applications. And now you have the newer business objects type applications. How do we fully virtualize all that with these heterogeneous stack on a common platform was really what we were trying to focus on and keep it 100% virtual. So let's talk about the before breakdown, what that looked like, and we can talk about the after just from a configuration and technical standpoint. What did it look like, the as is, as sometimes people call it? Right, so highly customized Oracle-based application. I think about 2 million or so lines of code, I believe. And really what we're trying to take it to is completely vanilla, change the business process to run on top of SAP. Let's not customize SAP. We've got to stay on the upgrade path. That was one of our core principles of the entire project. And in fact, that's something that we're working on right now quite shortly after Go Live is we're already working on an application upgrade to keep us up to date with all the latest and greatest technologies from the SAP product standpoint. And so you're running on Unix, right? Red Hat 5 or Red Hat 6, actually, now throughout the environment, primarily. So Linux now, previously it was Unix or Linux? Previously it was Unix, yep. OK, so you had kind of a proprietary Unix system. You've migrated to x86 Linux, is that right? Correct, yep. And so the applications are supporting today, how many users? Today we have around 10,000 to 12,000 users. And again, that's across not just the ERP space, but also analytics and planning and consolidations in some of those other products. So am I to understand that prior to the migration to Propel, it was really focused on the core application? You weren't doing the analytics piece of it. You've now brought that in? Correct, a lot of the analytics, there were some analytics capabilities in place that quite frankly we had to kind of sidecar. We had to figure out the best way to get data into that existing analytics market, or sorry, product suite. And in fact, that was one of our kind of core design principles of how we best leveraged SAP BW, was really as an extraction layer into that analytics space. But then along the way, we had to bring on our own operational type analytics. And that's where we used not just BW and business objects, but we're also leveraging HANA as well. OK, and so the Oracle environment was not virtualized, correct? The Oracle environment actually was, well, sorry, we have an existing legacy Oracle environment that is virtualized, the previous one was not correct. OK, so now the SAP Propel environment is virtualized, correct? You're running on x86 virtualized? Absolutely, yes. All of our databases, all of our SAP dialogues, even some of those one-off SAP products, things that are memory-intensive, such as the search engine tracks, such as live cache, all 100% virtualized. So a lot of customized code, you had to migrate that code. Did you have to freeze the code? Yeah, we did have to free. Well, let's say we attempted to freeze the code, right? OK, so you were sort of gassing the plane, filling up the plane, fueling the plane while it was in flight, which is dangerous. So talk about that a little bit. How did you manage that complexity? Well, we had a core design principle throughout within our development community that was absolutely no enhancements whatsoever. Granted, we had to make a few exceptions to that along the way, but really it wasn't that difficult to pitch this, because there were a lot of pain points involved with what the old system looked like, the fact that it was barely getting through quarter-end closes due to the level of customizations, due to the level of code that we put in there ourselves. So going with that really vanilla principle for our propel project was not that difficult. OK, so basically you said to the lines of business, look, we have to stop servicing new requests. Now, things like compliance you probably had to deal with, but new functions, we're going to freeze that until we go live with the new system, right? Correct, or unless we could take advantage of it based on the SAP products we bring brought to us. But we really did try to focus on a one-to-one. One of our kind of going-in principles was crawl, walk, run, right? So let's take what we have, convert it to SAP, and then we'll move into more of a, we'll take more advantage of the SAP capabilities, and that's why it's so important that we now stay on the upgrade path. So as new capabilities are being produced by SAP, we're bringing them into our environment such that the business can make use of them. So talk a little bit more about the infrastructure that you're running on now. It's x86, so what is it? It's VBlock, so obviously it's virtualized, you've got Cisco UCS in there. What's the back-end storage? EMC. No, I know it's EMC, but is it VNX? Is it Symetrix? Is it all of the above? VMAX, VMAX. It's VMAX, OK. So you've got the highest performance storage that you have using Flash in there? We are using, well, we're using FAST4 to support both our EMC and our BW databases at the moment, so FAST, you know, the FAST basically where it goes between Flash and Fiber channel, et cetera. What we did was we allocated some of that FAST to both, again, the ECC and BW databases, so that's your ERP core and the analytics piece. OK, and you're using HANA, so HANA's an in-memory database, as many of you know. There's not a ton of installations out there, but it's been around for a couple years now. Talk about HANA, what you're doing with HANA, what kind of value it brings to you, what's different from a business value standpoint. So really, one of the keys to our business model is the ability to kind of react quickly at the very end of quarter when we gotta get products out the door, right? That's really all falls on kind of operational reporting. Within the absence of HANA, our operational reports had a lot of latency to them, and we're up to two or three hours in some plants in terms of what the business needed to make key decisions on how they were gonna close the quarter. HANA basically enabled us to throw some of those reports into that kind of real-time operation, what we refer to as an operational data mark, really. I refer to it as HANA as a sidecar, and we've been able to kind of position a few of those key reports on to HANA, bringing down those response times to about seven or eight minutes. So talk about that a little bit more. So you've got end of quarter, you've got sales guys, booking business, you're trying to figure out what gets built, what gets shipped, how to prioritize that, how to make sure that you're maximizing customer satisfaction, your financial performance, and that you can actually execute on all this stuff so the employees don't all walk out the door. So did I, first of all, get that right, and talk a little bit about how the new system is helping you do that? So yeah, so exactly what you just said. I mean, really it's, we're focusing on kind of those operational key decisions that have to happen at the end of quarter. We also are, so it's really kind of manufacturing floor-type decisions. We also are, however, leveraging HANA to support some of our financial decision-making, not so much right then at end of quarter, but shortly thereafter, as we're getting ready to close the books and such. Now talk a little bit about the virtualization aspects of this. I know early on a lot of people were concerned about the virtualization tax. Talk about the performance of the new system relative to the old system from a user perspective. What are they seeing? So the last quarter or so that we had on the old system, the thing almost fell apart on us, right? And on this, now, yes, we are fully virtualized. Our response times are, right in line, what you would see, let's say it, I would say more of a well-performing SAP shop, about one second dialogue response time, across all of our dialogues, across all of our applications. So we are fully virtualized. The end users, some of their key, like sales order processing type transactions, which used to take upwards of 20 or 30 minutes, I believe, are now down to just a couple minutes. So I'm gonna ask you, Mike, the action item question that I asked Kate before. And I'm gonna ask you to focus in on, you know, you're talking to the CTO. It's a technology integration issue. And I know there are many, many, many that the punch list of this project must have just been enormous. But from a, what's the gestalt of technology integration from a high level? What advice would you give to CTOs out there trying to go forward with a project like this? Skill sets, it's all about the skill sets. So one of the things that we had going for us as a new SAP customer, there are a lot of SAP customers out there who have developed a lot of ABAP type skills from a development standpoint. For better or worse, there are plenty of, let's say, not very proficient ABAP skills out there. We had a really healthy core of Oracle developers here at EMC, those Oracle developers know exactly how code should operate inside a database, how to best maximize it. They're able to really kind of translate that skill set into the ABAP layer. So the ability to, I think, to leverage your existing skill sets as much as possible, we have another example with our common integration cloud, or sorry, our application integration cloud, where we took an existing skill set based across a suite of VMware tools and leveraged them to basically support an entire new middleware product that we effectively home grew. And you had to bring in new skill sets as well around SAP? Yeah, that's why I'm here. Okay, and so what happens to all the Oracle skill sets? Do they get retrained, or do they get reapplied? How's that all working? Right, so exactly, like I just said, we're able to translate a lot of those. So from a business standpoint, I mean, business key decisions are gonna stay the same, right? But at a technology standpoint, some of our best ABAPers right now were probably the best Oracle developers only three years ago, right? So they've been able to, because of the intimacy that SAP has at the database layer, they were able to translate those skills rather easily. Awesome story, Mike. Thanks very much. Really appreciate you coming on theCUBE. It was great to meet you. All right, everybody, keep it right there. We're back with our next guest. We're here at SAP Week 42 South Street, Hoppington, Massachusetts at the EBC. We'll right back.