Avantajele integrării continue pentru Business Intelligence

Modul în care industria de business intelligence poate beneficia de integrarea continuă

În termeni de industrie, Business Intelligent (BI) este încă un domeniu relativ nou. La fel ca multe industrii bazate pe tehnologie, BI a progresat prin etapele sale timpurii, cu implementări supuse unor procese ad hoc și cu succes variabil. În trecut, a fost obișnuit ca mai multe proiecte de BI implementate de aceeași organizație să adopte abordări extrem de diferite pe drumul către obiective foarte similare. Cu toate acestea, în ultimii ani, organizațiile de perspectivă și-au sporit capacitățile de BI prin centralizarea cunoștințelor și expertizei BI. Cu modele precum „BI Competency Center” (BICC) și „BI Center of Excellence” devenind din ce în ce mai răspândite, aceste organizații definesc acum stive de tehnologie BI, seturi de instrumente, procese și tehnici pentru întreaga organizație pentru a asigura succesul și a maximiza rentabilitatea investiției pe noi inițiative BI. Aceștia iau, de asemenea, indicii din cele mai bune practici din categoriile însoțitoare, în acest caz, industria software-ului.

O bună practică care nu a fost încă recunoscută de comunitatea BI este cea a Integrării continue (CI). În domeniul dezvoltării de software, CI este procesul prin care o bază de cod software este construită automat și testată la fum la intervale frecvente - în mediul de dezvoltare. Pe un proiect software tipic activat CI, un „server de construire” monitorizează depozitul de cod sursă al proiectului și, atunci când sunt detectate modificări, extrage o copie curată a sursei, face o reconstrucție completă, rulează toate testele de regresie și notifică proactiv dezvoltarea echipa oricăror eșecuri. Fiecare ciclu de succes complet1 produce un set instalabil de binare pentru produsul software.

Această integrare frecventă și automată surprinde rapid orice erori introduse în sistem (adesea în câteva minute de la introducerea lor) și face mult mai ușor să vedeți cine a introdus eroarea și când. Defectele și incompatibilitățile sunt invariabil mai ieftine de corectat atunci când sunt surprinse în câteva minute de la introducerea lor (mai ales dacă nu scapă niciodată din mediul de dezvoltare).

Principiile principale ale integrării continue (CI)

• Procese de construire și testare repetabile, automatizate.
• Aceste procese automate de construire și testare sunt executate frecvent, astfel încât problemele de integrare să fie detectate devreme.
• Ciclurile frecvente și automate oferă avertismente timpurii pentru artefacte rupte / incompatibile.
• Aproape validarea imediată și testarea tuturor modificărilor sistemului.

Există puține dispute că practica CI a devenit un instrument de neprețuit în arsenalul organizației moderne de dezvoltare software. CI îmbunătățește atât calitatea, cât și impulsul echipelor de dezvoltare software. Echipele de dezvoltare cu experiență care au îmbrățișat conceptul CI nu își pot imagina să întreprindă niciun proiect software considerabil fără el.

Ar putea industria BI să beneficieze și de practica integrării continue?

Absolut. În anii următori, practica CI va fi recunoscută pentru potențialul său imens atunci când va fi aplicată mediilor moderne de dezvoltare BI. Ecosistemele BI sunt inerent complexe (a se vedea figura 1). Sunt adesea alcătuite din multe părți în mișcare, cu multe interdependențe. De exemplu, un ecosistem tipic de BI poate conține:

• Mai multe surse de date în amonte.
• Procesele ETL extrag periodic, curăță și încarcă date din fiecare dintre aceste surse din amonte în martie de date sau depozite de date.
• Multe produse BI adaugă un strat „model” deasupra acestor marturi sau depozite.
• Autorii profesioniști ai BI construiesc conținut BI în raport cu acest strat de model (de exemplu, rapoarte).

Așa cum pot atesta practicienii BI experimentați - modificările minore în oricare dintre aceste straturi pot crește în întregul sistem - creând erori sau ineficiențe în rezultatele BI rezultate. În funcție de locul în care echipa BI se află într-un ciclu de lansare, aceste erori sau ineficiențe pot trece neobservate zile, săptămâni sau chiar luni.

Iată câteva exemple din lumea reală:

• O modificare aparent inofensivă la nivelul modelului determină modificări neașteptate ale numerelor pentru un raport care nu a fost editat de câteva luni. Aceste modificări degradează, de asemenea, performanța aceluiași raport (o condiție care este chiar mai greu de cuantificat și detectat manual).
• O schimbare a vizualizării într-un DB determină o creștere dramatică a timpilor de rulare a raportului.
• Un modelator redenumește sau șterge o coloană de care depinde un raport.
• Un autor de raport încearcă să optimizeze un raport, dar noul raport nu produce rezultate corecte atunci când sunt setați parametrii opționali.

În majoritatea mediilor de dezvoltare BI, testarea conținutului BI în curs de dezvoltare se face adesea într-un mod foarte manual (de ex. „Rulați un raport, verificați numerele, verificați dacă sunt corecte”). Echipele BI tind să concentreze aceste teste manuale asupra artefactelor3 pe care le schimbă activ, mai degrabă decât pe cele care nu au fost modificate recent. Această tendință se pretează la probleme nedetectate atunci când modificările la un nivel inferior al sistemului încep să se repete în sus și afectează multe artefacte BI.

Majoritatea organizațiilor vor livra periodic linii de bază ale conținutului BI dintr-un mediu de dezvoltare într-un mediu de testare sau asigurare a calității (QA), unde vor fi supuse testării mai formale de către profesioniștii QA. În funcție de minuțiozitatea echipei QA, defectele sau degradările de performanță pot fi surprinse aici, dar în acest moment, costul corectării acestor probleme a crescut considerabil. Odată ce un defect a ieșit din mediul de dezvoltare (de exemplu, într-un mediu QA), devine mult mai scump de corectat. Fluxul de lucru tipic pentru corectare include crearea unui ticket ticket care descrie modul de reproducere a defectului (de către echipa QA), triajul echipei BI a tuturor ticketelor problemelor în așteptare (pentru a decide care dintre acestea primesc prioritate), reproducerea problemei în curs de dezvoltare, implementarea unui remediați și apoi redistribuiți o altă linie de bază în QA. La fel, defectele descoperite în mediile de producție sunt chiar mai scumpe de remediat decât cele descoperite în QA.

Folosind principiile CI, o echipă de dezvoltare BI poate detecta proactiv probleme precum acestea (adesea în câteva minute de la modificarea care le-a cauzat) și poate lua măsuri corective în timp ce conținutul BI este încă în mediul de dezvoltare. Aceasta înseamnă că costul general al corecției este mult mai puțin costisitor.

Deci, cum pot fi aplicate principiile CI unui proiect tipic de Business Intelligence? Pentru câteva exemple concrete, vom lua în considerare MotioCI™, un instrument comercial care permite integrarea continuă pentru mediile de dezvoltare Business Intelligence. MotioCI oferă echipelor BI următoarele caracteristici:

Integrare continuă pentru Business Intelligence

1. Validarea automată a tuturor artefactelor BI în raport cu modelul lor corespunzător. Acest lucru asigură faptul că orice modificare a modelului sau a bazei de date nu „rupe” artefactele BI existente.
2. Executarea automată a cazurilor de testare pentru fiecare artefact. Aceste cazuri de testare pot fi utilizate pentru a asigura lucruri precum:
   1. Executarea artefactului a produs date exacte
   2. Executarea artefactului a produs cantitatea preconizată de date
   3. Performanța artefactului este acceptabilă (execuția se finalizează în perioada de timp așteptată)
3. Verificarea automată a coerenței. Pentru fiecare artefact:
   1. Verificați dacă respectă proiectul stabilit sau standardele corporative pentru lucruri precum culori, fonturi, stiluri, imagini încorporate etc.
   2. Verificați dacă numele parametrilor sunt coerente între artefacte
   3. Verificați dacă relațiile de foraj între artefacte sunt încă valabile
4. Urmărirea modificărilor ecosistemului BI, astfel încât atunci când un test începe să eșueze, părțile interesate din proiect au o viziune clară despre „cine a schimbat ce” de la ultimul ciclu. De exemplu:
   1. Ce modele au fost schimbate (și de cine?)
   2. Ce artefacte au fost schimbate (și de cine?)
   3. Au existat modificări ale schemei surselor de date relevante?
   4. Au existat modificări drastice ale cantității de date din sursele de date relevante?

Prin automatizarea procesului de mai sus și executarea acestuia la intervale frecvente, conținutul BI produs de o echipă va fi verificat continuu pentru acuratețe, consistență și performanță, încă în mediul de dezvoltare. Dacă procesul CI detectează un eșec, acesta va notifica proactiv echipa BI despre problemă, precum și va cataloga modificările aduse ecosistemului BI care au avut loc de la ultimul ciclu de succes. Această metodă permite echipei BI să observe rapid problemele create de modificările recente, să ia măsuri corective și să minimizeze costurile.

Rezultate nete ale implementării integrării continue pentru BI

1. Erorile, ineficiențele și încălcările standardelor sunt surprinse foarte devreme (de obicei în câteva minute sau ore de la introducerea lor.
2. Echipa BI câștigă înapoi nenumărate ore petrecute altfel testând manual toate artefactele pentru a se asigura că ceva nu s-a stricat, economisind timp, dar și menținând impulsul (permite autorilor BI să se concentreze asupra sarcinilor reale de dezvoltare).
3. Echipa BI câștigă o vizibilitate sporită în „cine schimbă ce” în ecosistemul BI.
4. Rezultatele produse de echipa BI sunt de o calitate mult mai mare.
5. Organizațiile QA din amonte își pot concentra energiile pe mai multe teste la nivel înalt (toate „fructele cu agățare redusă” sunt filtrate automat înainte ca conținutul BI să fie promovat în QA).

Pe scurt, pe măsură ce industria BI se maturizează și stabilește cele mai bune practici în consolidarea, gestionarea și aplicarea informațiilor de business, BICC-urile emergente ar trebui să examineze și să profite de lecțiile învățate în categoriile alăturate, în special industria software. CI nu este doar o bună practică din industria software, dar evoluează și într-o procedură de operare standard. Pe măsură ce se adoptă practici dovedite, cum ar fi CI, BICC-urile vor continua să se maturizeze ca disciplină de bază a afacerii, nu numai prin îmbunătățirea randamentului unei echipe de BI (esențială pentru scalabilitate), ci și prin creșterea calității rezultatelor sale. Acest impact dublu reprezintă un salt în performanța BICC și va fi în curând un pilon pentru mediile moderne de BI.

1 Un ciclu de succes este cel în care niciun test nu eșuează.
2 Lucrarea originală a lui Martin Fowler care descrie Integrarea continuă a fost publicată în septembrie 2000.