Møller Grand College Ewa Goddag og velkommen til denne udsendelse af AlwaysAge. Asher. Jeg er blevet efterladt i studiet i dag og er helt alene, så vi må se, hvordan det går, når jeg ikke har nogen kompan her i studiet, men må ikke klare den alligevel. Jeg havde fornøjelsen af at lave en præsentation til Computerworlds Cloud & AI Festival om cloud-platforme, og dagens session bliver faktisk omkring præcis det. Så vi skal høre lidt om, at cloud-platformen aldrig bliver færdig. Og hvad betyder det? Og det vil jeg egentlig præsentere lidt, det slide, jeg kørte igennem der, og også så komme ind på noget teknisk demo, hvordan FellowMind så har løst nogle af de udfordringer fra sådan en teknisk vinkel. Men vi kommer i virkeligheden også til at snakke masser om det organisatoriske, og hvad det betyder. Så i dag vil jeg køre det igennem sammen med jer helt alene, og den klarer vi også alligevel, det er jeg helt sikker på. Så hvis vi dykker ind i det med det samme, så er dagens emne, det er, at din cloud-platform bliver aldrig færdig. Og hvad betyder så det? Ja, det skal vi jo så prøve at komme ind på. Med lige sådan en overordnet tema her i forhold til cloud-platforme, det er, vi prøver ligesom at adressere det her, det er et spørgsmål, vi har stillet os selv her internt også, at en cloud-platforms eneste holdbare egenskab er evnen til at ændre den overalt, sikkert og for altid. Og det betyder i virkeligheden, at vi ikke har en tilstand, man skal nå, men noget, at vi er foranderlige, og vi kan tilpasse os, og en hastighed, vi skal holde for at kunne følge med vores forretning, som mere om en masse ting. Og det er ligesom det, vi har kigget meget ind af i FellowMind, hvordan kan vi løse de her ting, når det kommer til arkitektur og compliance og landing zones og Azure, og alle de her ting, som vi har snakket rigtig meget om i Always Azure. Hvordan har vi i virkeligheden løst det i FellowMind? Og i FellowMind har vi i rigtig mange år leveret Azure-projekter, hvor vi har gået til vores kunder, og vores kunder har sagt, at vi vil rigtig gerne migrere til Azure, for vi synes, det er det rigtige for os, eller vi vil gerne modellisere vores applikation. Og det kræver tit, at der er en masse ting, vi skal have styr på rundt omkring den her applikation, eller det, vi migrere, som er den her platform, vi snakker om, de her shared services. Det har vi levet rigtig meget som projekter, hvor vi har defineret en sluttilstand, og et scope og en deadline og overdragelse. Vi har snakket med vores kunder omkring succes, hvornår vi er færdige med den her platform, så man kan tage Azure i brug, det her fundament, vi skal have bygget til vores hus. Sådan har vi drevet det i rigtig mange år. Men vi vil i virkeligheden meget hellere kigge på det her, hvordan bygger vi den her platform som et produkt? Og gå ind og definere, at grunden flytter sig hele tiden. Så det her med at bygge det her fundament på en grund, der hele tiden flytter sig, jamen det vil kun du i det øjeblik, at grunden ikke har flyttet sig endnu. Men så snart grunden flytter sig, så skal vi have flyttet fundamentet med, og passer det så til det nye sted, hvor vi kommer hen. Det gør, at vi skal tænke på det på en helt anden måde i forhold til at vide, at grunden flytter sig. Og vide, at vi ikke har en leverance, der skal godkendes, og noget økonomi, der skal godkendes. Og succesen, det er i virkeligheden ikke, at vi er færdige med de målbare ting, men succesen er, at vi kan ændre os til den given situation, der måtte komme. Så det er vi begyndt at have rigtig meget fokus på. Og vi stillte os selv det spørgsmål her, som ligesom er, som jeg stiller lidt ud i det rum her, det stiller vi os selv sådan at, om kunne vi rulle ændringer ud i vores eget miljø, lave ændringer og rulle dem ud inden for en uge, uden at vi skulle gøre noget manuelt, uden at vi skulle spørge nogen om lov, og uden at nogen i vores interne forretning i fellowmangene rent faktisk bliver overrasket over, at vi lavede en ændring. Det ville vi rigtig gerne kunne løse det her. Det ville vi rigtig gerne få til at virke, så vi kunne drive den her platform i virkeligheden, uden at nogen vidste, at vi lavede de her ændringer. Fordi grunden flytter sig hele tiden, så vi er hele tiden nødt til at flytte med med vores platform for at understøtte vores egne interne forretning i fellowmangene på vores egen Azure. Hvis man kigger lidt på, hvad det er vi gerne vil håndtere i den her platform, så er der jo en masse kompleksitet, som vi rigtig gerne ville flytte væk fra vores forretning, at de skulle håndtere og i virkeligheden tage ejerskab på den her kompleksitet. Det er jo en masse omkring, at der er noget netværk, og der er nogle identiteter og adgange, der er noget sikkerhed og overvågning, der er noget backup og omkostningsstyring, og der er en masse andre ting i forhold til alt det, der er rundt om den applikation, vi så har i Azure, som vi driver, som jo hver enkelt team faktisk skulle have ansvaret for at drive selv internt. Der vil vi jo rigtig gerne ind i vores driftsorganisation gå ind og påtage os det ansvar på vores egne vegne i fellowmind, men i virkeligheden også, når vi kan det, så kan vi jo også påtage os det ansvar på vores kunders vegne. Så man kan sige, at vi fjerner ikke kompleksiteten, der er. Vi overdrager den egentlig bare til nogen, der får et meget klart ansvar for den her kompleksitet, der er. Og så vil vi gerne, som det her isbjævslide lidt viser, ligesom abstrahere den kompleksitet væk for vores brugere, så de kun skal tage stilling til ret få enkelte ting, og der har vi lavet en lille portal, som er så vores kunder og vores brugere og selv internt i fellowmind, indgangsvinkel til den her platform. Hvordan vi så har gjort alt det her? Og der er en masse i det. Så man kan sige, der er en masse kompleksitet, vi har taget ejerskab omkring, og nu går vi ind, og så kommer vi så i gang med det her? Hvordan får vi bygget det her? Som produkt nu har vi en masse gode ideer til, hvordan vi gerne vil understøtte forretningen. Der er en masse ting, der er nogle ansvars, der er skubbet ud til nogle decentrale teams. Vi vil gerne påtage os og centralisere noget ansvar. Vi vil gerne gøre det smart, og vi vil gerne gøre det som et produkt, der er automatiseret. Så man kan sige, hvis vi så hopper lidt ind i maskinrummet, hvad har vi så gjort? Der er fem forudsætninger, som vi har taget til os, og hvad har vi så gjort internt i FellowMind, for ligesom at kunne opfylde det her? Så de fem forudsætninger, vi stillede os selv, for at blive forandringsklar, for at kunne understøtte vores forretning, med den her Azure-platform, det er, at vi ønskede en fælles kodebase, så alle vores miljøer bliver bygget fra den samme kode, og så har vi forskellige parametre, som definerer forskelligheden, og ikke kopier af koden. Og det er så det, vi har arbejdet rigtig meget med, at lave den her fælles kodebase. Det kommer selvfølgelig med en pris, af at særtilfælde skal afvises, for du skal passe ind i den ramme, og den kasse, vi bygger, ellers så skal et særtilfælde ligesom blive en del af løsningen. Og det kommer vi lidt dybere ind på, hvordan vi har arbejdet med det. Så vil vi gerne lave insert og governance, så politik og test er i koden, som kode, så vi har det med hver gang, så det er bygget ind i løsningen, og ikke noget, vi driver på siden af løsningen. Og sammen med sikkerheden, at den skal følge samme vej. Og hver gang, der vil komme en undtagelse i vores produkt, så skal den undtagelse også komme med en udløbsdatum. Så vi er sikre på, at hvis der er undtagelser, så er de undtagelser, de har noget tid at løbe på, indtil vi adresserer dem igen. Er det stadig nødvendigt med den her undtagelse? Og det er jo undtagelser for vores, når jeg siger politik, så er det jo sådan noget, som rekolutive politikker, IT-politikker, ISO, NIS, SIS, alle de der gode. Det kan egentlig også være vores egne firmepolitikker, om hvilke regioner må vi operere i, hvordan arbejder vi, og hvem må have adgang til hvad, og sådan nogle ting. Så er det super vigtigt for os, at gå ind og kigge lidt på, hvordan vi lavede automatiseret drift af det her, fordi det er jo lidt en af de tunge elementer i det, er jo vores medarbejdere i virkeligheden. Vi vil jo gerne skifte fokuset fra, at vores, så mange som muligt, i det her team gik ind, og lavede produktudvikling, og forandring, og understøtte forretning, og mindre drift. Og det er sådan lidt en vippe, vi tit arbejder med, at hvis vi laver rigtig meget drift, så er der mindre tid, til vi kan gå ind og arbejde med forandringen, og løsningerne i de teams, vi har. Så vi skulle have en handling, som rammer alle vores miljøer på en gang, og vi skulle kunne køre nat, og weekender og ferier, fordi vores kunder, de kører også nat, weekender og ferier, det gør vi også i fellowmind. Og så skal vi gå ind og have fokus på, at styre automatikken, i stedet for at gå ind og styre, de enkelt dessen processer og driftprocesser. Så havde vi en rigtig stor ting, i forhold til, at vi faktisk skulle gå ind og bygge, et helt nyt team op, der kunne drive den her platform. Så vi lavede det samme team, et team, der sad i fellowmind, og som både byggede og driftede den her løsning, så vi ikke havde overdragelser på tværs af teamsene. Og at alle ændringer, der måtte komme ind i den her platform, de fulgte alle sammen den samme vej ned igennem den samme traktor. Det kommer jeg også lidt tilbage på, hvordan vi så har gjort. og det gør jo så også, at der heller ikke er nogen genveje, der er ikke nogen, vi kan bare lige klikke her, eller gøre her, vi skal lidt følge den samme proces, hver gang. Og det kommer selvfølgelig også med en pris, ikke? Alle de her fem elementer, vi kommer med at præsentere her, kommer med en eller anden pris, som vi har skulle forholde os til i Fælgevejen. Og så skal vi selvfølgelig også lave noget kompetence, og noget investering i, at der er nogen, der skal eje den her platform, og det vigtigste er, at de skal eje den næste version, som hele tiden kommer, permanent. Så hvordan sørger vi for, at der ligesom sidder nogen i det her produkt, der ejer den næste version? Så når vi laver noget rigtig fedt, så ved vi, at det også virker i morgen, og når det skal ændres, fordi at grunden hele tiden bevæger sig, så ændrer vi også de løsninger, vi kommer med i de næste versioner. Og så er der en driftsudgift, og ikke et projektbudget. Og det helt svære her, har jo været for os at arbejde med, at vi ikke har en slutdato på det her. Så jeg kunne ikke komme med, hvad kostede det her på andet år, på tredje år? Nå, men det har jo en løbende omkostning hele tiden at drive det her. Der er selvfølgelig en masse ting, man kan bruge og målepunkter på det her. Hvor mange folk har du, og alle de her ting, du skal have. Selvfølgelig have en eller anden form for budget, men vi kan ikke lave sådan en skarp estimering, fordi vi skal have den her løbende drift og udvikling fra vi starter til aldrig slutter, i virkeligheden. Det vi så har gjort i FellowMind, det er, at vi har gjort, at vi arbejder alle sammen fælles på en vej, og en fast ramme for det her ene team, og et helt klart ansvar for, hvordan vi arbejder med det. Det vil sige, at vi har jo en platform, der nu er bygget, men så har vi kundene beder om noget. Microsoft ændrer noget i Azure. Noget går i stykker, fordi der er en driftshændelse, eller det kan også godt være, at vi har lavet noget, der ikke virkede. Det sker jo også. Hvordan arbejder det, eller vi bygger noget selv, altså vi kommer med en ny funktion, vi synes er supersmart, som vi gerne vil tilbyde til alle vores kunder, og i det her tilfælde er jo FellowMind jo også kunden. Så hvordan gør vi alle de her ting, så alle fire ændringer følger fuldstændig den samme proces og den samme vej? Det er jo super vigtigt for os, at arbejde på den her måde, så vi har styr på alle vores ændringer, der måtte ske i vores platform. Og det første er, at hver gang der kommer et behov, og et behov opstår af de her forskellige elementer, som jeg nævnte lige før, så bliver det behov defineret som en user story. Så det vil sige, at alle vores behov bliver defineret som user stories. Og så er det næste, det er, så laver vi en ændring på baggrund af den beskrevede opgave, kunden beder om noget, Microsoft ændrer noget. Det bliver så til et branch, der har et klart formål. Vi arbejder selvfølgelig i noget gitverden her, når jeg nævner branch, og det er fordi, vi har et produktteam, som arbejder som et udviklingsteam med udviklere. Og så har vi et klart formål. Et branch har et klart formål, som er det behov, vi har beskrevet i vores user story feature. Kald det work-right, som kald det, hvad du vil. Når vi så har lavet vores ændring, så går vi så ind og siger, der skal altid være to, der godkender den her ændring. Og der er en masse automatiske test, vi vil have på, for at kunne teste alle de her ting. For har vi lavet en fejl et sted, så rammer vi jo lige pludselig med vores platform, alle de løsninger, der bruger den her fælles platform. Og det kan vi jo så sige for fellow mind internt. Hvis vi laver en ændring, så rammer det alle de systemer, vi har liggende, som bruger den service, vi ændrer. Men den kan vi faktisk gange med en grad mere, med en potens mere, som så gange løsninger, gange kunder, fordi alle vores kunder vil jo så også blive berørte der. Så det er super vigtigt for os at have nogle rigtig gode tests, der tester de her ting. Så når vi er igennem vores eget internt udviklingsmiljø, og vi så skal til at gå i produktion med vores ændring, så er det super vigtigt, at vi har automatiseret tests og tester rigtig meget. Fordi vi skal kunne deploy den her 24-7 dag og nat, uden at spørge om lov og alle de her andre ting, som vi gerne vil have med. Det næste vi så gør, så begynder vi i virkeligheden at udrulle det her, så vi laver den samme version i alle miljøerne, så alle vores kunder faktisk kører på den samme version af vores platform. Så alt er ens. Så det er ret nemt for os at styre det her, når vi begynder at rulle det ud. Og vi ikke har de her ændringer og exceptions og kopier af koden, men alle ligner faktisk hinanden, og ændringerne var jo så parametriseret forskel i vores platform. Når vi så lidt kigger på, hvordan vi så arbejder i det her team, så har vi taget noget til os i vores platformteam, som hedder Golazo, som er en Microsoft udviklingsproces til lidt mindre udviklingsteams, som i virkeligheden laver et flow for os, for hvordan vi skal arbejde med vores ændringer. Og det kører lidt i tre spor, at vi har noget, der hedder Swarm, Interrupt og Plant, som gør, at vores team, hvis der kommer noget ind, som vi definerer som værende en swarm, når man så er det en ændring, eller en fejl, eller et driftafbrud, som gør, at alle vores kunder er berørte, og intet virker. All hands on deck. Alle skal tage sig af og få løst det her problem. Vi laver ikke andet, før det her problem er løst. Det er det, vi ville kalde en swarm. Så det er sådan et, vi kan kalde det et major incident i en eller anden IT-verden. Så går vi ind og kigger på, at vi kan få opgaver ind, som er interrupts, altså vi har en løbende service, det er en bug, som har en fejl. og det skal vi have løst efterfølgende. Hvis vi ikke har nogle swarms, så løser vi de her interrupts. Det går ind og laver en driftafbrudelse af vores løsning. Når vi kigger på vores interrupts, og de er væk, så kan vi gå i gang med vores plant arbejde, altså vores feature backlog, vores roadmap, og de ting, vi arbejder med. Og gå ind og få løst de ting, så vi hele tiden kan lave nye features. Og det er selvfølgelig, vi vil rigtig gerne have 0 swarms og 0 interrupts, så vi hele tiden kan lave nye løsninger. Og så er det jo sådan et loop af, at kunne gå ind og gøre sin løsning mere robust, så man får færre og færre interrupts. Vi har, den række følger os og godkendt på forhånd, og vi har nogen, der styrer det her flow, og den her proces. Og så er vi sikre på, at hver gang vi laver de her ændringer, så har vi et ticket i det med, som følger med hele vejen. Så vi ved præcis noget audit i det her. Det er jo super vigtigt for os, at vi havde det med. Så har vi noget kapacitetsstyring i vores team, hvor mange sager må man tage. vi hjælper noget i mål, før vi starter noget nyt. Vi kører daglige stand-ups, ugenlige demoer og planer og retro. Det kender man, hvis man kører Scrum og Agile og alle de her andre ting. Og så har vi sådan et klart af ansvar, vi gerne vil tage os i det her team. Den, der bygger det, drifter det. Det kan vi egentlig meget godt lide, at vi også håndhæver det, så vi ikke bygger noget, vi bare kaster over hegnet og leverer til nogle andre. og hver gang vi laver en undtagelse, når man sådan en undtagelse, får også et ejerskab og en udløbsdato inde i vores team, så vi kan holde øje med de undtagelser. Nå. Så har vi et slide, der hedder Det ærlige billede, fordi vi kan jo godt lide at lave den her ene platform, som rammer alle vores kunder, og hvis alle ligner hinanden, så kommer det selvfølgelig med den pris, at det passer alle, men det passer ingen perfekt. Og det er jo noget af det, vi har arbejdet rigtig meget med. Det er jo det her med, at for hver standard, vi vælger på vejen af vores kunder, eller en ramme, man skal passe ind i, så fjerner vi en valgmulighed. Og man kan sige, i de dialoger, vi har haft, så kan man sige, meget af det, vi er blevet mødt med i at lave sådan en platform, som I også ville kunne lave intern for jeres egne systemer, i jeres egen forretning, så måles platformen tit på, det den forbyder. Så ej, hvor er det irriterende, at vi ikke bare kan klik, klik, klik, og så glemmer man faktisk, ej, hvor er det, tak fordi I løste alle de her andre ting for mig, som jeg ikke behøver at tage mig af nu. Og det kommer lidt ind på den her svære samtale, som vi tit har, internt i fellowmine, for den sags skyld, men også med vores kunder, som jeg, kan vi ikke bare lige, før vi havde det her, den her driftede platform, og nu er den jo så driftet i fellowmine, det kan også være jeres eget interne team, der byggede det til jeres egen forretning. Kan vi ikke bare åbne det her? Det var hurtigt på talen, jeg kunne bare lige klikke, og så havde jeg mine firewallregler, og så kørte det hele. Nu skal jeg vente på at lave en formular, og så kommer firewallregler, og så bla bla bla. Jo, det kan du sagtens, men hvem tager ejerskabet for den ændring? Hvordan ved vi, hvorfor den ændring er lavet, og compliance, og der er styring igennem hele den her ændringsforløb? Det er jo så det, vi gerne vil tage en dialog omkring vores kunder og vores egen forretning med, i forhold til, at den her fleksibilitet uden ansvar, er det i virkeligheden noget, vi gerne vil have, eller vil vi gerne have, at vi får lidt mindre fleksibilitet, men vi er meget styre, og der er et klart ansvar for hvem, der tager sig af det her. Og så skal vi jo selvfølgelig, der hvor det ikke bare klik, klik, klik, kunne gøre det næsten lige så hurtigt. Næsten klik, klik, klik. Så vi skal selvfølgelig ikke vente mange dage på, at få noget, man kan få inden for 20 minutter, hvis man klikker, hvis man gerne kunne nå og kunne gøre det rigtig hurtigt. dermed den automatisering, jeg nævnte tidligere. Så i virkeligheden, noget af det, vi har kigget meget ind i, det er, at det første byggeår, det er virkelig det billigste. Ho, hej, hvor går det godt? Vi får bygget en masse ting, og det kører bare. Og arbejdet stiger og stiger og stiger, vi får flere og flere features, og i virkeligheden, så skal vi prøve at kigge lidt efter den økonomi, fordi vi besitterer måske efter at gå med nogle klare features lige her i starten, men vi besitterer ikke efter de næste par år og efter mange år, der kommer. Og det skal vi prøve at have med. Og det er ligesom noget, vi har måttet lære her, det er, at det er dyrt, når vi går ind og kigger i år tre og skal bygge de her ting, hvis vi ikke har tænkt det med i starten. Så det har vi haft stort fokus på. Og så igen, vi fjerner ikke kompleksiteten. I overtager kompleksiteten ind i et andet team, så man skal ikke tro, at det her løser den del kompleksiteten, er der stadig væk. Alt det, vi skjuler over for vores kunder og fjerner væk, den abstraktion, vi fjerner væk for vores kunder, den skal vi jo varetage og passe på for altid indtil, at vi ikke længere skal have den her platform af en eller anden grund. Så vi skal vælge bevidst, hvad det er, vi prøver at skjule. Altså, hvad vil vi gerne drifte, så vores kunder ikke skal forholde os til, fordi det tager vi ejerskab på. Og det er jo også de elementer, vi tager ind der, er noget af det, der bringer den svære samtale også. Og så den her, vi har lavet rigtig mange valg, som vi har lavet om, og man kommer til at tage fejl, og så i den her evne til at forandre sig og ændre sig, den forhindrer ikke de her fejl. Så det er, hvordan man håndterer de fejl, hvordan snakker man om de fejl, hvordan tør man for, at de fejl ikke opstår igen. Det er sådan nogle ting, man skal være vigtigere at få med i det her. Yes. Nå. Men, noget af det, der så var det sjove, da vi så lavede den her platform, som vi har kørende nu, og har kørende hos mange kunder, vores fellow mind managed platform, kalder vi den. Det er jo bare en eller anden cloud platform, som vi har bygget. I bygger jeres egen, eller forhåbentlig bruger vores, eller et eller andet andet. det er, at i det, vi fik opbygget alt det her styring, det gjorde faktisk, at vi fik et uventet udbytte, vi ikke vidste, hvad var. I det, at vi var forandringsklare, gav os faktisk evnen til, at kunne i brugtage, det vi ikke vidste, hvad var. Og i virkeligheden, så gjorde den her styring os klar til det uventede, og det uventede var jo så, at der lige pludselig for, nu ved jeg ikke, om vi skal sige et halvt år, eller et år, eller hvornår kommer alt det her, i forskellige størrelser og hastigheder. Men AI og agenter er ligesom trådt ind ad døren. Og hvad skulle vi, hvordan forholdt os vi til det her, hvad skulle vi gøre, for at vi internt i fellow mind, kunne tage alle de her agenter i brug, og tage AI i brug. Hvordan hjælper vi vores kunder med, at de kan tage de her agenter i brug. I det, vi var forandringsklar med, en platform gjorde faktisk, at vi kunne gå ind og kigge på de her agenter, og håndtere dem. Nu kunne det være, nu snakker jeg agenter her, så snakker jeg måske meget, sådan nogle coding agents, der støtter vores egne udviklere, som udvikler løsninger på platformen. Men de fik ikke en ny proces, for den havde vi allerede. Det vil sige, at vi gik ind i, ikke inden at skulle kigge ind, og opfinde noget, der ville tage flere år. Vi kunne gå ind og kigge på uger og måneder, til at vores kunder faktisk kunne i brug tage de her agenter, for at vores eget team kunne i brug tage de her agenter, fordi vi havde styr på, hvordan ændringerne kom ind, hvad processen var. Vi havde styr på, den trakte helt kom igennem, om den del så var udviklet af mig, eller udviklet af mig, i samarbejde med en agent, var jo så fuldstændig ligegyldigt. Det gav det samme, for vi havde styr på hele fødekæden, fra idé eller ønske og ændring, til at den var i produktion. Så det gjorde i virkeligheden, at vi ikke skulle lempele på en måde, vi skulle ikke ind og ændre noget, vi skulle ikke bygge et nyt sandbox-miljø, vi skulle ikke bygge, vi kunne faktisk tage det direkte ind i vores produktionsmiljø, og begynde at arbejde med de her agenter, også få dem til at arbejde med vores processer, og forstå vores golazo-processer, og forstå alle de her ting, til at hjælpe os også med, at forbedre vores backlog i virkeligheden også, og lave meget af det arbejde også. Så det er virkeligheden, i det vi havde, den her platform, som ikke var et projekt, men hele tiden løbende udvikling, gjorde, at vi var klar til det uvæsset, så i virkeligheden, vi vidste ikke, vi byggede det her, for at kunne understøtte AI. Og det er i virkeligheden, hele pointen i det her, det er, at vi ved ikke, hvad der kommer i fremtiden, men hvis vi er forandringsklar, og har lavet en platform, som kan ændre sig, lave et fundament af vores IT-løsning, her er det så cloud-platform, som hele tiden kan ændre sig, i forhold til den virkelighed, vi står i, så er vi også bedre rustet, til at tage imod, den fremtid, der måtte komme, og her var vi så, ret godt rustet, til at tage imod, nogle af de her coding agents, der er kommet ind, og faktisk også, til at bygge, løsninger på Foundry, og med vores egne agent, der vi så bygger. Nå, så i virkeligheden, det næste, der er så spændende nu, det er så lige at dykke ned i, når vi havde det her isbjerg, jeg vidste tidligere, vi får lavet en masse ting, der er under vandet, vi gerne vil abstrahere væk, fra vores brugere, og en masse ting, som vi gerne vil have, vores brugere forholder sig til. Så nu vil jeg egentlig gerne vise, prøve at vise lidt toppen, af isbjerget, hvordan har vi så arbejdet, med det her. Og nu skal vi se, om jeg kan, kan få gjort det, på en god måde. Så i virkeligheden, vi har i Fellowmind, lavet en løsning, og den her løsning, kalder vi for, Fellowmind Managed Platform. Den indeholder, alt det der, under linjen af vandet, al kompleksiteten, som vi har overtaget driften af, som vi bygger, og leverer ud til, alle mulige tenants, for vores kunder, og for os selv, også i alle, Fellowminds regioner. Men vi er nødt til, at have et interface, ligesom en frontend, som man kan se, toppen af det her isbjerg, fordi hvordan skal, vores teams arbejde, ind imod vores platform. Og her har vi bygget, en portalløsning, vi selv har bygget til, netop, og kunne abstrahere, alt det her væk. Den portalløsning, kan I så, gå ind og bruge, som inspiration, til hvordan, ved jeres eget platform, team, eller gå ind og sige, okay, det var faktisk interessant, det Fellowmind har lavet der, det kunne jeg godt bruge, det kan I så også gå ind og tage, og tage med hjem, i den snak her. Vi har lavet den her platform, som giver et hurtigt overblik, over ens Azure estate, der er noget omkring noget, omkostning og secure score, og policy, og hvor mange landing zones har jeg, og hvor meget log in, og sådan en masse data, vi får ind her. Vi går så gar ind, og går ind og viser nogle, af de her elementer, der er, når man her er mit AQS cluster, hvilke note pools har jeg, hvilke projekter har jeg, hvilke namespaces har jeg, så man kan gå ind og få en masse information, om den her delte platform, der er, mit Azure DevOps estate, hvilke organisationer har jeg, hvordan er de konfigureret, min connectivity, hvad har jeg for en type connectivity, hvilke site-to-site VPN'er har jeg, hvad er min topologi, hvis jeg vælger en given landing zone, hvordan ser mit netværk ud, hvad er mine firewall regler, der er så ingen firewall regler, det var da dejligt nemt, men så igen, kunne gå ind og give, vores brugere, den her platform, altså vores udviklere, eller dem der ejer, de her landing zones, en masse information, de skal bruge, for at kunne interagere med os, som platformteam, der er en masse ting, de skal vide, der er også en masse ting, de kan gå ind og se, om deres egen landing zone, nøj, hvad er det for en environment, jeg har, hvem ejer den, hvem får alarmerne, hvad er det for en netværk, der er i, alle sådan nogle ting, hvilke firewall regler er der, for den her given landing zone, hvilke budget har jeg, en masse information, og vi også hele tiden bygger på, vores løsning, med nye features hele tiden, så man kan gå ind og finde, den her information, og når man så skal interagere, med vores platformteam, nøj, men hvordan sørger vi for, at de ændringer, der kommer udefra for vores kunder, så kommer ind til os, igennem den trakt, der så er, så har vi bygget en masse service requests, som ligger oven på vores platformløsning, så hvis man vil have et nyt AQS cluster, have en ny site-to-site, have lavet en firewall regel, hvad der nu er løsninger, i vores platform, som vi skal sørge for, at vores kunder, kan begynde at interagere med os omkring, og så have den automatik, så når det kommer ned igennem, flowet og traktet for ændring, til godkendelse, til use story, det er der hele vejen over herovre, hvor den nu er i produktion, der skal vi gerne sørge for, at alt er end-to-end automatiseret, så vi kan gå ud og levere de her service requests, på click-over-button-agtig følelse for vores kunder, men stadig gå ind og have en proces, og en audit trail, vi ved hvem der har lavet det, hvorfor det er blevet lavet, vi kan gå ind og se, vi kan gå ind og rulle tilbage, vi har det hele som source code derinde, så have de her ret stærke processer omkring det. så vi har simpelthen gået ind og lavet nogle formularer, for vores kunder, så hvis man går ind og opretter en ny landing zone, eller opdaterer en eksisterende landing zone, så kan man gå ind og gøre det, eller hvis man vil interagere med os på anden vis, lave en ny firewall-regel, så kan man gå ind og få lavet den firewall-regel, nu er det sådan en demo site, den er altså ikke så god til at lave firewall-regler, kan jeg sige. men i virkeligheden også gå ind, når man har nogle feature requests, det vil vi gerne høre. Hvordan interagerer du med dine kunder, det gør vi den her vej igennem. Og også giver dem en masse data, for en ting er, det kan være, du ejer landing zone derude, det kan også godt være, du ejer hele platformen, så vil du gerne vide en masse ting, om hvad det koster, hvad er det, der koster, og hvad for noget login-gestion har jeg, hvad med min sikkerhed, hvad med min Azure Advisor, hvad med min Azure DevOps, så er der, kan jeg spare nogle licenser, så har jeg, min Azure DevOps rigtig konfigureret i forhold til compliance, så er der en masse andre ting, vi arbejder med herinde. Så det måske sige, det måde, vi har lavet et interface ind til det her store isbjerg, vi har af alt det services, fordi det her, det er bare, portalen er bare en lille bid af vores platformløsning, som i virkeligheden er der for at drive hele vores fundament, og hele vores forretning på den her cloud-platform, som skal kunne flytte sig hele tiden. Så jeg håber, det her har været sådan en speed talk og inspiration til at gå ud og kigge på, hvordan adopterer vi, og hvordan arbejder vi i virkeligheden med den her platform selv internt, og hvordan sørger vi for, at vores platform er forandringsklar, og kunne understøtte vores forretning nu, men også i fremtiden, for de ting, vi ikke ved kommer. Så med de relativt kloge ord, vil jeg selv sige, så var det dagens Azure, Always Azure Broadcast, og tak fordi I så med. kan henYo性 igjen selv unter what Tád är kjord. realidade sist skal beknå, malekvorsklar. 쁘Europavgårda.