“Wantrouw standaarden”

7 december 2011

Het eerste project waar ik zo’n les bij leerde is alweer jaren geleden. Ik was gevraagd om mee te helpen bij het destilleren van een standaard. Een J2EE-architectuurstandaard om precies te zijn. J2EE was toen net aan het opkomen en de organisatie waar ik voor werkte had net met veel moeite hun eerste succesvolle J2EE-systeem opgeleverd. Nu was het de bedoeling om al die opgedane J2EE-kennis om te zetten in een echte architectuurstandaard, een beschrijving van hoe J2EE projecten voortaan binnen die organisatie uitgevoerd zouden moeten worden. We waren er best tevreden mee - het resultaat was redelijk compact, toepasbaar en praktisch. Een prima architectuurdocument.

Toen vroeg iemand wat de houdbaarheidsdatum van het document was. Daar hadden we nog niet over nagedacht. Wat is de halfwaardetijd van een architectuur?

Onze opdrachtgever vond die houdbaarheidsdatum niet belangrijk. “Voor altijd”, daar ging hij voor. Ik dacht daar anders over. J2EE was toen net twee jaar beschikbaar en in die twee jaar was het al twee keer over de kop gegaan. Het nieuwste type javabean was nog niet bedacht of het was alweer achterhaald verklaard. “Zouden we dit project een jaar geleden ook zo hebben kunnen doen?”, was de vraag waar ik mee zat. Zo nee, is deze architectuur over één of twee jaar dan nog wel zinvol? Daar kwam nog eens bij dat de meeste projecten van deze organisatie al gauw een jaar in beslag namen. Tegen de tijd dat een project afgerond werd zou de dan beschikbare technologie heel anders zijn dan bij de start van datzelfde project. Mensen houden veel langer vast aan architecturen en andere standaarden dan goed voor ze is. De les die ik bij dat project leerde noemde ik “wantrouw standaarden”. Ik gebruik hem nog dagelijks.

Het is misschien een beetje raar voor een architect om standaarden te wantrouwen. Dat is als een boer die geen koeien vertrouwt of een kok die bang is voor messen. Er zijn mensen die beweren dat architecten niets anders doen dan standaarden bedenken en afdwingen. Ik zie dat dus anders. Architectuur gaat over het nemen van belangrijke, vaak pijnlijke beslissingen. Bij die beslissingen kunnen standaarden van pas komen - maar dat hoeft niet altijd. In de eerste paar jaar na “wantrouw standaarden” was de houdbaarheid van standaarden de belangrijkste reden voor dat wantrouwen. Nu zie ik dat breder. Er zijn veel meer redenen om standaarden te wantrouwen. Standaarden blokkeren per definitie opportunistische oplossingen. Soms is dat wat je wilt bereiken (productielijnen, koekjesfabriek?), meestal is het dat niet (maatwerk software, integratie, ...). Standaarden hebben een waarde - onderhoudbaarheid, overdraagbaarheid, ... - maar ze hebben ook kosten. Die kosten willen we nog wel eens vergeten.

Wanneer een collega uitroept dat “het toch niet zo kan zijn dat elk team dit op een andere manier oplost!”, dan denk ik “waarom eigenlijk niet?”. We hebben het werk verdeeld over teams en die teams krijgen de verantwoordelijkheid om hun klus zo goed mogelijk te doen. Telkens wanneer je een standaard (een standaardproces, een technische standaard, een documentstandaard, ...) afdwingt, dan verliest dat team een beetje verantwoordelijkheid en vrijheid. Met de verantwoordelijkheid en vrijheid verdwijnt ook een beetje motivatie en innovatiekracht. Is die standaard dat waard? Als die teams goede oplossingen bedenken, dan heb ik graag dat ze die delen en zo nieuwe standaarden laten ontstaan. Dat zijn de standaarden die ik eerder vertrouw.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!