Fordelene ved kontinuerlig integration til Business Intelligence

Hvordan Business Intelligence-industrien kan drage fordel af kontinuerlig integration

Branchemæssigt er Business Intelligent (BI) stadig et relativt nyt felt. Som mange teknologibaserede industrier har BI gjort fremskridt gennem sine tidlige stadier med implementeringer underlagt ad hoc-processer og vidt varierende succes. Tidligere har det været almindeligt for flere BI-projekter implementeret af den samme organisation at tage vildt forskellige tilgange på vej mod meget ens mål. I de senere år har fremsynede organisationer dog øget deres BI-kapaciteter gennem centralisering af BI-viden og -ekspertise. Med modeller som "BI Competency Center" (BICC) og "BI Center of Excellence" bliver mere og mere udbredt, definerer disse organisationer nu BI-teknologistakke, værktøjssæt, processer og teknikker for hele organisationen for at sikre succes og maksimere ROI på nye BI-tiltag. De tager også udgangspunkt i bedste praksis i flankerende kategorier, i dette tilfælde softwareindustrien.

En bedste praksis, der endnu ikke er blevet anerkendt af BI-fællesskabet, er Continuous Integration (CI). Inden for softwareudvikling er CI den proces, hvorved en softwarekodebase automatisk bygges og røgtestes med hyppige intervaller - i udviklingsmiljøet. På et typisk CI-aktiveret softwareprojekt overvåger en "byggeserver" projektets kildekodelager, og når der registreres ændringer, trækker den en ren kopi af kilden, laver en fuld genopbygning, kører alle regressionstests og giver proaktivt besked om udviklingen. team af eventuelle fejl. Hver fuldt vellykket cyklus1 producerer et installerbart sæt binære filer til softwareproduktet.

Denne hyppige, automatiserede integration fanger hurtigt eventuelle fejl, der introduceres i systemet (ofte inden for få minutter efter deres introduktion), og gør det meget nemmere at se, hvem der introducerede fejlen og hvornår. Defekter og inkompatibiliteter er uvægerligt billigere at rette, når de fanges inden for få minutter efter deres introduktion (især hvis de aldrig kommer ud af udviklingsmiljøet).

Hovedprincipperne for kontinuerlig integration (CI)

• Gentagelige, automatiserede bygge- og testprocesser.
• Disse automatiserede bygge- og testprocesser udføres ofte, så integrationsproblemer opdages tidligt.
• Hyppige, automatiserede cyklusser giver tidlige advarsler for ødelagte/inkompatible artefakter.
• Næsten øjeblikkelig validering og test af alle ændringer i systemet.

Der er ingen tvivl om, at CI-praksis er blevet et uvurderligt værktøj i den moderne softwareudviklingsorganisations arsenal. CI forbedrer både kvaliteten og momentum af softwareudviklingsteams. Erfarne udviklingsteams, der har taget CI-konceptet til sig, kan ikke forestille sig at påtage sig et større softwareprojekt uden det.

Kunne BI-industrien også drage fordel af praksis med kontinuerlig integration?

Absolut. I de kommende år vil praksis med CI blive anerkendt for dets enorme potentiale, når det anvendes til moderne BI-udviklingsmiljøer. BI-økosystemer er i sagens natur komplekse (se figur 1). De består ofte af mange bevægelige dele med mange indbyrdes afhængigheder. For eksempel kan et typisk BI-økosystem indeholde:

• Flere upstream-datakilder.
• ETL-processer udtrækker, renser og indlæser periodisk data fra hver af disse opstrømskilder til data marts eller datavarehuse.
• Mange BI-produkter tilføjer et "model"-lag oven på disse marts eller varehuse.
• Professionelle BI-forfattere bygger BI-indhold ud mod dette modellag (f.eks. rapporter).

Som erfarne BI-udøvere kan bevidne - mindre ændringer i et hvilket som helst af disse lag kan bølge gennem hele systemet - skabe fejl eller ineffektivitet i de resulterende BI-output. Afhængigt af hvor BI-teamet befinder sig i en udgivelsescyklus, kan disse fejl eller ineffektivitet forblive ubemærket i dage, uger eller endda måneder.

Her er et par eksempler fra den virkelige verden:

• En tilsyneladende harmløs ændring af modellaget forårsager uventede ændringer i tallene for en rapport, der ikke er blevet redigeret i flere måneder. Disse ændringer forringer også ydeevnen af ​​den samme rapport (en tilstand, der er endnu sværere at kvantificere og opdage manuelt).
• En ændring i en visning i en DB forårsager en dramatisk stigning i rapportens køretider.
• En modelbygger omdøber eller sletter en kolonne, som en rapport afhænger af.
• En rapportforfatter forsøger at optimere en rapport, men den nye rapport giver ikke korrekte resultater, når valgfrie parametre er indstillet.

I de fleste BI-udviklingsmiljøer udføres test af BI-indholdet under udvikling ofte på en meget manuel måde (f.eks. "kør en rapport, tjek tallene, bekræft, at de er korrekte"). BI-teams har en tendens til at fokusere denne manuelle test på de artefakter3, som de aktivt ændrer, snarere end dem, der ikke er blevet ændret for nylig. Denne tendens giver sig selv til uopdagede problemer, når ændringer til et lavere niveau af systemet begynder at bølge opad og påvirke mange BI-artefakter.

De fleste organisationer vil med jævne mellemrum levere basislinjer for BI-indhold fra et udviklingsmiljø til et test- eller kvalitetssikringsmiljø (QA), hvor de vil gennemgå mere formelle tests af QA-professionelle. Afhængigt af kvaliteten af ​​QA-teamet, kan defekter eller forringelser i ydeevnen blive fanget her, men på dette tidspunkt er omkostningerne ved at rette disse problemer steget betydeligt. Når først en defekt er kommet ud af udviklingsmiljøet (f.eks. ind i et QA-miljø), bliver det meget dyrere at rette. Typisk arbejdsgang for korrektion inkluderer oprettelse af en problembillet, der beskriver, hvordan man reproducerer defekten (af QA-teamet), BI-team-triage af alle ventende problembilletter (for at beslutte, hvilke der skal prioriteres), reproduktion af problemet under udvikling, implementering af en fix, og derefter omplacering af en anden baseline til QA. Ligeledes er defekter, der opdages i produktionsmiljøer, endnu dyrere at rette end dem, der opdages i QA.

Ved at bruge principperne for CI kan et BI-udviklingsteam proaktivt opdage problemer som disse (ofte inden for få minutter efter ændringen, der forårsagede dem), og træffe korrigerende handlinger, mens BI-indholdet stadig er i udviklingsmiljøet. Dette betyder, at de samlede omkostninger ved korrektion er meget billigere.

Så hvordan kan principperne for CI anvendes på et typisk Business Intelligence-projekt? For nogle konkrete eksempler vil vi overveje MotioCI™, et kommercielt værktøj, der muliggør Continuous Integration for Business Intelligence-udviklingsmiljøer. MotioCI giver BI-teams følgende funktioner:

Kontinuerlig integration til Business Intelligence

1. Automatiseret validering af alle BI-artefakter mod deres tilsvarende model. Dette sikrer, at eventuelle model- eller databaseændringer ikke "bryder" eksisterende BI-artefakter.
2. Automatiseret udførelse af testcases for hver artefakt. Disse testcases kan bruges til at sikre ting som:
   1. Udførelsen af ​​artefakten producerede nøjagtige data
   2. Udførelsen af ​​artefakten producerede den forventede mængde data
   3. Udførelsen af ​​artefakten er acceptabel (udførelsen afsluttes inden for den forventede tid)
3. Automatiseret konsistenskontrol. For hver artefakt:
   1. Bekræft, at den overholder de etablerede projekt- eller virksomhedsstandarder for ting som farver, skrifttyper, stilarter, indlejrede billeder osv.
   2. Bekræft, at parameternavne er konsistente på tværs af artefakter
   3. Bekræft, at boreforhold mellem artefakter stadig er gyldige
4. Sporing af ændringer i BI-økosystemet, så når en test begynder at mislykkes, har projektinteressenter et klart overblik over "hvem der har ændret hvad" siden sidste cyklus. For eksempel:
   1. Hvilke modeller er blevet ændret (og af hvem?)
   2. Hvilke artefakter er blevet ændret (og af hvem?)
   3. Er der sket skemaændringer i de relevante datakilder?
   4. Er der sket drastiske ændringer i mængderne af data i de relevante datakilder?

Ved at automatisere ovenstående proces og få den til at køre med hyppige intervaller, vil BI-indholdet, der produceres af et team, løbende blive verificeret for nøjagtighed, konsistens og ydeevne, mens det stadig er i udviklingsmiljøet. Hvis CI-processen opdager en fejl, vil den proaktivt underrette BI-teamet om problemet, samt katalogisere de ændringer af BI-økosystemet, der er sket siden den sidste vellykkede cyklus. Denne metode gør det muligt for BI-teamet hurtigt at bemærke problemer skabt af de seneste ændringer, træffe korrigerende handlinger og minimere omkostningerne.

Nettoresultater af implementering af kontinuerlig integration til BI

1. Fejl, ineffektivitet og standardovertrædelser fanges meget tidligt (normalt inden for få minutter eller timer efter deres introduktion.
2. BI-teamet vinder utallige timer tilbage, ellers brugt manuelt på at teste alle artefakter for at sikre, at noget ikke er gået i stykker, hvilket sparer tid, men holder også momentum (det giver BI-forfattere mulighed for at fokusere på reelle udviklingsopgaver).
3. BI-teamet får øget synlighed i "hvem ændrer hvad" i deres BI-økosystem.
4. De output, der produceres af BI-teamet, er af meget højere kvalitet.
5. Opstrøms QA-organisationer kan fokusere deres energi på mere test på højt niveau (al den "lavthængende frugt" filtreres automatisk fra, før BI-indholdet blev promoveret til QA).

Sammenfattende, efterhånden som BI-industrien modnes og etablerer bedste praksis inden for konsolidering, styring og anvendelse af business intelligence, bør nye BICC'er undersøge og udnytte erfaringerne fra flankerende kategorier, specifikt softwareindustrien. CI er ikke kun en softwareindustris bedste praksis, men den udvikler sig også til en standarddriftsprocedure. Efterhånden som gennemprøvet praksis som CI bliver vedtaget, vil BICC'er fortsætte med at modnes som en kerneforretningsdisciplin ved ikke kun at forbedre gennemstrømningen af ​​et BI-team (kritisk for skalerbarhed), men også ved at øge kvaliteten af ​​dets output. Denne dobbelte påvirkning repræsenterer et spring i BICC-ydeevne og vil snart være en grundpille for moderne BI-miljøer.

1 En vellykket cyklus er en, hvor ingen test mislykkes.
2 Martin Fowlers originale artikel, der beskriver Continuous Integration, blev offentliggjort i september 2000.