 Thank you. The only thing I'm going to correct is I actually don't work for IT organizations. We use IT for IT for business value. Almost all of my engagements I work for the business. And I've got four steps through here. We're going to talk about a brief bit about me so you know whether you believe a single thing I say or not. Then we're going to talk about value. Because value is quite important and often very tricky. We're going to talk about how we assess value and deliver it. So, I'm an able consultant. So, I'm active in the standards world at SABSA and here at the open group. And I own our method at Conexium. And we're a management consulting firm. We work with standards to deliver things for people. We help them change their organizations. That's enough about us. What's valuable? It's an interesting question. We often carry implicitly assumptions of value into the room. We've decided, I'm going to pick on the guy before, that automation is good. It's a value. To who? For what? Where is the value add? What is the business goal that is being realized? So, I'm going to talk a bit about value curves, value propositions, value chains and shareholder value. If we're working with private companies or publicly traded companies, end of the day, that board of directors is aiming at shareholder value. And there's only four ways they can achieve shareholder value. They can increase their revenue. They can increase their margin. They can lower their assets required to produce margin and revenue. Or they can get people excited about them and increase the multiple on their stock price. That's it. Four ways for business value. So in IT for IT, when we're talking about shifting the conversation for value, what is the straight line? What's the path to increasing revenue? What's the path to increasing margin? What is the path to lowering our asset efficiency? And what is the path to exciting our shareholders so that they think we're going to do cooler things? Because IT for IT, if we're talking about enabling business value, that's what we're talking about. What is our IT organization doing? And I'm going to accidentally use the word IT organization because... I'm going to trip over it. What we keep finding at our customers is there isn't an IT organization. If I'm inside the IT organization, I go, oh, there's shadow IT. All these other people are doing it. Almost exclusively when we find shadow IT organizations, it's they exist because they deliver more business value. So which one do we want to get rid of? Which one is on the straight line to shareholder value? And when we're thinking about value, it's very important to think about economic value. We often think something's worth what we'll pay for it. It's actually always worth more. Because if you're investing in something for your business and you're prepared to pay a buck or a hundred bucks or a trillion bucks, it's because you're expecting to get more out of it than you're paying. So the really important thing on a value analysis is what is this delivering? Where's our path to delivery? What do I get? What's my multiplier in there? One of the recurrent themes, and I'm going to provide a personal warning here for people who are sitting inside an IT organization, is don't get confused by cost and value. Classic Porter value chain, primary functions you invest in because they deliver value. Supporting functions you invest in because they lower your cost. In a classic Porter value chain, IT's supporting. And that works really well in the good old days. When your product, when your service wasn't IT based, I like you to think about Apple. Where's value produced? And shipping you my iPhone that I left at the back so it wouldn't interfere with the microphone? Or is it in the iTunes app store? Where's the IT function in that app store? That's the product. When Steve Jobs was alive, did he care about the efficiency? Or did he care about the utility? How many times do you worry that you're damaging utility? You want to know where an IT organization is damaging utility? Go look at a shadow IT organization. It exists to deliver the value. So, value chain, and one of the things that I really like, because I'm an enterprise architect management consultant, and we do stuff here at the open group and there was, oh, IT for IT, cool. New standard, let's have a look, see if we can use it. Flipped it open, started at a value chain and went awesome. This is a thing of beauty, because it has identified for me at least what somebody thinks delivers value. So I read a Porter value chain and it on the far right has margin. You can put whatever you want on the far right. And if anyone ever shows you a value chain and on the far right, it doesn't tell you what the value is, stop reading. This one says efficiency and agility. The definition of value in IT for IT is efficiency and agility. Everything in that value chain on the primary activities had better be optimized to deliver efficiency and agility. Everything on the supporting side exists only to make the primary activities more. Enable better value. I know I'm blabbering here, but this is the critical crux for shifting the value, the conversation to a discussion of value. And it is what is the definition? What is valuable? I'll ask you another question. Who's efficiency? Who's agility? The IT functions or the operational functions in your business? It's not the IT function. Are you lining up to deliver agility to the operational part of the business? Are you lining up to deliver efficiency to the operational part of the business? Back to Steve. Is he fully prepared for extra work to be done in the IT organization if the app store ships when the iPhone was ready to go? What was the definition? One of our major customer segments are capital intensive organizations, people who spend tens of billions of dollars building something so that they can use it. So one of our clients was in the middle of building an oil sands facility, total budget $15 billion. At the same time as they were doing this, they were spending an outlandish $111 million on building and deploying SAP. While they were deploying the oil sands facility, they needed to have a procurement system that would be up and running and managing procurement for the oil sands facility during its build. The only problem was the SAP build could not hit the time frame of the oil sands facility. What's the value? Do I defer or do I deploy a tactical ERP into my oil sands facility? Let's do the math. I'm just going to make you wait one quarter before you can go live and produce 150,000 barrels of oil a day. 150,000 barrels at $100 a barrel and yes I know the price isn't there but the math's easy and up here on the stage the math has to be easy. 150,000 barrels a day, $100 is $15 million in revenue a day. How many days before I get to buy an entire SAP plant? That's right, 10 days. What am I going to do next 10 days? I'm buying another SAP project. So a quarter late is 90 days. How many SAP projects do I get to buy? Nine. So why did we deploy a $1 million tactical ERP that was specialized on procurement management? It was to get that oil sands plant up and running. Now I've now got an IT function that's scattered. I'm in-house and I'm out of house. But what did I do for efficiency? I was able to bring on, we were able to bring on an oil sands facility on time. We were able to put up the functionality that was required to keep the evil vendors controlled. What was our fear? On the business side, two-fold, I'm going to be late. Second, cost is going to overrun. Let's do a 10% overrun on that oil sands facility, $1.5 billion. How many SAP plants do I get to build for that? It keeps adding up, doesn't it? Who gets the agility and the efficiency? And if an IT organization doesn't deliver it, the operational units will go out and get it themselves. So where do we use IT for IT in that story? Building an efficient and agile IT organization that can actually deliver. Agility is the speed of change. Best definition available of agility is in supply chain literature. Agile, if you're able to switch supply sources. I'm buying stuff from these guys and now I'm switching over and I still get to sell whatever it is. I get to continue selling these nifty devices that move the slides along. I can continue selling whatever my service is and I have switched out my vendor. That is agility. Ability to deploy something in the field is agility. We usually measure it in terms of the acceptable degree of difficulty to achieve the change. Why acceptable degree? What's acceptable degree of difficulty to change your ERP? Usually a lot because it's a pain in the butt to put in. The ROI on it's normally zero. So we don't need to be very agile here. Where do we need to be agile? Where do we need the ability to switch? Where can we move it? And efficiency? How many resources are required to deliver the outcome? I can go back to Michael Porter and he talks a lot about in his literature efficiency. And he talks about the productivity frontier. And one of the challenges for a well-run IT organization is they very rapidly achieve the productivity frontier. What is the best in available? It's really hard to continually be more and more efficient. That productivity frontier. Once you have picked up all of the lean best practices, once you have picked up on DevOps, now go farther. So efficiency doesn't give you unlimited advantage because it's also relatively easy to copy. I'm going to pick on Steve Jobs again. When he came back to Apple as CEO, who had the worst supply chain in the technology industry in terms of efficiency, he came back to Apple. And 18 facilities in North America making way too many computers. What did Steve do in 18 months? He closed all the facilities, outsourced it all. And now, instead of Dell being the most efficient manufacturer, it was them. What did he do for his asset efficiency? So when we're thinking about this, when we're thinking about it, it's hunt down what it is that delivers value and value to whom. What are we trying to achieve? Because IT efficiency and IT agility are interesting only when they deliver efficiency and agility to the company. It is recurrently easy to damage the company, chasing divisional efficiency. Whether that division is HR, whether that division is IT, it becomes fascinating when we optimize our organization. I don't know if you guys know the myth about Sisyphus. Sisyphus is a guy who pissed off one of the Greek gods and was cursed with having to carry a heavy stone to the top of a hill where it immediately rolled down and guess what he got to do? Pick up a heavy stone and carry it to the top of the hill. I believe many IT organizations are Sisyphus. They have to carry a heavy burden to the top of a hill. And at the top of the hill, the business changes the rules. Which is why I'm very, very fascinated by the use of agility in this value chain. The ability to change. The ability to change the services we offer. The ability to change our operating model. The ability to change the toolkit used by our services. Because the fundamental nature of our operations, our business, is they need to change. I don't know how badly they need to change. Harvard Business, I think it was them last year or so. I have this working theory. Anything past last week happened a year ago. Because it goes into this gray zone. So in the last year there was a survey of CEOs. What fraction of them thought their business operating model would be fundamentally changed in the next few years. About 60%. So if your business is undergoing a fundamental change in operating model, what's that mean your IT shop has to be able to deliver? Agility. Because that fundamental way of how we construct value in our organization is going to change. What happens when it changes? Well, all those services that an IT organization delivers. So although I talk about working in the businesses, all my examples keep coming back to IT things that are offered. Why? In the good old days you didn't need IT. Life was really easy. You wanted to change your process. You got the people together. You changed the form and the process changed. Now we've automated it. And we've automated it. What changes now? Go ahead, change something without changing SAP. You can't. Go ahead and change something without changing your enterprise resource planner. You can't change something without changing your asset management. Go ahead and change something without changing your digital customer experience. Nothing changes. You want to make an airline better? Probably the one example. You can actually put better engines in. Oh darn. You know how you get better fuel efficiency out of your engines in an airline? You do in-flight operational data collection. And you run a big giant ops center and then commands back to your pilots about what throttle settings to run the engines at. And then you monitor them so that your airplane spies on your pilots and reports to the ops center every five minutes. That's how you optimize fuel. Why do you care about fuel? If you're running an airline, that's about 60% of your cost goes into fuel. So how are we going to make our businesses better without IT? We can't. We use score-based architecture. We use scores on a whole bunch of components, business components, IT components, because we're chasing variants. So I've got an example customer here. They're a public sector incubator in the Middle East. They develop and operate high T-heavy solutions that are designed to remove barriers to local employment. A lot of the Middle Eastern countries that make oil have very, very low levels of local employment. You can go to the extreme case of Kuwait where Kuwaitis, I think, represent 4% of the labor force. The problem you've got right now is that many of those countries have had burgeoning local population growth. So if you're Kuwait, you are now graduating 100% as many young adults into the workforce as there are Kuwaitis employed every year. What are the structural barriers for Kuwaiti employment? What are the structural barriers for other employment? Experience, finding the rules around it, employment. So what we did with this customer is we were looking at how this incubator was how can they improve their ability to deliver solutions. Their value proposition is they were owned by the Ministry of Labor. The Ministry of Labor had them in existence so that they would deliver solutions faster than the Ministry of Labor could do it. And you can think about, you know, efficiency of government, and you can immediately see what they were chasing here. How fast can they get stuff deployed? Well, most of their solutions were IT-oriented, a lot of portals, portals for job opportunities, so that in order to do, to get a work permit for an expat, you first had to offer your job to locals. Why? Because one of the barriers to entry is that locals didn't know where jobs were available because the companies would go hunting for expats because that's how you always employed 96% of the people in the economy, was you went outside the country and got somebody to come in and do the job. And when you're graduating 100% of your labor force every year into the labor force, that's a lot of new entrants. How do you find them? So you start linking together the visa application with job offers. Because you've got a dual problem here. You've got to enable locals to pick up the jobs but at the same time you can't get in the way of your economy because if you get in the way of your economy what's going to happen? Lying, cheating, stealing because the businesses will move forward. So you don't want to set up conditions that create corruption. So, IT functions as a result were distributed. As a startup they decided not to have an IT shop and they went to a series of platform providers to provide IT stuff. And they went, ah, no worries, we've outsourced that and then went and started developing code and deploying platforms and supporting platforms. So what we did, same thing we do for all of our architecture, we looked at the capabilities that were required by the operational units to excel and then we identified the supporting capabilities of the IT function. Build a gap and a roadmap. Our basic model is relatively straightforward. A capability is something that is interesting that you want to improve. If you don't want to improve it, don't talk about it. Because you lose the attention of your leadership team, they can only think about five things. So if your capability model has more than about five things, they stop paying attention. But a capability that requires something that needs to be improved will have a set of processes, it will have a set of software, it will have a set of infrastructure that's required. And we score our capabilities and our processes. Score them by efficiency, we score them by a whole bunch of things. And what comes out on the scoring approach, capabilities, how efficient? One to five. How fit? One to five. How much management control do you have? One to five. Score processes for competency. Is this something we need to excel at or is this something that everybody in the world, as long as we're average? For many organizations, average is good. And in fact about 85% of your processes should be following industry best practice. The other 15% are where you're special. So what are you trying to line up now for? So what we do, we take those 15% of the business processes that the guy is special. Those are the ones I care about. My IT shop had better be enabling them by specialness. And what are the functions in my IT organization that have to deliver it? So for this organization, we identified eight capabilities they needed. They needed to be able to rapidly prototype. They needed to be able to get a design and engineering out and get a product out quick. Because one of the joys of being an incubator is you don't know if the product is going to succeed until it's out in the market. So you put it out in the market, try it and discover whether it's going to succeed or not. One of their first thoughts to enable employment of women in their country was they needed daycares. What they found out was that no one wanted to take their children to a daycare. They wanted a nanny. So that was rapidly prototyped and they discovered the only way it worked was with massive subsidies and the massive subsidies didn't work economically. So get it out in the field. What processes are required? Design and products and services. Test market. Prepare product delivery. Incubator required people to be migrated around. Skill based staffing. The ability on a project to spin it up and slam people into it. Assemble and disassemble the organization. What do you do with the guys who've all been set up to run daycares when you decide to not go forward with daycares? If you can't disassemble that organization, you're in trouble. And managing your stakeholders. Managing portfolio program projects. Because you've got to go back to the Ministry of Labor and explain to them why the pet project of daycares doesn't work. Because somebody knew it would work and they probably read a Harvard study or an Accenture study that said what we need are daycares. Because after all the biggest barrier to developed world participation of women in the workforce is childcare. So we did a broad analysis, looked at the capabilities, looked at it and scored them. There's the scores that came out. Gaps on the top and orange. We always color code so that red is my problem children. So the higher the score, the redder the color. Because those are the ones I have to worry about. So I had a big challenge on all those capabilities for fitness. Then we mapped that back to what the IT function had to deliver. And the part that was really exciting, IT for IT, gave me an end-to-end model of IT. I didn't have to worry whether it was perfect or great. I like end-to-end models. Said here are all of the functional blocks, all of the things you need. So we did the same thing. We scored all of the functional blocks. We identified a set of capabilities that were required. What did we need? Ones on the bottom are from IT for IT. We needed the ability to manage the cost, the finance and to flow back what IT cost. Why was that an absolutely critical component? Because it was tied to the ability and cost of the products that were being offered. So in order to commercialize them we needed to be on top of the cost curve. In order to commercialize them we needed incident. Because that portal for job offerings is the product. Where do the help desk tickets go to? Interesting question. Who runs the help desk? The operational business unit because that's a end customer facing service. So when the portal was down they phoned the business unit. When they had a functional problem they phoned the business unit. Fulfillment, rapid deployment, that fulfillment service. Rapid design, rapid prototyping and project in a box. We needed demand management. We needed the IT ability, the IT function to be very good at managing forecasting and responding to demand. And then requirements management. There's the set of capabilities that came out that directly traced back to what was valuable. Now I'm in a position to deliver agility and efficiency to the business because I know where to focus my improvement effort in my IT function. Now I get to ask all the questions about what's required. Look at IT for IT and it's got the data flow and it's got the functional blocks and it's got the explanation about what's going in there. So you can now think about incident. Where does an incident flow to? Knowing that my product has incident management for IT. How do I build and I'm required now to build a very interesting incident management system. That links four different business units offering 27 different IT based products to an IT shop. That's my problem for value. Deliver that. That's what's going to get me agility and efficiency and business value. The financial flows. The in-house IT organization had concluded, well that was a second order concern. They didn't really need to worry about it. What they really needed to worry about was some operational things. Now we had no clarity of what the cost was of the product. How much does that portal for visas cost? When it gets 90,000 visa applications a week for a company that employs 200 people. Oh, that's right. That visa system is now immediately linked not only to my company but to the Ministry of the Interior and to the Ministry of Labor because they have to grant and approve all of the visas. They don't come? What we got into here? Confidence. Organization needs to move forward and build and plan and change. What is the right thing to work on? Value proposition based capability ignored functional specificity. IT to IT fit in. Focused on the capability discussion. What are the things my IT organization, my IT function has to deliver? Whether it's done by IT or done by the business unit or done by an outsourcer or done by a contractor or done by all four that function supports commercialization. That function supports operation. What are my gaps and what are my improvement targets? Where do I invest in what's my priority? All aimed at value. So I need confidence and change decisions. Because if we're going to pick up the organization and shake it and shuffle it and move forward everybody has an opinion. What's the right thing to do is debatable. Often people's preferences are parochial. They look at themselves and say we need to improve my life. We need to improve what works for me. So path to enabling business value. And I'm very clear here we said enabling not delivering. Because I go back to my quarter value chain. Technology services are supporting. IT functions are supporting. IT functions are an enabler. And value is in the eye of the consumer. What is the economic value of the consumer? What's it worth to them? Because that determines what they want. And as a management consultant what do I get? I get a faster time to market. I don't have to have an argument about what is the functional decomposition model or what are the things I just use IT for IT. It tells me here the value chain areas where I can work. Because all good wheels are round and removable. We don't need to spend a lot of time on the basics. It allows us to focus on enabling value rather than inventing a method of analysis.