Det har ganska länge talats om big data och om hur viktigt det är för företag att samla in och behandla data. I vanliga fall skulle jag bara använda detta som ett axiom och börja prata antingen om GDPR eller om strategier för datasäkerhet baserade i antingen en cloudmodell eller en hybridmodell.
Det är förvisso viktiga perspektiv, men det är sommar och vem vill läsa ytterligare en blog om GDPR i värmen? Vi kanske kan återkomma till det en annan gång. Plus att jag har haft semester och känner mig lite extra avslappnad och filosofisk.
Jag, liksom förmodligen alla utvecklare, har arbetat med data och olika former av datalagring sedan hedenhös. Varje system har alltid någon form av data, allt från poängsumman i Ormen på en gammal Nokia till hela sökhistoriken i Googles sökmotor. På senare år har jag arbetat med (mycket) mer data och mer direkt. Det är ingen slump, vi är många som arbetar med data nu jämfört med förr. Det i sig beror på att data, eller mer korrekt informationen i data, har seglat upp som den kanske enskilt största differentieraren mellan olika företag. Det räcker idag inte längre att sälja en bra produkt. Man måste också leverera en bra kundupplevelse och så mycket interaktion man kommer undan med.
Nu är min upplevelse säkert färgad av att vad jag faktiskt gör om dagarna är att samla in information till econometrics. Vilket kan vara den mest datahungriga av alla discipliner eftersom man försöker svara på frågan ”Hur ska vi ändra variablerna A, B och C för att få utfallet X?”. Låter det enkelt? Jo. Jag missade att nämna att man inte vet vad X beror på utöver A, B och C. Så det behöver man lista ut, och för att kunna göra det behöver man … just det, all data som kan tänkas vara relevant.
Så jag tar ingången ”vi tror vi behöver detta” samt min kollega dataarkeologens ”Jag har hittat det här borta! Eller det liknar det lite men…” och sen bygger jag en maskin som producerar något som förhoppningsvis är vad som efterfrågades.
Lärdomen ur detta är att det som utan tvekan är det viktigaste för ett lyckosamt och lönsamt nyttjande av ett företags data är
- Tillräcklig data
Det går bara att använda historisk data man faktiskt har, det går sällan att samla in den retroaktivt i efterhand när man märker att den hade varit bra att ha. - Dokumenterad data
Data kan bara användas som information om den är väl beskriven. Det är bra att vara övertydlig på ett sätt som annars ofta egentligen inte behövs i mjukvarusammanhang eftersom det är svårt att se att man aggregerat saker som inte går att aggregera och därför hamnat 2.8% fel. Till skillnad från hur svårt det är att detektera att, säg, ett API säger ”JSON format error”. - Katalogiserad data
Det går inte att använda data alls om man inte kan hitta den. Gör den lätt att hitta och kombinera gärna med dokumentationen så att allt finns på ett ställe. - Supportad data
Hur bra dokumentationen än är så kommer de som ska använda sig av data att vara olika människor ute i organisationen som kan behöva hjälp. Med att förstå data, med att skriva queries som inte kostar en förmögenhet att köra eller tar tre dagar, med olika saker. Det måste finnas hjälp att få även för dem som inte sitter med SQL hela dagarna. - Kvalitativ data
Ingen datakälla är perfekt, det finns alltid fel. Det är ok. Men det bör finnas ett aktivt arbete med att skapa och att bibehålla så hög informationstäthet som möjligt. Det här innefattar också saker som att ha en process för och en kommunikation kring förändringar i dataset. Det blir ogörligt att arbeta för bättre data om man inte får göra ändringar, och samtidigt går det inte att göra ändringar om man inte kan kommunicera med sina användare
För visst bör man säkra sin data mot intrång, det kan vara otroligt dyrt om fel data läcker. På många sätt. Men det kan vara väldigt kostsamt att använda sin egen data fel också. Det är bra om prognosgrafer är snygga, men det är bättre om de är rätt. Även detta är datasäkerhet.
