 We have two more sessions in the IT for IT stream this afternoon. The first is led by Lars, the chief architect of IT for IT at HP, whom you've met before. And it's my pleasure to introduce friend and colleague Richard Einink from ACMEA in the Netherlands. So I will leave the floor to them. After their session, we have a Q&A panel when we can invite questions to all of the speakers that we've heard since lunchtime. So Lars, Richard, thank you. Thank you. So I'll kick it off in opposite direction of this. So I'm the Lars and Richard is there, right? But you figured that out already. What we're going to talk to today, or not today, because we've been talking a lot today, but in this session would be around this concept of this service backbone and what that really implies. And then also put it into context of a real company doing real work with IT for IT and what the benefits have been doing that. And Richard will represent that part of it. The first part in the introduction will be around why is the CMDB and CMS concept not really working today? So it links a little bit back to the itel discussion that Charlie and myself was discussing earlier in the day. And it's a slightly provocative statement that it doesn't work, because a lot of people are implementing these kind of things and are getting results out of it. But what we are making a case for here is that it can only get you so far and you need something more than what is currently being described in, say, the ITEL books around this stuff. So we're not saying that ITEL is wrong, but almost. That was the closest I could get to being political correct here. So the IT value chain, as we discussed, is really sort of going all the way from the planning part and over to the consumption and running part of the stuff. And if you look at how you organize your things, it's very much around the processes. ITEL is not around describing what do you need to do in all of these various stages. So when you start at the left-hand side, the strategy to portfolio side, you run into the business leader. They're looking at demands and business process modeling. So not IT process model, but business process modeling. How are you doing insurance processes and what have I when you sell insurances, for instance? What are the policies, the company policies that needs to be applied, which of course then propagates down into real demand that IT needs to deliver in order to support these business processes. And then by some strains means it becomes handed over to somebody that actually developed this stuff. And so this demands gets translated into requirements at some point and being evolved through IT projects and being developed, defects being discovered during the process, et cetera. And that's all very good and fine. And at some point you say the agile process is now done. We've done our 10 sprints and that is what you get here. It's now in production. Well, I know that DevOps would put it into production a number of times during that process. But somehow, nevertheless, and it could also be waterfall process, you request some changes in the operational requirement, environment, you put it into production. You start running incidents and problem processes around it. You detect the events and maybe by the way also you start managing the subscriptions that is associated with these services who's actually consuming the services at the end of the day. Though again, the concept of subscription and how to manage that is not really well described in a lot of the existing process standards. You would, and that's sort of a side note into this standard discussions we had earlier, you might want to go to E-Tom to see how to do that because the telco industry have done the cloud consumption model for 100 years plus, actually. So it's nothing new. Telco has always been a cloud business before we invented that term way before. So we actually went in and used some of that to innovate that and Richard will come back to that later. But what do happen is that somehow we try to move all of that down into a physical service model, the CMDB. And so the CMDB classically is something that is initially being introduced in the operational environment because you have chaos and you can't figure out is this event important, not important, what is running on it. So in order for operations to work, put the CMDB in place and in order to calculate it, you put some kind of discovery process in place. And then hopefully also through the process of the request for change, you start managing it a little bit more systematic of making sure that you actually update the CMDB. Now it's starting to look like a CMS in ITEL terms according to the change that is coming down the pipe. But if you do move backwards into the development and the planning side, then the link into what is there in the CMDB is pretty weak to say the least. You might try to do it. I know some organization that has tried to do that and have in general not been very successful with that. So that's a real issue. Now I have a history, a legacy, so to speak, in the telco industry. That's why I'm referring to E-Tom and I've been stealing from E-Tom what I believe is the best of E-Tom. But one of the things I noticed in the telecom industry is that they were struggling with some of the same problems 10 years ago. And they started putting in place inventory systems. And there was a trend about 10 to 15 years ago where they had inventory projects. They were enormous. They really put hundreds of millions of dollars into creating them in order to actually figure out what is going on. I tend to call it the mother of all databases where you just keep everything in there and then you're done, then you are in control. They all, without exceptions, well that might be one exception, but I haven't heard about it, failed. The concept of trying in the operational, in the process environment to create a single system that just contains all of that is virtually impossible. You might be able to do it within an industry where all of this is controlled by a single vendor. You are a single organization. So if you go to the not the IT domain, but say the ERP domain with SAP, et cetera, you could do something like that, but even SAP is not actually trying to do that any longer because it is just very problematic. You are very much locked in. So can we do it differently? And you can. So you've seen this before. It's the value chain, the four essential value streams that you need to manage in IT. I want to explain that in more detail today. But if you look at it, sort of look at it in terms of there is something going on between them, there is a handover. And again, I want to stress here because that has been misunderstood by many people reading it initially. We are not advocating that this is a waterfall. You do all of this half a year, then you hand it over and then you do this part in another development cycle for nine months and then you hand it over. There is certainly interaction back and forth. There is a continuous interaction between these places. And actually, what it also indicates is that there is an evolution of the model of the service that IT delivers. So the demand comes in saying I need a new account receivable system or I need a new time tracking system or I need a new application for analyzing results from drilling for oil or something like that. And it comes in here and it initially is a conceptual service model. These are the business requirements and they go into development, but they also go back again and say, well, this is possible. This is not possible and get revalidated with the business if you run in an organization that is agile. But it requires that you have something to work on. So you could say that in essence, you really need to have a conceptual service model, a logical service model, and a realized or physical service model that interact. So the first one focused on the portfolio on the business side, the middle one really on how do we actually develop this, how is it constructed, and the final point, what does it look like when it's in production? And there are two things you can say about these information models. The first one is that it's really a refinement model. Initially, it's a very abstract entity. I need a time tracking system. And then the next thing you say is, okay, and it needs to deliver these capabilities to the business. How you actually deliver it? Is it my own application in a trieteer way that has a mobile front end or whatever? Or is it a module in SAP or is it what is it like? That's something you design here. And then finally, when you realize it, you go down to saying these are the services run on or these are the cloud service providers is being pushed to, et cetera, et cetera. These are the IP numbers. It's on, et cetera. Much more details in the final one. But there's another thing as well. And that's the one to end relationship that is indicated here on the arrow, which is to say that you might have a single conceptual service design that says I need time tracking. But you might have several very different logical designs. You might have an existing time tracking system that you still evolve on. It's version 3.x. And you need some extra features. So you design a mobile front end or whatever. But you actually in parallel are saying, well, I'm going to scrap some of these and we're going to build one time track system to rule them all. And that becomes a completely separate logical design. They're all related to the same conceptual one because it still needs to deliver the same stuff, but they're very different in design. And similar, when you go into production, it might very well be that you have developed or insourced a time tracking application that serves your need. You can validate them back with what the business need. But you actually deployed several places, right? You deploy one in AMEA and you deploy one in Americas. And there are different instances because of response time and what how I actually want to run to, right? And it might be very okay to do. Or you could say that I have one in production and I have another one which is in early production test and I have one in pre-production test or whatever, right? And some of them you monitor more than others. But it really is essentially different copies of the same logical model. Trying to do all of that in a single big repository where you just have everything in tend to be quite complicated. Also from the fact that you probably use very different IT systems in these various parts. You also, excuse me, might very well have outsourced part of it so that you don't have necessarily control over what tool chains are being used for part of it. So if you take that and look into it in more detail, then what happens is that around the service model you have a number of these artifacts that we talked about earlier. The key artifact, the 25 artifacts that are really controlling IT and they associate with either the conceptual, the logical, or the physical service model. Over here at this end, the conceptual service model, it's stuff like the demand object or which is, we did a name change in the latest version. So I have to remember what we ended up agreeing on in the consortium of users of this. It's a portfolio backlog item. So fundamentally things that I want into my portfolio. Or it's the investment budget that is associated with the conceptual service model. And the logical service model, that's typically the defects and the requirements and et cetera that you have there. And then finally, the physical service model where you have the concept of say the events and the incidents, et cetera, because it's all related to stuff that is actually running. The physical service model is the model that you typically are more used to see because that's where you have the configuration items. That's the things you can go and touch and change, et cetera. So they are the ones you can configure. And then it can come into an almost religious war about, well, is these things that are conceptual also configuration items in nature or not? Personally, I don't really care. I just want to make sure that we understand what you capture here and that it can be kept separate from the next stages in here. There is a little extra thing coming in on the top here, which is another thing that we realize around the service model is that if IT is to become much more a service broker or service provider in nature, excuse me, I've had a past couple of days and this is my second speaking opportunity, so I hope it will last me, else I'll hand it over to Richard to rest of it. Traditional IT, again, is saying, well, we plan, we build, we run. Plan, build, run. We've seen that mantra many places in IT. That's actually not what we are saying in IT for IT. We say plan, build, consume, run. That consume part is very important. It's not just one extra little function that sits there. It's an entire value stream. That's pretty big, actually. And if you look into ITO, et cetera, it's very difficult to see that. They do talk about consumption, et cetera, but to us, it's a much bigger thing and that's part of changing the business. And consumption is something you do from the logical service model in towards operation. So I consume something. It implies that I'm looking at what capabilities is possible based on the logical design and then I instantiate those capabilities in the production. The place where you see that most today in the industry is the cloud providers. They design the concept of infrastructure as a service, put it in the catalog, and then there's nothing that is running. They just design some infrastructure you can consume and then you can consume it and it becomes realized. But that is actually taking place in much more than just infrastructure as a service. It should really happen within the IT organization themselves with everything you do. Often in order to put something in the catalog, you need to put in some basic capability or basic service systems in place and you would still push them sort of more directly release deploy into the environment. So there's kind of two ways stuff happens in the operational domain according to the IT for IT. The traditional way that puts the systems in place and then the consumption part, which is really driven by the end consumers. And all of that needs to be governed by service model. And it's also remember or see here that we constantly talk about service models, not about applications or infrastructure. Infrastructure is delivering service. Applications are delivering service. You need to think about service. That's also another change. Now, again, if you read it, they also talk about service. Absolutely. Then we can come into discussion about is the definition of the word service actually the same last open group event in Boston. We had a discussion with a group of people called taking service forward. Any representation from TSF here? Okay. But anyway, they were looking at saying, well, how can we better actually describe everything as a service? And it turns out there is an awful lot of advances in starting to think that way. But it's a roadmap. It's not something IT will just do overnight. It's a transition. Now, we then drilled into saying, well, what is it really you have in these three areas? And we actually get to a little bit more refined model when we get down into what are the individual data objects, the key artifacts you want to maintain within the conceptual, the logic and the realized one. On the conceptual service model, there are actually two things. There is the conceptual service itself, which is kind of just a container or saying any time tracking. And then there is conceptual blueprints, which is fundamentally trying to keep track on what are the agreed set of features from a business perspective that the is being delivered as time tracking. So that allows you to build out a roadmap of what you want to do. And you can start doing all kinds of interesting planning activities around the conceptual service and conceptual service blueprint if you can track that. Moving into the logical domain, that's where you would not be surprised about, well, it makes sense to create a logical service blueprint or a logical design, if you will. That is really supposed to capture, well, when I start developing stuff, I make some design decisions. Some organizations are very structured around that. They have architects sitting here, which are sort of the borderline between enterprise architect and software architect that figure out, well, this is actually what I want to do, and they do all the detail of design. And then there are some programmers that look at these designs, which can be Word documents or Sparks, UML diagrams or various sorts, et cetera. What we have recognized is that in many organizations, unfortunately, these artifacts are being created initially read by the first set of programmers and then forgotten about and never maintained. And they are also often, especially if they are documented in Word documents, very difficult to access. You might have a document control system where you can find it, but it's still sort of, well, you can't actually do analysis on them necessarily. And now we can have a longer discussion about big data and what you can do on unstructured data, et cetera. But let's park that for now. In the agile community, it's typically worse that these things doesn't seem to be captured. What is more normally captured is requirements in terms of user stories. And then you just go ahead and refine, refine, refine, eventually get something that looks beautiful and performs reasonable well. But what did you actually do? So if you onboard new people, it can actually be very difficult to get into understanding what was taking place in these agile scenarios. That is not to say that agile is wrong. I'm just saying there are certain disciplines that you should be very careful about not forgetting in the process of trying to be smarter. But there is another aspect of the logical service design, which has to do with the release that goes out. And we call it service release and service release blueprint. The service release is fundamentally a capture of saying, well, I am planning out a certain set of releases with a certain set of features being implemented. You could sort of where I'm also talking about releases here, really. That's typically in a very, very simplistic mindset. This would be the major ones, right where you say, well, the business wants something new and better of some sort, where the release is over here, really determined. What are the individual chunks of stuff I want to put into production in order to get to the level of eventually satisfying all the requirements that came in from the business side, right? And the reason why I need to becomes a little bit of a, I wouldn't call it a technicality. It's actually pretty important, but there's a lot of details in it. Well, this one fundamentally described you have a new service release whenever you actually fundamentally add features to what you do. You could imagine, for instance, in an agile world, it would be the end of each sprint. You have a new release. It doesn't need to be that way, but that could be so every three weeks, you would have something like that. Or in a more waterfall, you planned out and say, I have an early access release. I have a beta release and an alpha in between, I guess, and what have I. Where the service release blueprint are actually the ones that are completely specifying, this is the package I'm handing over, right? Which is very important because in production, this is the reference you go back to and say, this is what I put into production. If you do a single patch, if you do a single bit change, you create a new one of these so that you fully can track it. Now, in agile, again, if we look at the bigger diagram, they talk about the concept of a built typically. And you could say, well, the service release blueprint is kind of equivalent to a built. This is one thing that we also recognize. This is where a lot of these dev ops guys or agile guys in combination of these, they have this very advanced pipeline or tool chain that allows you to constantly iterate and put stuff in production here. They're typically not taking into account where they're only part of a slightly larger environment where whatever they put out in these very agile way might interact with, say, the some APIs on SAP that they're also replying on another team that upgrades the SAP API for the time tracking, right? And that might not be developed in the same form. But this one keeps track on all of these dependencies. The final part of the service model is the desired, and you can't read this, but I'll read it out then, desired service model or CIS and the actual service model. Now, if I go back to the CMS descriptions in ita, these two things are to some degree actually collapsing to one. It is really a state transition that you manage the state of is a particular CI in production or not production is this change going to happen or not happen. What we are arguing for is that it actually makes sense to split it up. And there are a couple of reasons for that. They're easier to illustrate if you go to this diagram which you've seen a couple of times before. So these are the components that are actually controlling the reference architecture or the information model. And where the actual service CIS or the actual service model is very equivalent to what you typically see in a CMDB, you would have a reasonable complete picture of what you should have, not saying you do have, but you should have a reasonable good picture of what is actually in production. But that might not really be what you intended to have in production. The system that understands what you really should have in production should be what is in the generic term here called the fulfillment execution component, the one that is responsible for pushing stuff into production. And again, in many organizations, this is a manual process. It's controlled by IFCs and you do all the stuff, you configure a server, you put the software on, you configure it, et cetera. But we're all moving towards something that becomes more and more automated. And that automation system would really control what it desires to go into production. And what we then also see is that in any given organization, you will have a number of these functional components in place. You would have one that is very good at doing infrastructure for cloud. You have another one that is good at application layer. You have a third one that is good at providing laptop services. They function very differently. They each have a concept of desired service, but they live in different systems and they need to interact where the CMDB here would be much more focused not on what technology but what data center goes into. So you sort of have a, when you're looking in an outsourced and multi-supply environment, the organization and the people and the systems responsible for the desired service is inter-imrelated to the organization systems that are responsible for what exists in the data centers. And therefore they cannot live in the same system. They need to be split up. I see a number of people saying, is that really true? And that's fair. I mean, if you just say, yeah, that sounds reasonable, then I would be scared that you weren't really thinking about it. But that service background here is a very essential part of what we're doing in IT for IT. That is how we actually, at the end of the day, tie all the rest in but still being able to do it in a distributed manner across multiple suppliers, et cetera. So with that, I'll hand it over to Richard that has tried to take some of these concepts and also be part of developing some of these concepts. Thank you very much Lars. How do I advance slides? No, exactly, please now. Thank you very much. So I'm going to tell you a little bit more of a request to fulfillment as we started in 2008 looking at the materials that were presented by Carol. We found that one value stream was missing, namely request to fulfillment. We had discussions in our company, which is a merger company, and I'll have a slide with a little more details on our problems. But basically what we had was an internal distribution department delivering services for end users, IT services for end users, I have to say. They delivered all these in IT services themselves. There were no vendors involved. They acquired the hardware themselves. And whenever an end user called with a specific question, a specific demand, they looked at the capabilities of other vendors and they delivered the service. So in the end, we had an end user catalog that exploded with a number of services that were not no longer standardized in any way. And there was no means of getting a smaller standardized set of services other than when we would actually look at it from a broader perspective. And we did it in looking at this picture and started discussing within our company, how do we actually make sure that we get more standardized end user services and also relate or solve other problems that we have in our company as well. And we look at a little bit more detail here. This is the level two, if I'm correct, because it's not a formal representation yet. But this was our discussion slide when we actually discussed, sit down with our business and discussed what are our problems. One of our problems were the exploding catalog of services. But the other one, a very important one, was that we actually had no track on showback and chargeback because we used CI administration to do the chargeback and showback. But in the process of delivering all kinds of requests, some of them got mixed up a little bit and not all the CI were correct. So in time when some materials broke and got disposed, the showback and chargeback was actually still going on where the IT service was no longer delivered. To keep a more coherent set of services, we started drawing a picture. And that's this picture. It's quite difficult to read and it's late already so I will not try to bore you with every detail of it. But the new thing in this is actually that we created the offer catalog component, the service catalog entry and created link to the service backbone that Lars just described. On the other hand, we added an offer which is the commercial setting of the service that we want to provide so that a specific same service, technically the same service can be offered to different departments, technically the same with two different chargebacks, types of chargebacks or even we can discuss whether or not a specific audience has a right to order a specific service. The other new thing is that we have a subscription to manage that we actually do the chargeback only when we have a subscription in place. We created that artifact so we ensure that whenever we deliver a service, a subscription is being created and whenever we change a service that is a new request for changing the service that is being delivered, we also change subscription. And that is then tied back to the chargeback or showback whatever you would like to have. The other thing is that we also now have a link to assets which is down here and the fulfillment execution engines because in the couple of years that followed after 2008 we got other partners in delivering the IT services as well so all of a sudden we have to broker between different IT partners delivering parts of the service and we had to make sure that the components that make up the service actually being constructed into an actual service that we can deliver to our end customers. So in this engine, the fulfillment execution engine is now responsible for making sure that all the fulfillment and deployment engines, also other external parties, IT suppliers, make get their part of work being distributed to them and either automate delivery of it or manually deliver that part of the components of the service. It very much helped that we actually could draw this picture and then map our existing systems at that time to this picture. So now you see the backdrop here, the components that we saw on the previous picture and I looked for applications that fulfilled or partly fulfilled the capabilities of the components and we quickly found that there is a lot of components that actually were not existing within our company. There were manually tasks which is very expensive, a lot of errors made in that area and one of the objectives was to standardize but also to speed up the delivery of those components of those services, therefore automating the delivery of it. We also found that there were systems which we created ourselves, there were systems that are of SAP, there was a lot of in the usage area when we do the monthly or weekly chargeback, there were a lot of Excel systems being used, Excel sheets and we had a part of the organization that was already looking at Microsoft orchestration components to deliver components automatically. Now we have a picture that is simple enough to go to management and explain look we have a problem, there is overlap in capability in applications that are fulfilling the same functional component which is not bad in itself but can be bad but also we have caps and that made it very easy for us to discuss a project that is now in the way delivering this request to fulfillment value stream with a standard tool set looking at the delivery of end user services with also infrastructure services with ATOS where we tie the actual fulfillment engines of ATOS to our own systems making Ahmed the real service broken. So we had the bigger picture, I also explained that the need of integrations with our vendors was more clear and we could explain that also to the vendors what we expect from them and what we will do is more in future ask for standard integration so that whenever a new vendor comes in we can say these are our services, we would like you to deliver a deployment engine for your services and this is the service that we will provide you to actually deliver those services but also there is a information stream going back to update the the CEIs and the other picture that we shown and maybe I have to simply show it whenever we talk that kind of services we discuss all of the integrations needed depicted by this picture there's in other areas we have also similar kind of discussions because Ahmed is a very architectural driven company so what we do is discuss in the IT for IT space that all of this is being modeled out in our internal architecture department where we create archimage pictures for this and we start mapping all of the applications in a similar way that we that I've shown earlier to this to this backdrop helping us the distinguishing between what are the integrations there what are the integrations missing but also if you look at our landscape where we deliver insurance policy systems consisting of SAP, Microsoft and Pega and all other types of legacy applications that we built over the last 30 years how do we actually manage that and this picture would help us very much in actually making sure that we get more grip more insight in how we do that and I would like to hand over to Lars to summarize thank you very much thank you Richard so it's been very fruitful in our work together with in the consortium because Agmira actually took a lot of the early versions of the ideas of course Richard was was scared whenever we then changed it early versions of things like this tend to change I think we are getting to a reasonable stable one but we still have a number of outstanding questions where we would like to work with with more companies in figuring out what is the right way of doing it we didn't have time today to also take say for instance Pricewater of Cuba but Sue has been working very much within the consortium on the on the detector to no sorry requirement to deploy area not detector correct but the requirement to deploy so development area the build area and again looking at how are all these things actually working in a nice manner but that will be for another day so to summarize up uh and yeah we were here on the last one uh so one part was the service backbone that is a new concept it's a very important new concept in it for it and to understand what that implies is is important uh we believe that is very innovative and will allow you to actually connect much better all the various parts of it and the second part was the in terms of real innovation here would be around the R2F all of that consumption part which is not traditionally being done so much but it's not just a a again a piece of paper a theoretical piece of work but we work closely with with companies as a consortium on on figuring out what makes sense for us and organization and and Richard is actually implementing part of this as we speak so that's pretty exciting so with that we are five minutes before time but uh so there are time for questions before we go into the question round or maybe we should just go into the uh so if there are questions specific to the material that Richard and Lars have presented we can take those now and then in a few minutes i'll invite charlie and case and gaon back up to the platform and we'll run a full panel for you on the afternoon's work but i think once again we've a a searching question from our friend over on the far side there thanks thanks steve it's nice to be called a friend that's nice uh Richard i was quite interested to uh to hear or to learn more about the perceived value that you have received in your organization applying these frameworks or to execute the activities you've just outlined since 2009 do you have any kind of a rather than uh untungible volume like uh better agility better flexibility or better visibility to you or have you done any kind of commercial audio assessment in terms of what's the impact to an organization from a commercial perspective or applying or applying such a process i think that's a little bit too early for now but if you look if you look at it at this um within agmia there's a lot of pressure on costs the the insurance market in the netlands is um saturated a lot so the the cost of one policy needs to go down and if on my personal opinion is that if we never we get this service backbone in place we get a far more better um knowledge on how much one policy one insurance policy would actually cost us from it perspective um but it's a long way to actually getting there i could i could maybe add to speaking also to other customers of hp where we implement the the r2f uh part it's a lot around uh this is a taxonomy that gives you an ability to implement automation uh in a big way there's a lot of project that goes on oh let's build another engine that can automate something or let's put in some more workflows that is automated in in whatever automation technology you have but this actually gives you a way of structuring how you do that all automation and that helps uh a number of our our clients to to to find out an important piece that wasn't uh isn't easy to just read out of this it is in the white paper so uh is that between sort of the the upper part and the composition component here that's two sides of the catalog there's actually an aggregation going on if it's implemented in the right manner these are actually different systems right so you have a single place where you go in and you manage all subscriptions to all departments to all lines of business but it's a thin layer that only concentrate on the commercial aspects or how you present it and then you have several system beneath that are specializing in particular technology like private cloud or sap application modules or whatever right um and and they will be different but you aggregate them into a single place and and that that creating that kind of taxonomy suddenly makes it much more clear what to do and where to concentrate I think um added to your question um we we did of course make a business case for implementing request of fulfillment and we found that whenever we do it right and we can automate let's say 90 percent of all the activities we could reduce the number of FTEs within that department by roughly 20 to 25 that's a lot um but if you look at at this um majority that we are currently today um we will not meet that 90 percent yet that's one um reality that we have to face and the other one is that those are people that are not actually being put on the street but we need those people other way in the in the IT department to solve other problems that we currently can deal with so business case is very if I would ask my CIO he would say to me name the name of name me the name of the persons that actually would leave the IT department because then I would have a real benefit but um it's it's not always quantity quality as well okay thank you regarding the service model back but how do you position the service service for your architecture right it sits there thank you no so so the uh and again well I could I could go back with a question what do you mean my service oriented architecture uh and and in the sense that there is a couple of different interpretation of what it really entails and how big that concept is right um the if I go back some years and and service oriented architecture was all the rage of of of how we would get the new style of IT well that's maybe five ten years ago when that started and we should be there today but we are not there today and one of the reasons in my view is that this part never actually really got managed and so and this part being the logical service design and and and then you could say well I know companies that are doing it very well they're using uh say rational tools from from IBM that that can actually really manage all of these service endpoints and understand the dependencies uh etc and then once you do that you can start act because the important part of these service models is that they have dependencies right you shouldn't develop monolithic application you should develop services that depends on each other and you should actually be able to track it all the way up to the conceptual service so that you can make decisions about those dependencies and the service oriented architecture is the governance structure of saying is it really true that we have these dependencies and and how do we also design reusable things that can be used at least in in my interpretation of service oriented architecture so service oriented architecture fits very nicely into this concept and can help you in in actually make it usable because the problem we have today is often you have some nice service oriented architecture work going on there but when it actually gets deployed a lot of this information disappears and and are not reusable and then you're losing a lot of the value and you kind of either see it up at the uh up at the business level either and then the value of it becomes much smaller so this can help make the value of service oriented architecture is much larger if if i may last can i can i make you a bit more bold would it be fair to say that service oriented architecture generally is a a faddish type term it's quite nebulous we have got a more prescriptive orientation to service and indeed there's a white paper amongst the collateral on the forum's website now i would encourage you to take a look at so large as the service model management is is the white paper so again it's it's it's a key underpinning concept that we're aware of that we need to fully articulate okay any other questions in the center there so you think you should take a seat oh we'll start on the panel by sitting there yes you should you should be the the fangirling very vital focused organization Norwegian healthcare thanks to hb by the way you say that i only think to this forum so in the common language if i was to address this management why should we do this in a common language this is what do we gain before well we are an idle shop as well but what i found is that whenever i start talking idle process owners start looking at their process and their process alone and and they look at how do i manage my process in a most optimized way but they are not always aware of what is going on in the other processes that are connected so presenting this kind of picture and you could also draw this picture on a process level of course we're presenting this kind of pictures to me helps me making sure that process owners that are for instance in the area of problem incident event they actually come together look at the tech to correct and understand more how they should work together optimize it more in a value stream approach complimenting that would be also to say that idle as we discussed in an earlier presentation today is more centered around the right hand side of the picture also turned on an 80 degrees here and and so all these process optimization might be going better and better within say just detector correct but their linkage in to say what is going on in the development side is is in general basically missing right it's it's the and i've seen cio's going out and saying well they want the developers to go on idle training so at least they understand what the operational guys are doing right but he does recognize that that idle only really works for his operational staff that that's where it has its value and we're trying to to go more to about which would actually benefit i so because it it would it would help enabling the dev ops version of i so in my view as as one example here you had a yeah i actually had a question i got a question in a break from somebody who's not in the room that's why i just wanted and it's very much in context because okay listen to you and essentially you were saying if you you keep i tell this not describe integration so we need to do this way so okay i've got all the different processes i've got a prescription that says okay here the process steps have integrated with other processes here's the data handshake so essentially you get to an automated tool chain right that that you can get from from looking at it why isn't that enough why is why isn't that enough so what what does the service back in addition to integrating tool chain approach would you johnny well i'm not sure this is on i'm not sure that you actually do get that just from i tell i mean i think to both questions i think i think the key point is a number of us in this room i've had the identical experience of looking at ital and realizing that at best it was a reasonable statement of requirement and we still had substantial design and mapping of existing a state to actually start to make sense of how ital were working in the process of doing that i came up against all kinds of ambiguities and gaps you know from an architecture perspective and i think that's i think that carl not to put words in your mouth carl had much the same experience i think richard is at similar experiences and so i think the thing with me learn learn from you know rather than yet again reinventing this which you will if you are in a company of some size we'll find yourself doing you know that would be the value proposition i'd like to add to that that if if you do that and so even without the prescription and i tell you managed to actually figure out how to to put the right tools in place and a lot of vendors are going out with tools that would support you so you're not starting from scratch necessarily but if you don't have the service backbone and and and and this essential service model it's very difficult to report out from so so you want to to get to a point of actually understanding your the quality of your conceptual service right so so your portfolio planner how do you really know where the issues are how do you explore what is going on there you have maybe five different releases of time tracking system to take that example again and and in different regions with with whatever so how do you know what is actually part of that conceptual service typically you don't well you can if you run all the spreadsheet exercises but but that's not really that's that's very reactive so the data model gives you an information model that that also allows you so you can go and use the boss for a big data they're probably not big i don't think there we have enormous amount of data in in it actually even counting all the events etc compared to some other industries and what they're doing but but the connectedness that's the interesting part you can get out of it and you have to put that in content with one other thing and that's the fact that pretty much everyone we talked to from an it department perspective a multi vendor and multi supplier so there are several it vendors in to deliver these blue boxes and there are also several partners in terms of delivering the service so you outsource the the networking infrastructure to one partner the application surveys to another partner etc etc and so if you don't have that common language from the data model perspective so you can say i really want to have information about your incident and that's the fundamental information i want then you will never be able to actually manage it you can manage the individual process but you can't manage it good answers there's a saying and the guys running the operations that Norwegian health care say that to get in contact with the architects you need to know someone in NASA to really find these people because they're i-flying with this help closing this gap yeah yeah i mean it's it's at the end of the day it's not rocket science good taking your your NASA analogy it's it's it's actually just doing what we as it predictors doing for all the other industries we've done it for for enterprise management we've done it in within the manufacturing industry we've done it in many different industries why are we not doing it for ourselves and that's that's as an industry as opposed to individual IT organization that's what we're doing here if i may add to the workshop with organizations basically giving them this picture you see on the screen and the moment they see it they start relating great into it in a way that they understand if i then open up a uml type of models and whatever i lose them completely if i stick to something simple they engage with me so yes i need those umls to really go into the details understanding how it works and having you know the science coming out of it yes but simplifying it to a level where i can communicate that's really the power of it and the the point of what we are constantly doing is it's not around this picture that is there we have reporters behind it we have those details so if there is a choice of this is how we want to work this is how we're going to operate there is a material that they can really brought into you know into the organization to help them do the details and i think that's the power of the reference structure and just to come back with another biggest question um you know we seem to be very much into uh idle history is what it's all about but actually when you read the the diagram from in this case right to left the amount of influence of idle on those domains is coming less and less how many of you have actually implemented all idle processes that are out there and it's really based on how many areas between different versions so depending on where you are you know i've not seen any organization that has done exactly the way idle described and that's also the issue that you don't have a common discussion point if you just stick to that that way of working um what we said it is not only idle it's also code with all kinds of understand that said influence the way you talk about how it operates and that's the difference okay thanks thanks case i'm reluctant to interrupt the flow but i want to invite georg back to the are you good there okay then we'll we'll we'll stay as we are so further questions from the floor for the panel plus georg who is here amongst us have a completely different question it's not content related but it's related to the or your plan or the plan of the forum i for the forum for developing more content over the next coming months so what's the kind of the shopping list of things that you or you want to focus on ah come tomorrow because we have an open house session whatever we did is we looked at at the reference architecture as it as it stands here and we discussed all the lines and whenever we come back after a couple of weeks we start rediscussing the same lines over and over again and at some point in time we decided let's stop that kind of discussions let's let's look at scenarios let's look at scenarios that we can actually implement within our companies let's look let's look at the scenarios that we would actually benefit from as our companies and we had created a short list of those scenarios that we would like to be implemented um for ourselves but now we are at a point that we also look at you and your scenarios so tomorrow we will have a session where we actually list those scenarios and start prioritizing and i would like to welcome all of you um to to actually help us out getting a prioritized list of scenarios in place Richard we've got financial and asset management on our list right we have yeah those are looming large for a number of people in conversations yeah and i think we would be we would be very readily able to um propose some some good strong architecture support for that domain yeah yeah also adding to to to the list so so uh case mentioned it a little bit is saying there's something around SLA management service level management and and and you would see a glaringly hole in in in this diagram because you can't see SLA anywhere but there is actually a place for it it's sort of a white spot right uh no that's not the way we work but but what we have the the the way we want to work is that we are very much as Richard is saying driven by these scenarios or guidance document and then the result of that would be proposals for change to the normative standard so SLM is one area that we also look into and there are some proposals for then changing the normative and there are two several ways it can change the normative standard there is one where we say at the even at the level one diagram as you see up here we need to add something or modify something i i i i don't have a big problem with adding or modifying necessarily but we have to be very very careful when we do it up there because that's one of the reasons why we did the layer is that we can have something that is reasonable stable at the top level and we think that with all the validation we've done we are in a pretty good spot but there are still a few things wrong or missing at that level at level two there are more things to be done at level three which is where it becomes the archimede formal repository where we have the attributes to the key artifacts where we also list some of the more auxiliary things that we normally would see associated that's the area where there's a lot of work to be done in the incident a case exchange we we've come up with something and there are a couple other proposals but there's a lot of work to be done there yeah and and then in terms of prioritization we there is a bandwidth limit to how much we can do in one go because we want to make sure everybody everything is vetted to be consistent but we try to set it up so that the if we if we imagine that we keep running snapshots in in whatever cadence six months or something like that then the guidance document can be a hit of a snapshot and then in the next iterations we decide to take it back so there's a lot of possibilities for parallelization of the work so it's really up to how many people are contributing yeah and just to articulate that in time terms the way that we've organized our time here over the next couple of days is to move from information giving an invitation today to if you will a recruitment and development function tomorrow we begin with an open house then we will spend time with new members onboarding them and immersing them more deeply in this and then in the afternoon we will look at putting you directly in touch with the people that you've seen here today and at previous open group events so it's continuing to grow that and recruit to the opportunities where we can continue to develop the collateral so it's a pity that you won't be here tomorrow but I do hope that your Capgemini colleague will maintain that momentum and move things forward and that will be great and did you find that link good we're going to need to wait for Steve to run the mic over to you thank you Steve thanks so much I'm sorry to say I missed the talk about how IT for IT fits in the broader standards landscape so perhaps I should have asked this earlier but how this model takes advantage of enterprise architecture practice in the company does it make a difference if you have an enterprise architect or you don't well the first part is that if you if you have a TOGAP based enterprise architecture practice which I assume you have because you are here then it's very much around the to be architecture and then analysis architecture and finding the difference and then creating a roadmap based on that that's a very simplistic way of saying it but then the IT for IT reference architecture is the vendor independent to be architecture for well basically in I'll believe any IT organization then of course you need to specialize it into a concrete to be architecture for your organization which will have all the other kinds of prioritization that needs to go into it so Richard that's fundamentally what you've been doing right yeah yeah not sure what I need to add to that what we did within our domain architecture for IT for IT is we looked at it to be as a to be architecture mapping all existing applications like I explained and also finding gaps and created our roadmaps from that so that's that's the way how we apply this yeah there's there's a bi-directional relationship that is almost like a strange loop you have the fact that enterprise architecture is itself a component and enterprise architectures are art you can be seen as an artifact flowing through the value chain or initiation value chain and yet it also is expressed as an enterprise architecture and so therefore is a consumer of our command to GAP well think about it long enough you right so crazy standard because I have a second question I don't totally get what is an artifact is it a process has it got a budget has it got someone responsible for it it's defined what's the benefit let's say that each artifact brings and and lastly are all their artifacts I can see on that slide the same let's say level of abstraction or there are some charge higher lower level okay I heard about six there I would definitely encourage you to come to the onboarding session okay but in the meantime I'll leave Lars to respond since we are looking at Lars's precious notation I'm not sure I capture all six questions but the the the first one is and and and that's say that's a real issue with the word in key artifact yeah and and especially Charlie helped a lot in in researching what is the right uh naming so we are in a transition phase where we also just call it um and correct me if I'm wrong here with data okay data okay so so so the word artifact elites people to think about it also being physical and have an asset quality of some sort which is not the incense so it's basically just a data object we need to go ahead we need a little more amount of work here but but in general what you see here as the circles are largely conceptual entities so it's an entity relationship model you can think of them as data high level data objects there are there is a concept of artifact that is more akin to say uncompiled source code or compiled source code assembled into a package and those are more true true artifacts in the in the industry usage and certainly as you see them expressed in standards like you know and I think we are still settling on some of that nomenclature because we are certainly also interested in that actual you know comp those computational artifacts as they go through the value chain and then you have this this more almost metadata phenomenon you know where you see defector incident as in a sense metadata above the actual computational phenomena getting out of the weeds here but you know to to to take it simpler as you can say if you feel a lot of the black key datum objects if you will like incident we keep talking about incident that's a pretty simple one it's a record right it's reasonable well understood in the industry it's not very complex though unfortunately we're still arguing about what are the individual attributes and life cycle states etc it should have but it's fairly simple if you go down to say an actual service model that is fundamentally modeling out what is say the the the production environment looking like for say the time tracking system then that's a complex thing right consists of a lot of individual configuration items that relates to each other what does that look like that's much more complex and and and you could say when it comes to the to the realized one the the the physical ones that there is a a long history also in the industry around the cmdbs and how do you model in the cmdb and we basically just want to inherit that there's no reason for us to reinvent the wheel around that as you then move to the to the to the right in that diagram it becomes a bit more fussy because there isn't a long transition for modeling that out in details so if you take something like the the service release models the the model that governs a service release that's actually not necessarily well understood in the industry what that should look like the best examples we have of of standardization in that area would be other togaf the lot of that people in in the industry are sampling around togaf which is not an open group standard but another standard policy that that that governs that one toskar did i yeah teas and blitters right yeah i mean i mean toskar sorry for for confusing everyone here the the other one would be heat from the open stack community they're actually trying to model exactly that area of of of the model and again we're saying well we don't want to reinvent that wheel we're saying it has a place within the larger organization right thank you last all six but of all six that was two of the six at least do do please come to the sessions tomorrow it would be valuable to have your continued if you will observation okay thank you any more questions there was a discussion earlier the question earlier i wanted to respond to when i was still on the floor which is what is the value of doing this and i think it was addressed to richard i wanted to chime in on on that the as it becomes more and more an essential product of the essential component of all of our products i think it's essential to have a strong capability for managing it and the value is actually increasingly to be found in your primary value if it's your intent to bring to the market a service or a product offering and it is a larger larger component of it it's no longer nuts and bolts and widgets or you know food products or even food products that you know more and more it in order to bring them to market in a timely way let alone you know the connected car and the internet of things really the risk for not having a well-managed and it value chain is the risk to your company's profitability and so you know it's not a question of how many people can we take out of the data center anymore you know it's like saying well why would i you know why would i improve my hr process you know i you know i'll personally improve your hr process and continually improve because that's how you get qualified people and to your organization of course you're going to want to improve your financial processes because you know that's how you govern and control that very critical aspect of your business same thing goes for it and so i think you know we have to really look at you know what is what is the cost to not having well-managed it and increasingly it is it the constraint you know to actually bring in things to market it's no longer in the back office it moves into the front office it becomes embedded in actually your company's offerings to the market how can you afford not to do this i would think that is that that's it so are you considering introducing an implementation guideline and the maturity framework let's say in order for the it organizations to gradually implement or align with this it reference architecture well when you start okay so speaking purely personally um at a high level maturity frameworks they seem to make sense you know i mean obviously you my knowledge is progressive you can't study calculus unless you have a background in trig and algebra right so maturity intuitively makes sense but i think the maturity frameworks also can be badly abused i'm skeptical about some other usage i think that there's actually been some serious retrenchment of the united states from i won't mention the capability frame by name but i'm aware that there's been some very critical studies that have gone on in the pentagon have found you know actually empirically there isn't any you know any value there because they have no large populations of projects that they can compare you know you know did they use the framework did they not use the framework they're not finding statistically any meaningful difference this is one of the under reported developments in the it industry in the last few years however you know that doesn't change the fact that it's useful to have you know some level of process assessments and benchmarking and how does you know how do you even begin to you know have you know come in as a consultant and assist somebody if you haven't got you know some some understanding of well they want to they're here and they want to get there so certainly i think as we go through the next few days we are going to have our conversations about you know actually turning it for it into educational framework getting into the training and certification and accreditation of the training providers and all of the the mechanics that are necessary there how we do that you know i will have some opinions about that but i think there's certain things you just have to do that are going to be relevant i mean no i i mean within our company we uh we we do a lot of engagement with customers where we take this reference architecture as a starting point for for a dialogue and what we can do and we certainly see that there is a big difference in maturity of our customer base and and so you could say for some customers we basically know we don't want to go in and have a dialogue about that because you you you you're not even ready to take very very simple steps right but but for many for instance we can go in and say okay this is the big picture but let's concentrate on detector correct most organization has a reasonable set of of practices around the run stuff right they might still have players they might still have 50 systems and what have i just to manage events etc but but then you can start building up where are you maturity wise and how can you get to that better in-state on detector correct but they're not ready to talk with on any of the other ones we see the the the request to fulfill very few companies today are actually mature enough to really have the right dialogue around this it's it's you need to be where you really realize that in order for it to survive it needs to become a service broker and and and a lot of people can say that word today they couldn't a couple of years ago but they still don't really have a clue as to what it means right it basically is something we need to do in order to avoid being taken over by amazon or something like that but but but having that dialogue is is difficult so there certainly is a maturity thing involved in this we would and and even if if if Charlie is saying well it's we have to be careful about formal maturity models because they can be dangerous there is an idea about having a basic understanding what does it mean to uh to be able to start tackling one of the value streams right it's also how we work ourselves I mean we use scenarios and those are business driven objectives that we want to reach so it's not like we just talk about we're going to do something around one particular problem I think that's also what we're looking for from the community here to help us understand which scenarios are relevant in the market at this moment in time that will help customers with the organization that will adopt this so our problem is x so there is a scenario that describes how to solve that using that fast action and take from there so we don't necessarily as a maturity model to find that cash there's always something that in bugging the minds of people how should we solve this I think that's an approach that we're more keen to that having only a maturity one I do think that it's necessary to have something like that and have a start on this question and again it's something that's high on the agenda for this group this week okay further questions I'm seeing no hands moving it's it's been a long but very very memorable day so what I'm going to propose now is that you join me in thanking the wonderful team of experts it's my honor to lead and I will give you a head start towards either the bathroom or the bar to help us celebrate it thanks again for your questions