 De volgende seizoen wil ik opnieuw praten over wat Lars zegt. We hebben deze mooie referentie-architectuur en in de einde kan we het eigenlijk gebruiken, want het is leuk als we over dingen in de buitenkant denken over hoe de wereld moet lijken, maar opnieuw het in reale leven is wat we nodig hebben. Ik zal een logische laagje steken, dus ik ga niet op fysieke implementatie gaan laten zien. We hebben dat ook gedaan, dus we kunnen praten over dat. Maar eigenlijk in de groep hadden we deze discussie omgaan. Wat is er dan aan als het niet een unieke sourcen environment is? Het is niet een IT-organisatie die het zelf moet automaten, maar wat is het? Het gebruikt sourcen van veel verschillende partners. Dus er was deze werkgroep begonnen, die eigenlijk gaat na multi-sourcing. We begonnen met een grote scope, waarin we eindelijk discussie hebben over wat er zou moeten zijn. Dus we stoppen dat en zeiden, laten we focussen op eerste instantie-management. Er zijn twee objecties die we willen ontdekken. Ik zal het over dat praten. De eerste objectie was, kunnen we eigenlijk de referentie-architectuur gebruiken om een businessprobleem te handelen? Een businessprobleem van IT, natuurlijk. In dit geval gaan we kijken naar multivander instantie-management. En dan de andere deel was, als we dat doen, kunnen we eigenlijk identiferen of er issues zijn met de referentie-architectuur zelf. En kunnen we dat proberen? En hoe gaan we dat gebruiken om dat te komen? En eindelijk, als we dat hebben, dan hebben we al wat werk gedaan. Wat zijn de conclusies voor multivander instantie-management? Ik heb het gevoel dat het niet een rocket-science gaat worden. We hebben onvermiddelijk een heel simpele item gekregen, voor ons dus te bevestigen in de eigen werk. Dus naar LARCH, de introductie, heeft hem die structuur van de referentie-materiaal gegeven. En zoals LARCH zei, de zon van de functionele component was de langzaamheidsartificatie en de specifiek vent production gesloten met dat. Maar om brand te installeren in referentie-architectuur is dat niet genoemd. En zoals LARCH was indikating, hebben we scenario's de capaciteit van de disciplines. Dus wat we deden, is dat we begonnen met een scenario, in dit geval multivander instantie management en begon te zeggen, oké, als we de multivander instantie management willen doen, die de capaciteit wil gebruiken. Dus dat is waar de capaciteit van de disciplines in komt. Dus we hebben onze eigen structuur gedaan, of wat we hebben gezegd, dit is wat de referentiearchitectuur ervan is, het IT-referentiearchitectuur, en we hadden het in de scenario. In onze structuur, Lars heeft het over deze niveels gezegd. Dus ik ga de maximale niveau 3 stikten. Ik ga er niet verder in mijn discussie. En dit is een representatie van de referentiearchitectuur. We proberen je te beboven met hoeveel mogelijk het is, zodat het stikst. Maar eigenlijk, als ik dit bekijk, is het de koor van de referentiearchitectuur met de functiecomponenten van de blauwe blokken, de blokken en de artefactuur als de zwarte dotten. En de zwarte dotten zijn de service model backbone. Ik kom terug naar dat later. En dit is echt wat we brengen tot de table als ze zeggen, oké, dus laten we proberen, als ik de multivander ingewikkeld is, hoe het werkt. We hebben eigenlijk de scope naar de focus-area. En zoals ik zei, we proberen het te doen met het simpel, iets dat iedereen weet, maar dat is echt waar mijn focus gaat worden vandaag. Dus wat gebeurt erop? In een environment waar we multivander sourcen. We hebben begonnen op deze reis van het start. En we zeiden, we moeten weten wat er is om sourcen. Wat is er? En we stappen terug een beetje, en het eerst begint te zeggen, oké, dus wat zijn de soort guiding patterns die we kunnen zien. Als we in het groep over onszelfs praten, dan bevinden we snel dat er verschillende manieren van hoe organisaties sourcen kijken. En hoe om sourcen in de lijn van denken te ontdekken. Ze maken keuze die impacten op hoe je een sleutel maakt. Dus we stappen terug en zeiden, kunnen we een komende pattern ontdekken met wat iedereen gebruikt? Of moeten we er een variety van ontdekken? En eigenlijk hebben we er een variety van ontdekken. Dus laten we eerst praten over wat multisourcen is. Dus in onze reis hebben we de lijn van denken gehad. Er is een lijn van business met kustamers. Je weet, er zijn kustamers met wat ze doen. Zij sellen oil, sellen insurances, sellen, ik weet niet wat. Nails, wat nog. Er is een centrale IT, die eigenlijk is responsieve voor de IT-operatie, met een CIA-office, PMO, er zijn alle soorten activiteiten erop. En dan zijn er soorten services die er gebruikt zijn van extreemers. En die zijn dingen zoals hosted services, de gebouwenbusiness met sourcen. HP doet dat ook. Outsourcing is genoeg. Deze zijn typische dingen. Maar je hebt ook cloud services, die zijn veel meer agile. Dus dat is ook daar. Maar de verschillende manieren van sourcen zijn er ook. En een ding die we hebben gedaan is zeggen, oké, er zijn veel companies als ze sourcen. Je kunt eigenlijk kijken naar veel internere partijen als gewoon een andere sourcenpartij. Niet externe, maar intern. Dus laten we niet verschillen tussen internere sourcen en externe sourcen. Laten we dat standardiseren. Het is eigenlijk sourcen. En het kan beïnterne, externe. Het maakt het veel meer makkelijk. Dus dat is één ding die we hebben gedaan. Maar als je kijkt naar het van een deel, dan zeg je, oké, dus als ik al deze elementen heb komen in, en ik, op het bottom van de foto, en ik moet iets supporten centraal tegen mijn customers, mijn internere bussiness unit en de consumer van mijn IT-services, er moet iets zijn in de middel die het verbindt. Het kan heel simpel zijn, gewoon een breukere functie, die het basis van services en rapsen alleen in SLA om het te geven voor de consumers. Maar het kan ook zo complex zijn dat ik er verschillende soorten services verbinden in op een en dat aan mijn partneren, aan mijn consumers. Dus de concert van de service integrator is het tweede element die we hebben gegeven wanneer we op de multisourcing gereden. Er moet iets zijn dat is responsabel voor de integratie in een IT-organisatie. En dat kan ook gezocht worden. Het moet niet necessarily iets doen internally alleen. Dus, gewoon de informatie, eigenlijk wat er gebeurt is, informatie komt van consumers, ze vragen wat ze de demanden hebben gegeven, die naar de service integrator, service providers, ze geven de informatie terug en zo. Dus dit is een heel simpel informatie gevolg dat we kijken. Dus met deze concepten in de achtergrond van mogen we begonnen te zien, oké, dus als we al deze verschillende implementatie en hoogsourcing hebben gedaan, kunnen we standaard patternen vinden. Dus de eerste is, we ontdekken en we begonnen te nemen. En dit is gewoon om te frame ze voor de rest van de discussie. De eerste is het centrale setup. Het is het centrale setup. Er zijn situaties waar de sourcing, de sourcingpartner, de organisatie die zegt, we willen de sourcing doen. Ze besluiten, we implementeren iets in een tool en we veranderen de data in één plek. En alle vandaar, alle vandaars moeten loggen naar datzelfde instantie, datzelfde tooling en werken op hetzelfde artefact. Er is geen andere manier om het. Dus dit is het centrale setup, alle loggen werken op hetzelfde tool en interacten op hetzelfde manier. Het is niet een heel geweldige pattern, maar het is zeker iets wat we zien als een potentie. Nu, als je de referentiearchitectuur wilt gebruiken in deze pictorie, het betekent dat er één functie componenten, en in ons examen hebben we de instantie management component, de functie componenten, met één artefact. En voor de completheid van de pictorie, heb ik hier de CMDB functie componenten met de actual servicie componenten gecombineerd met het, om te laten zien dat het in de eind niet een stand-alone tool is. Er zijn relaties met het, het wordt meer belangrijk voor de andere patterns. Maar eigenlijk is één functie component één artefact. Dat is de belangrijkste deel. En als ze de servicie-provider of de servicie-integrator zijn, is er niet echt veel verschillen. Het is één instantie, dat is wat je werkt. Maar het heeft implicaties over hoe je je zelf organiseert en hoe je werkt met je partner. Natuurlijk. De tweede pattern dat we ontdekken, we namen het replicaties. Dus eigenlijk werkt het een beetje verschillend. De capaciteit die je wilt is nog steeds dezelfde instantie management als de capaciteit die je wilt. Maar in dit geval heb je niet één functie componenten, je hebt twee functie componenten. Een is door de centraal, sorry, door de sourceorganisatie. En de andere is door de supplyorganisatie. En beide hebben een implementatie vanzelf. Het kan dezelfde tool zijn, het kan een verschillende tool zijn, maar ze hebben hun eigen implementatie. En ze hebben ook hun eigen artefact daar. En zondag is er een hele verschil in wat er moet worden gedaan. En we gaan naar details van dat. Maar dit natuurlijk ziet er heel anders uit dan de vorige pattern. En de tweede pattern dat we ontdekken is wat we referentie konden. En dit is waarom ik had de event, sorry, een extra, hoe je het moet zeggen, een extra artefact, een functie component aan de foto. En omdat soms je de situatie ziet waar de connecties zijn over de organisatie. Dus bijvoorbeeld hebben we iemand sourceering, ik weet het niet, cloud environmenten. En we willen een setup niet een instantie management proces in die organisatie. We willen gewoon begrijpen wanneer iets ergens op de cloud environment weer een event komen in, creëren een incident in onze eigen environment. Dus zonder echt voorzien iedereen in hetzelfde tool te werken of opgepakt over de data. We hebben een verschil in uhandel eventen en je connecten met mijn instantie management systeem in mijn environment. Zoals een exemple. Dus dit is wat we referentie konden. Deze zijn de tweede patternen en we kunnen debate over de verrens van dit. Maar deze zijn de de ones die we bekeken. Voor de rest van de presentatie ga ik de referentie houden omdat het meer naar de confusie en als we aan het doen dezelfde over en over weer. Dus met deze patterns met deze verrens en we hebben alle deze in een verrens documenten beschrijven. We proberen dat we verrens documenten doen. Een van die is available wat is over de multisourcing en wat de impact van dat is in de referentie architectuur in general. We hebben dan gezegd oké, nu let's apply this en let's stick with incident management hier. Zo 1st of al in order voor me te really talk about it, I had to step back and understand. So what are we talking about? What is the concept? It's nice that we have this function component and artifact of ld, but we need to have something that I can talk to with my business. I mean, they're not talking about functional components to me. They're talking about I want you to be able to manage IT and as an IT management capability you need to be able to handle incidents. So as one of the core elements in de reference architecture we added capabilities. Not to prescribe capabilities in any way shape or form, but we took market standards like the ITO and COVID and you name it and we harvest those capabilities into the model to use. We actually have a repository which stores those capabilities with descriptions on it which are linked to function components. So if you want to build an IT capability model with that you can start doing that. So here you see the representation in argument notation. So we actually want to show that we also use other standards in the open group argument notation of capability in this case instant management and for those who actually can read it I would applaud you because it's too small. Within it a process step. Now a process. Now again we don't want to prescribe process because that's something that is for other standards already there. We don't want to reinvent the wheel. We actually say we harvest them just like the capabilities you harvest the process. So in this case instant management is pretty straightforward instant management process. Which is all fine. You know anybody who has done anything in IT before could have drawn that picture. It's not very complicated. So the other ones are actually also not complicated. What I did is with the central setup. You know we suddenly have this in a boxes of organization around it. And the way we describe it here is when you look at the instant management process with a central setup your supplying organization suddenly focuses on the same process internally. And your sourcing organization is actually the owner of the whole capability including the triggers going in and out of that particular capability. So this is how we describe this central setup. And then on the other side we have the replicated version. And I'll do it on the screen otherwise you won't see it on the other end. So basically what we said in this case we suddenly have two organizations which have their own setup of a tool. It's basically means they also have their own settle of the process. But from a capability perspective it's still one capability the whole is the capability that were after instant management. So we said there is a kind of a synchronization happening in this particular template. So we have instant management process on the sourcing and the instant process on the supplying part. That's all fine. And then the triggers in and out are basically handled on the sourcing organization as a responsibility. So if we look at this this is fine so it tells us we need to set up two processes basically. But that doesn't help me much yet with understanding how to actually implement a reference architecture make it real. So in order for me to understand this I went into OK I want to have a version of a process like you see here with all the block boxes you see with the arrows pointing to the right those are steps in an instant management process. And you can look up any process I don't really want to prescribe anything here but this is a instant management process. But what's more important that from a logical view from a perspective of logically how things are done I don't have a duplication of the whole process. I only have a set of steps that are suddenly handled outside my own organization in a replicated setup. So basically I need to understand where I'm going to hand over where I'm going to say this is now somebody else's responsibility and that's where the process helped me at least think about it. So I have errors going across organizational boundaries and it helps me already a lot. The other part is that I have this data object the business data object which is basically telling me there is an incident object. But if I look at it there's a version of it on the other side with my supplying partner as well. So I have suddenly the need to also synchronize data between two organizations. So by just applying the process the standard that you adhere to and putting it into this perspective using the patterns and using the reference architecture I understand that I have a data synchronization and I have an interaction needed at business level between two organizations. But it goes further because the reference architecture helps me to understand there's other information that needs to be available. So it's not only about the incident certainly that is there. If I do incident management I need to be able to connect to configuration management. I need to be able to connect to problem management. I need to be able to connect to maybe change, maybe defect. There's all kinds of interactions, events might be there. So these are all necessary to understand how does this work. Do we copy the data or do we have one and certainly have a referential set pattern for that relationship or do we really copy. So these are suddenly discussion points that you can bring to the table and having everybody understand what do we need to set up. And as I show here we basically have configuration management, change management and problem management duplicated. So that has an impact on it. That's a choice that has been described here. And you can make different choices but okay. It's still a reference architecture. So then we have an understanding what we wanted to do. That's the next layer is that, okay, how do we actually, how do we go to the physical layer? How do we go to the application layer? And for that we use the term what we call essential services and functional components. The essential services are services that are provided by the functional component to support the capability. And in this case, you know it's an incident management approach so you have an essential services manages an incident provided by a incident functional component. Again, architecture notation, argumentation here. And the central one, we discussed that before the setup with the organizational setup and the hierarchy of that but basically is one function component. But when we look at the replicated pattern which is much more interesting in our case, we certainly have this situation where I don't have one process, I have two. Although they interact with each other and logically it's one process, I suddenly have this need to have multiple functional components. Which means that I need to have provide services that exchange this trigger because I have this process trigger and I have this data exchange. So that's why we have certainly this extra box here in the middle which is called case exchange. And again, you might not be able to read it but case exchange is basically the term that we used here. So from a reference perspective, a reference architecture, that's not in the reference architecture. In a reference architecture we don't find it but in the guiding documentation it is clearly explained that in order for us to handle this type of information, it's there and therefore it's part of the non-normative part of the reference architecture. If I look at the more detailed version and it's becoming much more squinting eyes and Lars optimistically said, we can put it in one A4 and can talk about, well, as a hardcore architect I'm more than happy to create these type of diagrams just to make it more complex. But the bottom line is, I want to have an overview of what is connected to what for me to be able to understand this. So in here we have the same process in this case, again with the separation between the two organizations and suddenly I see the duplication of essential services exploding. I have on two sides a lot of essential services. Now, this also means that I can go to my partner if I'm sourcing and say, look, this is our setup, this is our process, this is our way we work centrally in our own organization. We do setup case exchange and these are the services that I expect you to provide. And as a partner that provides services to a sourcing organization, I can say, if you standardize on something like IT for IT, I know which essential services you want to have for me to work with you. And that makes my life much more easy in that discussion with my sourcing partners or with my sourcing partners. So, just to show a picture on more detail on the case exchange itself, the box here is the case exchange in the middle. It's not only the, like we saw on the process level, it's not only the individual object or the individual capability that needs to interact. If you really want to do this correctly, if you are expecting CIs and changes and problems being connected to it as well, you now have the need, the requirement to actually expand the discussion with your partner to say we expect you to handle problems. And because we expect you to handle problems, we expect that you expose the sensor service to the case exchange so that we can talk about that problem process across the line. We expect that you create CIs on your behalf. For us, we need to have then a sensor service that provides that CI to us, that information so that we can put it in our process into the CI process. And this helps us to table the discussion what we need to do. And all of this was done using the reference architecture with the interactions between them. Now, I'm sure that a lot of you have implemented case exchange already in your organizations, so I'm not hoping, I'm not completely telling anything completely new, but the bottom line is, using the reference architecture, I was able to identify what needs to go over the line. So the next layer is the data layer. And this one was a little bit more interesting for me because this pointed out something in the reference architecture where I really found something, well, I need to discuss that with my peers in the board. So bear with me a little bit, but what is interesting here is that, you know, on the top is the instant artifact that's being a business or a business object that needs to be connected. En the business object, from a capability perspective, basically works together with a lot of other business objects. This is defined from what IT needs to provide and how to service that. And on the other side, in the sort of supplying organization, I also have a set of business objects that are connected to it. So when I start mapping that to artifacts, which are in the reference architecture, I can then find out in the reference architecture there are connections between them, yes or no. I can see if the incident process, incident artifact, is actually connected to all of the business objects that I have. And what you can see here, that some of them do not have a direct connection with the incident business object. So the association that I use on the business layer, I can then map into the actual implementation layer and say, sorry, the application layer, and say, do I have that information connected in the right way? And do I know if all these objects can be used? Now, if there's no direct line in the reference architecture, it doesn't mean that it doesn't work, but what it means is that for, in this case, for example, let's take one, which is a knowledge article, is not directly linked to the incident. It goes via, in this case, the problem. So basically what it means is that if you want to find a knowledge article related to something that happened, you need to create that problem first. Is that the way you want to work just to know? It's a reference architecture. You can define that, change that. The other part is, in the end, there is a connection to all the carnality in the artifacts. So you do have the possibility to create at least the insight of what happens and what the information needs to be connected. The other part, which I've found interesting, is that there is this need to create this connection with defect. A defect is certainly in the NGO world, if something happens in operations, you create an incident. And sometimes the incident needs to be handled as something you want to change. You create a defect for the R2D failure stream, basically. That means that I expect that I can create that connection. Now, when I look at the reference architecture, I notice that there's a weak link between incident and defect. Maar als ik dat bekijk, van een artefact-niveau perspective, dan is er geen connectie daar. Dus het betekent dat we iets in de reference-architectuur missen. Of moeten we dat in een betere manier om dat informatie te behandelen? Dat is waarom we in dit werkbedrijf een certaine scenario praten. Oké, dus eindelijk, moeten we naar een niveau waar we over de informatie eigenlijk veranderd hebben. En in de structuur dat Lars zei, we hebben deze artefacten. We gaan niet om de bestaande artefacten voor alle attributen. Er zijn attributen daar. We gaan niet om de bestaande artefacten voor de fun van het. Eigenlijk, er zijn veel standaars of at least open-source type van werk. Wat is werk dat we kunnen versterken, dat we kunnen opnemen, dat we kunnen zeggen, eigenlijk, of je echt wilt weten hoe het aan de atributale artefacten lijkt, dat is één voorbeeld. De instantie heeft veel documentatie opnemen, dus ik zal niet betekenen dat dit natuurlijk uit waar we zijn. Maar wat we hebben, is dat we alweer deze referenties op andere objecten moeten hebben, zodat ik deze cardinaliteit between artefacten kan creëren. Dus als we een sleutel willen implementeren dat het instantie management is, ik moet kunnen connecten met problemen, veranderen enzovoorts. Ik moet weten of ik de connectie op de instantie of op de veranderen en waar we terug en voortkijken. En hoe doen we dat? Dus dat is voor de actuale implementatie. Dus in de eind, met deze hele exercice dat we in de werkgroep deden, hadden we eigenlijk een paar conclusies. Dus in de centrale setup, oké, ze zijn gegeven. De data sync is niet nodig. De supplier wordt de resolutie groep. Er is meer detail in de actuale werkgroep documentatie. Het gaat te ver om echt in de detail hier te gaan. Maar de supplier is gewoon een resolutie groep. De measurement van de performance moet iets extra in je instantie management systeem hebben, zodat je niet de proces van instantie management over de suppliers niet kunt bemeten. En de measurement van de service performance ook moet iets in de centrale systeem zijn. Met de replicatie, het wordt meer interessant. We ontdekken de need voor case exchange. We moeten dat triggeren over de organisatie. We moeten het exchange van informatie over de organisatie. We ontdekken ook dat, als je dat hebt, de measurement van de performance van je suppliers kan focussen op dat case exchange. Want dat is de handoverpoing dat je hebt. Dus de measurement van de performance kan veel meer focussen op dat. En finally, dat ligt, als je op de consumer nog iets moet hebben centrale systeem. Dus met dat, ik ben aan het einde van mijn part in de presentatie. Ik was gebouwd om 50 minuten van de vraag, dat is precies wat we hebben. Dus ik ben open voor vragen of er een input is op dit moment. Oké, kijk. Dank u wel. Mijn apologie is om de tijd te mixen. Ik ga in de stereotypische rol van de professor en ik ga meer absoluut minuut als ik. We hebben een paar minuten tussen nu en koffie voor vragen voor case. En ik denk... Of for a large. Big button. Of for a large. Ja, van de pfd-session. Of towards Lies en Charlie who is stood in the room, I think. Oké. So Steve has a microphone. Question. Of... You can shout from the corner. Hi. Can you just elaborate where of how you are with the definition of the... Taxonomy within the various different use cases that you went through. Oké, voor dit one specifically. We have... Sorry, also with the incident management, problem management. So the incident management, the problem management, you mentioned in the picture you showed how far are you with the definition of the taxonomy. Oké. We have, of course, the functional component, the artifact defined, and the taxonomy of those are defined. We have the relationship between the artifacts defined. Actually much wider than the ones I showed here. Of course. That's a reference, our second law show. We have so far set up all the capabilities that are necessary for an IT organization to have. Based on standard that we harvested. So it's open for discussion if that's enough for too much or whatever. We have that also. We describe those capabilities. We have mappings of functional components and artifacts to capabilities. So which capabilities are basically responsible for managing those artifacts or being supported by that functional component. We have done that for all. It's not all in the repository yet. We have two value streams already in the repository. Two more to go. En dan we have for this scenario. We actually have much more detailed out on how the connections are where we actually started to use essential services in a more detailed way. So initially we map an individual functional component with one essential services providing support to a capability or high level ones. In a scenario like instant management in multi vendor instant management we actually went down and started to individually have the essential services defined. En described on these other ones that we actually need. For the instant we also have the attributes associated with the artifact level. And we have the mapping of the artifact to the business objects like I showed. So which artifacts are basically representation of a business object that you need to have in your application. So that's there. Next to the multi vendor instant management process we have started on service level management. It's work in progress. We started on Agile or DevOps or whatever we want to call it. It's wider Agile. The worker was Agile. So that's work in progress. Help me out. So it's the core that we have. So Agile just going back to putting into taxonomy of the reference architect has been focused on requirements and defects as well as portfolio background items. So all the concept that you typically see as artifacts in the safe framework for instance. I'm trying to map out the core attributes that needs to be there. Now it is early work as we said. It's not like you're coming with a complete standard where you sign and start using it. So that's why we soliciting more people to come in and add to it. But it's also on the other hand it is so that we had examples of how to do it in scene that works. So apart from the work on paper like you saw here we actually have also implementations of actual tooling, connecting and working according to this reference aspect as well so that we can show it can be implemented and can get to work in that way. So that's also something that is not taxonomy anymore, but that's also available. It has been very important for us to not just say that we can make the paperwork in terms of we can describe a scenario and see that with these attributes it all works. We want to make sure that every other customer or IT organization, my speakers have ended, but IT organizations are actually implementing something like that.