 Please give a warm open group welcome to Lakshmi Malhotra. Hello everybody, it's a great honour to be actually standing here and speaking about IT for IT. So, as Steve mentioned, I've been associated with the forum for about two years and am leading the development of the IT financial management stream. So, today in terms of the agenda, the way I'm going to structure it is I'll be first talking about how the business scenario is changing IT. So what are the changes that we are seeing in IT since the business scenario is changing so rapidly. Then we will get on to what are the challenges that CIOs are facing in running their IT organisations and managing the expectations of business. We'll then move on to what is IT for IT. So I'll do a deep dive into what is IT for IT, what is it that the forum is building, how is it that it will help US practitioners as well as vendors. So we'll do a deep dive into IT for IT. And then we will also compare, so Steve touched upon it, but I'll briefly touch upon how IT for IT compares to other standards because there's a lot of questions that come in that how IT for IT compares to ITIL specifically. I'll be covering that and then in the end we will go into that if IT for IT needs to be implemented, how do you go about implementing IT for IT or what is the method you should use, methodology that you should use for implementing IT for IT. So if you look at this slide, what we're basically trying to say is that the business is expecting the IT to be more effective and efficient. So typically the way IT organizations have worked and somebody raised a question in the last session that they work as a support organization or they worked as a shared service organization. But what with the changing business scenario, what business is expecting IT to do is to be more effective, more efficient and the business is expecting that CIOs need to be business leaders. So CIOs need to run IT like a business rather than like a supporting organization. But if you look at any IT organization, the CIOs typically have focused on fulfilling the needs of business. So what you would have seen is that the business says that okay, these are my demands, this is what I want you to fulfill and the CIOs are busy actually meeting the needs of the business. But they have no time to look at the internal IT organization. So the analogy that I like to usually draw is that the CIO is like a shoemaker. He has the worst shoes. So if you look inside any IT organization, you will see that the way CIO has been managing his organization is not the optimum way. So if I take an example, within a large IT organization, you will see that there are a lot of IT management tools. So there are different departments. There's a development department. There is a strategy department. There's an operations department, a support department and all these departments have basically been working in silos. And for each of these departments, there have been different tools that have been implemented. So the development department has been using some tool for requirement management. Somebody else has been using the testing team has been using some tool for test management. The release team has been using some tools for release management. Similarly, the strategy team is using some tool for investment management. And the support team is using something for incident management, problem management. But these departments do not talk to each other. So these tools do not talk to each other. So the way it happens is that these departments have built in their solutions. They need to talk to each other. The support department needs to talk to the requirement department because the defects need to go back to the requirements. But there's no integration between the two. So what has happened is that there are point to point integrations that have been built in within the CIO organization. So the tools need to talk to each other. The defect management tools needs to give some feed to the requirement management. But there is point to point integration that is there. And it is a sort of a spaghetti. So yesterday there was some reference to spaghetti by one of the speakers saying that within the business that IT services, there is a spaghetti organization. But if you look at the IT department itself, it also has a spaghetti architecture because all the IT management tools do not talk to each other. And there are point to point solutions or there are point to point integrations that have been built between the two. For businesses, so if I look at businesses like a manufacturing, there's an ERP for manufacturing. But there is no ERP for IT. So for a CIO to run his organization starting from strategy to build to deploy to run, he needs a lot of tools. He or she needs a lot of tools. But there is no ERP for the IT organization. There are point to point solutions or point to point integrations that are built between solutions. And the issue that happens because of this is that today if the CIO wants to know that what is the value a particular system is providing to business, there is no way he can determine that. So what would typically happen is that there will be one person from the CIO team who would go and pick up data from 10 different systems and create a report which says, okay, this is a value this particular IT system is generating. So there is no visibility for the CIO to ensure what is the value that a particular system or the value that business is providing to IT. There is no common reference architecture for standardization. So every organization has done it in their own different way. So if somebody is using a PPM from one vendor, a project and portfolio management system from one vendor and an incident management system from another vendor, they have built their own integration. And they spend a lot of time and money to maintain this integration. So if HP comes up with another version of PPM and BMC comes up with another version of remedy, they again need to basically change the integration or they need to spend time and effort and money to rebuild that integration. So there is no common reference architecture that drives the standardization. So there is high cost of maintenance. CIOs are spending a lot of money to basically maintain these integrations. And the strategic problem is that the CIO is not able to tell the business that this is the value that I am providing. So it is more like that CIO is working like a support organization wherein there is a budget that is provided by business to IT and he just ensures, he or she just ensures that they build and maintain systems using that budget. But if somebody questions the CIO what is the value that IT is providing to business, nobody has an answer to that. So that's the problem that most organizations or most large IT organizations are facing. Also, if you look at the landscape, so if IT has been changing very rapidly, so if you look at the left-hand side of the slide, what the left-hand side says is that in the past what was happening is that everything was built mainly inside the IT department. So most of the work was done by the IT departments and they would have one or two vendors to whom they would give large outsourcing contracts. So they had a complex legacy internally but it was mainly inside the firewall and they had only one or two large outsourcing providers to whom they would have a connect who would provide them services. But with the digital disruption or with the way the IT is changing, IT is moving more towards a service broker model. And what that means is that IT is getting more and more services from third-party vendors rather than building it on their own. So more and more IT organizations are looking at basically sourcing services from third-party providers rather than building it from scratch. What happens with that is that you have sourced services from the cloud, you've got a lot of third-party vendors, so your interfaces with the outside world increases. So that's one problem, you have to manage those vendors, you have to manage the interfaces with the third-party. So what you see on the diagram, the circles which are there on the right basically represent that these are your interfaces with the third-party vendors and you need to manage them. The other thing that has happened is that with the internet of things there are more and more people who are connecting their own devices to the IT departments. So there are a lot of companies who have brought in things like bring your own device or there are a lot of other devices that have come in and so there are more and more devices that are connecting to your systems. So security has become a risk. So cyber security is an inherent risk because more connections to your system, more threat of some hacking and all that. And lastly, the expectations from IT has changed. So in the past what used to happen is that if there's a particular IT CIO who says that I'll take one year to deliver a release. So I remember 20 years ago when I started I was a product manager and I would say I would give only two releases in a year and the business had to accept that. But today if I tell the business that I'll give you two releases in a year they are going to tell me that I'll go and get it from a third-party service provider. I don't want your services because a third-party service provider provides me better services. He will do things faster. I'll get software as a service rather than you maintaining my service. So the expectations of business have changed. They want IT to be more agile. They want IT to be more faster. So the landscape has changed. Digital has added a lot of agility and improvement but it has also increased complexity. So the old style of IT, the old style which we have been using for IT is not going to work anymore. And that is where you need a new style of IT and IT for IT comes into picture. So I'll briefly touch upon the questions that the CIOs need to answer. So today CIOs are being asked questions like what is the value that you are providing to me? Why do I need an IT department? I could as well go to a service provider and do it. So the main question is how can I measure the return on my investments? The questions like that there are more and more suppliers that are coming in, more and more vendors that are coming in. So what supplier management model should be used? Then there are things like that how can you shrink delivery timelines? So these are the challenges that the CIOs are facing. And unless the CIO has a complete visibility of what is happening into his IT organization, he or she will not be able to answer these questions. So it's important that the IT department cleans up internally to be able to meet what business requests are from them. And that's where I would say IT for IT comes in. So what IT for IT and I'm going to be talking more from a conceptual perspective because this is a relatively new standard and I would like people to understand what the vision of the forum is. So the forum is basically planning to develop or has already developed a vendor neutral reference architecture that supports an integrated IT management approach. And what this means is that if you look at any IT department, they have processes in place. So IT actually prescribes that these are the processes that you should have within your IT organization. These are the kind of processes or the COVID prescribes you. This is the governance structure. But in terms of the interfaces between the different departments or between the different functions in IT, like how should service strategy talk to service development or what are the kind of interfaces that should be there between service strategy and service development or service development and service operations, there's no standard which basically prescribes that. And the vision of the forum is that they have developed a vendor neutral reference architecture. And when I say a reference architecture, we'll get into a little more detail of that. But the reference architecture is more technical when it talks about that within each function of the IT department, what are the kind of software components or what are the kind of functional components that should be there and what should be the integration points between the IT department, between these IT functions. So the forum is basically developing a vendor neutral reference architecture. The other vision that the forum has, which will take some time to realize is that it will provide a set of open standards to vendors. So what will happen is that if you all might be aware that there are some large vendors which are in the IT management tool space. So there are vendors like IBM, there's HP, there is BMC, there's ServiceNow. So these are some large vendors within this space. The vision that the forum has, which will take some time to realize, is that once the reference architecture is standardized, then each of these vendors will basically get their products certified. So ServiceNow would come and say that certify my product for service operations or for service management. What that would mean is that if somebody gets their product certified for service management, they would have to expose the standard interfaces that the reference architecture prescribes. So if I, as a vendor, go and get my product certified, I will have to have all the functional components that the reference architecture prescribes and expose the standard interfaces that the reference architecture prescribes. So I have a question for all of you. What will come out of that? If each of the vendors, or most of the large vendors, get their IT management tools certified to IT for IT, what will be the outcome? Yes. So there is no need of integration because it will plug and play. So if today somebody is using BMC for service management and an HP for PPM, they don't need to build integration because both of them are IT for IT certified and it becomes more of a plug and play rather than everything. So this vision will take some time to realize, but that's where the forum started from. So the value chain, so this is something that Suresh touched upon briefly. I'll not spend too much time on this slide, but as Suresh mentioned, this is based upon the concept of Michael Porter's value streams or value chain. So what the forum did was they applied the concept of value chain to the IT business. So to run an IT business, what are the value streams that I need? So the strategy to portfolio is basically focusing on plan, how to basically define your IT strategy and how to meet your needs of the business. The requirement to deploy is how to develop or deploy a system because in requirement to deploy, you could either build your system from scratch or you could get it from a third party service provider. The request to fulfill is a new concept in the reference architecture which basically talks about that IT needs to act like a service provider. So IT needs to provide a service catalog to business and business should be able to consume any services using the service catalog. So the request to fulfill is a new concept. Usually it was always plan, built and run, but the request to fulfill talks about how IT can basically set up a service catalog so that business can actually consume services from the catalog rather than asking it a dog. One of the other concepts that the request to fulfill covers, which somebody raised a question in the last session, is that it covers the concept of charge back and billing. So somebody asked that question that how should CIOs convince business what is the value I am providing. So the request to fulfill talks about a charge back mechanism wherein you can charge back business based upon the services that the business uses. So you establish a charge back mechanism and based upon whatever the usage is, IT can basically charge back to business. So that way what will happen is that the CIO is running his or her IT more like a business rather than a supporting shared services organization. They will be able to generate their own revenue because they are charging business based on the services. So these are the four value streams. What you see below are the supporting functions. So these are something that all the value streams basically use. And if I look at the supporting functions, there's not much work that has been done on the supporting functions. The major work that has happened is around finance and assets. And as I mentioned that Accenture has been leading the development of the IT financial management stream because we thought that it is important that even though we're talking about a reference architecture which provides an integrated landscape for a CIO, unless he understands what is the cost of the service and what is the charge back he can do to business, he will not be able to run his or her IT like a business. So the financial management stream is working on how can you determine the cost of a service and how can you do charge back. So the main concepts that the IT FM is working on how to manage IT investments, so there's investment portfolio which is already a part of the standard. We are currently working on the service costing, how to determine the total cost of ownership of a service. And then once we finish that, we will be going to the pricing part wherein we will be providing guidance around how to basically price or how to basically charge back to business, how to price services and charge back to business. So once that happens, then this will even become more powerful because this can be used as a guidance to define or to determine your total cost of ownership of a service and define the rising pricing models within your organization. So there's a lot of work that has happened in finance and assets and as this progresses further, there is work also happening in the intelligence and reporting work stream which is more around KPIs and all that and as there is plan to actually start work on the other work streams as well. So the idea for doing finance was to make IT for IT more attractive to CIOs and CFOs because once you start talking about costing, pricing and charge back, the CIOs, you will immediately get the attention of CIOs because that's something that they've been struggling for so long. Okay. So like if I talk about the strategy to portfolio, the strategy to portfolio focuses more on IT investments, planning and prioritizing IT investments to meet business demands. The requirement to deploy is more about sourcing and developing services. The request to fulfill is more about ensuring that IT becomes more of a service broker wherein it provides a service catalog and does a charge back based upon the business services. And then there are individual supporting streams. So the key things that I want to highlight over here is that the finance, when coupled with the reference architecture, it will help CIOs to run IT like a business because they will be able to track what is the cost of the service, the total cost of ownership of the service and then depending upon the maturity of their organization, they can decide what is the price. There might be some organizations who might decide that, okay, my price will be initially equal to my cost. There might be some organizations who might say that my price is equal to cost plus some premium and that premium is basically their revenue. So when finance gets combined with the value streams, it will basically ensure that IT can run like a business and IT can generate its own revenue. So I think I'll not spend too much time on this slide since Suresh already covered that but the key concept I want to highlight here is that the reference architecture or the value streams are all connected by a service backbone. So if you look at the problems that you see within IT organizations, typically what happens is that when a demand comes in from business, there's some team which created the requirements. Then it went into the design stage and there was a design and development that was done. Maybe there were three or four instances of that services that were deployed and there is no way through which you can basically trace from a conceptual model to the physical model. So the reference architecture has a service model backbone which enables you to actually connect all the pieces together starting from the conceptual service which sits as a part of strategy to portfolio to the logical service which is a part of requirement to deploy to the physical service which is a part which is basically your physical instance of the service. So that is an important concept in the reference architecture and this is the way the reference architecture looks like. So if you look at the reference architecture what you see is on the bottom there's strategy to portfolio on the bottom and there are some blue boxes and some black circles. The blue boxes are basically your functional components and the functional components are, what they mean is that these are the software components that you need for your service strategy to work or for your strategy to portfolio to work. So what the team has done is that they've basically defined that for strategy to portfolio these are the software components you need to basically automate this function. The black circles that you see are basically your entities. So the black circles are entities we are saying that these are the primary entities which are there which need to be there as a part of those functional components and the black lines are basically the interfaces. So this is the level one of the reference architecture. There's a level two of the reference architecture which goes into a little more detail which talks about what are the flows between each of the functional components like between the enterprise architecture and the service portfolio what should be the flows and interfaces and what are the kind of cardinality between those two. So for each of the value streams they've gone to the detail of defining that these are the software components that are needed these are the entities that should be there and these are the kind of interfaces that should be exposed. And this is as I mentioned and if you look at this purple circles this is the service backbone which basically connects the conceptual service to the physical service. So when you start from getting demands from business to basically realizing a service then how the service model backbone enables that flow or connectivity from the conceptual to the physical model. Now the way how will this get used so there are two ways in which this can get used one is that I mentioned initially that vendor organizations which are providing IT management tools if they start getting the tools certified on IT for IT and I think the vendor certification program is still not launched it will be launched later in the year but once that gets launched they will be using this reference architecture to see what are the gaps they have in their product with respect to the reference architecture. They will fill those gaps and once they get their product IT for IT certified that means they are following they have these standard entities that the reference architecture prescribes and the standard they expose the standard interfaces that the reference architecture prescribes. So you know that if a product is IT for IT certified it has this software components and it exposes the standard interfaces. So the vendors will be using this reference architecture for that purpose. Organizations or consultants like us how would they use the reference architecture they would basically use the reference architecture to look at what are the gaps that you see within a client's IT organization so if you go to a particular client and the client says that I have got too much spaghetti architecture within my IT landscape you will use the reference architecture to find out where are the gaps and what should be the roadmap for them. So there are two ways in which the reference architecture can be used one for the vendors and the other is basically for the consulting organizations wherein they can use it for the clients to find what are the gaps that are there. So there is a level two of the reference architecture which you can find on the open group and that can be downloaded from there. Now I will briefly touch upon the comparison of IT for IT with other standards. So like Steve was mentioning a lot of questions that come in that how is IT for IT different from ITIL. And most of you may be knowing about ITIL ITIL is more of a process model wherein it says that if you have to set up an IT organization then these are the processes you need to put in place to ensure that your IT organization works right. What IT for IT will do is that it will provide you a reference architecture that can help you connect all these pieces together so it provides you a reference architecture for the software ecosystem through which the CIOs use to manage their IT. And TOGEP and ARCHIMATE you are all aware about that TOGEP is the enterprise architecture standard and ARCHIMATE is a modeling language. And I think somebody later during the day is going to talk about how IT for IT and TOGEP William is going to be talking about how IT for IT and TOGEP William is going to be talking about how IT for IT and TOGEP will be working together so I don't want to steal a standard. So in terms of the implementation how should you go about the implementation of IT for IT? So the way to go about the implementation is that for large organizations the way Shell has been doing it and Shell is one of the organizations that have implemented IT for IT in a big way they have said that they want to embrace IT for IT as the architecture for the business and the way they have done it is that from the top they have a plan in place they have a vision in place and it is being driven from the top saying that okay if we have to comply or if we have to follow the reference architecture for managing our IT then this is the way we will go about. So this basically lists down what are the steps that you could use to basically start for a large organization if IT for IT needs to be implemented the first thing that you need to do is you need to define the problem. So you need to look at what is the current landscape that they have in place what are the gaps that they have do a baseline assessment and develop a business case and get buy-in from stakeholders. So I think this is something that Shell has already done. They've got buy-in from stakeholders so they've decided that yes there's going to be a three-year plan or a two-year plan wherein they are going to implement IT for IT. And then once you have a business case and once you have a vision from once you have a top-down approach where somebody is driving it from the top then you perform a detailed value stream analysis. So depending upon the organization the first value stream that you could pick up could be different. Like I was reading about an example where an insurance company used IT for IT and they said that they will start with R2F because that will help them understand they did not know what are the services IT provides to business. So they said that will help them understand the services that IT is providing to business and they will be able to build a service catalog so that will become their starting point. There's some organizations which decide to start from D to C wherein they say because Detect to Correct is all about service operations so they want to get their service operations right. So depending upon the organization's pain point you can decide which is the area you want to work upon first and you do a value stream analysis and you start working on that. So understand the problem is do a detailed value stream analysis you define IT for IT ownership and governance model so that you ensure that this is driven from the top and then you develop a vision, mission and strategy for IT organization. So I remember one of the speakers yesterday also said that it is important to develop a vision. When you're doing an enterprise architecture also it is important to develop a vision because that vision actually helps you drive the entire thing and then define your target state using the reference architecture and then put down a roadmap for implementation. So typically these are long projects because if you're talking about a large IT organization which has a budget of about 3 to 4 billion dollars and if they want to set their IT organization right they might be using multitude of vendors they might be using several incident management tools because every vendor has come up with their own incident management tools. So it is typically a two to three year roadmap wherein for large organizations if you want to implement IT for IT. So that is one way in which you can implement IT for IT if it is driven from the top. The other if a particular organization has not bought into IT for IT or they're not sure about the value that IT for IT is providing and they do not have budgets to get their IT organization right you could start small wherein you could basically take some use cases. So things like that they could say that for any new service that we are launching we will try to use IT for IT. So for example if they're launching a new service and if they're using a third party service provider for that service then they could say that the tools that you come in should be IT for IT certified or in the RFP they could mention that the tools that you provide for IT management could be IT for IT certified. So that way you could start small wherein you don't have a big bang approach you don't need a full-fledged budget but you start with your newer services and you ensure that the principle of the reference architecture is included in those new services and then slowly actually take it to the top. So this could be another approach that you could use IT for IT for a smaller organization or for an organization who is not ready to actually set aside a budget for IT for IT. So this could be another approach that you could use. So I think that's what I had for my session. The idea was to give you an overview of what is there as a part of the reference architecture and thanks everybody for listening.