Fördelarna med kontinuerlig integration för Business Intelligence

Hur Business Intelligence -industrin kan dra nytta av kontinuerlig integration

Branschmässigt är Business Intelligent (BI) fortfarande ett relativt nytt område. Liksom många teknikbaserade industrier har BI utvecklats i sina tidiga skeden med implementeringar som är föremål för ad hoc -processer och mycket varierande framgångar. Tidigare har det varit vanligt att flera BI -projekt implementerade av samma organisation har väldigt olika metoder på väg mot mycket liknande mål. Under de senaste åren har emellertid framåt tänkande organisationer ökat sina BI -kapacitet genom centralisering av BI -kunskap och expertis. Med modeller som ”BI Competency Center” (BICC) och ”BI Center of Excellence” blir allt vanligare, definierar dessa organisationer nu BI -tekniska staplar, verktygsuppsättningar, processer och tekniker för hela organisationen för att säkerställa framgång och maximera avkastningen på nya BI -initiativ. De tar också ledtrådar från bästa praxis inom flankerande kategorier, i detta fall mjukvaruindustrin.

En bästa praxis som ännu inte har erkänts av BI -gemenskapen är den för kontinuerlig integration (CI). Inom mjukvaruutveckling är CI den process genom vilken en programvarukodbas automatiskt byggs och röktestas med jämna mellanrum-i utvecklingsmiljön. På ett typiskt CI-aktiverat mjukvaruprojekt övervakar en ”build-server” projektets källkodförråd och, när ändringar upptäcks, drar en ren kopia av källan, gör en fullständig ombyggnad, kör alla regressionstester och meddelar proaktivt utvecklingen team av eventuella misslyckanden. Varje fullt framgångsrik cykel1 producerar en uppsättning binära filer för programvaruprodukten.

Denna frekventa, automatiska integration fångar snabbt upp eventuella fel som införs i systemet (ofta inom några minuter efter introduktionen) och gör det mycket lättare att se vem som införde felet och när. Defekter och inkompatibiliteter är alltid billigare att korrigera när de fångas inom några minuter efter introduktionen (särskilt om de aldrig kommer ur utvecklingsmiljön).

Huvudprinciperna för kontinuerlig integration (CI)

• Upprepningsbara, automatiserade bygg- och testprocesser.
• Dessa automatiserade bygg- och testprocesser körs ofta så att integrationsproblem upptäcks tidigt.
• Frekventa, automatiserade cykler ger tidiga varningar för trasiga / inkompatibla artefakter.
• Nära omedelbar validering och testning av alla ändringar i systemet.

Det råder ingen tvekan om att praxis med CI har blivit ett ovärderligt verktyg i arsenalen i den moderna programvaruutvecklingsorganisationen. CI förbättrar både kvalitet och fart i programvaruutvecklingsteam. Erfarna utvecklingsteam som har anammat begreppet CI kan inte tänka sig att genomföra några betydande mjukvaruprojekt utan det.

Kan BI -industrin också dra nytta av praktiken med kontinuerlig integration?

Absolut. Under de kommande åren kommer praktiken med CI att erkännas för sin enorma potential när den tillämpas på moderna BI -utvecklingsmiljöer. BI -ekosystem är i sig komplexa (se figur 1). De består ofta av många rörliga delar, med många inbördes beroende. Till exempel kan ett typiskt BI -ekosystem innehålla:

• Flera uppströms datakällor.
• ETL -processer extraherar, rensar och läser in data från var och en av dessa uppströms källor regelbundet till data marts eller datalager.
• Många BI -produkter lägger till ett "modell" -skikt ovanpå dessa marts eller lager.
• Professionella BI -författare bygger ut BI -innehåll mot detta modellskikt (t.ex. rapporter).

Som erfarna BI -utövare kan intyga - mindre förändringar i något av dessa lager kan krusa genom hela systemet - skapa fel eller ineffektivitet i de resulterande BI -utmatningarna. Beroende på var BI -teamet befinner sig i en släppcykel kan dessa fel eller ineffektivitet gå obemärkt i dagar, veckor eller till och med månader.

Här är några verkliga exempel:

• En till synes oskyldig ändring av modellskiktet orsakar oväntade ändringar i siffrorna för en rapport som inte har redigerats på månader. Dessa förändringar försämrar också prestanda för samma rapport (ett tillstånd som är ännu svårare att kvantifiera och upptäcka manuellt).
• En ändring av en vy i en DB orsakar en dramatisk ökning av rapporttiden.
• En modellare byter namn på eller tar bort en kolumn som en rapport är beroende av.
• En rapportförfattare försöker optimera en rapport, men den nya rapporten ger inte korrekta resultat när valfria parametrar ställs in.

I de flesta BI -utvecklingsmiljöer utförs ofta testning av BI -innehåll som utvecklas på ett mycket manuellt sätt (t.ex. "kör en rapport, kontrollera siffrorna, verifiera att de är korrekta"). BI -team tenderar att fokusera denna manuella testning på artefakterna3 som de aktivt förändrar, snarare än de som inte har ändrats nyligen. Denna tendens lämpar sig för oupptäckta problem när ändringar till en lägre nivå av systemet börjar krusa uppåt och påverkar många BI -artefakter.

De flesta organisationer kommer regelbundet att leverera baslinjer för BI -innehåll från en utvecklingsmiljö till en test- eller kvalitetssäkringsmiljö (QA), där de kommer att genomgå mer formella tester av QA -proffs. Beroende på QA -teamets noggrannhet kan defekter eller försämringar av prestanda fångas upp här, men vid denna tidpunkt har kostnaden för att korrigera dessa problem ökat avsevärt. När ett fel har gjort det ur utvecklingsmiljön (t.ex. i en QA -miljö) blir det mycket dyrare att rätta till. Typiskt arbetsflöde för korrigering inkluderar skapande av en problembiljett som beskriver hur man reproducerar defekten (av QA -teamet), BI -team triage av alla väntande problembiljetter (för att avgöra vilka som prioriteras), reproduktion av problemet under utveckling, implementering av en fixa, och sedan omplacering av en annan baslinje till QA. På samma sätt är defekter som upptäcks i produktionsmiljöer ännu dyrare att åtgärda än de som upptäcks i QA.

Med hjälp av CI: s principer kan ett BI -utvecklingsteam proaktivt upptäcka problem som dessa (ofta inom några minuter efter den förändring som orsakade dem) och vidta korrigerande åtgärder medan BI -innehållet fortfarande finns i utvecklingsmiljön. Detta innebär att den totala kostnaden för korrigering är mycket billigare.

Så hur kan principerna för CI tillämpas på ett typiskt Business Intelligence-projekt? För några konkreta exempel ska vi överväga MotioCI™, ett kommersiellt verktyg som möjliggör kontinuerlig integration för utvecklingsmiljöer för Business Intelligence. MotioCI ger BI-team följande funktioner:

Kontinuerlig integration för Business Intelligence

1. Automatiserad validering av alla BI -artefakter mot motsvarande modell. Detta säkerställer att alla modell- eller databasändringar inte ”bryter” befintliga BI -artefakter.
2. Automatiskt utförande av testfall för varje artefakt. Dessa testfall kan användas för att säkerställa sådant som:
   1. Exekveringen av artefakten gav exakta data
   2. Exekveringen av artefakten gav den förväntade datamängden
   3. Artefaktens prestanda är acceptabel (körningen slutförs under den förväntade tiden)
3. Automatisk konsistenskontroll. För varje artefakt:
   1. Kontrollera att det följer de etablerade projekt- eller företagsstandarderna för saker som färger, teckensnitt, stilar, inbäddade bilder etc.
   2. Kontrollera att parameternamn är överensstämmande i artefakter
   3. Kontrollera att borrelationer mellan artefakter fortfarande är giltiga
4. Spårning av BI -ekosystemförändringar så att när ett test börjar misslyckas har projektintressenterna en klar bild av “vem har förändrat vad” sedan förra cykeln. Till exempel:
   1. Vilka modeller har ändrats (och av vem?)
   2. Vilka artefakter har ändrats (och av vem?)
   3. Har det skett ändringar i relevanta datakällor?
   4. Har det skett drastiska förändringar av datamängderna i de relevanta datakällorna?

Genom att automatisera ovanstående process och få den att köras med jämna mellanrum kommer BI -innehållet som produceras av ett team att kontinuerligt verifieras med avseende på noggrannhet, konsistens och prestanda medan det fortfarande finns i utvecklingsmiljön. Om CI -processen upptäcker ett fel meddelar det proaktivt BI -teamet om problemet, samt katalogiserar de ändringar i BI -ekosystemet som har inträffat sedan den senaste framgångsrika cykeln. Denna metod gör att BI -teamet snabbt kan märka problem som skapats av de senaste ändringarna, vidta korrigerande åtgärder och minimera kostnaderna.

Nettoresultat av implementering av kontinuerlig integration för BI

1. Fel, ineffektivitet och standardöverträdelser fångas mycket tidigt (vanligtvis inom några minuter eller timmar efter introduktionen.
2. BI -teamet får tillbaka otaliga timmar som annars används för att manuellt testa alla artefakter för att se till att något inte har gått sönder, vilket sparar tid, men också bibehåller fart (det gör att BI -författare kan fokusera på verkliga utvecklingsuppgifter).
3. BI -teamet får ökad insyn i "vem ändrar vad" i sitt BI -ekosystem.
4. Utgångarna från BI -teamet är av mycket högre kvalitet.
5. Uppströms QA-organisationer kan fokusera sina energier på mer tester på hög nivå (all "lågt hängande frukt" filtreras automatiskt bort innan BI-innehållet marknadsfördes till QA).

Sammanfattningsvis, när BI -industrin mognar och fastställer bästa praxis vid konsolidering, hantering och tillämpning av business intelligence, bör framväxande BICC undersöka och dra nytta av lärdomarna i flankerande kategorier, särskilt mjukvaruindustrin. CI är inte bara en mjukvaruindustrins bästa praxis, utan det utvecklas också till ett vanligt operativt förfarande. När beprövade metoder som CI antas kommer BICC: er att fortsätta att mogna som en kärnverksamhetsdisciplin genom att inte bara förbättra genomströmningen av ett BI -team (avgörande för skalbarhet), utan också genom att öka kvaliteten på dess resultat. Denna tvåfaldiga inverkan representerar ett steg i BICC -prestanda och kommer snart att vara en grundpelare för moderna BI -miljöer.

1 En lyckad cykel är en cykel där inga test misslyckas.
2 Martin Fowlers originalpapper som beskriver kontinuerlig integration publicerades i september 2000.