Met een pattern wordt het bijna onmogelijke mogelijk
Hoe doet ze dat?
Het was begin januari. Samen met mijn vriendin verbleef ik in een prachtig kasteeltje ergens in Vlaanderen. De decembermaand was de natste ooit gemeten en januari dacht 'dat kan ik beter’; er was voor de hele dag regen voorspeld. We besloten voorlopig in het kasteeltje te blijven. De tijd zouden we doden met onder andere spelletjes. In de voorkamer stond een mooie biljarttafel. Met een vader als kroegbaas, heb ik dit vroeger veel gespeeld. Mijn vriendin koos voor een ander tijdverdrijf. In de spelletjeskast hadden we de dag er voor een mooi exemplaar van het spel solitaire zien liggen. Met dit spel is het de bedoeling om vanuit een startpositie de knikkers van het bord te verwijderen tot er nog één knikker over is. Helemaal knap is het wanneer deze laatste knikker zich dan in het midden van het bord bevindt. Ook dit spelletje heb ik vroeger vaak gespeeld. Ik kan me niet herinneren dat ik het ooit heb uitgespeeld. Ik wenste haar veel succes, en ging aan de slag met de keu en biljartballen.Twintig minuten later kwam ik kijken hoe mijn vriendin waarschijnlijk gefrustreerd gebogen boven een plankje met 33 knikkers aan het proberen was deze puzzel op te lossen. Tot mijn verbazing gaf ze aan dat het haar was gelukt. Om het te bewijzen plaatste ze de knikkers op het bord, en vervolgens zag ik hoe ze drie keer het bord een kwartslag draaide en in een rap tempo de knikkers verwijderde tot er één knikker in het midden overbleef. 'Hoe doe je dat?!', was mijn vraag. Haar antwoord was eenvoudig, ‘Op you-tube vond ik een filmpje. Op elk kwart voer je dezelfde handelingen uit, tot de knikkers de letter T vormen. Vanaf dan is het eenvoudig'.
Elk IT-probleem is uniek
Patterns zijn onderdeel van ons dagelijks leven. We maken gebruik van patterns terwijl we het niet altijd door hebben. Een pattern heeft de volgende kenmerken, een beschrijving van een probleem en een beschrijving van wat te doen om het probleem op te lossen^.
In de afgelopen decennia zijn veel patterns die betrekking hebben op IT-problemen vastgelegd. Is het dan zo makkelijk, IT-architectuur? Ik zorg dat ik toegang heb tot de patterns, bestudeer ze en pas de oplossing toe. Bij een spelletje Solitaire is het probleem altijd hetzelfde. Voor een IT-probleem geldt dat elk probleem uniek is. We kunnen er niet van uit gaan dat de schrijver van het pattern jouw unieke probleem voor ogen had. Het hoofddoel van een pattern is dat het de architect helpt besluiten te nemen die het specifieke probleem oplossen. Voegen we een correlation id toe aan mijn berichten of maak ik gebruik van een routing slip? Of kiezen moeten we voor beiden? Archiveren we alle berichten in een message store of archiveren we alleen de metadata van de berichten? Definiëren we een canonical data model voor de definitie van de contracten van de services of definiëren we alleen de sleutelwaarden canonical?
Een pattern over patterns
Wellicht bestaat voor de IT-architect zoiets als een meta-pattern.
Probleem
Het ontwerpen van een IT-landschap is complex. Foute besluiten kunnen leiden tot grote kosten voor de organisatie of het niet benutten van kansen die de markt biedt (marktpartij) of ontevreden burgers (uitvoeringsinstantie).
Oplossing
De IT-architect baseert zijn besluiten op patterns. Hij beoordeelt of de patterns goed worden toegepast in zijn organisatie en of deze het gewenste effect hebben.
Toepassing
De IT-architect zorgt dat hij toegang heeft tot uitwerkingen van patterns. De IT-architect bladert regelmatig door de patterns heen en bestudeert de patterns die van toepassing zijn bij het nemen van een besluit.
De IT-architect heeft regelmatig contact met ontwerpers en ontwikkelaars om te leren van de toepassing van de patterns.
Impact
De IT-architect moet tijd reserveren voor het bestuderen van patterns. Boeken vol met patterns zijn niet altijd de leukste boeken. Het is af en toe doorbijten voor de IT-architect.De IT-architect is aanwezig bij dagstarts en luistert. Hij is aanwezig bij sessies waarin de teams het gerealiseerde demo-en.
Bronnen: ^ Enterprise Integration Patterns, 2005, Gregor Hohpe, Bobby Woolf.
Meer informatie:
Messaging Patterns Overview - Enterprise Integration Patterns
SOA Design Patterns, 2008, Thomas Erl.
