Data kommer inte från en svart låda

Inte allt för länge sedan satt jag med i ett möte där man diskuterade olika lösningar för både DW och BI. Det var en del av ett stort DW/BI projekt som skulle innebära stora förändringar för hela organisationen. Projektet hade fortlöpt under ganska lång period innan detta möte och det var många personer inblandade. De allra flesta hade deltagit i ett antal workshops både internt och externt med leverantörer och konsulter för att arbeta fram lösningen. Mitt i detta möte ställer helt plötsligt ekonomichefen frågan: "Alltså en databas, vad är det för någonting egentligen? Är det ett program? En burk? Eller vad?". Svaret på frågan som han fick från leverantören var någonting i stil med "Man lagrar data i en databas och det kan både vara mjukvara och hårdvara". Då kände man verkligen klyftan mellan leverantören, IT-avdelningen och verksamheten. Jag förväntar mig verkligen inte att en ekonomichef skall förstå sig på underliggande teknologier i databaser, men tycker att det är ett misslyckande om hela företagets DW/BI lösning uppfattas som ett stort svart magisk hål som spottar ur sig rapporter och KPIer. Om varken IT eller leverantörer kan göra ett bättre jobb i att förmedla vad det är som leverar allt data ut till slutanvändaren, vem ska då kunna göra det?

Vi föreställer oss att jag har en receptsamling på 1000 recept i en låda. Vem som helst kan komma och fråga mig om recept och mitt jobb är att kunna ta fram rätt recept. De första frågorna som ställs är i stil med "Kan du ge mig receptet på kladdkaka?". Ganska snabbt inser jag att det vore nog klokt att sortera recepten i bokstavsordning, på så sätt kan jag mycket fortare hitta rätt recept.

Sen börjar frågorna förändras "Kan du ge mig alla recept som innehåller nötter?". Hur ska jag lösa dessa frågor på ett effektivt sätt? Alla recept innehåller flera ingredienser så det går inte att sortera på något vettigt sätt. Tre alternativ skulle kunna vara:

1. Jag skaffar fler lådor, en låda per ingrediens. Sedan tar jag kopior av recepten och lägger en kopia i varje låda för varje ingrediens varje recept innehåller.
2. Jag köper ett gäng Post-it index och färgkodar alla recept med olika färger beroende på vilka ingredienser de innehåller.
3. Jag tar hjälp av fler personer.

Alternativ ett blir en grymt effektiv lösning. Ifall någon vill ha recept med nötter så tar jag bara alla recept i nötlådan. De går nästan inte att komma på en lösning som skulle gå snabbare. Nackdelarna är dock många och växer på sikt. Ju fler recept jag samlar på mig, dessto fler ingredienser kommer det att finnas och dessto fler lådor måste jag förvara någonstans. Potentiellt köpa nya hyllor. För varje nytt recept måste jag lägga tid på att kopiera receptet och sortera in det i rätt lådor. Ifall jag har skrivit fel någonstans, måste jag leta upp alla kopior och ändra på samtliga. Ifall jag missar att ändra på en av kopiorna kommer jag att ha olika recept för samma sak. Sen kommer det stora problemet. Frågor angående olika kombinationer börja ställas, "Kan du ge mig alla recept som innehåller nötter och grädde?". Shit, ska jag ha lådor och kopior för alla olika kombinationer av ingredienser!!! Den tekniska motsvarigheten till detta är att skapa silos (kuber, in-memory, materialiserade vyer, etc.) för att få prestanda.

Alternativ två är inte lika effektivt. För att hitta alla nötrecept måste jag plocka fram t.ex. alla blåa recept, men det går betydligt fortare än att läsa igenom alla recept och leta efter nötter. Fördelen är dock att jag har fortfarande bara en kopia av receptet. Det går lite fortare att klistra på mina Post-it index lappar än att göra kopior och sortera dem. Jag kan på ett lättare sätt hantera kombinationer då recept med nötter och grädde skulle innebära t.ex. blåa och röda recpet. Det blir dock lite jobbigare ifall jag bestämmer mig för att grädde inte längre ska vara röd utan gul. Då måste jag gå igenom alla röda och byta till gult index. Det börjar bli ännu jobbigare att få plats med alla möjliga färgkodningar för alla möjliga kombinationer rent fysiskt på receptet. Den tekniska motsvarigheten till detta alternativ är att försöka ha en generell modell i sitt DW och arbeta med inbyggd funktionalitet (index, hashmaps, projektioner, etc.) för att snabba upp sökningarna och hitta rätt.

Alternativ tre kan bli riktigt effektivt. Dessto fler personer som hjälper till dessto fortare går det att hitta rätt recept. Det är lätt att hantera ökade antal recept då det bara är att ta hjälp av fler. Spontant känns det som en väldigt dyr lösning att betala löner till alla som hjälper till, men när det kommer till de tekniska lösningarna finns det både dyra och billiga alternativ. Den tekniska motsvarigheten är att parallellisera och/eller distribuera beräkningarna (MPP, Hadoop, etc.) för att snabba upp sökningarna.

Exemplet är så klart väldigt förenklat, men ett sätt att illustrera att en databas är ingen svart låda. Man kan lagra allt data i en viss ordning på hårddisken och ha olika sätt för att sedan hitta delmängder baserat på vissa villkor men mycket mer än så kan man inte göra. Rent krasst kan man säga att blir lösningen snabb på en sak, blir den långsam på en annan. Poängen med detta exempel är att jag anser att det är viktigt att alla inblandade i ett DW/BI projekt bör ha en insikt på denna nivån. Alla måste förstå att oavsett vad någon säger eller lovar så finns det ingen silver bullet. Alla lösningar har begränsningar och det gäller att välja en lösning vars begränsningar får så liten inverkan som möjligt.