Bulbul Automation Tool – så här gjorde vi

Vi på Bulbul har utvecklat marknadens snabbaste automation tool för att generera Data Vault-system. Men hur gjorde vi? Vi började i behoven.  

Med utgångspunkt i de behov som en modellerare/utvecklare har när den ska bygga ett Data Warehouse gjorde vi en lista. Utifrån listan med behov kunde vi sedan bygga en programvara som ger användaren av vårt Automation Tool en så snabb väg som möjligt till ett Data Warehouse deployat i produktionsmiljö. På det här sättet vet vi att Bulbul Automation Tool, BAT, både tar hänsyn till modellerararnas/utvecklarnas förutsättningar och till de förutsättningar som våra kunder har. Hela paketet!

‍

De behov som vi identifierade var följande: 

1. No “no-code” 

“No code” är ett begrepp som ungefär används som: "Ni ska inte behöva hålla på med jobbig kod för att implementera ett Data Warehouse". Det kanske låter häftigt och det skulle det vara om det fungerade i praktiken. Det är tyvärr naivt att tro att ett avancerat datasystem inte skulle behöva kodändringar eller att de personer som bygger ett Data Warehouse inte skulle behöva förstå programmatisk kod. I stället har vi tänkt på ett sätt som faktiskt fungerar i verkligheten. Vårt Automation Tool genererar kod utifrån metadata men samtidigt kan användarna av verktyget lägga till skräddarsydd kod eller overrida den kod som genereras av verktyget. Det är en förutsättning för att ett Data Warehouse ska kunna svara mot verksamhetens alla krav. 

2. Det måste vara enkelt att använda 

Att utveckla Data Warehouse och skriva programmatisk kod är svårt, därför behöver ett automationsverktyg vara så enkelt som möjligt så att användarna så snabbt som möjligt kan få ut värde av det. Därför har vi byggt validerare som, redan när man modellerar, berättar för användaren att den har gjort fel och på vilket sätt. Vi har även gjort så att de system som genereras måste uppfylla kraven om Zero Data Loss, utifrån Data Vaults principer. Idag är det bara Bulbul som levererar detta på marknaden. Att systemen uppfyller kraven om Zero Data Loss innebär att användarna av systemen får en guidning i att bygga datamässigt säkra system.

3. Allt måste gå snabbt

Om man utvecklar något som går långsamt kommer det fungera hyfsat för att köra två-tre processer. Men vad gör du när det är hundra processer som ska köras? Tid är pengar och för att få ett Data Warehouse att kunna skala upp med ett växande behov så måste alla processer gå så snabbt som möjligt. Tekniken ska inte stå i vägen för verksamhetens krav på sitt Data Warehouse. Ingen orkar vänta. Kompilering och generering av kod, deployment till server, feedback till användaren – allt måste ske så snabbt som möjligt. Även den kod som genereras, alltså den som faktiskt kör Data Warehouse, är framtagen för att exekvera så snabbt som möjligt. Den kod som BAT genererar på några sekunder hade tagit veckor att skriva för hand.

4. Det är mänskligt att fela 

Den mänskliga faktorn är något man behöver utgå från istället för att irriteras på. Därför har vi byggt systemet att vara feltolerant: det går att ladda om data, migrera data, ändra på strukturer, ta in nya definitioner av samma data och rätta tidigare fel. På detta sätt kan vi möta dåliga beslut, trasiga data, felaktiga rapporter, motstridiga önskemål och luddigt formulerade krav. Systemet är byggt för att människor kommer göra fel och när de väl gör fel så ska det vara så lätt som möjligt att göra rätt.