”Vem som helst kan skapa en oreda, men för att VERKLIGEN ställa till det krävs ett rejält ETL-verktyg”.

Ett modernt ETL-verktyg är väldigt duktigt på att skyffla data mellan olika databaser. I verktygens kraftfullhet ligger också deras inneboende svaghet. Dataskyfflande ersätter ibland en god arkitektur. Kortsiktigt gör detta inte så mycket, det finns få systemsamband och antalet gränssnitt är lätta att underhålla. Så småningom kommer dock problemen att hopa sig, när ingen längre vet vilken information som skapas, lagras eller används var. Systemen vävs samman i en ogenomtränglig struktur som blir omöjlig att hantera eller byta ut likt en gordisk knut.

Ett vanligt ”ETL-relaterat” problem är att man missuppfattar begreppet ”god arkitektur” med begreppet ”överföringsmetod”. Dvs olika system görs beroende av varandra men så länge detta sker genom offline-metoder såsom textfilsöverföring och ftp-siter så gör det inget. I stället för att använda effektiva anslutningsmetoder inom en god arkitektur så används dåliga anslutningsmetoder inom en dålig arkitektur. Detta kanske låter som källarföretagsproblem, men man blir förvånad ibland över att möta den typen av åsikter inom de mest ”professionella” organisationer.

Är detta då ETL-verktygens fel? Svaret är nej på den frågan. Ett modernt ETL-verktyg kan göra otroligt mycket nytta i rätt händer, men jag tror det är med ETL-verktyg som när jag själv försöker använda en driver på golfbanan. Drivern är väldigt bra på att slå iväg bollen långt. Tyvärr i mitt fall så blir riktningen allt som oftast fel vilket resulterar i att bollen går långt, men åt fel håll. En bättre strategi är att använda järn-5 som visserligen inte ger lika längd men däremot ger färre slag till hålet i och med att jag kommer dit jag vill att bollen skall landa.

En god arkitektur enligt mitt sätt att se på det är en arkitektur som bygger på begreppet ”less is more”. Om man ser översiktsbilder som verkar fått röda hund för alla databaspluppar, etl-pluppar och andra pluppar så kan man vara ganska säker att det går att förbättra med mycket enkla medel.  Inom data warehouse och business intelligence är det extra lätt att det blir soppigt eftersom många olika leverantörer gör lite olika saker och det finns få leverantörer av en helhet. Det ställer extra höga krav på arkitektursidan att ha god förståelse för problemställningar och möjligheter samt försöka förenkla i alla lägen. Är det till exempel ett nytt system som krävs eller är det en utbildningsinsats som krävs?

Skall man våga sig på några generella råd så bör man fundera på om man skall ha ett centralt datalager som alla intressenter ansluter till eller om man skall ha en distribuerad arkitektur där data marts skapas. Stora fördelen med centralisering ligger i kontroll och att man bara behöver utveckla på ett ställe. Fördelen med distribuerat synsätt ligger i att prestandafrågor kan lösas lokalt. I ett lokalt data mart kan också data strukturer anpassas i större utstärckning än vid centraliserade lösningar som måste generaliseras att passa många.  

Man bör också fundera på hur mycket av ”spindelstruktur” man skall ha jämfört med ”spindelvävsstruktur”. Dvs skall alla dataflöden gå genom ett centralt datalager eller kan delsystem ansluta direkt med varandra. Fördelen med att alltid gå via det centrala systemet är att informationen kommer att vara tillgänglig för alla, nackdelen är att det blir ett extra utvecklingssteg. Det går i och för sig att till stor del minimera detta problem genom att omgivande system själva laddar in data i det centrala systemet – on demand så att säga.

Ett gott råd är också att vara noga med att ”metadataprinciper” gäller för alla system, dvs att inte delsystem själva hittar på namn eller affärsregler för centrala begrepp. Om till exempel ”personnummer” kallas orgnr, pnr, personnummer, organisationsnr, organisationsnummer,persnr eller någon annan variant i respektive delsystem så ökar svårighetsgraden att hålla ihop arkitekturen. Ett annat vanligt fenomen är att data skall ”ändras lite” för att passa ”bättre”. Dvs i gränssnittet mellan system så duger inte färdiga strukturer från levererande system utan datat måste varje gång aggregeras, surrogatnycklas eller segmenteras på något sätt. På så sätt ökar utvecklingskostnaden mellan system och det blir ännu svårare att ändra något i förlängningen för datat ”måste” fixas till i varje nytt steg. Lite som ”viskleken” man lekte på dagis, tillslut vet ingen vad datat står för längre. Dessa fenomen är egentligen bara ett resutat av en slapp IT-governance både från CIO-håll men också enskilda utvecklare får ta ansvar, som ofta tycker det är bekvämare att hitta på eget än att följa en standard.