I en stor dansk virksomhed havde en direktør fundet et smart værktøj til videndeling og innovation. Det var en cloud-løsning, så det var nemt at bruge med både egne ansatte, partnere og folk i andre virksomheder. Der var dog et praktisk problem: For at medarbejderne kunne logge ind, skulle de registreres i systemet.
Det var let at løse: Et udtræk fra SAP-systemet gav en liste over alle ansatte. Og et øjeblik senere lå hele firmaets interne brugerdatabase ude på nettet. Det var et brud på firmaets sikkerhedspolitik.
Derfor blev it-afdelingen bedt om at finde en metode til at give medarbejderne adgang, uden virksomheden gav køb på sikkerheden.
Historien er et godt eksempel på de udfordringer, det giver at integrere cloud-løsninger med virksomhedens interne it-systemer. Udfordringerne kan handle om sikkerheden eller om, hvordan man rent praktisk fragter data mellem systemerne.
Brugerdatabasen er en oplagt udfordring: Hvis man ikke kan integrere med den, skal hver medarbejder holde styr på separate brugernavne og passwords til hver eneste cloud-løsning, virksomheden abonnerer på.
– Initiativet til cloud-løsningen i historien kom ikke fra it-afdelingen. Den blev først kaldt ind, da der skulle ryddes op. Det er meget typisk for den måde, cloud tages i brug på. Heldigvis kan det lade sig gøre at kombinere interne og eksterne brugerdatabaser, fortæller Søren Ørslund fra konsulentfirmaet Timengo, der rådgiver om cloud.
Replikerer via LDAP
En af løsningerne går ud på at replikere brugerdatabaser via LDAP (Lightweight Directory Access Protocol). Den metode bruger blandt andre Microsoft til deres Office 365 og Google til Google Apps. På den måde undgår virksomheden at oprette brugerne separat i cloud-systemerne. I stedet får de automatisk en kopi af brugerdatabasen eller dele af den.
En anden metode hedder føderation. Her er der ingen kopier af brugerdatabasen. I stedet opbygger man et tillidsnetværk: Man finder en organisation, som man har tillid til. Brugerne logger ind hos organisationen, som udstyrer dem med et token, de bruger til at logge ind på andre tjenester med. Dette token er en digitalt signeret tekst, som fortæller noget om brugeren.
Et eksempel er OAuth, som blandt andre Facebook anvender. Når man er logget ind på Facebook, kan man få adgang til andre tjenester, der stoler på Facebook og derfor giver adgang til brugere, der har et OAuth-token.
– Udfordringen ved føderationsmetoden er, at vi savner en fælles myndighed, som alle i Danmark har tillid til. Måske kommer det med medarbejdersignaturen fra NemID, bemærker Søren Ørslund.
Han understreger, at det ikke er blevet nemmere at indføre single sign-on, hvor brugerne kun skal logge ind én gang, efter at cloud-systemerne er kommet til. Meget kan klares med replikering af brugerdatabaser, men det er primært til de store, etablerede systemer.
Brugersupport uden link
Hans kollega Thomas Dalager har erfaring med at indføre forgængeren til Office 365, BPOS-D, i en international virksomhed med 55.000 brugere. Virksomheden havde en intern e-mail-løsning baseret på Microsoft Exchange. Den blev afløst af cloud-versionen af Exchange.
I projektet gav det problemer, at der manglede integration mellem to systemer: Det interne system til håndtering af brugersupport (incident management) og det tilsvarende system hos cloud-udbyderen.
– Det er afgørende, når man har tusindvis af brugere, at den samme henvendelse ikke skal indtastes to gange. Den slags skal man sikre sig, før man skriver under på kontrakten, siger han.
Han mener, at flere problemer kunne være undgået, hvis projektet tidligere havde inddraget de lokale it-folk. De kunne hjælpe med at påpege, hvor der lurede udfordringer for eksempel i form af vanskelige integrationsopgaver.
Dataintegration begrænser
Mens det altså godt kan lade sig gøre at integrere brugerdatabaser i cloud-løsninger, er der større udfordringer i at udnytte andre interne data. Faktisk er udfordringen så stor, at den er med til at begrænse, hvad man bruger cloud til. Det mener Søren Ørslund:
– I det offentlige har vi i Norden nogle få store udbydere af fagsystemer til stat og kommune. De har lavet integration til Office-pakken, så man kan udskrive breve i Word med brug af data fra fagsystemerne. Men den integration kan man ikke få, hvis man vælger en cloud-baseret løsning som Google Apps, siger han.
Den tekniske årsag er, at integrationen ofte er lavet i form af COM-objekter, der kræver, at begge applikationer kører på pc'en. Men der er også en markedsmæssig forklaring:
– De store spillere som KMD og CSC har ingen forretningsmæssig interesse i at åbne deres systemer. Det kunne de gøre med åbne snitflader, men så risikerer de at miste forretning, siger han og fortsætter:
– Derfor ser vi, at det hovedsageligt er mere isolerede systemer, der har succes som cloud. Ting som CRM-systemer, løn, e-mail og andet, der ikke kræver tæt integration med interne data og systemer.
Svartider blokerer
Selvom en virksomhed selv ejer sine data, er det ikke sikkert, at det giver mening at lave integration med cloud-løsninger. For hvis man har store datamængder, kan det give problemer med lange svartider.
– I princippet kan du godt integrere et system i skyen med data, som du har liggende lokalt. Men hvis det tager meget båndbredde, kan det give så dårlige svartider, at det er ubrugeligt i praksis. Til sammenligning er brugerdatabaser enkle – det er små datamængder, der kun sjældent ændres, siger Søren Ørslund.
Han ser udfordringerne ved dataintegration som et forbigående problem. Især for mindre og mellemstore virksomheder er fordelene ved cloud så store, at mange vil vælge det som deres eneste it-løsning. Så har de ingen udfordring med at integrere interne data, når der ingen interne data findes. Til gengæld kan der opstå en ny udfordring med at integrere data på tværs af cloud-udbydere.
