De voordelen van continue integratie voor Business Intelligence

Hoe de business intelligence-industrie kan profiteren van continue integratie

Industrieel gezien is Business Intelligent (BI) nog een relatief nieuw vakgebied. Net als veel andere op technologie gebaseerde industrieën, heeft BI de vroege stadia doorgemaakt met implementaties die onderhevig zijn aan ad-hocprocessen en zeer wisselend succes. In het verleden was het gebruikelijk dat meerdere BI-projecten die door dezelfde organisatie werden uitgevoerd, totaal verschillende benaderingen volgden op weg naar zeer vergelijkbare doelen. De afgelopen jaren hebben vooruitstrevende organisaties echter hun BI-capaciteiten vergroot door de centralisatie van BI-kennis en expertise. Nu modellen zoals het "BI Competency Center" (BICC) en het "BI Center of Excellence" steeds gangbaarder worden, definiëren deze organisaties nu BI-technologiestacks, toolsets, processen en technieken voor de hele organisatie om succes te garanderen en de ROI te maximaliseren op nieuwe BI-initiatieven. Ze nemen ook aanwijzingen van best practices in flankerende categorieën, in dit geval de software-industrie.

Een best practice die nog niet is erkend door de BI-gemeenschap is die van Continuous Integration (CI). Op het gebied van softwareontwikkeling is CI het proces waarbij een softwarecodebase automatisch wordt gebouwd en met regelmatige tussenpozen op rook getest - in de ontwikkelomgeving. Op een typisch CI-enabled softwareproject bewaakt een "buildserver" de broncoderepository van het project en, wanneer er wijzigingen worden gedetecteerd, haalt een schone kopie van de bron, voert een volledige herbouw uit, voert alle regressietests uit en stelt de ontwikkeling proactief op de hoogte team van eventuele mislukkingen. Elke volledig succesvolle cyclus1 produceert een installeerbare set binaire bestanden voor het softwareproduct.

Deze frequente, geautomatiseerde integratie vangt snel eventuele fouten op die in het systeem worden geïntroduceerd (vaak binnen enkele minuten na introductie), en maakt het veel gemakkelijker om te zien wie de fout heeft geïntroduceerd en wanneer. Defecten en incompatibiliteiten zijn altijd goedkoper te corrigeren als ze binnen enkele minuten na introductie worden opgemerkt (vooral als ze nooit uit de ontwikkelomgeving komen).

De belangrijkste principes van continue integratie (CI)

• Herhaalbare, geautomatiseerde bouw- en testprocessen.
• Deze geautomatiseerde bouw- en testprocessen worden frequent uitgevoerd zodat integratieproblemen vroegtijdig worden gesignaleerd.
• Frequente, geautomatiseerde cycli bieden vroegtijdige waarschuwingen voor kapotte/incompatibele artefacten.
• Bijna onmiddellijke validatie en testen van alle wijzigingen aan het systeem.

Het staat buiten kijf dat de praktijk van CI een instrument van onschatbare waarde is geworden in het arsenaal van de moderne softwareontwikkelingsorganisatie. CI verbetert zowel de kwaliteit als het momentum van softwareontwikkelingsteams. Ervaren ontwikkelingsteams die het concept van CI hebben omarmd, kunnen zich geen groot softwareproject voorstellen zonder.

Kan de BI-industrie ook profiteren van de praktijk van Continuous Integration?

Absoluut. In de komende jaren zal de praktijk van CI worden erkend vanwege zijn enorme potentieel wanneer het wordt toegepast op moderne BI-ontwikkelomgevingen. BI-ecosystemen zijn inherent complex (zie figuur 1). Ze bestaan ​​vaak uit veel bewegende delen, met veel onderlinge afhankelijkheden. Een typisch BI-ecosysteem kan bijvoorbeeld het volgende bevatten:

• Meerdere stroomopwaartse gegevensbronnen.
• ETL-processen extraheren, opschonen en laden periodiek gegevens uit elk van deze stroomopwaartse bronnen in datamarts of datawarehouses.
• Veel BI-producten voegen een "model"-laag toe bovenop deze marts of magazijnen.
• Professionele BI-auteurs bouwen BI-content uit tegen deze modellaag (bijvoorbeeld rapporten).

Zoals ervaren BI-professionals kunnen bevestigen - kleine wijzigingen in een van deze lagen kunnen door het hele systeem rimpelen - waardoor fouten of inefficiënties in de resulterende BI-output ontstaan. Afhankelijk van waar het BI-team zich in een releasecyclus bevindt, kunnen deze fouten of inefficiënties dagen, weken of zelfs maanden onopgemerkt blijven.

Hier zijn een paar voorbeelden uit de praktijk:

• Een schijnbaar onschuldige wijziging in de modellaag veroorzaakt onverwachte wijzigingen in de cijfers voor een rapport dat al maanden niet is bewerkt. Deze wijzigingen verslechteren ook de prestaties van hetzelfde rapport (een toestand die nog moeilijker te kwantificeren en handmatig te detecteren is).
• Een wijziging in een weergave in een database zorgt voor een dramatische toename van de runtimes van rapporten.
• Een modelleur hernoemt of verwijdert een kolom waarvan een rapport afhankelijk is.
• Een rapportauteur probeert een rapport te optimaliseren, maar het nieuwe rapport levert geen correcte resultaten op wanneer optionele parameters zijn ingesteld.

In de meeste BI-ontwikkelomgevingen wordt het testen van de BI-inhoud die in ontwikkeling is, vaak op een zeer handmatige manier gedaan (bijv. "maak een rapport, controleer de cijfers, controleer of ze correct zijn"). BI-teams hebben de neiging om deze handmatige tests te concentreren op de artefacten3 die ze actief aan het veranderen zijn, in plaats van op de artefacten die recentelijk niet zijn gewijzigd. Deze neiging leidt tot onopgemerkte problemen wanneer wijzigingen naar een lager niveau van het systeem naar boven beginnen te rimpelen en veel BI-artefacten beïnvloeden.

De meeste organisaties leveren periodiek baselines van BI-inhoud van een ontwikkelomgeving naar een test- of kwaliteitsborgingsomgeving (QA), waar ze meer formele tests zullen ondergaan door QA-professionals. Afhankelijk van de grondigheid van het QA-team, kunnen defecten of verslechteringen in de prestaties hier worden opgevangen, maar op dit moment zijn de kosten voor het corrigeren van deze problemen aanzienlijk gestegen. Als een defect eenmaal uit de ontwikkelomgeving is gekomen (bijvoorbeeld in een QA-omgeving), wordt het veel duurder om te corrigeren. Typische workflow voor correctie omvat het maken van een probleemticket waarin wordt beschreven hoe het defect moet worden gereproduceerd (door het QA-team), BI-teamtriage van alle in behandeling zijnde probleemtickets (om te beslissen welke prioriteit krijgen), reproductie van het probleem in ontwikkeling, implementatie van een repareren en vervolgens opnieuw inzetten van een andere basislijn naar QA. Evenzo zijn defecten die in productieomgevingen worden ontdekt, nog duurder om te repareren dan die welke in QA worden ontdekt.

Met behulp van de principes van CI kan een BI-ontwikkelteam dit soort problemen proactief detecteren (vaak binnen enkele minuten na de wijziging die ze heeft veroorzaakt) en corrigerende maatregelen nemen terwijl de BI-inhoud zich nog in de ontwikkelomgeving bevindt. Dit betekent dat de totale kosten van correctie veel minder duur zijn.

Dus hoe kunnen de principes van CI worden toegepast op een typisch Business Intelligence-project? Voor enkele concrete voorbeelden zullen we overwegen: MotioCI™, een commerciële tool die continue integratie mogelijk maakt voor Business Intelligence-ontwikkelomgevingen. MotioCI biedt BI-teams de volgende functies:

Continue integratie voor Business Intelligence

1. Geautomatiseerde validatie van alle BI-artefacten ten opzichte van het bijbehorende model. Dit zorgt ervoor dat eventuele model- of databasewijzigingen geen bestaande BI-artefacten "breken".
2. Geautomatiseerde uitvoering van testgevallen voor elk artefact. Deze testgevallen kunnen worden gebruikt om zaken als:
   1. De uitvoering van het artefact leverde nauwkeurige gegevens op
   2. De uitvoering van het artefact heeft de verwachte hoeveelheid gegevens opgeleverd
   3. De prestaties van het artefact zijn acceptabel (uitvoering is binnen de verwachte tijd voltooid)
3. Geautomatiseerde consistentiecontrole. Voor elk artefact:
   1. Controleer of het voldoet aan de vastgestelde project- of bedrijfsnormen voor zaken als kleuren, lettertypen, stijlen, ingesloten afbeeldingen, enz.
   2. Controleer of de parameternamen consistent zijn tussen artefacten
   3. Controleer of de analyserelaties tussen artefacten nog steeds geldig zijn
4. Het volgen van veranderingen in het BI-ecosysteem, zodat wanneer een test begint te mislukken, de belanghebbenden van het project een duidelijk beeld hebben van "wie heeft wat veranderd" sinds de laatste cyclus. Bijvoorbeeld:
   1. Welke modellen zijn gewijzigd (en door wie?)
   2. Welke artefacten zijn veranderd (en door wie?)
   3. Zijn er schemawijzigingen geweest in de relevante gegevensbronnen?
   4. Zijn er ingrijpende wijzigingen geweest in de hoeveelheden data in de relevante databronnen?

Door het bovenstaande proces te automatiseren en met regelmatige tussenpozen te laten draaien, wordt de BI-inhoud die door een team wordt geproduceerd, voortdurend gecontroleerd op nauwkeurigheid, consistentie en prestaties terwijl deze zich nog in de ontwikkelomgeving bevindt. Als het CI-proces een fout detecteert, zal het het BI-team proactief op de hoogte stellen van het probleem en de wijzigingen in het BI-ecosysteem catalogiseren die hebben plaatsgevonden sinds de laatste succesvolle cyclus. Deze methode stelt het BI-team in staat om snel problemen op te merken die zijn ontstaan ​​door recente wijzigingen, corrigerende maatregelen te nemen en de kosten te minimaliseren.

Nettoresultaten van het implementeren van continue integratie voor BI

1. Fouten, inefficiënties en schendingen van normen worden zeer vroeg opgemerkt (meestal binnen enkele minuten of uren na de introductie ervan.
2. Het BI-team wint talloze uren terug die anders besteed zouden worden aan het handmatig testen van alle artefacten om er zeker van te zijn dat er iets niet kapot is gegaan, wat tijd bespaart, maar ook het momentum behoudt (het stelt BI-auteurs in staat zich te concentreren op echte ontwikkelingstaken).
3. Het BI-team krijgt meer inzicht in "wie verandert wat" in hun BI-ecosysteem.
4. De output van het BI-team is van veel hogere kwaliteit.
5. Upstream QA-organisaties kunnen hun energie richten op meer testen op hoog niveau (al het "laaghangende fruit" wordt automatisch uitgefilterd voordat de BI-inhoud werd gepromoveerd tot QA).

Samenvattend, naarmate de BI-industrie volwassen wordt en best practices vaststelt voor de consolidatie, het beheer en de toepassing van business intelligence, moeten opkomende BICC's de lessen die zijn geleerd in flankerende categorieën, met name de software-industrie, onderzoeken en benutten. CI is niet alleen een best practice in de software-industrie, maar evolueert ook naar een standaardprocedure. Naarmate beproefde praktijken zoals CI worden toegepast, zullen BICC's blijven groeien als een kerndiscipline van het bedrijf door niet alleen de doorvoer van een BI-team te verbeteren (van cruciaal belang voor schaalbaarheid), maar ook door de kwaliteit van de output te verhogen. Deze tweeledige impact betekent een sprong in BICC-prestaties en zal binnenkort een steunpilaar zijn voor moderne BI-omgevingen.

1 Een succesvolle cyclus is er een waarin geen enkele test mislukt.
2 Het originele artikel van Martin Fowler waarin continue integratie wordt beschreven, werd in september 2000 gepubliceerd.