Bulbul Automation Tool – varför utveckla ett eget verktyg?

Det är inte speciellt svårt att starta utvecklingen av ett automatiseringsverktyg, det är desto svårare att få verktyget att praktiskt fungera bra i en organisation. För att göra ett heltäckande automationsverktyg för Data Vault så behöver kunskaperna om Data Vault, RDBMS, systemarkitektur och human-to-machine vara på en hög nivå.

Vi på Bulbul hävdar att de verktyg som ligger ute på marknaden, och de verktyg som är hemtillverkade inom organisationer, inte uppfyller de kunskaper inom Data Vault, RDBMS, systemarkitektur och human-to-machine som vi kräver. Marknaden har en mängd verktyg (Wherescape, Data Vault builder, DBTVault, Vaultspeed) där utmaningar så som skalbarhet, användarvänlighet och hastighet är åsidosatta. Verktygen har ofta ett GUI som ser fint ut, och presentationerna av dessa verktyg hanterar endast några få väldigt enkla case.

‍

Det ligger utmaningar i att till exempel visa en stor Data Vault-modell i ett Web GUI, både för självaste browserna och för människan som ska scrolla runt i en area, klicka på objekt och göra inställningar. Det är oroväckande hur ofta vi först får höra att det är "enkelt att lägga till x" och sedan klickas det runt i en tio minuter lång tutorial för att göra en enda sak.

Därför har vi utvecklat ett Automation Tool

Vi har tagit fram ett Automation Tool eftersom det gör att utveckling, vidareutveckling och förvaltning av ett Data Warehouse kan skötas med så låg arbetsinsats som möjligt. Vårt Automation Tool, BAT, bygger ett Data Warehouse modellerat efter principerna av Data Vault.  

‍

Det innebär att en tolk läser av hur en modellerare/utvecklare modellerat ett Data Vault system och sedan skapas koden "automatiskt" istället för att en utvecklare behöver skriva den förhand. Detta gör att mängden fel, utvecklingstid, deployment och testning i ett projekt kan ske på mycket kortare tid.  

‍

Det finns en mängd Automation Tools på marknaden som vi testat och gemensamt för dessa är att de på ytan ser bra ut men gör inte att projekten genomförs på ett effektivt sätt. Vi har byggt vårt verktyg för att användarna ska kunna ta del av alla de fördelar som Data Vault modellering innebär. Det är också därför vi säger att vi kan genomföra projekt mycket snabbare än traditionella Data Warehouse-projekt.  

Varför har vi valt Microsoft SQL Server som plattform för våra Data Warehouse? 

Vi har valt att generera kod för SQL Server då vi anser att man får vad man betalar för i den databasmotorn. Valet av SQL Server gör att det finns en mängd praktiska mjukvaror som används i en Bulbul Automation Tool-lösning. Användaren av systemet sitter i Microsoft Management studio som har fått modelleringstjänster installerade via en lokal databas. Det är alltså inget Web GUI eller något externt program som modelleraren/utvecklaren behöver jobba i, utan en trygg miljö där de vet hur saker fungerar.

‍

GIT används som versionshanteringssystem för metadata och skräddarsydd kod. Vi genererar dacpac och ispac utifrån metadata så vi enkelt kan göra dacpac publish mellan ett redan deployat system och ett soon-to-be-deployed project. Att sedan använda publish-metoder i de CI/CD pipelines som vi bygger är standard. Så när vi talar om automation, continous integration, continous delivery så är det riktiga saker i våra Data Warehouse-lösningar. Lösningarna kan deployas både i Cloud och on-prem. 

Varför har vi byggt BAT som ett fristående hjälpmedel?

Vi har valt att möjliggöra en lösning, som versionernas av GIT, utan att vara bunden till mjukvaran Bulbul Automation Tool. De objekt som genereras blir en del utav ett "project" som kan hanteras i VisualStudio som vilket "project" som helst. Det är alltså möjligt att fortsätta jobba med en, utav Bulbul Automation Tool genererad, lösning helt utan Bulbul Automation Tool.

‍

Detta gör verktyget helt unikt mot konkurrenterna och det eliminerar risken för kunderna att bli "inlåsta" i vår mjukvara eller riskerar att lösningen skulle sluta fungera om uppdateringar för Bulbul AutomationTool skulle sluta komma ut. Kunderna sätts inte i knät på oss som leverantör och systemet är framtidssäkrat. 

Är det enkelt att ta hand om ett system genererat av BAT? 

Vi har hela tiden fokuserat på att systemen som genereras ska bli så enkla som möjligt att ta hand om. Därför deployas också en schemaläggare till varje lösning. Schemaläggaren använder standardobjekt i SQL Server och ansvarar för de olika körningarna som behöver utföras i ett Data Warehouse.

‍

Här finns funktionalitet som när, varför och vem behöver jag vänta på, för att en körning ska exekveras. Det går att definiera beroenden mellan körningar och det går att manuellt lägga in körningar i ett kösystem. Väldigt praktiskt när en initial laddning av ett system ska ske. Systemet använder också standardkomponenter i SQL Server för att logga alla körningar. 

Marknadens bästa crossvalidationenhet för Data Vault modellering

När användarna jobbar med modellering ska systemet så snabbt som möjligt guida användaren att göra rätt. När BAT sedan kompilerar metadata till kod så valideras metadata, källa för källa, mellan alla metadataspecifikationer. Den kontrollerar till exempel om en hub med samma namn i olika metadataspecifikationer innehåller samma egenskaper.

‍

Valideringen kontrollerar också den modellering som är gjord kommer uppfylla det så kallade Jedi-testet. Ett lyckat Jedi-test innebär att systemet tar in data utan några som helst dataförluster – Zero Data Loss. Praktiskt så tvingar BAT fram en RTS (record tracking satellite) på en UOW (Unit of work) link för att garantera att ett genererat system som inte läser in data med dataförluster. Denna typ av validering är vi de enda som kan erbjuda på marknaden idag.