karriere
Supergraf kartlegger de Lego-ansattes kompetanse
Med grafdatabaser kan Lego virtualisere utviklernes kunnskap, slik at man slipper å spørre kolleger. Men fremgangsmåten kan også resultere i isolasjon, advarer ekspert.
Developer Experience, eller devex, er det nye begrepet i devops-verdenen. Vi var nettopp blitt kjent med platform engineering, som prediker at utviklere skal utvikle og ikke gjøre alt mulig annet, som å fikle med nettverk eller sette opp databaser. I samme gate finner vi det nye fokuset på utviklerne.
Spåmennene hos Gartner definerer devex – utvikleropplevelse – som programvareutviklernes generelle tilfredshet og produktivitet når de bruker verktøy, rammeverk og plattformer til å bygge applikasjoner. Det omfatter brukervennlighet, effektivitet og virkningen av utviklerverktøy, dokumentasjon, støtte og fellesskapsressurser, lyder konsulenthusets definisjon.
Hos leketøysfirmaet Lego har man tenkt radikalt om hvordan utvikleropplevelsen kan bli bedre. Med utgangspunkt i Spotifys verktøy Backstage, som er et åpen kildekode-system for å bygge utviklerportaler, har firmaet skapt sitt eget system, Baseplate – oppkalt etter den bunnplaten man setter Lego-klosser på.
– Vi trenger data for å skape gode utvikleropplevelser, fortalte sjefutvikler Jonas Druedahl Rask i Lego på Eficodes Devops Conference Global, som fant sted i London i mars og ble strømmet over hele verden.
Supergrafen
Den spesielle ingrediensen som får det hele til å gå opp i en høyere enhet, er supergrafen. Rask forklarer på scenen i London:
– Vi har hentet inspirasjon fra hva Netflix og Volvo gjør med sine supergrafer. I bunn og grunn er en supergraf et GraphQL API. Du har ett inngangspunkt der folk kan hente alle data fra de underliggende grafene. Vi har bygget det opp rundt tripletter, hvor man har et subjekt, et objekt og et predikat, slik at man kan skape detaljerte og meningsfylte relasjoner i denne modellen. Her har vi for eksempel en ansatt som kan ha flere forskjellige relasjoner til et produkt.
Denne måten å beskrive fakta på stammer fra vanlig logikk, også kjent som knowledge graph – en trestruktur hvor bladene på treet representerer kjent kunnskap.
I eksemplet ovenfor er utvikleren subjektet – det kan være «Lisbeth» – som har en egenskap (et predikat), for eksempel «er-ledende-utvikler-på», og objektet er produktet, eksempelvis «det nye regnskapsmodulen» eller noe lignende. På den måten kan man beskrive en overraskende stor mengde fakta. Fordi dataene er bundet opp i en graf, kan man søke på innviklede relasjoner og få klare svar, slik vi kjenner det fra semantisk web-teknologi. Alle ressurser, ansatte, produkter og annen kunnskap er representert i systemet på en måte som gjør det enkelt å søke frem informasjonen.
Gammel måte gir utfordringer
Og hva skal så denne manøvren være godt for? Rask gir et klokkeklart eksempel med utgangspunkt i en fiktiv nyansatt i en organisasjon:
– Her har vi Emma, som slutter seg til et produktteam. Emma har nå i oppgave å ta en del av produktet til skyen. Hun må finne ut hvordan det skal gjøres. Emma ser seg rundt og finner noen kolleger som kanskje vet hvem hun skal snakke med. Hun er heldig, så disse menneskene vet at det er et team som heter Cloud Enablement. Emma tar kontakt med teamet, og de snakker frem og tilbake. Det kommer noen e-poster, og det blir bedt om noen opplysninger som hun må fylle ut. Og så, endelig, etter en ukes tid, får Emma tilgang til en sky-konto. Det er ikke den beste utvikleropplevelsen, sammenfatter Jonas Druedahl Rask.
Utfordringene med den gammeldagse fremgangsmåten er at det er vanskelig å vite hvor man skal henvende seg for å få tingene gjort. Man må kjenne noen som kjenner noen, og det er et reelt problem som man ser igjen og igjen, sier han. Og når man har funnet de riktige menneskene, mangler det fortsatt automatisering.
– Det betyr at du har en veldig lang leveringstid på oppgaven du prøver å løse her. En ting som ikke er umiddelbart åpenbart, er mangelen på eierskap. Så i vårt eksempel fra virkeligheten ville sky-kontoen faktisk være bundet til Emma som individ.
Hvis Emma bytter team, følger kontoen henne, i stedet for å bli hos teamet som eier produktet.
Hjelp til samarbeid
Rasks kollega Waqas Ali er seniorutvikler på Legos utviklerplattform.
Han fortsetter historien om Emma, basert på Legos og andres konkrete erfaringer. Ali ser for seg at Emma har fått en ny oppgave som innebærer at hun må jobbe sammen med andre team. Nå kan hun bruke Baseplate-systemet til å finne relevante API-er, dokumentasjon og andre team i organisasjonen som berøres av oppgaven.
– Hun trenger ikke snakke med noen. Hun er også interessert i å finne ut mer om folk, så hun kan også finne folk å samarbeide med. Hvis hun finner et produktteam, kan hun se hvem som jobber på dette produktteamet direkte fra Baseplate, og så kan hun kontakte dem og samarbeide. Og du kan selvfølgelig, hvis du er modig, opprette en pull request til det aktuelle teamet, sier Ali. Det handler om å ønske en ny funksjon i et stykke programvare.
Og systemet fungerer, bedyrer han. Det er mer enn 60.000 klikk på dokumentasjonen hver måned, og over 400 API-er er rullet ut via systemet.
Plattformen inkluderer også en plugin-modell som gir teamene mulighet til å utvide funksjonaliteten og skape plugins ved hjelp av maler, for eksempel for raskt å lette tilgangen til skyen, mens det før tok tre dager å skaffe en konto.
En sidegevinst er at sky-kontoen nå er knyttet til prosjektet og ikke til en gitt person. Det er også mulig å se nærmere på utviklernes brukerreiser i systemet, og hvis opprettelsen av en sky-konto ofte feiler, kan man gå tilbake til utviklerne og finne ut om det er uheldige forhold i prosessene.
Supergraf kan øke isolasjon
Tina Blegind Jensen er professor ved Institutt for digitalisering på Copenhagen Business School. Hun ser klare fordeler med supergrafen, spesielt i eksemplet med Emma, som nettopp har begynt i jobben:
– Det er utrolig godt som nyansatt å kunne sitte for seg selv stille og rolig og prøve å finne ut: Hvem er det jeg skal interagere med? Når man gjør det gjennom systemet, unngår man å bryte for mange koder fra starten – som å banke på hos feil person eller trå over noen grenser.
Men hun ser også ulemper. Ved ikke å gå inn dit man ikke skulle, går man også glipp av noe, ettersom det er slik man lærer å inngå i relasjoner og i organisasjonens kultur.
– Det kan føre til at man kanskje blir mer isolert, og hvis man ikke er så flink til å ta kontakt, kan det bli enda vanskeligere å ta kontakt, fordi man gjemmer seg bak systemet.
Dette innebærer også at man som leder må være oppmerksom på hvordan man både får gjort nye ansatte fortrolige med systemet og også får folk – og særlig nye ansatte – fortrolige med å interagere med hverandre og skape de nødvendige rommene for interaksjon.
– For det har vi alle behov for. Kanskje sitter en person med en kompetanse som ikke er registrert i systemet ennå.
Og det finner man kanskje bare ut ved kaffemaskinen.
Artikkelen ble først publisert på Version 2 for deres abonnenter. Den er tilgjengelig på norsk for abonnenter av Ekstra gjennom vår samarbeidsavtale.