 Okay, we're back live here at HP Discover 2012. I'm John Furrier, the founder of SiliconANGLE.com. I'm joined by my co-hosts. I'm Dave Vellante at wikibond.org and we're here with Paul Muller, who's the vice president in HP's software group. We're going to talk about IT performance, IT performance management, very importantly, measurement. If you can't measure it, Paul, you can't manage it. That's what they say, Ryan, absolutely. And there's a lot to be managed and a lot to be measured. So tell us about your role within HP and then we'll get into it. Right, so one of the critical things we believe is that customers always need to perform better. And it's never been more important for IT to be able to deliver consistent, predictable results, secure results, and more importantly, to be able to speed innovation from idea to implementation. I mean, it's such a challenging thing for people to do. My role is to help organizations understand how they can do that, to help them assess where they are today and help them figure out how software, but also people in process can be changed to achieve those results. So is the approach that you have, the solution that you have, is it all in software? Does it start with services? Can you take us through the sort of anatomy of how I engage with HP in this front? You know, one of my customers once said to me, you know, a fool with a tool is still a fool. So it's really a combination of services and software that we think is really important. We really typically begin with a conversation with our clients about where they are today, their challenges, their opportunities, and they typically fall into a number of areas. Help me deliver applications faster, help me secure my existing systems, help me operate my data center more efficiently, help me manage the information that's coming out of it, or maybe help me better align business and IT. Depending on where their challenges are, we'll then build a plan that incorporates both the transformational services as well as the software to help them do that. So one of the big tensions you hear a lot in IT is the misalignment, between the misalignment and the wrong way, but the pace at which business goes and the fact that IT can't keep up with it and the fact that there's so many processes involved. And a big part of that is the application portfolio is so complex and it's growing. That's right. We do application rationalization. I'm sure you have tools that kind of sends processes that can assist in doing that. Where are we in terms of the whole application rationalization? I mean, it's really different cycles and different customers are in different modes, but it just seems to me to be an ongoing process. Is that an accurate observation? What do you see? It's an accurate observation. In fact, we talk about continuous assessment. So understanding continuously, where is my portfolio today? What is in my portfolio? What should be in my portfolio compared to the need that we have? Are there any gaps that we have as a duplication of portfolios? So continuous assessment and what we call continuous delivery. So building those systems, also continuous integration. So building the systems we need to address that requirement and then continuous delivery. So making sure that as the business has that demand, we build it quickly and then deliver it more most importantly. This is no point in having code that's sitting in a system that you've spent money building that isn't deployed, right? That's, you know, technology is a perishable good in some respects, right? If that innovation isn't the market straight away, you're basically giving up an opportunity to a competitor. So in my experience of working with CIOs, they've got, you know, hundreds if not thousands of applications. They know that many, many, many, it's a long tail. So many of them are below the line. They're not used. They know they're getting negative ROI. It's a history museum. Yeah, it's a history museum. They have to support the infrastructure and it's a real matter. And they have a spreadsheet that shows you all those applications on there. Okay, so I'm a CIO. I have this problem. I know my application portfolio is too large. I'm bleeding money on probably two thirds of my applications. Absolutely. But the business lines, you know, don't want to allow me to cut them or rationalize them in any way. So I have to demonstrate, I have to go herd cats and sell the organization on change. How do you help me do that? So the couple of things we do, I mean, the first and most important is getting that inventory. You know, one customer said to me, our organization never met an application they didn't like. They've pretty much got everything there well. I know several of those. Yeah, and there's a lot of duplication of functionality. So first of all, you want to discover everything that's there. The second thing we do, once we've discovered that and you can mechanize that process, you can automate that. That's what we do with our software is you want to map those applications to the business processes that they support. It's critical to understand how does that app relate to the business process? Because then you can answer the most fundamental question. How much duplication do I have? How many ways do I have of booking a purchase order? How many ways do I have of posting an HR entry of hiring a new employee? And if the answer is more than one, unless there's a very good reason that's more than one too many, if that makes sense. And then what we do is we basically map value. So what is that business process generating in terms of value for us against the cost of that application? And we can again, automate the process of discovering the cost of that application. And you pretty much build an ROI model for you that pretty much tells you, this is your low hanging fruit. This is where potentially it's going to be not cost competitive to change those apps. So a lot of organizations most don't have that map between the linkage between applications and business process. And that's what we do for them. So you help build that through services and your software, right? Again, the software helps, but also the services too. And then the other piece is a lot of organizations have no idea what they're spending by each application. Correct. Okay, so you're, again, software and services help them do that. You go through and figure out what the costs are. You figure out how it's allocated. So it's a cost allocation. We basically automate the forensic accounting process of saying, okay, what does the general ledger look like? Mapping that to the infrastructure and that infrastructure obviously maps to the app. And once you've got that triangulation, you're able to pretty much tell everyone what an app cost. I should be clear here. It's not just the infrastructure. It's also the people cost. So for example, how many trouble tickets are we getting against an application? Is my old legacy app soaking up a ton of time? It's the full cost model. Absolutely. And you got to deal with CapEx and OPEX and Capitalism. And then how about the value piece? How do you quantify value? Well, quantify value is by mapping it to the business process. If we understand the business process, you can typically understand, for example, let's take quote to cash. You typically know what your quote to cash system is generating, right? It ties directly to, you know, your general ledger. So we essentially take all of the business process. He's mapped the value of the business processes that are transacted over that. And then you have a very simple sum. Cost, value, one subtract the other, and you put an ROI. It's pretty straightforward. Boom, you can see what's below the line. And there's another element that's critical to that too, which is risk. So when one analysis we did with one client, we discovered that they had a high value business process that was sitting on infrastructure that was running on, in this case, it was actually Windows 2000 to be clear. And as we know, that platform is no longer supported in the sense we'd think about it. Mission critical app running on unsupported infrastructure, usually a high risk situation. It pretty much cost justified the upgrade of that application almost instantly. Paul, I want to get your take on big data. So we had Kim Stevenson earlier from Intel, the CAO giving her definition of what she, from her view of big data is. It's not small data. And the opportunity. Yeah, I think it's not small data. But she used an example of how they're using big data in manufacturing with the waivers and collecting all this data. You're asking the data-driven business because you're using a lot of data. Absolutely. So tell us what your definition of big data is. Because you must have no problem putting the big data value properties together because you're in that mode of putting understanding performances. So tell us about what you think big data is and what it could do. And then give us an example of areas that in the processes you're looking at that can benefit the most from big data like analysis. Well, there are two applications to big data. I'll talk about it in the context of business value generation and then how IT can use big data principles. Because machines are thrown off data. Splunk is so in the public. But any users are with mobile devices. But apps are a big workload. Absolutely. When you talk about workloads of apps and it could be mission critical apps to production, non-production, they're generating a ton of data as well. So all that's going on. So that's going to create a draining data for your job, right? Absolutely. Are you running around collecting all the data? Well, that's one of the challenges. If you're a CAO today, your biggest problem is that every one of your teams is collecting a huge amount of information. And the signal to noise ratio is not great. You've got a huge amount of information but you're not able to bubble that up to a business care about. And you're the CAO. Do you want to walk into the boardroom meeting saying, well, we had less than 1% network jitter on your report. It's an important metric if you're a network manager but it's certainly not important to the business. What we focus on with our IT performance suite is collecting over 170 different best practice key performance indicators. Bubbling that up into scorecards that can be tuned to different roles within IT. So if you're the head of operations, creating a scorecard, not the whole 170 or a subset of that, it might be 12, it might be 20, that matter to you in the context of the business. Likewise, if you're the head of applications, as you mentioned, what does my lead to delivery time from idea to implementation? How much technical debt have I accumulated in terms of code that hasn't been deployed? Those sorts of ideas. Each of them can collect KPIs that are relevant and most importantly, do that in real time. I think the important point about big data from our perspective is you can't afford for that to be a lagging indicator. It's got to be real time. It's got to be real time or near real time. So talk about the structure versus unstructured in context to your focus within IT because a lot of times with big data, the benefits are things, questions you don't know what to ask and that's kind of the unstructured side. The structured side is pretty much you got it all and then wired up and you're watching instrumenting things. What are you seeing out there in IT that is new opportunities for getting some of these unknown data sources and weaving it into the performance management suite that you're providing? It's a really important one. We always talk about this technology. We talk about layers one through seven. The hardest thing to manage is actually layer eight. People, biggest problem. We always talk about management tools and we're a software company. We're talking about management software but we actually found through our research roughly between 90 to 95% of your time is actually spent outside of using management tools. And you think about it, it's pretty logical. You were sitting with the business, you were sitting with your team members and especially if you've hired a lot of millennials, they tend not to work in structured management tools. They tend to use things like Skype and Google and search tools. They use social media to get their jobs done. The problem is you lose that other 90% of the day. You've got 10% in the structured information tool. The rest is pretty much an upgrade. Yeah, you're seeing Facebook's a time weaster. Absolutely. Well, actually, you know, I had one client who actually was using it to actually foster communication between different members of the development team. So they're actually using it as a business tool. My point is this, all of that information is lost to the IT manager. They don't know who their MVPs are. They don't know how they're solving problems and when those people go, they're taking that data with them. Because the siloed apps really aren't addressing that user experience. And more importantly, we're not integrating social media principles into structured IT management tools. And what our philosophy is with our enterprise collaboration tool, which we just really, in fact, we announced in November, is bringing those techniques, like email communicator and other social media tools, integrating that seamlessly with IT management tools, so people don't need to change the way they work, particularly millennials don't need to change the way they work, but you still have the advantage of structured plus understanding the value of unstructured, basically getting that other 90% and bringing it back into your IT organization. Give us a feel for the level of a scale one to 10, 10 being fully understand that dynamic. Within your customer base, how would you look at that? Are people at a five or at the average now? When I say average, I understand in that dynamic that, the prefabricated apps and the measurement systems, are you managing your environment relative to the people problem? How aware are they and their level of sophistication? I found it varies by country and it varies by market segment. In fact, it can even, so market segment in terms of industry vertical but also size of organization. It really is a maturity discussion. I'd say on average, we're probably looking, certainly in the Americas, I'd say we're probably at a six to a seven. There's a conscious understanding of the gap with most of our clients. They're not there, but they know they're not there. If I go out to other markets, having a conversation with some of our Chinese customers just yesterday and they're saying, we struggle to actually cost justify this with the business. Even our business sponsors don't necessarily see the value of having those metrics available yet. So they're at a three and four but they understand that they need to invest forward that they're actually struggling to cost justify this with the business that that makes. So what's your top three indicators now in IT performance measurement that you're looking at? You mentioned people's that number one is like, when you go, when you pull those dash, roll that up to the dashboard to the executives. Yeah, what are people measuring? There's, I mean, again, it will vary by organization goals. So we tend to find if, for example, your biggest business problem right now is cost reduction, your metrics will tend to reflect that. What's my capital efficiency of IT? What is my variable cost component of IT? Can I decapitalize IT? So you'll be very focused on cost. If you're in a high growth industry right now, particularly in the oil and gas segment, in the mining segment, we're finding this hyper growth, they literally can't put enough infrastructure down quickly enough, time to market is absolutely huge for them. And we're seeing in heavily regulated industries, of course, security and compliance is probably one of the highest priorities for customers to measure. So one of the big challenges you always hear about vendors love to give these stats as do consultants, the 70% of the IT investment goes to running the business, 30% goes to innovation. So our companies, are your customers looking at their IT investments as business assets? Are they looking at a portfolio approach? Number one and number two, can you help them look at the new initiatives, not just the existing install base where they're spending all the maintenance money, but can you help them model out what the business is going to look like if they apply different initiatives and help them prioritize those initiatives based on those business goals? Yeah, and I think that is actually a primary focus for our clients. One customer said to me, you know, deploy early, deploy often. They're biggest challenge right now, especially as IT becomes the predominant differentiator for an enterprise. Whether it be their web portal for transacting with their clients, whether it be their ERP or CRM systems for maximizing customer return, the challenge then becomes how do I take that idea and get it into the market as quickly as possible? And they're competing with cloud organizations which you'll know yourselves often deploy multiple times a day seamlessly. When was the last time Facebook or Google or Flickr upgraded their applications? The answer is 10 times a day, right? IT organizations need that level of agility and mobility. They need to be able to innovate, deploy early, deploy often. And that change takes place both at the people level and it also takes place in terms of trying to connect or break down silos because really IT and delivering IT is like a workforce, like a manufacturing production line. And if you think about what happened in the production line process, right? With the ideas of Kanban, the ideas of integrating different elements of a production line, we want to do the same thing with IT but you need to connect to systems. Yeah, I mean, we're seeing a lot of that agile message around the programming, around the Facebook examples. Totally relevant in fact. We're tracking, we just launched a new publication called DevOps Angle. Yeah, one of my favorite topics. So talk about DevOps because, you know, obviously we think it's really important because now developers have to essentially have that ops mentality, Facebook, they don't have an ops division, it's all engineering, right? So that is a foreign concept to an enterprise. I mean, they're shooting arrows at each other, right? The ops guys say, hey, it could never go down, right? And if you're a developer, you live by failure. Code's trace. Yeah. You debug it. It worked in the wind tunnel. It worked in the software. What do you mean it crashed? Well, that's software. You got to write code and you debug it and you iterate, rapid iteration. You can't do that in operations. I can't say, oh, oops, I'll just reboot the systems. Yeah. So is it ops, dev, DevOps? Share us your vision of DevOps. Well, and it's interesting. And there's one other group that's been left out of this discussion, unfortunately, which is security, right? So my view of DevOps is very simply this, is that it's not about dev and it's not about ops and it's not about ops being devs and devs being ops, it's actually about bringing the two groups together and in fact, adding security into that. The key here from our perspective is changing the way those two groups interact. The critical to this is we need to design for manufacture, right? Think about the way IKEA works today, right? Versus carpentry of times old. If you've ever done carpentry, you know, it's a very old craft. You need to learn a lot of principles, a whole bunch of tools and every output is slightly different in a unique way. Think about IKEA though, right? They've basically taken the concept of carpentry and building furniture and democratized it by designing for assembly. And that's what DevOps is essentially encouraging us to do. Take the operations team, make them part of the design process. It's the IKEA IT strategy. That's how I call it IKEA for IT, right? It's really simple, self assembly. Because we, you know, the business especially is used to this idea of consumerized services. They don't want to learn the arcana of all of this, you can avoid that, but you need to move the operations into the development requirements process. It's interesting, you like that? Yeah, absolutely. It's interesting, you look at the whole answer. And the security guys need to be there too, because they're like, Dr. No in most organizations. So I was, can I, No, why is that? Well, because we might introduce some risk, right? So unless they're in the process as well, there's no point in being agile in getting through like a release a day or two releases a day. Only to find the security guys that are saying, well, we're not going to deploy anything until we put it through a six month security test, right? I mean, you're balancing speed and execution with basically compliance, drag. You know, know that security changes. You're absolutely right. We're seeing the whole SOA, service-oriented architectures coming back in this kind of module simplicity approach. My opinion, it never went away. I mean, really what we're seeing is interesting is the maturation of that concept. And more importantly, it's been put into practice. It's just lost, you know, API's had a similar movement too. It was APIs were all the rage, and all of a sudden just hit a point where it just really, everyone's using RESTful APIs for everything now. So you're absolutely right. Now, I actually would argue that, you know, it's like TCPRP. We don't talk about TCPRP versus NetWare anymore. It's just part of the fabric. I think we've forgotten it just simply because it's so prevalent in the marketplace. Have you been following Node.js at all? Have you been following Node.js JavaScript on the server side? To be honest, now I haven't actually been following that closely. It seems to be an IO performance indicator for developers, more front end developers, no JavaScript. Oh, sorry, now I'm familiar with it. You're talking about JavaScript on the server side. Yeah, for that rapid IO. So that kind of, all these new development techniques are bringing developers into that ops environment. Yeah, absolutely. I'm so glad you mentioned that, because I think the other thing that CIOs need to be conscious of. And this is a CIO issue. We talk about DevOps, but it sounds like it's a dev issue, an ops issue, and it's a technical thing. I actually believe DevOps is a CIO level issue. I couldn't agree more. Get the kids to play nicely together, right? Unless the boss. Because you think about the CIO objectives and you think about DevOps. Thank you. That matches perfectly, right? Absolutely. We talked a lot of CIOs about DevOps ago. It's kind of a new term to me. What is that again? More importantly, it sounds geeky, right? So they're like, I'm not interested in this. But you're really basically saying, you know, in order to get the teams to play nicer together, the only person who controls the basically the paycheck of the ops team, the dev team, and the security team is the CIO. And, you know, I've got a saying, right? Which is, you know, people will behave tomorrow the way they got paid today, right? And unless you change their measures, unless you change the stimulus, and the only person who can do that's the CIO, you're going to struggle to get DevOps. Is that who you predominantly sell to, the CIO? From my perspective, I spend most of my time with the CIO and their direct reports. And my message to them has been for the last three years, maybe even five, actually, we've got to get better at playing nicer together. And to be fair, all of them recognize it. Their frustration is often that their scorecards are misaligned. They're a legacy issue. They're optimized locally, rather than being optimized systematically. Yeah, we've been saying, David and I have been saying, how should score, you know? I mean, it's really a team effort. And if you recognize that you're all up to have achieved the objective, it's not about, that's not my problem. It's your problem. It's so true. But that's great. Well, we appreciate your insight. My final question is, what do you see? I mean, you have a good view and good vision. You have a good understanding of what's going on on the bleeding edge. But also you understand clients that are kind of, you're rolling them along a little bit. Come on, let's go a little faster. Pedal as fast as you can. What's next? What do you see around the corner that people aren't really talking about right now these days that's peeking around the corner that's going to be our next discussion conversation? I think maybe the discussion that's not being had at the moment certainly is what I call the new heterogeneity. I think we are living in a time of, it's Cambrian explosion is the way I describe it, of innovation. There's so many different new technologies. You've got no JS, a term that probably didn't exist about six months ago. You talk about, look at the no sequel movement. Memcache, CacheDB, there's a whole bunch of technologies that developed up there. Ruby, PHP, I mean, half the time I'm not sure where the people are making terms up during conversations. I mean, there's that much innovation going on. But if you're a CIO, you're an IT leader, it's not like you can say, well, let's just leave that out, right? Let's not do that. Let's standardize on one or two things because you're basically closing the door to innovation. So the challenge becomes how do I embrace massive heterogeneity without increasing complexity, cost, and risk? I think that's the debate, probably for the next two or three years. And you bring up the labor issue, too. That's the next generation talent pool. So they're the ones who are going to be working. You better believe it. I mean, they're all being educated in these new technologies. All right, Paul, excuse me. Thank you very much for coming to theCUBE. It was a great segment. Pleasure to meet you. Great pleasure being here. Okay, we'll be right back with our next guest on SiliconANGLE.tv theCUBE right after this short break.