Igår så meddelades det att tidningen News of the world läggs ner som en direkt följd av att tidningens journalister under många år på ett systematiskt sätt avlyssnat diverse kändisar. Det är lite symtomatiskt att Aftonbladet några dagar innan braskar på med stora rubriker där tidningens journalister lyckats få tag på information om hur en fd politiker agerar på internet. Man måste fundera på vad skillnaden är mellan de två tidningarna? I båda fallen handlar det ju om att tillskansa sig personlig information som samlas upp genom loggar och annat som egentligen borde tillhöra den privata sfären. En liknande händelse för några år sedan på samma ämne var avslöjandet att flera ministrar i den nytillträdda alliansregeringen inte betalt TV-licens. Hur har tidningarna fått tag i sådana uppgifter? Det enda möjliga sättet är att någon på Radiotjänst samkört personuppgifter från tidningarna med sitt eget register. Tydligen håller Radiotjänst dessutom ganska mycket historik för det var under en lång period som det konstaterades att de utpekade ej betalat för sig.

Det känns som att i och med att information lagras i större utsträckning, och görs tillgängliga via kraftfulla verktyg desto mer suddas de moraliska gränserna kring vad som är integritet och inte ut. För ungefär 40 år sedan så kom den så kallade IB-affären ut i ljuset, där staten anklagades för att registrera känslig information. Jag kan i mitt stilla sinne tycka att IB-affären var rätt naiv i jämförelse med det avancerade underrättelsearbete som vanliga journalister på vanliga svenska tidningar ägnar sig åt idag.

Jag vet inte hur många gånger under årens lopp som jag stött på problem med att få ut data från operativa system. Ett operativt system, tex företagets ekonomisystem eller ordersystem eller vad annat system det än är har ofta, inte alltid, men ofta problem med att få ut data till företagets data warehouse.  Om det dessutom är ett gammalt system som levt länge så är det med mycket stor sannolikhet bäddat för problem.

Orsaken till problemen är många  – slarv med uppgraderingar,  för snävt dimensionerad hårdvara, en djungel av skript som ingen vågar göra något med för ”då kan allt rasa”. När data skall extraheras till ett data warehouse så kommer alla sådana problem upp till ytan som riskerar att skapa en konflikt mellan systemförvaltning av erp och systemförvaltning av data warehouse.

Vad kan man göra för att komma runt problemen? Min erfarenhet är att E i ETL är lösningen på många problem. Grundregeln är att belasta ERP-sidan så lite som möjligt, detta sker enklast genom att läsa ut fysiska tabeller direkt som de går och står från källan. Undvik för allt i världen att joina tabeller för att skapa ett mer färdigt resultat i källsystemet. Det är en säker väg att få prestandaproblem. Skall endast vissa kolumner ut så kan man avgränsa och även om man bara vill ha en delmängd. Avväg filtreringar mot tid det tar att spola ut hela tabeller. Om det tar längre tid att få ut tabellen vid filtrering än att plocka hela så plocka hela.

Denna tumregel gäller givetvis inte om ett mer avancerat middlware används, tex Tibco. I det fallet så sker ju uttaget på ett mer kostnadseffektivt sätt från början. Men det är inte alla som har råd att investera tid och kraft i middleware. Då kommer oftast gamla hederliga avgänsade textfiler i bruk.

Hur hanterar man affärslogik då? Det vanligaste argumentet för att låta levererande system göra mycket ”T” som i transform är att endast i källan finns affärslogik på ett vettigt sätt. Detta är ett synsätt jag inte håller med om. Oftast går det att med lämpliga avstämningar simulera affärslogik i en stageingarea. Användarna av data warehouse ser dessutom till att rättningar genomförs löpande så problemet är inte stort.

Att göra analyser är ofta en ganska tidsödande process. Något som ofta skapar en hel del frustration hos de som önskar få analyser av olika slag. En käck managementkonsult sa en gång att för att få igång jobbet med att analysera kundbasen krävdes att vi frontloadade resultaten. Dvs så fort som möjligt få ut tabeller med resultat som de sedan kunde jobba med. Problemet med detta sätt att jobba är att för att göra en vettig analys måste man vara noggrann med sitt grundarbete. Det finns ganska få genvägar till bra underlag för analysen. Därför så blir det i praktiken oftast att man bakloadar resultaten istället. Som en ketchup-flaska, först kommer inget, sen kommer inget och sen kommer allt!

Ända sedan millennieskiftet har leverantörer av BI-programvara basunerat ut att de äntligen skapat en mobil plattform. Mig veterligen med noll, ingen som helst framgång. Orsaken är, tror jag, att man blir rätt yr av att försöka kolla siffror i en liten mobilskärm. Det har varit lättare att skicka ett flash-sms istället som kommunicerar nått enstaka nyckeltal till säljchefer tex. Alla övriga kategorier av användare är mer betjänta av att använda sin PC för att konsumera siffror.

Men med tablet-PC kopplat till högprestanda-nät bör utvecklingen kunna ta fart. Även gränssnittet skapar intressanta möjligheter för olika visualiseringstekniker. Dra, zooma och editera med fingertopparna kan revolutionera inte bara själva analysen utan också hur vi i framtiden presenterar siffror och data. Det kanske blir lite som Hans Rosling on speed. Om det nu ens är möjligt att föreställa sig något mer speedat än honom.

Smolken i glädjebägaren torde vara företagets säkerhetsfolk. Kommer den nya tekniken att vara tillräckligt skyddad från obehörigt användande? Troligen kommer det att ta ett tag innan tekniken och förtroendet för de nya plattformarna är på plats. Men med tanke på hur snabbt företagsledningarna tar till sig det nya så skall inte det vara något oöverstigligt hinder. Det man verkligen skulle vilja se är en programvara som med sömlös mashup-teknik kan blanda traditionell powerpoint, filmer, ljud med adhoc-analys á la spotfire eller qlikview.

Var på en spännande kurs idag. Eller rättare sagt, jag tyckte det i alla fall. Stephen Brobst gick igenom allt man behöver veta för att bygga ett massivt högprestanda data warehouse. På åtta effektiva timmar gick han igenom joinar, index, parallellism, kolumndatabaser, OLAP-tekniker och mycket mycket mer. Jag kan garantera att man vet aldrig så mycket om data warehouse som man vet efter en dag med Stephen. Rekommenderas!

”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.

Tänkte tipsa om den TDWI-utbildning som Affecto anordnar mellan 30 november och 3 december 2010. Det är ett unikt tillfälle då TDWI sällan håller kurser i Europa och än mindre i Sverige. Ni får träffa de främsta inom BI/DW-branschen i två spännande utbildningsspår.

I ett nötskal är innehållet i kurserna följande:
- Advanced Data Modeling, Analysis and Design
- High Performance, Real Time Data Warehousing and Data Integration Techniques.

Det finns en Early-bird-rabatt samt grupprabatt om man bokar fler än tre deltagare.

Läs mer på: http://www.affecto.se/tdwi

Läs mer om TDWI på http://www.tdwi.org

Har hört att IBM hade en slogan förr i tiden (kanske fortfarande?), ”you won’t get fired for buying ibm”. Ibland får man känslan att ”BI-branschen” för tillfället använder samma talessätt. Ofta möts man med förvånade blickar när man i en beställarroll inte tycker att en leverantör eller konsults idéer är bra. Då ifrågasätts om man förstått sakens natur eller om det är något annat grundläggande fel på en. ”Business intelligence MÅSTE ju alla ha!!! Förstår ni inte det???”

På ett sätt är det bra att branschen har självförtroende, men ibland slår det över i högmod tycker jag. Det hade varit betydligt mer uppfriskande om man i dialogen ställt sig frågan:  Har ”Business intelligence” ett egenvärde i sig eller handlar det i grund och botten om att man vill skapa mer ”intelligent business”. Dvs kan en organisation bli mer effektiv genom tillämpning av olika metoder och tekniker?

Ett exempel: Om ett företag köper en superavancerad business intelligence-applikation (en så kallad SABIA) så kan man säga att man har ”Business intelligence”. CIO kan checka av den punkten på sin agenda. Men om företaget inte använder sin SABIA i verksamheten, dvs den tillför inget värde, kan man då säga att man har ”intelligent business”? Svaret är nej på den frågan.

Det är bättre att man pratar om hur man skall kunna införa mer ”intelligent business” snarare än hur man skall kunna införa mer ”business intelligence”. Begreppen är i sig radikalt annorlunda, i det ena fallet handlar det om att skruva in en burk, i det andra fallet handlar det om att förändra en organisations arbetssätt.

I slutändan faller ansvaret på att införa mer ”intelligent business” på beställarsidan, och då krävs det kompetens. På vilket sätt kan vi tillämpa alla nya tekniker som ”business intelligence” möjliggör i vår organisation så att vi får mer ”intelligent business”? Hur skall vi förändra vårt arbetssätt för att dra nytta av en ny metod? Vilka värden tillför detta till våra kunder som de är beredda att betala mer för? Eller kan vi göra samma sak vi gör idag men billigare?

Läser ett inlägg om att 7 av 10 IT-projekt helt eller delvis havererar.( http://definitionofdone.blogspot.com/2010/01/it-ar-varldens-mest-misslyckade-bransch.html ) Man funderar i sitt stilla sinne hur det hade fungerat om byggbranschen med samma effektivitet. Hade folk accepterat att bo i halvfärdiga hus där värmen inte fungerar eller där det inte går att reglera värmen i duschen på grund av att utvecklaren inte lyckats konstruera en fungerande kran?

Inom BI och data warehouseing är detta problem ännu större tror jag lite ovetenskapligt. Oräkneliga timmar med utveckling förbrukas till att skapa databaser, rapporter och analytiska applikationer som sedan aldrig används eller som är direkt felaktiga. Problemet är att vi i denna del av IT-branschen ofta rör oss på obruten mark, där det inte är helt självklart vilken väg som är den rätta. Det i sig ställer höga krav på att de som anlitar och de som anlitas för uppdrag av denna sort kan sina saker väl. Frågan är väl om så alltid är fallet.

I början av september hade SAS stor analyskonferens i Köpenhamn. Tonvikten låg på avancerad analys. Presentationer kan man finna här: http://www.sas.com/events/aconf/pres/