 Here's the obligatory slide. My name's Dan Warfield. I'm the principal of CCNC Europe. CCNC has been around for sort of 15 years, but not in Europe. So I'm hoping that we are as successful here as we've been in other places. The main point on this slide really is that I've been doing this kind of thing for a long time. And one of the things I've been doing recently is working with the CXO value proposition working group in the IT for IT forum, which has been interesting. And we've been talking about what is it about IT for IT that CEOs, CIOs, CFOs care about. And there will be a very short slide deck about that, which is currently being vetted, which will become part of the IT for IT material at some point. This is not that deck. There's one slide in here that I contributed that I also included in mine. How does that work? Which is this. I'm going to talk about this from two different perspectives. One is strategic and one is operational. I've got a little cheat sheet that I made here during the previous presentation that helped me to clarify something about IT for IT as it is in practice. And I think this is really important. And if you're interested in IT for IT and following it, you may have seen this as an issue or something to be concerned about or something to work with, which is that there are two kinds of threads. And we saw them in Ohad's presentation. He was talking about using IT for IT as a map against which we would look at HP software products and see how they fit within HP, see how we can take those to customers and talk about how best practice IT and HP software products fit together. I would call that the technology management standard aspect of IT for IT. And it's about, as in the forum this morning, there was more of this. It's about things like how does ITEM talk to configuration management? And going down that path, as the standard will go, we're going to see more things that are useful for, for example, certifying that a tool vendor is compliant. And that's all important and useful. But there's another reason that this standard is attractive, which is what we used it for at Walmart, which other clients of mine, since I left there, have been using it for. Which is partly what we just saw in Sven's presentation, which is what I would call the IT for IT as a technology management standard, as opposed to a technology standard. And the difference is the technology management standard, which is one way to interpret this, is about what is my operating model? If I'm a CIO, if I'm trying to understand how do I run my organization better, how do I understand how to structure things? How do I measure more effectively what we're doing? How do I understand the gaps in my enterprise IT operation? That takes you to things like, where should I invest in changing my process? It leads you to value metrics instead of operational metrics. It's a different way of using IT for IT, and it's the one that's more interesting to me. A question was asked about, why do you use use cases instead of data? And that's an illustrative question. That's a use case. If the use case is talking about technology standard, then the use case of, here's a detect correct use case. Here's a closed loop process is interesting. If you're using it as a technology management standard, then the data comes more into play, because you really do have to have a consistent way of describing what your business of IT is doing. So I'm going to talk about seven things in this talk. The first four are about the technology management standard, about the strategic level, where I think this is really useful. And this is not a technical presentation. But I'm going to go into one of these in a little bit of detail, because I think these are things that CIOs will care about. And based on my experience working directly for CIOs, interacting with them, and having them as customers. And we talk about portfolio management in IT for IT. But in fact, we've been talking about portfolio management in IT ever since I've been doing IT. And I had a lot more hair when I started. So this is not a new concept. Why can't people do this? Why can't we do manage my portfolio of IT services? There's been one cycle after another about how do we do this? Some are more successful than others. This is the latest one. I think it's pretty good. It helps. I don't know what I'm pointing this at. I think using IT for IT as a template for understanding portfolio management can help CIOs to make some progress on these points. One is accountability. If you map your IT services to specific business domains that are about IT, which IT for IT gives you a template to do, you can assign owners to that, and you can start holding people accountable in ways, in my personal experience, that weren't possible before. That's very important. You can't fix it if it's nobody's problem. Nobody owns it. You need somebody's throat to choke, and this helps you to put a name to that. Also, if you organize understanding the investment demand stream into those domains, it makes it easier to understand how to work in partnership within your IT organization. That's also very important, because that often doesn't happen. And finally, another thing that we've been trying to fix for years and years and years that this does help with, if we think about our IT organization like this, is it helps us to get rid of point solutions. And point solutions are the bane. That's why we have 10,000 interfaces, because everything's a point solution. It needs a new interface. Nobody thought about the person next door. It's all about silos. So I've done this. It's not perfect, but it's helpful. How do you get from a project-centric reactive way of dealing with demand to the service model approach? In stages over a few years, but you can do this in a way where you deliver value constantly. What we did was define a domain model based on IT for IT, refactored a bit, extended a bit, translated into language that made sense for our business. And I've done this twice recently. And both of the pictures that went out to the room full of vice presidents are different. Don't look like the IT for IT picture, but they are the IT for IT picture. That's very important. If we filter the demand signals into the right domains so that we understand what people are asking for and use the service model object, and this is the future stuff, if we use the service model object to record the rules around the things that we're building into our IT service portfolio as an IT delivery managed service, sorry, service broker, we will start to be able to govern the value chain in ways that we can't now. Now, in the real world, I've said this to architects. I've said, get started with this. Start building your domain model. Start using this as a template for how to run IT. And they say, well, I can't do that. I'm a trained architect. The first thing I need to do with our level of maturity is make models for a year. I don't think you have to do that. I think that if you start engaging with this as a new way of looking at IT, and this is the value for CIOs, but it has to be led by the CIO, you can start tomorrow to add value if you do it in the right way. I don't know what happened there. I'll go on, but I'll explain what I mean by factory design. One thing that we found really helpful in situations where I've used this that's important in most not very mature IT organizations is that if you have a lot of managers, a lot of vice presidents, whatever it is, each one of them spends a lot of time trying to design their little part of the factory. And that's most of what they talk about because we don't have a common way of talking about value. If we can move to this IT for IT based value chain model and start talking about that, we can move away from what I would call silo elaboration to value delivery. And how does that work in the real world? I've had a role where my main job was to try to keep the room full of the 40 10-year-old vice presidents all on the same page for more than five minutes. And that happens a lot in very large enterprise IT organizations. What we were able to do using IT for IT that we had not been able to do before was to shift people off of constantly doing the same fire drill on the thing that wasn't actually broken and use IT for IT as a way of helping them to understand the traceability from the real problem, which was a data problem in SAP, to the thing that they saw that was on fire, which was a problem in the service management area. Now, there are lots of ways to do that, but the value of IT for IT in situations that I've seen where this does make a difference is that we got everyone to agree. It wasn't done by brute force, by politics, by insisting it was actually. Here's an operating model that we all understand and agree to. Let's talk about where the spots are. And we can see how the data flows through that. So the problem is probably there. And we could do that in a 90 minute workshop with people whose main mode is to argue with each other. That's important. This is pretty basic stuff at the operating model level. We saw some of this in a previous presentation. How do we move from tribal to standards-based operating model? Use IT for IT as as is. Map the IT for IT model to your as is. Figure out where the gaps are. This is basic architecture stuff. Very important to make a new model. If you just take the IT for IT language as it is and the picture as it is handed to people, it's foreign. So at one client that I was working with recently, they developed part of their business transformation, a graphical representation of value chains for things like HR manufacturing that was sort of an S-shaped snake with a series of things in it. So we mapped IT for IT for that, showed it to the business people, and said, yeah, I get that. Can you do that for IT? Yes, we can. Yes, we can. And then we talked about where are the hotspots, where are the pain points, what are the things we need to work on? This is not entirely architecture work. It's also a change management work because when you start to do that, you're going to go back into your IT organization and start making people feel bad. Somebody has the budget for the service manager. Maybe he shouldn't have that anymore. Maybe that needs to come up a few levels. Three or four people think they all own the same thing. This will highlight that, shine a light on it, and you'll be able to say, actually, no. We're going to start doing things a little bit differently. Silo's get broken, people's empires get hurt. You have to be willing and able to do that. I'll come back to silos. This is really important because not in every industry, but in a lot of industries, everything except IT is managed pretty consistently by ERP, by Oracle, or SAP, or something like that. There's a whole school of managers who've come up in the world learning how to use these things. They understand the metaphor. They understand the value chain as a top-level idea. And they understand the implementation of that kind of way of thinking in ERP. And they come into IT and they say, where are the dials? Where are the levers? I can't tell anything about what's going on. By taking the same way of thinking, and this is, I think, very important, and this was raised in a forum meeting this morning, we need to keep that because that gets a lot of traction in the business side of the house. And if you don't have that, none of this other stuff will work. If we start to do this, if we start to move the way we talk about ourselves into a form and a metaphor that's similar to the rest of the business, we will start doing things like including cost and pricing models in our service model. Most IT shops don't do that. That's an afterthought. When you're trying to get the money to build whatever it is, you say, oh, we need to invest $10 million in this. And it'll be really, really great. And it'll give us this business benefit. We'll sell more widgets in Iowa. Nobody ever goes back and measures that because nothing about how to measure that gets built into the solution. By the time it's in development, nobody can tell you why they were doing it, what the financial idea was about doing it, who the beneficiaries are. By the time it gets into production, when somebody calls up and says, such and such a thing is broken, it's not unusual that the person on the help desk can't connect that human being in any way whatsoever to anything in the data center. And then you have hair on fire. You don't need to do that. Also, if we start with a financial understanding of what the service is that we're providing before we build it, then we don't get into charge backwars, which is another thing that CIOs care a lot about that architects may not see very often. But who's going to pay for this thing? If we construct things using this kind of a model so that they're instrumented out of the gate with a usage model, with a charging model, with a clear understanding of who's paying for it and how, a lot of that stuff goes away. And it's a minor irritant. It's like waking up in the middle of the night with something itching, but it does keep you up at night if you're a CIO and you're dealing with that. All of that takes you to talking about services instead of projects. And every CIO who is thinking about what it means to be a CIO who spends all of his time talking about projects would like to get away from that. So how do you get to that? Again, this is an iterative long-term journey, but we can start if we decide to. And again, this is a CIO top-down directed thing to do. It will never arise from most IT organizations organically. Start to include real cost, price, and usage assumptions in every set of requirements. Don't do it unless you can answer that question. Introduce the request to fulfill functionality and start to put some tools in place so that if you get something moved toward production that's actually got that sort of information in the package, you can deploy it on something. And then start to introduce the processes and the standards and the ways of working in development that will allow the developers actually to build a package that you can deploy onto your R2F infrastructure that you can then measure and charge for and also retire when nobody's using it anymore. This is a long iterative process. You can't do it overnight unless you're starting with a blank sheet of paper. And one of the things that is stressful to me because all the places I've been have been big companies with big legacy. And a lot of the interesting buzzwords are about things that you're gonna start from nothing with. Oh, we'll just put everything in the cloud. No, you won't. That's not gonna happen. And in large, mature organizations, you can have 60, 70, 80% of your IT spend is locked down into the technology that it's running on today. It is not imaginable to shove it all into Azure. That's just not gonna happen. And for new discretionary spending, yeah, maybe. But you can't do these things overnight. There is no overnight, but you can intelligently, iteratively, start creating value by going down this path and start to show people how this works. An interesting element of this, and actually something Lars mentioned in a slightly different context, is onboarding. If you think about most companies, every company that I know about onboarding a new person is a nightmare, if it's, there are 10 different IT systems you have to engage with, you have to know that Rob is the one to call about something you have to find out what to do when the person who's in charge of the active directory stuff is sick today. It's, they dump it on the clerical people, they go crazy, nobody cares because they're clerical people. You can fix that by building a onboarding process, using an IT for IT sort of model of what a service could look like. And you can build it in tools that you have, you can build it in the cloud without even having to get an approved change request for your complex data center. And you can show people, if we start to structure the way we think about services like this, then services can be delivered like that. And you can say now, everyone, and that's the strength of using onboarding as an example, everyone can suddenly onboard a new person without all of that aggro. And there's, how did you do that? And it could be in the back. I've been told that when Amazon started, they started with the wonderful front end and you ordered a book and it printed out a piece of paper and somebody went and looked for it. They don't do that anymore, but you can use the same approach with introducing why R2F, as it's described in IT for IT, is a good idea. You don't have to build the whole city at once. The value chain, I keep coming back to you because it's important. Not only is it important to talk about cost and payment and usage expectations when you're doing new solutions or changes to existing applications. If we change the way we talk about the demand stream you talk about end user value, and this morphed into some of the discussions we had this morning about, let's talk about the user experience in the 21st century. It's not what we were working on 10 years ago. If you want me to spend $5 million on this new thing and you can't explain the end user value or the company value, why are you talking to me? Go back and learn more about that. And when you do that, here's something else that happens in big IT. You can start to break this kind of badness. The badness is everybody knows that IT is crap and they take too long and they're not very good. But we have to use them for this. And in order to get them to do the project, we have to send somebody to the meeting. So let's send Bob because he doesn't do anything. He's no good anyway. So he goes to the meeting with the IT guy. They talk about requirements. Bob doesn't get it because he's the one they didn't need in the business. The IT guys build the wrong thing. Bob doesn't even remember the meeting. You give it back to the actual end user who wanted it and it isn't any good. And you keep having this war. This happens all over the world all the time. If we can start going to the business with a more familiar metaphor, the value chain is pretty good for that. If we can start engaging them in a way that is more to do what they're interested in, everyone knows that would be better. IT for IT as a metaphor for how to organize your IT division will help a lot with that. Again, it has to be CIO-led. The starting point for most of us is understanding IT is a set of loosely coupled activities. The goal is to understand it as a value chain. And the method, surprise, you can get out your TOGAF books if you like, is the same thing as the architecture methods that we've all been trying to use and learn about for years, which is to understand the context, analyze the gaps and begin and do a roadmap for how to adjust the way you work. But the way you're working in the subject matter is different, it's about value chains. This is not a technology project. And the CIO needs to lead it. And this is why CIO adoption is so important. If you're sitting in infrastructure sitting, we really need IT for IT because I can see how it would help me to work better. Let's start working really hard on that. You're pushing on a piece of string. It's not gonna happen. These things will start to happen. When the CIO, CEO says, this is a different important way to think about our business, let's start doing this. And it also needs the buy-in of people who are not in IT at all, because if you seriously take IT for IT as a metaphor for delivering value, you're gonna change some HR things. You're gonna change the way that you do financial evaluation of requests for money. Other people need to be buying in early enough so that they care about it and aren't threatened by it. That's a strategic view. It's a little bit jumbled, but I really believe based on my experience that if we take that kind of approach, first of all, we can have a conversation with the CIO that makes sense. And secondly, we have a chance to actually make some real differences. On a more tactical level, there are three areas that are more technology architecture than they are technology management architecture. And I talked about silos before. Everybody talks about silos. Silos are bad at a lower level, but still of interest to the CIO is why do I have all this stuff? And I was talking to a friend of mine whose main business is raising money for tech startups in London, trying to explain to him what I was working on. And I tried some architect babble and that didn't work, but what he understood was in traditional IT, the tools that we used to manage it grew up out of little isolated areas that used to be pretty manual to begin with and they started to become more and more automated. And as the automation increased, they started to touch each other and we started to have to build interfaces. We started to have to have common ways of describing things and it didn't work very well and it doesn't work very well. He understood that because that's not just an IT problem, that's a problem everywhere where things become more complex. In the specific case of IT, one of the things that happens when you do that is you start to get lots and lots of different tools. That's not a secret, I can say at Walmart, we had every service management tool that there is. We had different parts of the company that bought different things. We had the same part of the company that bought different things, pieces. And after a while, that became crazy and one of the things we used IT for IT for by building the domain model of how do we do IT based on that was to say first of all, how many ways do we need to do service desk? And the answer is really one, it's a commodity. We don't need a whole lot of those. How do we stop this too many different kinds of things? We lift the budget up. We lift it up from this manager and this manager and this manager. We bring it up to a person who's in control of the value stream tool budget instead of, and this is where you need the HR people to help you because you're gonna be breaking people's little empires if you do this right. The CIO would like to hear that. They don't like the little empires, they don't know how to get rid of them. They don't like to have 60 tools where 12 would do, but they don't know how to get rid of them. How do you get from decisions made in small teams to functional investment organized during the value stream? First of all, very important, if you're brave enough to do it, is appoint a single owner and give them all the money. They have to know what they're doing or they'll break everything. Then you do your architect work and you say what's the future state supposed to look like in that space from a point of view of tooling? What are the things we need to do? What are the capabilities? What are the ways to do that? And let's start getting rid of the stuff that we don't need. Make some roadmaps, make a plan, think about value year by year. We know how to do this. It's part of your architect training. Something I talk a lot about that I think we should talk more about is data because you cannot do this without a data model that spreads across your space. You have to have a consistent way of naming things, not just on a nice picture like this, but in your level three information model. If it's not consistent, you can't do it. Even an HP, which has been a leader in IT for IT, there's still a long way to go in integrating everything. At least they recognize the problem. A lot of people don't. But you'll never solve this if you have 20 managers in your infrastructure group and every one of them gets to pick the tool and by default pick the data model that we're gonna be used to describe things that matter right across the value chain. I would suggest you need an IT for IT architect to help the owner of that value stream do the right thing, create the right roadmaps, have the right data. I would say that because that's what I do. But you do need something like that. You can't just do it randomly. We've also been talking a lot even today about vendors and Siam and vendor stacks and things like that. IT for IT is not the whole answer but it's part of the answer. It can be part of the answer. It can help you think about vendors. What we have today, and this is a client that I've had that has this situation. They've outsourced their data center, hardware, physical data center to one company. They've outsourced the management of that to another company. They have developers from yet another company. They have network management people from yet another company. They have all of these people, but if you look at the contracts that they've negotiated and signed and agreed, the service levels don't take that into consideration. The service level says services company managing the data center. Here's what I expect to have from you as an SLA for managing the data center. What happens if the reason something fails the SLA is because the hardware didn't work which isn't something they supplied? What happens if the network is the problem which isn't something they're responsible for? These contracts are silent about that. IT for IT starts to give you a way of describing and I like what Lars is sort of recursive view of IT for IT that he was talking about this morning. You're in Alex Fenn's description of the layers that they're looking at in his company. Your IT enterprise operation is actually a layer in a stack of service providers, more and more so in any company of any size. And you have to think about that when you're thinking about how to deal with your suppliers. And if you don't have them all on the same page and if you're not all working to one hymn sheet then you have a lot of problems. This can help with this. So I would say from an IT for IT perspective for the CIO you can use this to map the vendor and in-house landscape that are being used to support your own IT operation as well as the services you're providing without. I think the maturity of IT for IT isn't at a point where it's really, really robust and doesn't give you everything you need to do this but the standard is going in the right direction and there's enough there to work with now. The SIAM work is very interesting. There's not much in the box right now. These things need to converge at some point and they will. But if you have a model of how services get delivered that you can apply to the various vendors that's much better than not having a model which is where most people are today. This is the last thing I'm gonna talk about but this is again in my experience working for different CIOs and people like that. One of the things that we kept doing over and over again without any useful outcome was what should our metrics be? And you have the sort of once or twice a year there's a crisis in metrics. I don't know how many of you have experienced that but they do all kinds of things to try to say what are the things I need to know about my IT operation so that I know what's going on? Where are the dials? What are the things I should measure? And then you form a committee and they have meetings and they make lists and you vet them and talk about them and you agree on something and somebody makes a dashboard and after about six months it's I don't like this dashboard. These metrics are wrong. What should we do? And then you make a new committee and you keep doing this. And the reason is that there is no semantically coherent way of describing what is it that we do in IT? The other reason is that the CIO usually wants numbers that you didn't want last month and won't want next month. That's a different problem. But you can have an underlying set of metrics that people actually care about. I've seen, worst case, a situation where it was somebody's job for a hundred grand a year to produce a monthly PowerPoint deck of measurements of things that nobody has cared about for the last four or five years. They just keep adding it and he was the metrics guy so he would just keep adding stuff to his deck and he'd send it out every month and that was his job. How much value does that add? There are people who will come in and do a benchmark study for you based on industry metrics of various kinds. Okay, that's all good. IT for IT is heading in a direction where we can start to have some standard operating metrics and a byproduct of the way that the model is going. If we can get tool vendor adoption, if we can get company adoption, is that we can start to have an industry standard reference set of metrics. And a lot of the times the reason that you have to go out and spend half a million dollars on yet another external metric study is because the CEO has said how do I know that what you're spending on this stuff is really right because I think maybe our competitors are only spending 80% of that. So you go get Gartner or somebody to come in and do a study, fine, that's one of their lines of business but you're not really gonna learn anything because it's always apples and pears and oranges anyway. But beyond that, if we can get to a standard set of metrics that start to be implemented in tools that most people are buying, then those metrics can start to be automated instead of having to be gathered by some hideous manual process that never sees the light of day, but you know that goes on. The reason that it's a hideous manual process is because it's not standard. So somebody has to cobble all that stuff together. If you automate it in a non-standard way, after about a year, no one will care about your metrics because they're out of date. If we can get to something that's standard, we can do a lot more. Beyond that, if we have a standard conceptual universe for metrics that are without operational IT things, we can start to interest people who are really good at big data and analytics in helping us to understand those things in a way that we don't today. And that should lead to real closed loop improvement of a type that we're not really talking about, usually when we talk about what you can do with IT for IT. What I would do in the short term, first of all, to go in this direction is there are gonna be people in any big IT department whose job it is to do metrics and business BI analytics and things about IT. They probably don't know about this. They need to know about it. They need to get them into the conversation so they can start to own it because otherwise you'll have another turf battle. And you say, well, we got these great metrics from operations. They say, yes, but that's my job. And I have this system that I've been using for five years and it's perfect and go away. And that happens too often. Try to anticipate the metrics that IT for IT in the forum are actually going to start adding to the standard and see whether they make sense in your environment and feed back in. And I would say this is really, we need to get more people into the discussion in the forum and one way to do that is to engage people who care about this, which is one of the big payoffs, in the forum to start being engaged in this conversation about what metrics matter. What should standard metrics really be? And the most important ones are not going to be the ones that we think are nice because we're IT guys. They're going to be the ones that talk about value for the organization and say that without including more end user consumers of some of the things we've been talking about, we're going to fall short on some aspects of developing the standard. So I think most of the people in here will have seen this before. This is another one of our slides from the CXO value step. I'm not going to talk about all these success stories and there are many more. But the things I've been talking about seem sort of woolly and they're out there a bit and they're not very specific except that if you go and find people who have actually used this in anger, whether it be one of these companies Walmart, other places where we can't tell you their name but you can find out their name if it really matters to you, you will find that people are going down all of these paths toward value and value that's recognizable to the CIO level person who doesn't care about the message format from OpenView but he cares a lot about the things that I've been talking about.