 So, thank you for coming to this session and a little bit about myself. I used to be an enterprise architect and I still think like an enterprise architect. My very first open group conference was in this building, as a matter of fact, probably in this room. And when I came to the open group in 2006, so it was my first meeting, I think 2006, 2007, it's kind of fuzzy. But I came here searching for the, for business architecture, by the way, when I was an EA and we had a lot going on and I have to say it was kind of an interesting scenario. I came in, it was a track meeting kind of like this and I waited for the business architecture meeting, which was like the third day or something like this, sat down and they decided that we didn't have anything to present, we couldn't agree on what business architecture is. So I'm glad during this conference they finally got a kind of a new published standard and that's kind of a neat story. Taken ten years, but it's there. But IT for IT strategist, I'm in the R and D organization at HPE and having that enterprise architecture background gives me a different perspective. I don't act like a vendor. I think like an IT person and when I first found the IT for IT standard, I just recognized it. It's like one of those things, you see it, you think about it for a few minutes and say, yep, that's how everything kind of works or should work. And that's it. The rest is sort of history. So this is my journey through this learning process, applying IT for IT as a tool, as an enterprise architect with multiple customers of ours to solve problems. There's going to be five, I've increased this to five case studies because as a vendor, although we helped create this new standard, we're not using it ubiquitously yet and I still get three or four requests internally to educate teams and to go and work with other BUs. So I thought that was worthy of a case study, a short case study discussion as well. So these are the ones I'm going to be talking about. Some I cannot rename and some I can because there's public knowledge or these presentations are already out there in the domain so you can go get them yourself. So these are who I'm going to cover. So with that, my situation, when I came to HPE about four years ago, I was new to this organization and we were large. We grew through acquisition, lots of different vendors that we've acquired over the years and we have hardware, software and services, if you want to look at the macro size of HPE. Very complicated. What I found out, I used to buy tools from vendors, so I used to be on the buying side, right? So I know kind of how that works and what I found out when I got to HPE that one does not just simply buy IT software from us because we're big and it's gotten a lot more complicated to identify how does this fit into my ecosystem. Not only that but the connections between the different pieces of software to enable the value streams and we don't call them that yet until IT for IT. There's a lot of tangling, right? I think Rick you talked about, it looks like spaghetti, right? How things are all glued together to enable work and why because you have a transactional need to connect something right now and then but then you forget about it and then you add another transactional need to connect something and after a while it's just a bit of a mess. So people don't spend money on IT software readily and not only that but you think about the budget, right? The IT budget is really to enable and to create business services not to create IT services that you use to facilitate the creation of business services. So that budget is a very small, miniscule part of the overall IT budget. So people just don't buy stuff off the shelf like you would candy and that's difficult in a company our size and a company with our complexity, you know, I remember going to my first few customers and saying which HP are you and I found out that we were so siloed right that even within the software organization we had different sales motions and I needed a way to express the whole portfolio and I'm an enterprise architect at heart and if I can't put it on one page and explain it then it's probably not a good story. So the very first engagement that I had where I started to pull IT for IT into the picture as a tool was an unhappy customer. It was an engineering customer of ours and we have a balance of trade situation. We use their engineering tools in manufacturing stuff that we sell to the market. So there was a bit of a balance of trade and as a result there's a very high level relationship between that company and HPE executives. And that was back in the 2013 is when I first saw IT for IT and when I got the courage and I got the sort of the knowledge and I guess confidence to use this in an engagement was around the end of 2013. And that was the result of an escalation and that escalation kind of went like this. Customer bought a lot of tools because of this, you know, dynamic between these two companies, right, they bought all our stuff and they were very angry. They were at a point, so they said, you know, we've bought everything, we've listened to you, you know, your different teams and we've integrated the best we can, we're not seeing the value from the tools that you sold us. And as a result, you know, because this is what we did, we said, here are the tools, good luck. There was really no guidance, there was no way of explaining how everything maps together. I equated to selling you a thousand part puzzle without showing what the picture looks like on the cover, right? So figure it out on your own, good luck. HP's reaction was not good, there was a lot of executives that basically responded. And we started looking internally to how can we better do this, right? And IT for IT was sort of the part of my answer. The solution was, you know, they brought myself in and Mr. Brancato, some of you folks might know him, my fellow EA culprit. And we just pulled in IT for IT at that point. It wasn't called IT for IT, I think it was still ERP for IT, we still hadn't branded it, it was not a standard yet, it wasn't in the open group yet. So it kind of predates a lot of the activity here to kind of nominate, normalize it. And engagement kind of went like this, a lot of whiteboard drawing to kind of figure out what are they using? How is it connected? Kind of just diagnosing the situation. So as we went through this whiteboarding exercise and gathered information and as a result of a two-day workshop, we were able to kind of categorize using IT for IT and take note of all the different tools that they had bought in the different categories and took lots of notes that we were able to go back later and sort of rationalize what is this current state really look like? Why is it they're not getting value from what we sold them? And what's really going on? So as we went through this process, we had the data and what we ended up doing is taking all that data and just mapping it as the backdrop. I think Rick, you mentioned this earlier today too, it's the backdrop. So we just used the backdrop. This is the original, by the way, the actual IT for IT standard changed some of the namings and some of the components. So it doesn't look exactly like this now. But this is the raw result from that effort. And so with that mapping, we were able to identify certain things that weren't connected right and also where things in their environment should have been removed long ago, but they were still there sort of creating noise, bogging them down. And out of this came very specific recommendations. The CIO in this case was dealing with everybody asking for money funding and he had no way to mediate that or to rationalize that funding request against where do I really need to spend the money. I call it that root cause analysis and where that root cause is. Don't whack the mole, let's kill the mole, right? That's the idea. And in this case, this organization had our tools, they already had them. Remember, this balance and trade, a lot of them use, most of the tools that we have, gave them access to everything. We implemented a lot of these things, but we didn't give them the guidance. And so based on this analysis, we were able to identify that they had all these monitoring tools connected directly to pagers. This is very tactical, mind you, right? Down in the left, right-hand side of the framework. But none of them were going into their BSM system. What that resulted in is a pager storm whenever an event happened, right? A big event that had a lot of impact, hundreds of people get paged and they all responded and it was just a war room situation. So but they had the tools and they just didn't use them and basically wire the tools that they had together properly. And the IT for IT framework gives you pretty clear instructions on how to do that. I equate this to an Ikea instruction set that allows you to connect things properly together so that you can get the value out of it. So this is the actual recommendation we had. We, the CIO in this case, we went through four workshops. This is kind of back in 2014 when we finally went to the EBC. We had an executive briefing at the result. It was about six months, I guess, span over those different workshops. And the customer was, as a result, well, one more view. This is interesting because we did this repeatedly for the different value streams. And when we did this, we found out the hotspots in each value stream where the problems were occurring for that particular value stream. And what the CIO, again, it was just waiting. It's a waiting process. Where is my real biggest problem, lowest hanging fruit? And where do they need to, sorry, where do they need to make the investments? And I'm sorry the numbers didn't come up for some reason. But the corporate priorities we also mapped down to each of the two value streams in this case that we evaluated. And so we were able to zero in on the one step in the value stream that had the greatest consequence and greatest value for them to invest in. In this case, it was diagnosis. When they have all these events, they can bring it to centrally and they can diagnose problems faster, get rid of the warm room situations, at least mitigate them, and increase their risk profile. And actually make that much better. Of course, you don't have to wake up 100 people, 1,000 people at night, people only the person that needs to get woken up gets woken up. So that was the recommendation, I gave this view to the CIO. A year later, I came back and it was still on their wall and they were penciled in dollars and people's names, a few things were scratched out. But this became his sort of high level strategic planning template for his team, which was kind of cool. Okay, so that was the story number one. The result of that really was the customer was now happy. No more escalations, the software team was able to move forward. And these are the three key value sets, right? The expectations as to how the software is all supposed to work and how IT is supposed to work was now set. They had the picture on the front of the puzzle box and they knew exactly which areas of the puzzles to build next. And then they have the logical prioritization process because we found the root causes and we were able to help drive that. On our side, of course, we were able to not deal with those escalations anymore. And after we got through sort of the pain points of where we were, we saw more business as a result. As a vendor, if you don't deliver and service what you sell, doesn't matter who you are, what industry, people won't come back and buy if they're not happy. So we kind of turned a really negative situation into a positive situation. The next one is Mr. Chris Genoine from Safeway. This is a situation where the organization was already kind of embedded inside of the, we were in there, we were helping Chris automate a lot of the functions that he was in charge of. And this basically takes us into the mid-2014 timeframe. And when we went through there, we looked at a lot of their, I'll show you lots of detail on this one too, because he's published this. After we went through the process and we presented our rationalization results, he presented this twice, once at Discover Barcelona in Europe, and then again in Las Vegas. And this is key to remember the Las Vegas one, and I'll come back to that in a moment. So after we kind of got to his value proposition, we were able to present the story a number of times. So their situation, shadow IT competition, this need to kind of automate. And Safeway was actually going through this merger with another grocery chain called Albertsons. So their IT situation was going to get worse. It was already, they considered it bad with all the duplications and things that they had that they should have gotten rid of with that merger. It made it much worse. This, right by the way, are excerpts from Chris's presentation. So I gave this twice, so I know it pretty well. So this just gives you a little bit of a metric on his environment at Safeway. This is again, pre-merger, but it gives you a snapshot of how things work, pretty large complex environment. They used IT for IT in this case to rationalize the tool sets, very similar, but they were much larger than the first example. They saw lots of redundancies and also lack of management of the specific functions so that they had a bit of a sprawling situation. And what they did was, when they brought in IT for IT, it became more than just a rationalization. They saw it as a new way of working and automating things. Gave them that backdrop, that template which everybody was able to kind of focus on the areas to automate and rationalize. Yeah, there's a lot of things internally for them. The big thing was there's a lot of organizational fear to kind of go through this process because it was kind of top down, sponsored in this case by the CIO. There was a lot of financial impact we actually were able to. We spent about six weeks with them, with their financial organization, doing the numbers down to the end detail on every software license and every server which equated to power or cost in the data center. So we did some really, I would say, detailed analysis on the impacts that going forward and rationalizing the portfolio looked like. This kind of details out the whole thing. But 74 different departments, 120 people and lots of data. And again, we had to go through that data, so it sounds exhausting. But what we found was people were calling the same thing by different names. And just by interviewing all these people, we were able to find tons of tools under people's desks, like these one-offs that folks either downloaded and they ran from a deployment perspective or monitoring or whatever. There was just a lot of stuff under people's desks that were operationally dependent on, but nobody really even knew. And of course, there's a little bit of open source in there and license software. So this is, again, you guys are familiar with this. This is, again, an older version. It's a little bit newer than what I showed you, but a little bit older. I think it's 1.3 version. The emblem is sort of predating the open group takeover of the IP. And this is what their environment looked like. So we plotted and we documented all the different tools and when you looked at it in a graph like this, what stands out? You got, for some categories like monitoring and deployment, there's a heck of a lot of tools. That's a lot to manage, a lot to pay if you have multiple vendors in the mix. And what we did was we mapped that to the IT for IT, it wasn't version 1.2 on this one, we mapped it out to 1.2 and then we found out where there was issues. Too many things and even areas where they didn't have a tool. That was kind of interesting cuz they weren't automating some functions that could have been automated better if they just bought something there that was specific for that purpose. The result, this is another way of looking at their data, which is very interesting if you look at it by product. So this is a value, this is like a high level dollar evaluation against vendors and the different functions along the way. And you can see who bubbled to the top. I'm HP, this is Rabbity kind of bubbled to the top in this case. To me, from an EA perspective, I'm just there to figure out and help them sort out the mess, right? We figure if we are there having those discussions, some opportunity will come up, maybe not this year, maybe not next year. But eventually we're having a discussion and we're improving the operations and therefore we might actually show up on that radar at one point. But these are, I would say, the biggest spend areas, right? That we identified. You can see how many different vendors, it went way down into the list of individual suppliers. So that was Safeway. I don't have any specific numbers, I can't share that with you. There was a lot of money identified in terms of savings out of that process, but it was extremely beneficial. The next one is a large retoil organization. And this is kind of interesting because back in 2013, this organization was the very first organization I actually did present IT for IT too. I didn't do much with it, right? I didn't actually stay with that company and work with them on a day-to-day basis. It was more or less presented it and walked away and did other things, right? They were pretty competent. And what I found out in 2015, end of 2015, was that they did some pretty miraculous things with IT for IT. They changed their entire operating model for their IT shop. So what I will show you is sort of what came out of that. What I learned and they started to communicate to their vendors that they wanted their vendors to map their stuff to IT for IT. What is it for? Why is it there? Can you qualify that? And this is basically what they did and they internalized it. Just similar to what Rick talked about earlier, they internalized it and they created their own sort of view and branding for IT for IT. And you'll notice that build and acquire was changed, right? It used to be just build. They said, we don't want to just build our services, we want to acquire them too. And they added an executive direction layer, which they said that's really their strategy process. And then a support layer, which are also very similar to what IT for IT describes. So they changed it around, they mapped it to what they actually are doing. And another piece of information about this, there's a little bit of feedback that did come in. While I was supporting, once in a while I would get a call from this company, they would ask a few questions, Mark, what does this mean? I'll explain it to them. Or if I didn't know what that function meant or a certain element of the standard meant, I would ask some of the peers, right? The folks that are in this room even and say, hey, where is this function? Why isn't this represented in the standard? And get some good answers. And some of that feedback in that dialogue, even though they're not here, they're not public. That feedback in that dialogue still came through me and you'll see there were some changes made in the standard as a result. So some of the lesson learned, okay, is that we may not know the use cases that are happening now that the standard is out there in the wild. I think the best stories are still to be discovered, to be honest. But this was a very interesting one. And I think it was, it took two years to kind of see this kind of result. But it shows you the sort of the value and how it got institutionalized within companies. The next one is my buddy Jody at FedEx. And this is a very interesting story too, because it mirrors what I just stated. So just a little background here. FedEx happened to be in the audience when Christian and I and myself presented at Discover in 2015. That's a little over a year ago. And just like you guys, right? In the audience, we may not speak, we may not meet. I mean, I don't know who you are. You'll leave today and you're on your merry way. FedEx, that was FedEx. And when we were canvassing customers or people to speak about IT for IT at the Discover conference, they raised their hand and said, yeah, we could speak. And everybody at least at HP kind of looked to each other, it's like, did you work with them? No, I didn't work with them. Did you work? No, I didn't work with them. Who are they? What did they do? No idea. So in preparation for that conference, we got into what do they do and it's kind of interesting. And actually, I like what they did. This right here is from their presentation at this year's Discover a couple of months ago. And I only took a few pieces of their slides to share their story. But this is sort of how they started the conversation. And Rick, this is your spaghetti. This is their picture, right? I call this a scare diagram. It's really the whole thing on one big diagram to show you how messy it is and unorganized it is. But this is their IT environment. And they know that they need to modernize IT and they needed to move faster, more aggressively. And so they picked up the open group stuff. They referenced it here in their presentation adequately. And as a result, they created this. So they branded it as well in FedEx colors. They took the basic concepts and they put this conveyor belt looking thing around there to represent the service model backbone and the back and forth nature in fluidity of the model, right? Because nothing's a silo, but you have to have structure and you have to know how you're moving back and forth. And so this is really nice because, again, they personalized it and they made it FedEx. Now, underneath the covers, they know it translates to IT for IT and you'll see that in the following slides. So some shared function is what they did was each of the areas they kind of personalized it. And you'll see down in the bottom, they have the KPI management parts of it and they have kind of personalized some of the key functions. But in the plan side, you'll see some correlations there. And they even introduced Gartner's bi-modal perspective in that planning, right? How much are we spending on mode one versus mode two initiatives? And so this is their presentation and I thought it was wonderful. Because now it was in their language but it was the same structure underneath. This is their build view and DevOps was another big part of their transition and how they were evolving. But the idea is build and they want to deliver those new capabilities. Deliver, once they have a catalog of course, that's where they actually are able to measure consumption. By the way, deliver I would say is the big disruptor in the entire value streams and entire IT for IT standard. And why that is? Most organizations I talk to, they have plan, build and run. They have no such thing called deliver. Their shops are organized by those three things. So deliver is sort of a new thing and I think this is an area where, and I'll explain how FedEx sees it and this is where you can deliver those commoditized services in an automated way. And this is exactly what FedEx kind of shared and I'll share some of their stories. But deliver is the disruptor and this is where I think IT for IT makes a big difference for many of the shops out there that I've talked to. And run, no obviously this is a pretty straightforward value stream. But I do like how they've structured this and they put the different functions around the center, which is a very nice way to describe the fluid motion. And of course the measurement goes back upstream because that's a part of the input for all the other value streams. So that was really cool. Uh-oh, my monitor went blank. No, looks like it was a power glitch. It's up now. So I have a lot more slides on the FedEx side that I can share with you. But before I kind of get into my last use case, just wanted to share, well, maybe I'll just rewind it. I wanted to share sort of what they were talking about. There was one really key use case where they had a service in the catalog and it needed to change. And they needed to change quickly because apparently they had an event in which people were bringing things into the event that needed to be checked in. And they had no such service in the catalog to provide that kind of capability. And what they did was because they automated all of the tools from requirements to deploy, they were able to go through and in one week, change the service and get it out in the catalog, which people then started using. So they only used that service and that adaptation for a week. And then once they were done using it, they killed it. And I think that's the epitome of where you can go when you automate and you look at the different value streams and how they interoperate. Because the business needs to move that fast. There's an opportunity, and if IT is sort of holding things back, right? They can't meet the opportunity and the business can't really grow or be dynamic. And so his story was really, I think, profound to talk about how these key functions integrate and facilitate the value stream so that they can get in there, do their thing, and get out, and put things back on track. Cuz stuff happens as everybody knows. So the last one is sort of a bonus, metric, a bonus use case. And the reason I, it's a bit of a bonus and kind of interesting cuz what I'm finding, the people that are in the room creating these standards aren't necessarily the people that adopt them. Even in the companies you work for. So it's a hard dynamic, but it makes sense in a way because I think what you're doing as contributing these standards is, you're taking all the knowledge that you have and vetting it with other folks that are in the room. And then you create the standard and we're all adopting. I mean, even the people that were in the room creating the standards for years are still in adoption mode. And now that I was in pre-sales, all these experiences that I shared with you were kind of on that customer facing sort of role that I had, just applying and using IT for IT. The role that I have now, being an R&D, is to help shape the HPE portfolio to adopt and apply the same thinking to the products and services that we sell. So we've gone through a process of evaluating our portfolio. So this is the latest diagram. And for, in this case, strategy portfolio level two. And what we've done is we've actually mapped our portfolio to it to see, functionally, what is our coverage? If we don't have coverage, is there a third party that can cover the space? So when I go back to my customers going forward, I don't have to start from scratch. I have a reference implementation and a diagram that I can follow to say, my logic is very simple. The sales guys that are out there talking HP, if they wanna sell things, they've got to talk in an IT language. And an IT for IT gives them that context, that language. And what we're able to do now is communicate the products that we're selling in an IT language, an IT language that you understand. And so some areas we don't have products. We have to use third parties. We don't do everything. We like the thing we do, but nobody does. And then anybody read the news and the rumors and see some of our last couple of years, we're getting smaller. So we're gonna be doing less anyway. So we're gonna have to figure out what is our core competency? Where do we focus? And where do we have and maintain our products and services? And where do we actually partner and use third parties? So this for us is kind of a really a key step for some of the things that we're doing and how we engage our customers going forward. The same thing down is done here for requirements to deploy. So we've got our picture here. And interesting story, I wanna stop on this one. This is request of Phil. If you're not familiar with the standard, it won't take long. You've got books in the room. This is a request of fulfill value stream and how we've mapped it. The neat story here, our own adoption story. There's a product on here called Propel. This didn't exist, what, three years ago. It wasn't in our software portfolio. When we were going through this process of creating IT for IT and seeing how this knowledge came together and what needs to happen in IT shops to be successful. We had a little bit of head start by having this consortium and then before it became a true standard. And we ended up saying, well, there's a product that our services folks had created. Let's bring that over and we basically hardened it as a deployable product. And it was the same name, Propel, just a different use case. And it covers these boxes, right? At a very high level. So we were able to kind of look inside and find out, what do we do? What do we not do? Is there an opportunity to cover some of these functions? Cuz the market needs it. You'll also see one that's not covered called usage. You can guess, I don't have to communicate where we might be investing, right? You might know where we're gonna be investing by looking at a view like this. So anyways, that's our high level internal story. We're still going through that process of implementing some level of governance, some level of analysis, some level of vetting. Making sure our leadership is making the right decisions to kind of map what we do to what you do as an IT shop. It's that simple. Makes sense? Okay, there's my pop up. Forgot I had put that in there. It's so propelled, yeah, new product for IT functions. And I'm just gonna zip through there. I'm not here to talk about our software. Just know that it's mapped. We know what the heck we look like against this. And this is how I present my use cases to customers today. When I go to talk to people, my job, I don't sell them software. I'm not a great sale. I can't sell anything. But I can architect stuff and I can use these great assets. IT for IT to kind of talk to customers about what they do and don't do. And do these kinds of rationalization and transformation exercises. Functional maturity, very similar to that engineering company I talked about. And from there, because you have a set of dependencies, you know what you need to do for second, third, right? So the roadmap planning process is naturally just emerges. You know where your biggest issues are and you know where your root cause issues are. And then last but not least is this new IT operating model. I think that's really kind of exciting. That's the part that I think is very transformative. It's the lack of that deliver value stream that has caused many businesses to source their own services in the market. Because we haven't paid attention to how they like the services, how they don't like the services, what services are commoditized that need to be in the catalog for everybody to get to. We just don't pay attention to that. We're not a storefront like Amazon. But that's the experience people want. People inside our organizations, right? They want an Amazon experience when they're engaging with IT. And we don't give it to them today. So they're gonna go find it. So the IT operating model changes are actually pretty profound. And I think that's gonna be where most of the, I think value is. Other things are valuable too, a bit more tactical. But operating model is, I would say, the biggest opportunity. And so here's a mapping to some of those assets and some of those things that I talk about. And that's all I have for the prepared session. So any questions? No questions? Maybe I have a question related to, because here you see how IT for IT can be used as an instrument already to basically get an understanding of your current landscape and where the tool rationalization opportunities are. But what is the next step? Do you see, for example, another aspect of IT for IT is the data model and the way components can integrate. So you have map, for example, the HP products to the functional components. But did you also do some work on the data model? So where is data mastered? And how can we improve the data governance of IT management? Yes. Or insight? Yeah, so there's a lot of opportunities, I think, to leverage the data model. Now I wouldn't say I've done a lot of that work in the field because there's a level of detail that the standard still doesn't provide. And I've used, they call them the main functions, they used to call them activities. I've used those activities to assess whether you're meeting those functional criteria within there, right? So for example, if you look at enterprise architecture, it might say to be and what if analysis, right? Are you doing that? And most organizations will say, sometimes someone will say, yeah, on spreadsheets, right? There's an opportunity to optimize and automate some of those. But that's kind of where I'm using it right now. I would say mostly it's the functional correlation of stuff, right? What are you doing functionally? How are those functions integrated right now? The data model, I think once we actually specify that into a level of detail that you can verify, right? It's very valuable. The one use case that we've actually implemented is Incident Case Exchange, which is we've come up with, we have multiple incident management systems. Even with HP, we have redundancies. And with those multiple incident management systems, we've identified how do I map them together? What if you're the supplier and I'm the consumer of a service? How do I integrate my incidents with you? You're supplying me a service, right? When I see an incident with your service, how do I integrate that seamlessly? So we've gone through an exercise of applying it for some of those use cases. But yeah, the standard needs to evolve a little bit more to get to that level of detail. Yeah, maybe another question that Rick was talking about as well is the governance around this case. Maybe we talk now about a tooling landscape map to the IT for IT reference model, but during the discussion of, let's say, Safeway had a thousand management tools, how many were there? Over a thousand management tools. So then you have a discussion who owns them and if you're starting to rationalize, let's say you have two development tools and the Java teams like this and another team like that. Did you also have those kind of discussions of creating ownership and who decides what we continue to use and what can we rationalize? Well, you can see we spent six weeks with them. You know, 74 somewhat different interviews, right? A lot of people. We had to discover that because they didn't catalog or treat their IT applications and tools like the rest of the business tools. But they are. IT is just one other aspect of the business, like HR or finance. We have a different mission, different job, but we don't treat the tools like they are part of the rest of the organization. So in that case, yeah, we needed to do the investigation.