Datamodelleren: regels zijn een aanwijzing, niet een gebod

Datamodelleren is abstraheren van de werkelijkheid. Zoals in elk abstractieproces moet je keuzes maken. Ik merk dat mensen soms dogmatisch omgaan met de regels van een datamodelleringsaanpak wanneer ze voor een modelleringskeuze staan.

De bedenker van de aanpak heeft vaak al een antwoord bedacht. Door aanhangers of de bedenker van de methodiek, wordt dit antwoord tot enig mogelijk juiste keuze verheven. Terwijl het niet per definitie het passende antwoord is. De consequentie is dat er moeilijk onderhoudbare of lastig te begrijpen constructies worden gekozen.

In de praktijk modelleer je om problemen op te lossen. Soms ervaar je dat de regels van een datamodelleringsaanpak in het modelleren van een specifieke situatie eerder een probleem veroorzaken dan het op te lossen. Je weet dan dat je een andere keuze moet maken. Daarbij is het natuurlijk verstandig dat je eerst de voor- en nadelen van een techniek goed begrijpt voordat je jezelf vrijheidsgraden gunt.

Keuzes onderbouwen is de uitdaging

Mijn motto is ‘slechte keuzes bestaan niet, wel slecht onderbouwde keuzes’.
De motivering van een keuze is vaak belangrijker dan de keuze zelf. Dit geldt niet alleen voor een logisch of een fysiek datamodel, maar voor alle keuzes die je moet maken over de modellen heen.
Als je begrijpt waarom je voor een oplossing kiest, dan vergroot je de kans dat je de consistentie en het begrip van je datamodel op lange termijn borgt.

Datamodelleren is een lastig vak. Het consequent volgen van regels biedt veel mensen houvast.
Ik zie de regels meer als een soort checklist om na te gaan of je wel consistent blijft in je benadering. Dezelfde soort problemen los je bij voorkeur op met dezelfde soort modelleringspatronen. Niet omdat het beter is, maar omdat het begrijpelijker is. De herkenbaarheid wordt groter bij zowel gebruikers als ontwikkelaars naarmate er meer herhaalde patronen in het model zitten. Daar waar nodig wijk je af en je motiveert en toetst een alternatief patroon op voorhand.

De consequenties van alternatieve patronen beschouwen vanuit verschillende oogpunten is cruciaal voor de levensduur van een oplossing. Elk keer kun je jezelf een aantal vragen stellen, bijvoorbeeld:

  • Begrijpen mijn gebruikers en analisten het model nog?
  • Wat is de consequentie voor de complexiteit bij het transformeren van data naar het model toe?
  • Wat is de consequentie voor de performance bij het bevragen van het model?

Voortschrijdend inzicht is geen noodzakelijk kwaad

Voortschrijdend inzicht is inherent onderdeel van het modelleringsproces. Naarmate je meer te weten komt over de materie en je meer feedback van gebruikers krijgt, wijzigt de interpretatie en daarmee het datamodel.

Daarnaast heb je in de praktijk te maken met de nukken van de gebruikte dataopslagtechnologie en analytische tools. Om deze nukken het hoofd te bieden moet je pragmatische oplossingen bedenken. In de loop van de tijd zie je dat door gebruikservaring en ervaring met technische uitdagingen de patronen verfijnen.

Wijzigingen met terugwerkende kracht zijn gevolg van voortschrijdend inzicht

Gewijzigde modelleringspatronen zijn niet alleen geldig voor toekomstige uitbreidingen van het datamodel, maar ook met terugwerkende kracht. Je borgt de consistentie van je model als je dit consequent doet.

Met terugwerkende kracht aanpassingen in je datamodel doorvoeren kost echter tijd en daarmee geld. Die investering laat zich niet direct vertalen in concreet aanwijsbaar korte-termijn voordeel. Pas op langere termijn leidt het tot een kortere time-to-market van toekomstige informatieproducten en tot lagere totale ontwikkelings- en exploitatiekosten over de levensduur van je analytische oplossingen.

Dat is lastig verkoopbaar onder de druk van deadlines, maar waar enige dogmatische vasthoudendheid wel gewenst is.

De (on)macht van de architect

Inez Bosch heeft op het Landelijk Architectuur Congres voor bedrijfsarchitecten een lezing gegeven over macht, waarvan de weergave op LinkedIn is gepubliceerd. Neem de tijd om het te lezen, het is zeer de moeite waard.

In de serie agile onder architectuur ga ik in op de mentaliteit die je als architect moet hebben in een wendbare omgeving waarin samenwerking steeds belangrijker wordt. Zij gaat een stap verder en haakt in op het karakter van de architect. Dit doet zij door het fenomeen macht als insteek te nemen.

Dit is een enorm gevaarlijk insteek, want macht roept negatieve associaties op. Het interessante van haar verkenning is dat direct duidelijk wordt dat architecten zich verschansen in hun ivoren toren vanuit onmacht. Dat is uiteraard generaliserend, maar het klopt wel.

Andersom geredeneerd, de karaktereigenschappen van de meeste architecten maakt ze geschikt voor een belangrijk deel van hun taak: verder kijken dan je neus lang is en de belangen wegen. De consequentie van die eigenschappen is dat de architect zichzelf vaak buiten het belangenspel plaatst. Ik weet niet of het altijd onmacht is, je zou het ook onwil kunnen noemen.

Ze eindigt haar betoog met een oproep aan architecten om uit hun schulp te kruipen. De wereld verandert en vraagt om een andere bijdrage van bedrijfsarchitecten. Ik heb het de ‘architect-verkenner’ genoemd, de resultaatgerichte architect die actief de ontwikkelingsrichting van een organisatie beïnvloedt.

Ergens wringt het betoog. Zij benadert macht als resultante van menselijke interactie. Mandaat is onbesproken in haar stuk. Zonder mandaat is er geen machtsbasis. Ook de alfa persoon (m/v) in de directie kan zonder een formeel toegedeelde macht, door Bosch beschreven als systeemmacht, niet ongebreideld de gang gaan. Anders wordt het intimidatie en crimineel gedrag.

Haar oplossing is dat de architect niet de tegenstem is, maar tegenmacht organiseert. De architect als hofnar. Dat is onvoldoende naar mijn mening. De macht van de hofnar was gebaseerd op een informeel mandaat. De hofnar werd gedoogd totdat de machtsbalans verschoof en de hofnar geslachtofferd werd.

Wil een architect in het belangenspel eigenaarschap nemen, en voor het resultaat gaan staan, dan zal hij of zij naast inzicht in hoe macht werkt en vaardigheden om hier instrumenteel mee om te gaan, ook als gelijkwaardige speler mandaat toebedeeld moeten krijgen.

ETL generatie is niet het ontwikkeleinde

Steeds vaker zie ik berichten over ETL-generatoren. Vaak beloven deze generatoren een verhoogde productiviteit en is “handmatig” ontwikkelen bijna niet meer nodig. Maar is dit daadwerkelijk zo? Ik ben van mening dat de productiviteitswinst van ETL generatoren vaak rooskleuriger wordt voorgesteld dan die werkelijk is.

De belangrijkste voordelen

Om generatie te starten wordt vaak gekeken naar de voordelen die generatie van ETL biedt. De voordelen die in mijn ogen het meest zwaarwegend zijn bij het generen van ETL zijn de volgende drie:

  • Snelheid van implementatie –  Als de generator reeds aanwezig is, dan is de uitrol naar meerdere objecten vaak een fluitje van een cent. Dit is juist het grote productiviteitspluspunt.
  • Testen is al uitgevoerd –  Aangezien alle te genereren objecten identiek zijn qua logica is een keer testen van de logica voldoende in plaats van elk proces opnieuw te testen.
  • Standaardisatie –  Door het afdwingen en het standaard uitrollen van het patroon krijgen alle objecten die aan dit patroon voldoen dezelfde naamgevingsregels inclusief de standaard implementatie. 

Nadelen van ETL generatie

Naast voordelen die te behalen zijn met ETL generatie zie ik ook een aantal nadelen.  De onderstaande nadelen doen vaak de voordelen weer teniet.

  • Alles proberen te genereren – Aangezien er snelheidswinst te behalen is met generatie zie ik vaak dat er geprobeerd wordt alles te genereren. De vraag of generatie de best passende oplossing is wordt daarbij vaak niet gesteld. Dit met slecht toegepaste generatie als gevolg.
  • Aanpassing van de generatie output – Uitzonderingen zijn meer regel dan uitzondering binnen datawarehouse land. Het is dan van een kleine stap om de uitzondering eerst te genereren en vervolgens handmatig aan te passen. Als er dan een wijziging moet worden uitgevoerd zijn dit ook weer 2 stappen, namelijk genereren en vervolgens weer aanpassing, omdat de generatie de eerste handmatige aanpassing ongedaan heeft gemaakt.

Toch niet het ontwikkeleinde

ETL generatie is dus niet alleen maar halleluja. Om van de echte voordelen van ETL generatie gebruik te maken is een aantal randvoorwaarden noodzakelijk.

  • Identiek patroon van verwerking – Het patroon van de verschillende ETL processen moet wel identiek zijn anders helpt het niet om te standaardiseren; genereren is dan niet de juiste oplossing.
  • Veelvuldige herhaling van dit patroon – Generatie begint pas echt z’n vruchten af te werpen in de vorm van productiviteitswinst als het patroon ook veelvuldig wordt toegepast. Vaak is het 2 keer toepassen sneller dan het maken van een generatie template en deze voor 2 implementaties uit te voeren.
  • Beperkte handmatige interventie – Handmatige input is vaak de oorzaak van fouten. Het is daarom juist van belang dat handmatige input voor het genereren van objecten tot een minimum beperkt is.

In de praktijk zie ik echter zelden voorbeelden waarbij aan alle randvoorwaarden wordt voldaan. Hierdoor is het optimale rendement voor generatie vaak beperkt. Als gevolg van deze uitzonderingen op de randvoorwaarden is handmatig ontwikkelen bijna niet uit te sluiten.  De grootste winst door ETL generatie is daarom te behalen waar het veel herhalend werk beperkt, zoals in het Operationele Gegevenspark (=historielaag van bronnen) van de Free Frogs referentie-architectuur.

In de volgende blog van deze reeks wil ik in gaan op specifieke details voor generatie binnen Informatica Powercenter, met name gericht het Operationele Gegevenspark met in het achterhoofd de geschetste randvoorwaarden.

Kanker opsporen met online zoekgedrag?

Dit weekend staat er een interessant artikel in de wetenschapsbijlage van de Volkskrant over de vergaande mogelijkheden van data-analyse. Door het analyseren van internet zoekgedrag zijn onderzoekers van Microsoft in sommige gevallen in staat om vroegtijdig alvleesklierkanker te signaleren.

Bij mij leidt dit artikel tot twee tegenstrijdige gevoelens: enthousiasme en scepsis.

Enthousiasme over de fantastische dingen we nog mogen verwachten van de analyses die mogelijk zijn door onstuimige groei in de beschikbare data.

Maar tegelijkertijd ook scepsis: weten we wel welke conclusies we kunnen en mogen trekken uit die data? Naar mijn idee zit de achilleshiel van ‘advanced analytics‘ in de interpretatie van de resultaten van statistisch onderzoek. Zien we in de data wel wat we denken te zien? De waarschuwende woorden in het artikel van emeritus hoogleraar Van Houwelingen zijn dan ook zeer terecht.

http://www.volkskrant.nl/wetenschap/google-alert-misschien-heeft-u-wel-kanker~a4348377/

Hoe neem jij beslissingen?

Barry Devlin onderzoekt de aannames die wij, als BI-ers, hebben over hoe beslissingen met data genomen worden. Besluitvorming is niet rationeel is zijn conclusie.

Ik zie in de praktijk dat veel rapporten niet gebruikt worden. We werken met z’n allen lang aan dashboards, hebben disputen over definities van KPI’s en al dat werk blijft ongebruikt.

Na het lezen van zijn serie begrijp je een beetje hoe dat komt.

RFI’s en RFP’s op dieet

Ik heb de afgelopen periode aan enkele RFI’s en RFP’s meegewerkt, zowel aan de vraagkant als aan de aanbiederskant. Deze instrumenten frustreren me. In plaats van de selectie van de best passende oplossing is het een beauty contest: de winnaar is degene met de meeste vinkjes achter zijn naam.

Beide partijen weten dit en de antwoorden worden vaak al niet meer serieus genomen. De oplossing van Alex van den Bergh die ik van harte ondersteun: zet de RFI en de RFP op dieet!.

Als vragende partij merk je dat het lastig is weerstand te bieden aan overvragen: wat kunnen we allemaal verzinnen aan functionaliteit die eventueel ooit gebruikt zou moeten kunnen worden? Het is de sport om zo volledig mogelijk te zijn.

Als aanbieder durf je geen nee te verkopen want dan lig je er bij voorbaat uit. Je gebruikt de RFI om eerst een voet tussen de deur te krijgen en pas als je uitgenodigd word, vertel je het echte verhaal.

De oplossing ligt denk ik aan bij de vraagkant. Doe je huiswerk goed. Wat heb je daadwerkelijk aan functionaliteit nodig? Besteed meer tijd aan een duidelijke vraagformulering en bepaal wat je daadwerkelijk aan functionaliteit nodig hebt.

Architects: “know nothing”

Ron Tolido (chief technology officer van Cap Gemini) in een blogpost van de Open Group. De mooiste quote die het sentiment reflecteert van de serie die ik aan het schrijven ben:

“Tolido says the new landscape will provide a lot of compelling challenges for architects who accept that they know “nothing”, go with the flow and who can adapt to uncertainty.”

Enterprise Architects “Know Nothing”: A Conversation with Ron Tolido

Agile onder architectuur

Agile onder Architectuur

In de serie ‘Agile onder architectuur’ wordt onderzocht hoe je in een organisatie afstemming houdt tussen autonoom werkende teams. Architectuur, als discipline, kan bijdragen aan het behouden van flexibiliteit om te reageren op veranderingen in de context van een organisatie.

Organisatieontwikkeling beschouwen als een evolutionair proces en de benodigde wendbaarheid borgen vraagt wat van de mentaliteit van een architect. Omgaan met verandering, op het niveau waar de verandering impact heeft, moet routine worden. De serie levert de aanknopingspunten om die routine in te bedden, wat resulteert in een wendbare organisatie.

De serie is gepubliceerd op: preachwhatyoupractice.nl/category/agile-onder-architectuur/

Data, puzzels en mysteries

Wat data, puzzels en mysteries betekenen voor de organisatie van analytics.

Donderdagavond was ik bij het Big Data 4.0 event in Amsterdam en luisterde naar een aantal mooie praktijkvoorbeelden van Deloitte. Een van die projecten, dat in de pers veel aandacht heeft gekregen, betrof een analyse naar het aantal banen dat in Nederland verdwijnt als gevolg van de robotisering. Volgens Deloitte zijn dat er miljoenen.

Boeiend verhaal, maar mijn gedachten dwaalden af toen de discussie verschoof naar de vraag welke nieuwe banen door de robotisering juist worden gecreëerd. Is dat dan niet een heel ander type vraagstuk: welke nieuwe banen gaan ontstaan? Nieuw werk, waarvan we nog geen idee hebben. Waarvoor een grenzeloze fantasie nodig is om je het te kunnen voorstellen. Wie kan een analytical model maken als de context en input volslagen onbekend zijn?

Ik herinnerde me een stuk van Gregory Treverton, over het verschil tussen “puzzles and mysteries”. Treverton is chairman van de U.S. National Intelligence Council en legt uit dat in zijn optiek puzzels vraagstukken zijn die, als je maar beschikking hebt tot alle benodigde data, opgelost kunnen worden. Zoals tijdens de koude oorlog de vraag hoeveel raketten de Sovjet Unie bezat. Mysteries daarentegen zijn niet oplosbaar met data. Een mysterie is de vraag welke terroristische aanslagen plaats gaan vinden. Nog meer data helpt in de regel niet om een mysterie op te lossen. Analyse van data is wel een hulpmiddel om de context te begrijpen maar geeft zelf geen antwoord op de vraag.

Mysteries worden getackeld door creatieven en strategen, mensen die niet per sé data literate en data minded zijn. Sterker: die onze liefde voor data zelfs heel saai vinden. Hun werkwijze is volstrekt anders, zij zijn juist enthousiast over methoden als bijvoorbeeld design thinking.

Als dat zo is en als wij met analytics niet alleen puzzels op willen lossen maar ook bij willen dragen aan het onthullen van mysteries, zouden we dan niet uit ons kwantitatieve getto moeten treden? Wordt het geen tijd om ons geloof in “fact-based” decision making te reframen naar “fact supported” decision making? Of, zoals een grote vastgoedbelegger me schetste: vakmanschap (art) met analytics (science) te ondersteunen. En ja: in die volgorde.

Dat lijkt een kleine nuance maar heeft grote gevolgen voor de manier waarop we analytics organiseren. Het betekent dat we analisten niet bij elkaar in een ivoren toren moeten zetten, maar direct naast die vaklui, creatieven en strategen.

Het betekent ook dat wij, data-freaks, ons ten dienste moeten stellen van mensen die niets van cijfers begrijpen. Dat we beter naar hen luisteren en hun manier van denken proberen te snappen. Oef! Hardcore beta’s die zich in het land van de alfa’s begeven.

En Design thinking zou wel eens de brug kunnen slaan tussen deze twee werelden.

 

Free Frogs illustratie Proces KPI's

Sturen op uitkomsten of op oorzaken

KPI’s (kern prestatie-indicatoren) worden veel gebruikt. Helaas wordt er daarbij vaak onvoldoende nagedacht over wat precies de bedoeling is van de KPI, hoe dat het beste meetbaar kan worden gemaakt en wat het effect van het meten is.

Voor een deel komt dat omdat men niet helemaal scherp heeft wat KPI’s nu precies zijn en hoe ze werken. In een presentatie op SlideShare heb ik een aspect van KPI’s uiteengezet, namelijk het onderscheid tussen “leading” en “lagging” KPI’s.