Så rev vi silos, fick mer luft i dataarbetet — och en guldpokal för jobbet

Produktägaren för Bonnier News datateam berättar om vinsten av Google Customer Award och vägen dit.

Genvägar är ofta senvägar, heter det. Det här är berättelsen om hur vi på Bonnier News tog oss ur en tradition av kortsiktiga lösningar och med ett tvåfaldigt angreppssätt byggde en skalbar dataplattform.

Vi tillgängliggjorde källsystemsdata så nära sitt råa format som möjligt och flyttade bort affärslogik från dashboards. Nu kan verksamheten innovera på vårt data och utvinna värde i vår tidigare så spretiga data.

Långt innan jag, som är produktägare i datateamet, kom till Bonnier News hade teamet insett bristerna i vår gamla dataplattform och strategin kring den. Det var dags att göra en förändring. Påfrestande perioder av samtal med stakeholders för att förklara den nya riktningen avlöste varandra. Teamet hade tidigare tagit emot beställningar på datapipelines och levererat dem. Nu tänkte vi inte längre bygga dessa utan låta teamets stakeholders göra det själva. Och som om inte det var nog, så skulle det göras på en ny dataplattform som ännu inte var färdig. Det var minst sagt svårt att sälja.

Men vi får backa ännu längre för att förstå bristerna i tidigare plattform. Våra stakeholders upplevde sig inlåsta. Tuffa prioriteringar är vardag för majoriteten av produkter och produktägare, men när de flesta stakeholders upplever att det tar lång tid att få sina pipelines byggda då har man ett flaskhalsproblem.

Lockelsen med snabba lösningar

Det finns många studier som fortfarande uppskattar att 40 till 80 procent av tiden i data science och analys initiative går åt till att skyffla, tvätta och transformera data. Addera sedan andra tjänster som till exempel marketing automation med stort behov av användardata. Då är det lätt att dra slutsatsen att det bästa vore att skjuta till fler resurser. Det är inget unikt problem i branschen, men kombinerar man det med Bonnier News Techs kultur där vi föredrar små innovativa autonoma team så blir det problematiskt.

Det innebär att

• teamet inte växa sig för stort
• andra team inte kan innovera i den takt de skulle vilja när de är beroende av datateamet för att få fram den data som behövs.

Det krävs inget svart bälte i theory of constraints eller kanban för att förstå att det inte är hållbart att en så stor del av arbetet handlar om att skyffla data i kombination med ett litet data-team som ska serva många och att andra team inte kan innovera i önskad takt.

I en sådan situation är det lätt för mindre team att bygga hyperlokala lösningar. Det kanske finns en eller två duktiga utvecklare i teamet som kan lösa teamets databehov och på så vis kringgå flaskhalsen. Ur välvilja och problemlösning föds data-silos. Dessa silos löser oftast behov på kort sikt och oftast med låg time to market. Men som ordspråket lyder “genvägar är ofta senvägar”. Ett team vars fokus ligger på något helt annat än att bygga lösningar för flytt, lagring och transformation av data måste i ett sånt här läge avsätta tid till förhålla sig till förändringar i resten av arkitekturen. Det blir jobbigt när ett litet team blir en blocker för resten av organisationens tekniska förflyttningar bara för att man inte kan lägga mer än en person några dagar i veckan på att anpassa sin lokala lösning. Ännu värre blir det när de få personer som ansvarat för lösningen slutar.

Specialanpassad frukost

Det finns flera anledningar till varför det har varit svårt att utvinna värde ur vårt data. Dels är datan i silos oftast utformad utifrån det begränsade problem som ska lösas, aktuellt affärsområde och varumärke, vilket gör det svårt för ett annat affärsområde att dra nytta av datan skala upp lösningen över fler varumärken. Dels sker hela tiden nyförvärv till Bonnier News och med det kommer flera uppsättningar av källsystem som alla har sin egen datastruktur. Det är inget unikt i branschen och behöver inte vara problematiskt. Men saknar man gemensamma datamodeller blir det oftast ett problem. Det är inte hållbart att förvänta sig att en ny analytiker ska förstå datamodellerna i fyra olika CRM-system.

Jag har lärt mig, både i en klassrums- och arbetsplatskontext, att kultur äter strategi till frukost. Därför har det alltid varit viktigt för mig att strategier utformas utifrån den kultur man befinner sig i och inte plockas färdigt från en hylla. Man skulle kunna säga att frukosten måste vara väldigt noga utvald och tillagad utifrån vem som ska äta den.

Photo by Brooke Lark on Unsplash

Här är lista över några viktiga faktorer att ta hänsyn till:

• Vår vision: “Vi drivs av att stärka det fria ordet och bidra till ett demokratiskt, hållbart och inkluderande samhälle”
• Våra värderingar: Vi verkar för ett öppet samhälle. Vi inkluderar, tar tillvara andras åsikter, delar med oss av information och kunskap. Vi uppmuntrar till samarbete och kommunikation inom och mellan varumärken och avdelningar.
• Vår kultur: “Någon” jobbar inte här, vi gör det (Bonnier News Tech “Den schyssta medarbetaren’)
• Ständig förändring: Vi är en organisation med många starka och unika varumärken och fler kommer säkerligen att tillkomma i framtiden
• Innovationsoptimering (Bonnier News Techstrategi)
• Strävan mot minskad komplexitet i våra lösningar (Bonnier News Techprinciper)
• Önskan om små och autonoma team

Vår datastrategi

Som något av en minimalist föredrar jag en enkel frukost. Kaffe, rostat bröd och ägg. Precis som min frukost så har strategin tre komponenter:

• Vi vill samla data om vårt innehåll, våra användare (läsare, tittare och lyssnare), deras prenumerationer och hur de använder våra produkter på ett och samma ställe.Genom att samla data på ett ställe kan vi underlätta för innovation, samarbete och inkluderande samarbete mellan team, affärsområden och varumärken
• Vi vill göra det möjligt för fler än specialister (data engineers) att flytta och transformera data.Genom att göra det möjligt för så många som möjligt att arbeta med data så skapar vi mer handlingskraftiga och mer autonoma team
• Vi vill göra det möjligt för fler än specialister (systemspecialister) att förstå data om våra användare, deras prenumeration och hur de använder våra produkter. Genom att göra det möjligt att förstå och jämföra vår data oavsett källsystem kan vi skapa skalbara och hållbara insikter, lösningar och produkter.

Realisering av vår datastrategi

Vi behövde ett ställe att samla och transformera data, det stället är Google BigQuery. Genom att använda oss av detta kan vi minimera databortfall genom att tillgängliggöra källsystemsdata så nära sitt råa format som möjligt och flytta så mycket transformation och affärslogik från dashboards och BI-system till BigQuery. När näst intill rådata finns tillgängligt i BigQuery så underlättar det för snabba innovativa experiment.

Målet är att det ska vara möjligt att testa något ute i våra produkter och sedan följa upp utan långa ledtider. Genom att flytta transformation och affärslogik in i BigQuery spelar det mindre roll i vilket analysverktyg man väljer att arbeta. Affärslogik är kunskap och genom att undvika att låsa in den i olika verktyg skapar vi transparens och kunskapsdelning.

Det finns alldeles för många fördelar med detta för att ens överväga att bygga silolösningar.

För att göra lösningen ovan genomförbar har vi i datateamet arbetat hårt för inte förbli en flaskhals. Det har vi gjort genom att bygga “Kirby”. En plattformslösning som huvudsakligen nyttjar Google BigQuery (tillgängliggöra data), Google Cloud Storage (temporär landningsplats för in- och ut-filer) och Google Cloud Composer (Airflow, schemaläggning av pipelines).

Med en pythonkodbas kan vi erbjuda mallar till backend-utvecklare, data scientists och analytiker för de vanligaste sätten att flytta data in och ut ur BigQuery. Vi har skapat mallar för att till exempel läsa in filer från Cloud Storage, hämta data från API och skicka data till en sftp. Vi har också byggt mallar för att transformera, aggregera data och skapa nya tabeller. Det är så pass enkelt att det enda som krävs är övergripande kunskap om github och sql. Vi har nyligen skapat en tutorial som på fem minuter beskriver hur du kan skapa din första pipeline.

Samarbete och organisation

Mycket av arbetet har vi gjort tillsammans med andra team och på så vis kunnat få input från dem under processen. När våra mallar inte mött andra teams behov har vi uppmuntrat dem att själva, om de känt sig manade och haft expertisen som krävts, att skapa egna. Dessa nya mallar kan sedan nyttjas av andra team med liknande behov.

“Någon” jobbar inte här, vi gör det — och på så vis kan hela Bonnier News Tech bidra till bidra till en bättre dataplattform. All kod bor i ett och samma github-repo, vilket bidrar till transparens och kunskapsspridning.

Vi har även slitit hårt med att vår viktigaste data, den som innehåller information om våra användare (läsare, tittare och lyssnare) och deras prenumerationer, ska vara lättförstådd och skalbar med gemensamma definitioner. Så pass hårt att vi insåg att det behövdes en ny roll och ett nytt team på Bonnier News Tech. Ur gemensamt arbete med bland annat läsaraffären kring att bygga en datamodell för våra användare, prenumerationer och prenumerationshändelser, skapades datamodellteamet. I det teamet arbetar analytic engineers vars uppgift är att bygga så skalbara och värdeskapande tabeller som det bara går. De arbetar både nära datateamet, som viktig stakeholder för att driva framtida features i Kirby, och nära affärsområdena. Med hjälp av dessa tabeller kan vi nu segmentera på Bonnier News nivå (för marknadsföring och annonsering) ochfölja upp och jämföra läsaraffärens nyckeltal över alla varumärken.

På så vis har vi gjort det så ofördelaktigt som vi bara kan för andra team att skapa silo-senvägar, vi är inte längre en flaskhals utan ett stöd för att snabbare kunna innovera med hjälp av vår data och vi har skapat ett helt nytt team med en ny roll för att göra det så lätt som möjligt att förstå och utvinna värde ur den.

Ibland känns det som att mycket av det hårda arbetet görs ouppmärksammat. Kanske för att de långa dagarna avlöser varandra, kanske för att jag är skitkass på att fira (jag vet, dålig egenskap för en produktägare, snälla skicka hjälp!). Men för allt det hårda arbetet har vi vunnit ett pris, “Google Cloud Customer Award” och jag är grymt stolt över alla som har varit inblandade under de här åren!

Framtiden

Det finns mycket kvar att göra. Den gamla plattformen måste stängas ner. Nya trackinglösningar måste komma på plats. Fler features i våra mallar och nya mallar tillkommer.

Här är de saker jag som produktägare ser mest fram emot:

1. En datakatalog som passar vår kultur. Ett ställe där vi lätt kan hitta beskrivande information om den data som finns tillgängligt, hur den används och exempel på queries. Även en sammanställning av de mest använda tabellerna och återkommande queries. Med den förmågan möjliggör vi för mer innovation, kollaboration och kunskapsspridning.
2. Ett data lineage-verktyg där vi kan se hur tabeller och kolumner har skapats. Genom att kunna spåra alla steg som vår data tar kan vi underlätta förändring och minska komplexiteten.
3. Ett datakvalitetsramverk, ju mer värde vi utvinner ur vår data desto mer kritisk blir den. För att minimera oönskad påverkan på våra användare (läsare, tittare och lyssnare) behöver vi ett generellt sätt att fånga och agera på avvikelser innan skadan är skedd.

/Annon Karlsson, PO för Dataplattformsteamet på Bonnier News