Chef Kok versus Enterprise Architect

Een jaar of wat geleden was er een TV-programma “Master Chef”. Een soort Idols voor kooktalenten. In dit programma moesten kandidaten (amateurkoks eigenlijk) meedraaien in een keuken van een echte master chef. In zo’n keuken gaat het er dynamisch aan toe.

Ik ben zelf overigens bepaald geen kooktalent en heb op dat gebied ook geen ambities. Eten bereiden kan ik wel, want dat zie ik als een belangrijke basisvaardigheid voor de ondersteuning van mijn gezin. Eten bereiden is een kwestie van het volgen van een in zekere mate vast proces met vaste ingrediënten. Daar komt weinig creativiteit bij kijken en het vereist nauwelijks improvisatievermogen. Maar koken kan ik dus nadrukkelijk niet. Koken is een creatief proces waarbij de kwaliteit van het resultaat in grote mate af hangt van de kennis, improvisatievermogen, finesse en oog voor detail van de kok. Een kok past wel bepaalde vaste bereidingspatronen toe, maar doet dit zoals een muzikant dit doet met akkoorden en ritmische basispatronen. Koken is een kunstvorm en een ambacht tegelijk.

Een chef kok is de baas in de keuken van een restaurant in de zin dat hij bepaalt welke gerechten zijn keuken op welke wijze voort brengt, en in de zin dat hij toeziet op de kwaliteit. Van de keuken van een restaurant wordt een vaste en voorspelbare kwaliteit verwacht. De gerechten die de keuken voort brengt moeten passen bij het (gewenste) imago en kernwaarden van het restaurant, en de beleving van de doelgroep van het restaurant (klanten).

Een master chef is een erkende meester in zijn vak en heeft een bepalende en richtinggevende functie. Je zou de master chef ook kunnen beschouwen als een Food Architect. Hij is in belangrijke mate verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe gerechten. Nieuwe gerechten of verbeteringen van gerechten of de bereidingswijze daarvan worden door de master chef ontworpen op basis van food trends, ontwikkelingen in kooktechniek, seizoenspatronen, et cetera.

Naast het creëren van een nieuw gerecht (vernieuwing) moet een master chef in staat zijn dit gerecht reproduceerbaar te maken voor de keuken van zijn restaurant, met behoud van de verwachte kwaliteit (beheersing). De onvoorspelbare dynamiek rond de  beschikbaarheid en kwaliteit van benodigde ingrediënten, maar ook de trends en ontwikkelingen op het gebied van voedsel en bereidingstechnieken en de verwachtingen van klanten vereist het vermogen om te kunnen anticiperen op veranderingen (toekomstvastheid).

Je ziet het, ik bezie dit allemaal door de bril van een Enterprise Architect. In de ICT wordt de keuken-analogie dikwijls toegepast. Van een ICT-afdeling wordt verwacht dat zij in staat is om binnen voorspelbare tijd, binnen voorspelbare kosten en met voorspelbare kwaliteit informatievoorzieningen voort te brengen. De ingrediënten bestaan uit basisvoorzieningen zoals portal, data warehouse en IAM, maar ook uit nieuw ingekochte technologieën. Van de gemiddelde ICT-afdeling wordt eigenlijk geen kookkunst verwacht maar vooral de bereiding volgens bewezen recepten.

Nu wil ik trouwens niet zo ver gaan dat een Enterprise Architect de baas is van de keuken en altijd een erkende meester is in zijn vakgebied, hoewel dat laatste op zich niet slecht zou zijn. Wel zie ik interessante parallellen tussen een Master Chef en een Enterprise Architect:

Master Chef	Enterprise Architect
verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe gerechten	verantwoordelijk voor het ontwerpen van de samenstelling en wijze van voortbrenging van nieuwe systemen
Nieuwe gerechten of verbeteringen van gerechten of de bereidingswijze daarvan worden door de master chef ontworpen op basis van food trends, ontwikkelingen in kooktechniek, seizoenspatronen, et cetera.	Nieuwe of verbeteringen/uitbreidingen aan informatievoorzieningen of de voortbrengingswijze daarvan worden door de informatie architect ontworpen op basis van technology trends, ontwikkelingen in methodieken en architecture patterns, et cetera.
De onvoorspelbare dynamiek rond de  beschikbaarheid en kwaliteit van benodigde ingrediënten, maar ook de trends en ontwikkelingen op het gebied van bereidingstechnieken en de verwachtingen van klanten vereist het vermogen om te kunnen anticiperen op veranderingen	De onvoorspelbare dynamiek rond de  beschikbaarheid van gebruikte technologie en de kennis daarvan, maar ook de trends en ontwikkelingen in de markt op het gebied van technologie  en ontwikkelmethoden en de verwachtingen die de klant ten aanzien daarvan heeft, vereist het vermogen om te kunnen anticiperen op veranderingen.

Koe melkt Boer en Applicatie gebruikt Bedrijfsproces. Wat klopt hier niet?

Informatiearchitecten zijn soms net monniken. Zelf voel ik me in ieder geval regelmatig monnik, ook al zit ik niet in het klooster, draag ik geen pij, en doe ik niet aan zelfkastijding. Dat ik me soms net een monnik voel komt vooral omdat ik regelmatig monnikenwerk aan het doen ben. In figuurlijke zin, maar desalniettemin monnikenwerk.

Wat ik dan doe is het op nauwgezette wijze vastleggen van de enterprise-architectuur binnen het procesdomein dat mij is toevertrouwd. Een secuur geduldwerkje. Mijn broeders in de organisatie doen dat voor de andere domeinen zodat er een compleet beeld van de organisatie wordt vastgelegd. Iemand moet het toch doen? Bovendien vormt architectuurvastlegging een belangrijk deel van het takenpakket van de informatiearchitect. Gelukkig vind ik het leuk werk, anders zou ik toch van kastijding kunnen spreken.

Dat vastleggen van architectuur doe ik in een architectuurtaal genaamd “Archimate“. Dit is een formele symbolentaal waarmee je op gestandaardiseerde manier de enterprise-architectuur van een organisatie kunt optekenen en vastleggen. Je kunt er imposante platen mee tekenen, waarop symbolen staan die met elkaar zijn verbonden door middel van lijntjes en pijlen. Hoe vollediger en gedetailleerder de vastlegging deste nauwkeurig zijn de analyses die ermee kunnen worden gedaan.

Archimate is een taal zoals Nederlands een taal is, maar dan veel strikter. In het Nederlands mag je bijvoorbeeld schrijven: “De boer wordt gemolken door de koe”. Daar klopt niets van maar grammaticaal gezien mag het. In het Nederlands is het om het even welk zelfstandignaamwoord wat ook maar doet met andere zelfstandige naamwoorden. Je kunt twee znw’s met elkaar in relatie brengen door middel van een werkwoord. Daar ben je heel vrij in. Er zijn alleen regels voor de manier waarop je het werkwoord dat de activiteit uitdrukt, vervoegd dient te worden. Nederlands is eigenlijk heel betekenisblind.

In Archimate gaat het juist om betekenis, maar wel eentje die zich beperkt tot enterprise-architectuur. Er kunnen alleen bepaalde zelfstandige naamwoorden worden gebruikt. Bijvoorbeeld: Bedrijfsproces en Applicatiecomponent. In archimate worden dit “componenten” genoemd. Ook kun je maar een beperkte set werkwoorden gebruiken. “Melken” zit er niet bij.

Werkwoorden leggen ook in Archimate de relaties. Er is precies bepaald welke relaties je mag gebruiken tussen welke componenten. Zo mag een Bedrijfsinformatieobject gerealiseerd worden door en Dataobject, mag een Rol een Business Service gebruiken en mag een Bedrijfsproces – in mooi Nederlands – getriggerd worden door een Business Event. Een Bedrijfsproces dat een Actor gebruikt is niet logisch, dus dat wordt ook niet door Archimate toegestaan. Door deze precieze regels worden de modellen die je in Archimate op stelt logisch en consistent. Hieronder een voorbeeldje.

Dus wie verbaasde mijn schets, eh…maar dan andersom…, toen ik ontdekte dat een Applicatiecomponent een Bedrijfsproces mag gebruiken? Dat slaat als een tang op een varken. Dat is zo onlogisch als een boer die door een koe wordt gemolken. Archimate 1.0 staat dit echter toe en zo ook het op Archimate gestoelde architectengereedschap Bizzdesign ™ Architect (tenminste, in de versie die ik gebruik). Begrijp ik het niet, of ben ik zowaar op een bug in de Archimate specificatie gestuit? Of is die bug op mij gestuit?