 Can you hear me okay? So, very nice to be here. Quite amazing venu for this conference. I'm actually son of a preacher, but I've never preached in a church myself. So this is the first time. Today the topic is the Gospel of IT for IT. Before we go into that, just brief introductions on the agenda, and then I will tell 5 stories about applying IT for IT in practice. Ja sitten myös ensimmäisenä lähellä, joista nähneet tarpeeksi ja tulevaisuudesta, miten näemme, että mitä voisi tapahtua tulevaisuudesta tämän domojen. Järjestelmistä minäkin. Mä oon tullut IT-tevällopuksiin, mutta sitten olemme IT-servis- managementa Värtsilä, global company based in Finland, jossa olen tullut IT-tevällopuksiin, ja me olemme tullut enemmän. IT-servis managementa ja tuossa SIAM framework. Se oli kustannuksen availu. Mutta sitten kun se oli tosi tullut, toimme mannistajastavuusprovida deeto, silti ensimmäisenä MSP-täljistä. Me teemme tämän saman vuoden, että saimme SIAM-täljistä, mutta tämän täljistä on tullut ja nyt jollain toimimme SOFIGATE as a consultant. SOFIGATE on ensimmäinen business technology company in the Nordics and today the focus is on business technology. Just a brief background why we talk about business technology, there's been good talk about that already, but when we meet with the CEO of a company and we have one minute to discuss with him or her, we ask how do you manage technology in your organization and they start telling that yeah, we do it very well, we have the CTO managing the technology that is in the core of our business, then we have the CIO she's focusing on the old school IT and making it run efficiently and then we have the CTO, he's now focusing on all the fancy stuff and the mobile apps and all these cool things and then we have chief digital marketing officer who's doing this and that and while they are explaining this model they actually start realizing that no, we are not really managing the technology. We have silos here and there who do something about technology, but there's no common management framework around it and that's where we aim to help now with this business technology concept that you should actually have one common way of managing business technology and there's plenty of things because suffocates background is in the IT management as a service and sort of IT service management largely we see that from there there's plenty of good practices that could be used more widely now that IT is becoming part of everything and we see that this is the golden era for IT service management, there are two mega trends everything as a service is turning well everything into a service and obviously that requires service management, but at the same time the digitalization means that IT is becoming part of everything and these together obviously lead to the fact that these practices we have in IT service management become much more relevant than they have been maybe in the past. So how did we get here? We have tried to picture this in three eras first maybe in the 90s or early 2000s we were in the ITSM era where we were focusing on ticketing and help desks and maybe the first ITSM tools were implemented back then but it was quite reactive and based on the contacts from the users and then from there for example what I was involved at Värtslä we moved towards this service management where service became the centerpiece of everything we by defining the services that we provided to the business actually we got the context for a lot of processes, we knew what these incidents were about, we knew what these changes were about and we could manage the services according to maybe ITL version 3 at that point but also implementing then more material IT service management tools, publishing the services through catalogs, enabling self-service etc and here we built a lot of really good structures important structures for good service management and in some cases maybe even two strong structures or two rigid structures in that sense that custom experience and user experience were forgotten we were strictly forcing users to know that this is an incident, this is a service request and we were educating them about it and now how do we see the future the next third era or something that might be coming we see that there could be two options maybe even we might go into more and more structure like IT for IT I think is an example of excellent structure for managing the business of IT but on the other hand we have technologies coming up which may be reduced the need for this kind of structure, we have things like the robotic process automation where actually robot can do things that humans used to do and we don't need a good tool, we don't need good APIs if we have a robot doing the clicking or then chatbots I will give an example later on but I think in general chatbots turn unstructured human talk or human writing into structured actions and that's maybe removing some of the need for this most structured architecture but I think it's not still saying that we wouldn't need this kind of reference architectures I think that's really the basis and you will be seeing that for the third era where we go towards the highly automated service management. So my brief history at Värtslä when we were implementing the SIEM and ITSM and service now was a tool there we did it based on the idle guidance and we read all the thick books and tried to understand what was the best practice and then based on that configured the tool and defined the processes and educated the people and during that time we had a challenge that there's 26 processes and nobody can list them by heart or at least people could not learn it and it was way too complicated so we decided to define end to end processes we defined four of them and we gave them certain names and then they were combining the different idle processes and I was we were almost completed with the project when then I first read from the internet about IT for IT and realized that actually somebody has done this already much better than we did and a lot of the same ideas there but defined much better and then when I moved to Tieto we decided from the first day that we will use IT for IT as the basis of redesigning the architects of managing IT services and that's what we did there and implemented basically all the tooling and all the processes based on the IT for IT and the most common question I back then got and still I get when I talk about this is that okay will this now replace the idle I'm not sure if that's a question because they would like to have something replacing idle or if they are afraid of their certifications that they have paid for but but that's the question anyway and I never I always say that no it's not really replacing it it's a different viewpoint it has different strong areas but certainly there are new ideas out of IT for IT that you should leverage and use to use to benefit the business but what I always always tell at the same time that well if you run an IT project do you not start IT for IT project that's certainly not needed start the projects that your business needs and then use IT for IT in those as an inspiration and as a guidance just as you should have done with the IT law so but it's not something that you decide to implement you should really have some business targets that you aim for so then one more question I often get is that well why do we at all need a reference architecture for the business of IT and that's when I usually tell them that well think about construction industry I've been involved there because I built a house couple of years ago and saw how the construction industry works and it's an old industry much older than we are in IT so there's something that is quite mature there and when I bought a piece of land I got this kind of a diagram showing the piece of land and there are some there's hardly any text in it there's some signs that even I can understand the size of the land and maybe some positioning and some other information it's very high level but when I gave it to an architect the architect designed more details on it building on top of it not really removing much but adding more signs and numbers and here there's already some information I might not understand but the professionals in this industry fully understand and then when I gave this architecture design to an engineer they designed air ventilation and water pipes and all that and they use their own reference architectures they know that these two pipes work together you can connect them easily and they use the notation that they understand so think about in this kind of context giving to the construction men five thick idle books this is the best practice for building a house read them go to the courses get yourself certified and do it I don't think that would be a success story and similarly in the IT I think this kind of reference architecture it's much more valuable in project context where you don't have time to start reading the books but you simply need to start executing that's when you need reference architecture some ready thinking done by someone smart and then you can build on top of it and use the for example the the signs and the kind of syntax that they have designed even to a level that you can then connect it to the IT like I have then Alexa in the house commanding or I can command all the all the systems almost through the Alexa so it even connects to the IT world so that's about the introductions to the topic then the five stories and now I must warn you that this is what I'm presenting now as the five stories of applying IT for IT this is not IT for IT the terms that you will you you will see and also kind of the theory I'm not saying that it's strictly IT for IT it's how we have used that as an inspiration and as guidance in these projects and it all starts from the user experience I think what has been very important in IT for IT is that there's this procuring model so the user should have one interface one common user experience of the IT services whether they want to use the mobile app or service portal or APIs for let's say ordering something still it should be consistent user experience underneath they should not need to jump to the portal of that vendor and then to the portal of that vendor and then to the internet for that that need but somebody should be procuring it and that's why we have often called it service management and orchestration layer that you should have in between and this is kind of the request rationalization so if we think employee onboarding as an example there's a new employee the manager goes to the service portal and submit some information selects the devices and the access rights they need it should be really orchestrated with the workflow that then integrates the different suppliers and internal service providers to the chain and then user has consistent experience they have one ticket to follow they don't need to jump between the different providers but not only that this could be easily done even by having a good instruction for how the ticket should flow between different parties it's really important that the workflow then handles the subscripts and does this user even have right to do that or have these services do they get the approval for all those services and what is the SLA the delivery times for those things that they have ordered and when the delivery is done then updating the cmdb the asset management charts back and show back information in the systems that's often forgotten but when it's built into this workflow running in this service management and orchestration layer then it gets done automatically so this kind of picture we have often designed and I think it's fully aligned with it for it thinking there that there's this request rationalization and there's the request execution of fulfillment at the supplier side but by separating these two and making sure that the orchestration is consistent then we can provide a really good user experience and we can actually control that that quite easily leads us to the second example the siam example so if that was request to fulfill let's take an example from the detect to correct value stream and here what has been a very typical implementation that I still see in many organizations in in the service desk sees that there's a ticket let's call it incident or interaction or something but anyway it's then bounced back and forth there's sort of a ping-pong between the teams and different vendors and then you have quite hard time measuring the SLAs by the system and and also from user's point of view it seems like nobody's really wanting to take the ownership of it so what we have used now as a best practice in this siam implementation especially is that then you actually have the second layer you have the customer interface layer let's call it now an interaction there that service desk takes and keeps the ownership from the very beginning till the very end and that's measured with end to an sla service desk cannot pause it they cannot have any excuses of not taking the ownership because somebody else is now responsible and that's related to the customer phasing service that also customer understands and then we have the service provider layer beneath that and that interaction might then require getting one or more incidents fixed at different service providers that provide these factory services that might be capacity or database management application management and those are measured separately with the operation level agreement so underpinning contracts and this has enabled us to very well measure the different service providers and their delivery times and their service levels separately from the service desk and it's not only a data model it's really a shift in the mindset that service desk takes the end ownership but it's we've seen it quite impossible to do without this kind of data model because it's so easy to build these exceptions into the process. The third example this is a typical architecture concern or discussion and that actually got into almost a fight at the architecture board where there were different opinions on how we should implement the self-healing and we had different runbooks or workflows or these kind of automation scripts and event management tool had one and then incident management needed something as well and even we were talking that maybe problem management should also trigger certain runbooks at some point of the process and none of the tools that we were using in that context really had this out of the box so we had to customize them and what really resolved that architecture concern was then IT for IT picture that we took and looked at and how does it define and it really defines only one runbook library that should be common for all these processes and that was used as the argument to get that concern resolved and have something that well made sense but once somebody has written it and it's actually part of reference architecture then it's much easier to much more easy to argue and get it done also accordingly. DevOps, a buzzword that doesn't necessarily always tell that much what is needed or what is meant by that and I've been often told that well it's not really about tools it's not even so much about processes it's a culture change but if the culture change doesn't result in anything tangible then it's not really of that great value and from IT for IT I think great benefit is the connecting the operations and the development into one big picture. It was really interesting to hear that at Oracle you have actually forgotten the problem management completely and used defect management for that purpose that might be really good idea but in this context that we were working we had problem management done by the operations tool people in the operations tool or ITSM tool and then the defect backlogs were in another tool or many tools actually so from IT for IT the guidance to integrate these two actually or at least so that we get the problems visible for the development we get them to the backlog of the of the development teams that was really valuable and that helped us to concretize that what could be one way to do this feedback loop between the dev and the ops. Next step might be that especially if they are within the same tool that you actually have just one backlog of problems and defects in the system. Okay final example and a little bit of background for this example so I don't know how many of you work with chatbots or virtual agents are they on the agenda in the organizations. Some of you have them on the agenda I think it's at least coming to almost everyone's agenda right now and we've been studying what is actually inside this kind of virtual agent and there's usually you need to define the utterances or the phrases that it recognizes like I would need a new laptop and then there's natural language processing that understands the phrase and turns it into an intent or links it to an intent that might be for example order laptop and that intent then has certain prompts or questions configured related to that that when you start that intent you need to ask the following questions to get more details and then you might be showing four options of different laptops for example there might be a question after another but then at the end you save those responses to a slot or some systems called them variables and then you can start the fulfillment. This is actually a very good structure even for when we think about not just that the human is chatting to a robot but even systems talking to one other system there's this fascinating idea that in the future why don't the systems talk basic English with each other if we can have this NLP natural language processing in between the systems could be configured to integrate with simplifying with English and not any XML or such structured language. In any case at the end of this kind of virtual agent discussion the virtual agent says that great after the approval from your manager one standard laptop will be arriving at your default location in three business days. Now how do you build this kind of virtual agent? How does the agent know what is the approval process? What is the delivery time for that laptop? What is the location of this user? No chatbot actually has this kind of information or at least it would be quite difficult to build all that in. It really needs a service management platform and some architecture on that platform underneath. So if we continue with the kind of similar example of a chatbot when then the user contacts the chatbot about my order for MacBook. To be able to provide relevant discussion with the user the chatbot should recognize that a MacBook is a product and actually for this specific user there's an asset out of that product model created it was delivered to him or her with this request and they can check the status of that request and they can communicate back to the user that well yes this request for MacBook Air is actually completed how can we help you with that. So it's already relevant for the user and then the user replies that yes I have received it but it's broken and that's when the virtual agent or chatbot should recognize that it's actually an incident in this case. A user didn't need to tell whether it's a service request or incident but we are understanding the context and we say that sorry to hear that I have registered incident this and that for you and then also we can tell that our onsite engineer will be within an hour with you because we know what is the onsite service provided for that user in that location and we know the responses SLA we have for that location so we are providing the service time already there and then we are confirming the default location that this is actually where the user right now is and once we get that confirmed then we can we can close the case from virtual agents point of view so without this kind of architecture information architecture behind a virtual agent you would not be able to have a relevant discussion like this but once you have the understanding and the context for this discussion then you can actually make it a relevant discussion. So some lessons learned from these cases and other cases we've been involved. First of all I think it's good to understand that IT for IT focuses on these levels one to three and always in projects we for example at SOFICAT we are working on on the level five mainly but we have developed level four sort of our best practice implementation for IT service management and and also many other other use cases and we have done the best practice configuration of that on top of service now and force.com platforms but to have this seamlessly linked I think that's really something we need to work with both at the consultancy house season and then together with for example open group to to make sure that there's a seamless linkage from the standard to the vendor specific refinement architectures and then naturally to the solution architectures that we built. But what we have learned I think it's very valuable to train the people with this value chain thinking that has been much more easy than you would think because at least the people who have tried to learn ITIL this is so much easier to remember plan build deliver run forwards and you have most of it covered already and it's a new perspective also to change the thinking from very siloed processes to value chains that that works and it's very well aligned with with the business goals of many organizations but it's not worth setting these ITIL and IT for IT for example against each other it's better to to build on top of the existing best practices that the organizations have and often it's easy to start from detect to correct because that's the most familiar part but then I I believe that the most value lies in request to fulfill and that's the biggest opportunity for a lot of companies that's really the value stream of this cloud era and consumerization enabled by that and then when we measure processes it's much better to measure the end to and value streams than the independent processes and their execution that has had a huge effort in certain cases where people have realized that after I have closed this incident my KPI is still running because I triggered the problem management and now it's pending for a change so I actually need to get the whole thing fixed before I get the KPI measured and then what we see and it's coming back to this everything as a service when we go towards everything as a service and we digitalize all these services it's having a huge potential of of using IT for IT as a reference architecture there so I really think you should aim high and aim wider than just the enterprise IT there's plenty of opportunities in the support functions but also on the business side so to summarize the top takeaways from this presentation I believe digitalization demands much more structured IT service management and there's much there are technologies that help you there for example virtual agents or robotic process automation but it's not going to fix the whole thing you certainly need the structure even behind those reference architecture has been especially valuable in multi-vendor discussions that's what I've seen when we have entered the room with different vendors involved and then we have tried to get them to work together they all have their own models but once you can bring something neutral to the table that many of the vendors even have been involved in in defining that's much better crown for the discussions and IT for IT certainly provides very valuable guidance for a lot of these challenges of the of the modern world so so certainly can recommend using that in your in your projects so thank you for the opportunity of for presenting here so we'll sit together and get through some of those one of the first ones that came in and Rob is just working with me to get some of the other questions that was near your last slide which was your first I think it was your first lessons learned the question was right out the gates you said better train them in value stream and value chain thinking so do you do that using IT for IT thank you or do you and that model and the information that's available there about value chains and value streams or are you recommending to your clients some other deeper training around value streams and value chain we've done both so finally we have also these trainings available in Finland so we have recommended those but then also we have kind of done more let's say custom made value chain thinking training and starting often from the processes that these organizations already have and trying to put those into a value stream that has been really beneficial so so that the processes are already familiar now we are just organizing them into complete chain yeah good the next question is you mentioned everything as a service how do you see organizations managing these services maintaining lists of services for example service portfolio service catalogs yeah that's where it should start from from defining these services in the first place so that you know what you are actually offering and even if it might sound like a bit theoretical and the difficult exercise I think it's certainly worth doing because it provides the context for all of it and then you can start measuring not just the overall incident management or problem management but you can start measuring the services and you know where the pain points are and then you can of course revise and do it better next time but simply defining the services will get you started yeah okay this one looks like it might have come from a friend of mine do you think everyone in the IT organization should have a high level understanding of IT for IT yeah I do I think it provides the big picture certainly for all the people I don't think everyone needs to know it to the full level of details but also today there's been the one slider many times shown I think that's certainly valuable for everyone to know yeah and by that you mean it allows you wherever you work in IT for IT to understand your position in the value chain exactly and then yeah maybe one level deeper which is what's my immediate upstream and what's my immediate downstream yeah and what's the impact when I do or don't work well with that flow exactly yeah yeah okay do you think IT for IT is a game changer for me it was when I learned about it it clarified a lot of things that I had been pondering on and resolved some current issues I had back then in the project so I'm only talking on my own behalf but for me it was a game changer in the way that I have designed service management in now both in custom environments as well as in the service provider environment yeah you also mentioned something at the start of your presentation that I that you shared with the audience that I thought was very resonated with a number of customers that I've met over the last four and five years working with this which is you are already halfway to building your own reference architecture it was it was I'm sure a very laborious process you weren't done and then you saw this that is the origin of IT for IT several customers had come together at an industry event and were kind of sharing notes and the complaint and the challenge and the need to fill this gap and showing their work and then they realized our individual company is spending all this resource to build this ref arc and yet it's not proprietary it's it's not a unique competitive advantage it's just something we all need and so that was the genesis of this and so you were you didn't happen to be in the room that day but you were clearly having that same epiphany so absolutely that's really excellent um let's see uh the next one is can you elaborate on how or whether you use IT for IT together with Siam yeah we we certainly use and uh well it starts in the Siam from the fact that you have different service providers doing different processes for to manage certain processes uh so manage certain services and and then they might be calling different objects with different names uh so once you bring the IT for IT to the table you have a common map that okay when you talk with that term you mean this object that actually in this integrated process should be linking to this one uh so there you have a common terminology to start with you start talking about the same things at least and then naturally when you run into discussions that okay how who's responsible for this or what is the interface between this party and this another party uh in the whole ecosystem then you have a neutral uh playbook that you can start from um definition of how it could be done according to the reference architecture and it's quite difficult to say that no we will do something totally different so that has been a good good use case and also of course from tooling point of view there's plenty of um data model and these can functional components in IT for IT that enable Siam yes yeah yeah actually this that question takes us back to part of what Rob was training us on in the end of the uh of the morning which is thinking about IT for IT as this very cost effective umbrella framework that that rationalizes all of these things Siam DevOps uh you know individual other standards and best practices and you sort of tapped into one of the key threads in there which is that they each come with their own language and vocabulary but perhaps you would like to have a single umbrella framework for a vocabulary that all could map to and that way these different entities and individuals and initiatives that are excited and working on their projects with their own vocabulary still flow back in and share a vocabulary I think it makes the work stream much easier we have another question for you which is you referred to the level of uh level of reference architecture near the end there you're showing it you know uh open group with our IT for IT standard is provided levels one and two and you were talking about that you go deeper as a as a vendor in a consulting firm so it's asking do you have a level three reference architecture defined or did it did open group provide that I don't know what is the official answer but I've seen a draft at least going to the attribute level you mean yeah yeah so I guess we can share the answer to this question we're working on that and there's a work group right now called interoperability which is trying to dig deeper because they're kind of part of their end game as they want to be able to get to to the point where there could be IT for IT tool certification today as you know we have IT for IT foundation people certification but in order to really help the vendors and help you in driving that interoperability between vendors we need to get to level three so that's a work in progress but then these deeper layers allow the vendors to come in and get more specific so yeah and then it starts to already be on a technology level and it might be dependent on the platform or tool that you use so that's where we have then helped our customers to start whether it's in our case it's typically service now or remedy force for example how do you then configure that tool to be aligned with IT for IT yeah another question for you is with the five or so use cases that you shared there's a curiosity about do you have those been out and in use long enough for you to have any cost measure cost savings measures or efficiency measures any kind of metrics around the success of that those initiatives all these were not just from one organization many of these have been used in a number of organizations so I don't think I have any numbers to share but certainly in each of them they have been successfully implemented and and then also from some of them I have heard that there has been good good results the objectives that were set by the business case have realized yeah so anecdotally so far yeah maybe we'll have you come back next year and maybe find the hard numbers for us too