Ontvlechting en sanering

Ontvlechting en sanering, twee ICT-vaktermen. Het zijn eigenlijk “gewone” Nederlandse woorden die door de ICT-wereld zijn geadopteerd. Blijkbaar was dat nodig. Neem bijvoorbeeld “ontvlechting”. Ontvlechten is alleen nodig als er sprake is van onwenselijke vervlechting. In de ICT raken zaken inderdaad nogal eens teveel met elkaar vervlochten doordat die zaken over de tijd, te haastig en op diverse manieren aan elkaar werden geknoopt. En dat gebeurt dan ook vaak herhaaldelijk en jaren achtereen, zodat de ongezonde situatie ontstaat waarin van delen van het geheel niemand helemaal begrijpt waarom het werkt zoals het werkt.

Het werkwoord “saneren” heeft louter betekenissen die nuttig zijn voor de ICT, zoals: opruimen, weer gezond maken, zuiveren en verbeteren. Maar we denken meestal aan deze betekenis: afbreken en vervangen. Natuurlijk zou je liever willen voorkomen dan saneren, maar dat is moeilijk. De druk vanuit de business is vaak te hoog waardoor toch concessies worden gedaan aan kwaliteit en zonder architectuur wordt gewerkt. En zonder overkoepelend toezicht op en zonder overkoepelende besturing van – ofwel, zonder architectuur governance van – ICT-ontwikkelingen komen de haastig neergezette oplossingen meestal niet weer onder architectuur.

Dus als een ICT-landschap over de jaren door vele uitbouwprojecten is verworden tot een complex, instabiel, onvoorspelbaar, moeilijk beheerbaar en lastig uitbreidbaar geheel, waarvan niemand meer helemaal overziet en begrijpt hoe het werkt en waarom, dan wordt het tijd voor ontvlechting en sanering. Dit zijn doorgaans grote uitdagingen.

Ontvlechten is het proces van het in kaart brengen van de complexiteit en het weer terugwinnen van het overzicht en het inzicht. Door ontvlechting komen we weer “in control” van het beheer en de ontwikkeling, zodat met vertrouwen kan worden besloten tot het opruimen van overtollige constructies en het weer beter maken van ongezonde constructies: ofwel sanering .

En als ontvlechting echt een heilloze zaak is, dan rest eigenlijk nog maar één ding: volledige sanering. Dat houdt dus in dat je een compleet ICT-landschap vervangt. Wanneer is ontvlechting heilloos? Dat is niet eenvoudig te beantwoorden, maar levensvatbaarheid en toekomstvastheid zijn belangrijke factoren.

Uiteindelijk hoop je met ontvlechting en sanering te bereiken dat we weer “in control” geraken over het betroffen ICT-landschap, en dat we deze weer voldoende gevitaliseerd hebben zodat het weer een tijd mee kan. Ook doet uw organisatie er verstandig aan haar ICT-processen te ontvlechten en saneren en te zorgen dat aan- en verbouw in het ICT-landschap voortaan onder architectuur gebeurt.

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?