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.