Constructieprincipes voor de informatiekundige (9): Standaardpatronen toepassen zonder afwijkingen
In deze serie van blogs sta ik stil bij de nog steeds geldige informatiekundige constructieprincipes die garant staan voor betere “informatiebouwwerken”. Deze laatste blog in de reeks over informatiekundige principes is eigenlijk ook een brug naar het vervolg van deze reeks met enkele informatica principes (zie voor het onderscheid mijn startblog). Standaardpatronen bestaan namelijk zowel in de informatiekunde als in de informatica.
Het elegante van een standaardpatroon is… dat het een standaard is. Maar in de praktijk blijkt er telkens een reden om een beetje af te wijken. Met als gevolg een gebruiker die de gebruikersinterface niet meer begrijpt of een niet langer interoperabel concept, lagere onderhoudbaarheid van een systeem en tijdverlies.
Waarom standaardpatronen?
De theorie en de praktijk laten zien dat het voordelen heeft als je dingen op dezelfde manier in richt. Het verbetert bijvoorbeeld de bestuurbaarheid in een organisatie als je de organisatiedelen gelijkvormig houdt. Mensen zijn gemakkelijker uitwisselbaar door kortere inleertijd. Om te kunnen besturen moet een model beschikbaar zijn van het bestuurde systeem en dit is sneller te ontwikkelen als daarin standaard patronen worden toegepast die herkenbaar zijn.
In de informatiekunde helpen standaard patronen in het eenduidig documenteren van informatie en herkennen van informatie (mede door een afgesproken syntax). Daarmee wordt bijvoorbeeld het lezen van de gebruiksaanwijzing en ook het bedienen van apparaten vanzelf logisch, denk maar aan kleurgebruik en positie van bepaalde bedieningselementen. Als de stopknop opeens groen is en de startknop rood dan krijgen we ongelukken!
Standaardpatronen groeien vaak uit tot officieel erkende standaard. Afwijken is niet toegestaan en als er iets wijzigt geldt dat voor alle toepassingen.
Standaardpatronen zijn typisch een “design” aspect.
Voorbeelden van goede en slechte standaardpatronen
Sommige slechte standaardpatronen hebben te maken met ergonomie-ontwerp. Lees de column van Jasper van Kuijk in de Volkskrant er maar op na (denkfouten in hedendaags ontwerp).
Een bekend goed samenwerkingspatroon is het afsprakenpatroon in DEMO van Dietz dat voorziet in het gestructureerd afhandelen van dienstafnemer en dienstleverancier transacties[1].
Een ander goed voorbeeld is het patroon van “publish-subscribe” tegenover “request-response”, zowel op niveau van de informatiedeling als op technisch niveau.
Voor alle patronen geldt dat ze geschikt zijn voor specifieke vereisten. Zoals ontkoppelen van actoren of componenten, afhankelijkheden beperken, eisen aan schaalbaarheid, onafhankelijk van een gekozen taal of protocol en asynchroon of synchroon. Als het gekozen patroon (hoe goed ook) niet past bij de beoogde toepassing ontstaan vaak afwijkingen en workarounds waardoor de voordelen van het patroon verdwijnen en het opeens een slecht patroon wordt in die context.
Bekende infrastructuur patronen zijn client-server, client-broker-server, master-slave of gelaagde architectuur en deze hebben hun waarde bewezen. En bij integratiepatronen herkend iedereen het succes van de application-programming-interface als standaard.
Het is wel van belang om te onderkennen dat het logische patroon pas een standaard is tussen systemen als ook een technische standaard is afgesproken! De ene API is de andere niet!
[1] Bron Wikipedia
Toepassing van standaardpatronen bij de constructie
Jaap van Rees[2] noemt hier twee doelgroepen:
- Eindgebruikers
- Ontwerpers van systemen
Voor eindgebruikers is het toepassen van standaard patronen evident een voordeel. Een eindgebruiker leert standaard patronen herkennen voor de bediening. Denk maar aan de eenduidige user interface voor smartphones of je internetbrowser. Hier is een marktstandaard van Google komen bovendrijven als winnaar. Afwijken wordt afgestraft door gebruikers die afhaken. Zonder te weten hoe de achterliggende techniek werkt kan via de standaard user interface het systeem voldoen aan de verwachting van de gebruiker omdat het gedrag voldoet aan het model van het standaard patroon; het gemeenschappelijk interpretatieschema. Alles wat hier van afwijkt zorgt voor inleertijd, tijdverlies of fouten en in het ergste geval frustratie of ongelukken. Denk maar aan de keer dat je van een MS Windows computer ging overstappen naar een Apple!
Voor ontwerpers helpen standaard patronen (of structuren) tijd te besparen want je hoeft het ontwerp niet meer zelf te verzinnen. Het verhoogt ook de overdraagbaarheid van een ontwerp aan ontwerpers die de standaard ook kennen en voorkomt kinderziekten/fouten. Testen kost dus minder tijd en inpassen van standaard modules wordt eenvoudiger. Al met al is de grootste winst betere onderhoudbaarheid omdat er een standaard model van het informatiesysteem beschikbaar is en je het systeem dus veel sneller kunt doorgronden.
Maar als de voordelen zo evident zijn waarom wordt er dan toch steeds afgeweken van de standaard?
[2] De informatiearchitect, van Rees en Wisse, Kluwer, 1995.
Standaard patronen en creatieve vrijheid
Standaards zijn strijdig met het creatieve ontwerpproces. Standaardpatronen moeten omgezet worden in standaard denkwijzen en dat kost tijd. Ontwerpbeslissingen worden ingekaderd door voorgeschreven standaardpatronen. In een norm, een architectuur of de eisen van de eindgebruiker.
Het invoeren en handhaven van standaards is dus een cultuurverandering, die roept weerstand op. Elke ontwerper of eindgebruiker zal proberen aan te tonen dat zijn probleem niet in de standaard past. En dan is de verleiding groot om af te wijken. Maar standaards verliezen hun waarde als duidelijk wordt dat er van afgeweken mag worden! Bij Comply or explain als bekend adagium in deze gevallen mag niet lichtvaardig worden omgegaan met de explain. Toestemming om af te wijken moet voorbehouden blijven aan de hoogste instantie.
Dat betekent niet dat een standardpatroon niet kan wijzigen. Maar een wijziging moet dan wel overal worden doorgevoerd of het moet leiden tot een nieuwe versie van de standaard waarvoor ook echt voldoende voedingsbodem is (veel vergelijkbare problemen).
De voortdurende strijd tussen creatieve vrijheid en standaard patronen vraagt om een standvastige informatie-architect die steeds kan aangeven waarom een patroon is toegepast en welke voordelen teniet worden gedaan bij afwijkingen.
Lees hier de andere informatiekundige principes:
- Betekenisloze identiteitsaanduiding, lees hier.
- Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen, lees hier.
- Consistentie van taal, lees hier.
- Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie, lees hier.
- Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen, lees hier.
- Autorisatie loskoppelen van identificatie/authenticatie, lees hier.
- Enkelvoudige vastlegging van stamdata, lees hier.
- Data en metadata scheiden in opslag en verwerking, lees hier.
- Standaardpatronen toepassen zonder afwijkingen, lees hier.
- Applicatiefunctie en dataopslag scheiden, lees hier.
- Apparaat onafhankelijk ontwikkelen, lees hier.