Tilbage

7 faldgruber i Data Warehouse del 3

Opfyld forventningerne. Dette er den tredje af i alt 7 artikler om de 7 faldgruber, som BI Architect Brian Bønk Rueløkke gennem tiden er stødt på i sit arbejde med Data Warehouse.

Overhold leverancerne

Så er det tid til at kode.

Men hvem skal bygge og kode?

Projektet har brug for ressourcer til et helt udviklingsteam, en DBA'er, en ETL specialist og en arkitekt, men budgettet har kun plads til ca halvdelen.

Via en dialog med HR skal der skrives jobbeskrivelser og stillingsopslag for de kompetencer der er behov for. Man kunne hyre eksterne konsulenter, men organisationens erfaring siger at det er bedst at have kompetencerne selv.

I mellemtiden skal der kigges på faktisk at begynde at kode og oprettelse af storage og computerkraft. Som nævnt i tidligere indlæg, kan man vælge forskellige faktureringsmuligheder - forskellige for storage og regnekraft eller samme beregning.

Anyway - første spadestik bliver taget til at opbygge en fysisk datamodel som skal afhjælpe et specifikt problem. Det går hurtigt op for en at, det på inden måde er så let som først antaget. Hvordan forudsiger man f.eks. design parametre og omkostninger uden at kende de forespørgsler der slutteligt vil blive foretaget mod løsningen?

Forskelle på kundskaber

En uges tid eller to efter, vender HR tilbage med mulige kandidater som måske kan passe på de givne profiler. Efter interviews er gennemført med de første kandidater, går det op for en hvor stort et arbejde det er at lede et teknisk team. Noget mere end først antaget.

Profilerne og kandidaterne som er kvalificerede koster langt mere end budgettet kan holde, og de kandidater der kan betales har ikke nok erfaring med denne type projekter. Efter en del ofringer og kompromiser sættes holdes endeligt og første skud på en infrastruktur-løsning kan begynde.

Det at lede et teknisk udviklingsteam er meget mere komplekst end først antaget. De siger mærkelige ord som "agil udvikling" og SCRUM. Hov, hvem har styr på SCRUM-masteren? Hvem er det?

Styring af kildekode bliver hurtigt et problem for teamet, de mangler en kommunikationsplatform og fælles fodslag for udvikling. Det lykkes dog at få fat i noget kildedata fra forretningens systemer og disse loades til databasen.

Det tager for lang tid

Den før omtalte fleksible arkitektur skal nu vise sit værd. Men det viser sig at slutbrugerenes forespørgsler ikke kører optimalt. Det går op for en at, det at bygge automatiske og real-time dataintegrationer er meget mere svært end først antaget. Og orkestreringen af integrationen er nu en flaskehals for at bringe data hurtigt nok frem til slutbrugerne.

Efter al data er samlet ind, begynder ETL processerne at tage alle ressourcer fra både teamet og den tekniske infrastruktur. Det går også op for en at data ikke er så pænt som først antaget. Der er NULL-værdier, manglende data, forkert data og alle mulige typer af problemfyldt data. Denne datavask tager alene 3 måneder at få på plads.

For ikke at tale om alle de events der kommer fra web og mobil. De udviklingsværktøjer der følger med de forskellige platforme, er på ingen måde lette at trække data ud fra. Det hele tager al for lang tid.

Ingen vej tilbage

Nu hvor teamet er på plads, ressourcerne er indkøbt og data er begyndt at flyve rundt mellem databaserne, er der ingen vej tilbage. Cloud omkostningerne begynder at stige ift. budgettet og forespørgslerne bliver langsommere og langsommere efterhånden som brugerne tilgår den nye platform. Teamet er 3 måneder bagud ift. planen for implementeringen og der er stadig mile langt til mål.

Men håbet er lysegrønt.

Beslutsomhed er hvad der for en til at køre videre med projektet, på trods af de bump og afgrunde der skal forceres. Andre steder i organisationen begynder de at undre sig over hvorfor de aftalte deadlines ikke overholdes.

Det begynder at stramme til.

Næste gang vil jeg skrive om "det store Data Warehouse problem" og brandslukning.