Prednosti kontinuirane integracije za poslovnu inteligenciju

Kako industrija poslovne inteligencije može imati koristi od kontinuirane integracije

U industrijskom smislu, Business Intelligent (BI) je još uvijek relativno novo područje. Poput mnogih industrija temeljenih na tehnologiji, BI je napredovao u svojim ranim fazama s implementacijama podložnim ad hoc procesima i vrlo različitim uspjesima. U prošlosti je bilo uobičajeno da se više BI projekata koje provodi ista organizacija zauzimaju izrazito različiti pristupi na putu do vrlo sličnih ciljeva. Posljednjih godina, međutim, napredne organizacije povećale su svoje mogućnosti BI -a centralizacijom znanja i stručnosti u području BI -a. Budući da modeli poput „Centra za kompetencije BI -a“ (BICC) i „BI centra izvrsnosti“ postaju sve prisutniji, ove organizacije sada definiraju hrpu BI tehnologija, skupove alata, procese i tehnike za cijelu organizaciju kako bi osigurali uspjeh i povećali ROI na nove inicijative za BI. Oni također uzimaju znakove iz najboljih praksi u pratećim kategorijama, u ovom slučaju, industriji softvera.

Jedna od najboljih praksi koju zajednica BI još nije prepoznala je ona kontinuirane integracije (CI). Na području razvoja softvera, CI je proces kojim se programska koda automatski gradi i testira na dim u čestim intervalima-u razvojnom okruženju. Na tipičnom softverskom projektu s omogućenim CI-jem, "poslužitelj za izgradnju" prati spremište izvornog koda projekta i, kada se otkriju promjene, povuče čistu kopiju izvora, izvrši potpunu obnovu, pokrene sve regresijske testove i proaktivno obavijesti razvoj tim svih propusta. Svaki potpuno uspješan ciklus1 proizvodi instalacijski skup binarnih datoteka za softverski proizvod.

Ova česta, automatizirana integracija brzo hvata sve pogreške koje se unesu u sustav (često u roku od nekoliko minuta od njihovog uvođenja), te znatno olakšava uvid u to tko je i kada uveo pogrešku. Nedostaci i nekompatibilnosti uvijek su jeftiniji za ispravljanje kada se uhvate u roku od nekoliko minuta od njihovog uvođenja (posebno ako nikada ne izađu iz razvojnog okruženja).

Glavni principi kontinuirane integracije (CI)

• Ponovljivi, automatizirani procesi izgradnje i ispitivanja.
• Ti se automatizirani procesi izgradnje i testiranja često izvode tako da se problemi s integracijom rano otkriju.
• Česti, automatizirani ciklusi pružaju rana upozorenja za slomljene / nekompatibilne artefakte.
• Gotovo trenutna validacija i testiranje svih promjena u sustavu.

Nema sumnje da je praksa CI -a postala neprocjenjiv alat u arsenalu moderne organizacije za razvoj softvera. CI poboljšava i kvalitetu i zamah timova za razvoj softvera. Iskusni razvojni timovi koji su prihvatili koncept CI ne mogu zamisliti poduzimanje bilo kojeg značajnog softverskog projekta bez njega.

Bi li industrija BI -a također mogla imati koristi od prakse kontinuirane integracije?

Apsolutno. U sljedećim godinama praksa CI -a bit će prepoznata po svom ogromnom potencijalu kada se primijeni na moderna razvojna okruženja BI. BI ekosustavi inherentno su složeni (vidi sliku 1). Često se sastoje od mnogih pokretnih dijelova, s mnogo međuovisnosti. Na primjer, tipični BI ekosustav može sadržavati:

• Više uzvodnih izvora podataka.
• ETL procesi povremeno izvlače, čiste i učitavaju podatke iz svakog od ovih uzvodnih izvora u podatkovne baze ili skladišta podataka.
• Mnogi BI proizvodi dodaju sloj "modela" na vrhu ovih ograda ili skladišta.
• Profesionalni autori BI -a grade BI sadržaj na ovom sloju modela (npr. Izvješća).

Kao što iskusni praktičari BI -a mogu potvrditi - male promjene u bilo kojem od ovih slojeva mogu se valoviti u cijelom sustavu - stvarajući pogreške ili neučinkovitosti u rezultatima BI -a. Ovisno o tome gdje se BI tim nalazi u ciklusu izdanja, ove pogreške ili neučinkovitosti mogu ostati neprimijećene danima, tjednima ili čak mjesecima.

Evo nekoliko primjera iz stvarnog svijeta:

• Naizgled bezazlena izmjena na sloju modela uzrokuje neočekivane promjene u brojkama za izvješće koje nije uređivano mjesecima. Ove promjene također umanjuju izvedbu istog izvješća (stanje koje je još teže ručno kvantificirati i otkriti).
• Promjena pogleda u DB -u uzrokuje dramatično povećanje vremena izvođenja izvješća.
• Modelar preimenuje ili briše stupac o kojem izvješće ovisi.
• Autor izvješća pokušava optimizirati izvješće, ali novo izvješće ne daje ispravne rezultate kada su postavljeni izborni parametri.

U većini BI razvojnih okruženja testiranje BI sadržaja u razvoju često se vrši na vrlo ručan način (npr. „Pokreni izvješće, provjeri brojeve, provjeri jesu li točni“). BI timovi imaju tendenciju usmjeriti ovo ručno testiranje na artefakte3 koje aktivno mijenjaju, a ne na one koji nisu nedavno mijenjani. Ova tendencija podliježe neotkrivenim problemima kada se promjene na nižoj razini sustava počnu nabirati prema gore i utječu na mnoge BI artefakte.

Većina organizacija povremeno će isporučivati ​​osnove BI sadržaja iz razvojnog okruženja u okruženje za testiranje ili osiguranje kvalitete (QA), gdje će prolaziti formalnija testiranja od strane stručnjaka za osiguranje kvalitete. Ovisno o temeljitosti QA tima, ovdje se mogu uočiti nedostaci ili degradacije performansi, ali u ovom trenutku troškovi ispravljanja ovih problema znatno su porasli. Nakon što je kvar izašao iz razvojnog okruženja (npr. U QA okruženje), njegovo ispravljanje postaje mnogo skuplje. Tipičan tijek rada za ispravljanje uključuje izradu problemske karte koja opisuje kako reproducirati nedostatak (od strane QA tima), BI tim trijažu svih neriješenih problemskih listića (kako bi se odlučilo koje imaju prioritet), reprodukciju problema u razvoju, implementaciju popraviti, a zatim ponovno rasporediti drugu osnovnu liniju u QA. Slično, nedostatke otkrivene u proizvodnim okruženjima još je skuplje popraviti od onih otkrivenih u QA -u.

Koristeći načela CI -ja, razvojni tim BI -a može proaktivno otkriti probleme poput ovih (često unutar nekoliko minuta od promjene koja ih je uzrokovala) i poduzeti korektivne mjere dok je sadržaj BI -a još uvijek u razvojnom okruženju. To znači da su ukupni troškovi korekcije mnogo jeftiniji.

Dakle, kako se načela CI mogu primijeniti na tipičan projekt poslovne inteligencije? Razmotrit ćemo neke konkretne primjere MotioCI™, komercijalni alat koji omogućuje kontinuiranu integraciju za razvojna okruženja poslovne inteligencije. MotioCI pruža BI timovima sljedeće značajke:

Kontinuirana integracija za poslovnu inteligenciju

1. Automatska provjera valjanosti svih BI artefakata u odnosu na njihov odgovarajući model. Time se osigurava da promjene modela ili baze podataka neće "slomiti" postojeće BI artefakte.
2. Automatsko izvršavanje testnih slučajeva za svaki artefakt. Ovi se testni slučajevi mogu koristiti za osiguravanje sljedećih stvari:
   1. Izvođenje artefakta dalo je točne podatke
   2. Izvođenje artefakta proizvelo je očekivanu količinu podataka
   3. Izvedba artefakta je prihvatljiva (izvođenje se završava u očekivanom vremenu)
3. Automatska provjera dosljednosti. Za svaki artefakt:
   1. Provjerite pridržava li se utvrđenog projekta ili korporativnih standarda za stvari poput boja, fontova, stilova, ugrađenih slika itd.
   2. Provjerite jesu li nazivi parametara dosljedni u artefaktima
   3. Provjerite jesu li odnosi bušenja između artefakata još uvijek valjani
4. Praćenje BI ekosustava mijenja se tako da kada test počne padati, dionici projekta imaju jasan uvid u to „tko je što promijenio“ od zadnjeg ciklusa. Na primjer:
   1. Koji su modeli promijenjeni (i tko?)
   2. Koji su artefakti promijenjeni (i tko?)
   3. Je li došlo do promjena sheme u relevantnim izvorima podataka?
   4. Jesu li se drastično promijenile količine podataka u relevantnim izvorima podataka?

Automatiziranjem gore navedenog procesa i njegovim učestalim izvođenjem, timski će se sadržaj kontinuirano provjeravati točnost, dosljednost i performanse BI sadržaja u razvojnom okruženju. Ako CI proces otkrije kvar, proaktivno će obavijestiti BI tim o problemu, kao i katalogizirati promjene u ekosustavu BI koje su se dogodile od zadnjeg uspješnog ciklusa. Ova metoda omogućuje BI timu da brzo uoči probleme nastale posljednjim promjenama, poduzme korektivne mjere i smanji troškove.

Neto rezultati provedbe kontinuirane integracije za BI

1. Pogreške, neučinkovitosti i kršenja standarda uočavaju se vrlo rano (obično unutar nekoliko minuta ili sati od njihovog uvođenja).
2. BI tim dobiva nebrojene sate koji su inače potrošeni na ručno testiranje svih artefakata kako bi bili sigurni da se nešto nije pokvarilo, čime se štedi vrijeme, ali i održava zamah (omogućuje autorima BI -a da se usredotoče na stvarne razvojne zadatke).
3. BI tim dobiva povećanu vidljivost u tome „tko što mijenja“ u svom BI ekosustavu.
4. Rezultati koje je proizveo BI tim mnogo su kvalitetniji.
5. Uzvodne organizacije za osiguranje kvalitete mogu usmjeriti svoju energiju na više testiranja na visokoj razini (sve "nisko viseće voće" automatski se filtrira prije nego što je sadržaj BI-a promoviran u osiguranje kvalitete).

Ukratko, kako BI industrija sazrijeva i uspostavlja najbolje prakse u konsolidaciji, upravljanju i primjeni poslovne inteligencije, novi BICC -i trebali bi ispitati i iskoristiti lekcije naučene u pratećim kategorijama, posebno softverskoj industriji. CI nije samo najbolja praksa softverske industrije, već se i razvija u standardni operativni postupak. Kako se prihvaćaju provjerene prakse poput CI -a, BICC -ovi će nastaviti sazrijevati kao temeljna poslovna disciplina ne samo poboljšanjem propusnosti BI tima (ključno za skalabilnost), već i povećanjem kvalitete njegovih rezultata. Ovaj dvostruki utjecaj predstavlja skok u BICC performansama i uskoro će biti oslonac za moderna BI okruženja.

1 Uspješan ciklus je onaj u kojem nijedan test ne uspije.
2 Originalni rad Martina Fowlera koji opisuje kontinuiranu integraciju objavljen je u rujnu 2000. godine.