De (on)macht van de architect

/in , /door

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

/in , /door

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?

/in , /door

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?

/in , /door

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

/in , /door

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”

/in , /door

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 , /door

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

/in , /door

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

/in , /door

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.

KPI VW motoren

Sturen op de zuinigheids-KPI

/in , /door

Vandaag kwam er weer een goed voorbeeld van perverse effecten van KPI’s (key performance indicator) in het nieuws. Volkswagen heeft in Amerika de verkoop van alle modellen met een viercilinder 2.0 TDI-motor stilgelegd nadat uitkwam dat ze jarenlang hebben gesjoemeld met de tests die meten hoe zuinig een motor is. Auto’s die als heel zuinig uit de test kwamen blijken nu in de praktijk helemaal niet zo zuinig.

Belangrijkste kenmerk van een perverse prikkel is dat je de KPI kunt halen (en de beloning kunt opstrijken), zonder de doelstelling te bereiken.

Als de beloning maar hoog genoeg is en als er voldoende licht zit tussen de KPI (hier de test om het brandstofverbruik op een standaardwijze te meten) en de doelstelling (auto’s die in de dagelijkse praktijk zuinig zijn), ontstaat er een sterke prikkel om – hoe zeg ik dit netjes – de creativiteit de vrije loop te laten. Oftewel – om het maar minder diplomatiek te formuleren – te frauderen.

In het geval van Volkswagen is de prikkel immens: de verkoop van vele, vele auto’s die voldoen aan de zuinigheidsnorm. En de score op die zuinigheids-KPI blijkt nu te beïnvloeden, namelijk met software die herkent of er een test werd afgenomen. Zo kreeg Volkswagen het voor elkaar om de KPI te halen zonder de doelstelling te bereiken.

Pervers.