Dat aanwezigheid van patronen samenhangt met complexiteit zie je ook in de definitie van Kolmogorov complexiteit: “the complexity of a string is the length of the string's shortest description in some fixed description language” (zie Kolmogorov Complexiteit ). Als er een patroon in de string zit, dan kun je die gebruiken om de string te beschrijven. Hoe minder patronen, hoe complexer de string.

Een manier om complexiteit te verminderen is dus door meer van hetzelfde te gebruiken. Of - zoals ik dat ook wel noem - het verminderen dan wel het voorkómen van non-functionele variëteit. Non-functionele variëteit treedt op als er verschillende oplossingen voor hetzelfde probleem zijn waarbij de variaties in de oplossing geen toegevoegde waarde hebben. In dit soort situaties kun je de complexiteit dus verminderen door één oplossing tot standaard te verheffen en de andere te saneren. Afgezien van de sociale weerstand die dit levert – iedereen is voor een standaard als het maar de zijne is – moet je soms ook kiezen tussen gelijkwaardige oplossingen. Vergelijk dit met een wegenstelsel waar je moet gaan kiezen of je links of rechts wilt gaan rijden. Het maakt helemaal niets uit welke keuze je maakt, maar als je eenmaal gekozen hebt, kun je het bijna niet meer veranderen. ICT-systemen zitten echter vol met dit soort arbitraire impliciete keuzes die lokaal gemaakt zijn. "Hoe lang maken we het telefoonnummer?" "Hoeveel posities moeten we reserveren voor de naam van een persoon? 10, 20, 200?" "Een indicatie, gebruiken we daar Ja/Nee voor, 1/0 of J/N? " “In welke volgorde komen de velden voor?” “Welke XML-tag gebruiken we voor “ingangsdatum van het contract?” Wanneer is iemand een klant? “ “Wat verstaan we onder het adres van een persoon? ” Tja, waar moet je dan beginnen met saneren?

Het "patterns" verhaal in systeemontwikkeling en in Architectuur (waar het oorspronkelijk vandaan kwam) is een manier om herhalende patronen te benoemen waardoor de communicatie effectiever wordt. Het zorgt er voor dat de "goede patronen" gebruikt kunnen worden in de taal en zich daardoor als vanzelf vermenigvuldigen. Een vorm van "genetisch programmeren" dus. Het levert daarmee niet alleen betere systemen op basis van bewezen oplossingen. Het is ook een manier om de complexiteit te verminderen omdat het aantal variaties vermindert doordat ontwerpers de bestaande patronen kennen en (onbewust) gebruiken. Patterns zijn echter nog niet echt "orthogonaal" Het Model-View-Control-pattern en het publish-and-subscribe bevatten impliciet enkele gelijke onderdelen, zonder dat je die nu precies aan kunt wijzen. Je zou kunnen zeggen dat de we basispatronen nog net niet te pakken hebben. Hieronder beschrijf ik een andere zienswijze en aanvliegroute. Mogelijk levert die nieuwe inzichten op.

Als je naar de informatie- en communicatietechnologie kijkt dan heeft men daar hoge verwachtingen van. Maar wat kan ICT nu in beginsel echt? Eigenlijk toch maar een paar dingen. Digitale systemen kunnen we opgebouwd zien uit een aantal (digitale) actoren (digitoren). Een digitor kan één of meer van de volgende zeven dingen en dat in allerlei samenstellingen. Bovendien doet een digitor alleen maar iets (zo'n combinatie) – eventueel continu - als daar expliciet opdracht voor is gegeven.

1. een analoog signaal (geluid, licht, beweging, temperatuur) digitaal maken
2. een digitaal signaal analoog maken (als boven)
3. digitale data bewaren (kort in memory of lang op schijf o.i.d.)
4. bewaarde digitale data uitleveren aan een andere digitor
5. digitale data transporteren van locatie A naar B (door één digitor)
6. digitale data volgens een van te voren gedefinieerde (digitale) instructie omzetten naar andere digitale data
7. een andere digitor van een voor gedefinieerd type creëren in een bepaald communicatienetwerk (de omgeving van die nieuwe digitor).

Elke digitor communiceert met zijn (digitale) omgeving. De communicatie met de analoge omgeving is gevangen in de eerste twee functies van de digitor. Behalve de atomaire digitoren onderscheiden we ook nog samengestelde digitoren, eentje die bestaat uit een eindige verzameling communicerende digitoren.

Als dit de basis is van ICT-systemen, hoe complex kun je het dan maken? Nou, behoorlijk complex als we om ons heen kijken. En dat is niet zo verwonderlijk. In de samenstelling van de functies van een digitor kunnen we kiezen uit deze zeven functies en we kunnen ook nog een digitoren samenstellen uit kleinere digitoren. Dus veel mogelijkheden om lokaal afwijkend te kiezen waardoor er in de huidige systemen zit veel “ruis” zit. Kan die er niet uit?

Ik denk van wel. Om dat in te zien verwijs ik naar complex ogende fractal-plaatjes die goede nabootsingen zijn van de complex ogende werkelijkheid. (Zie bijvoorbeeld fractal). Bij dit soort plaatjes is via herhaald toepassen van een basispatroon een complex ogende situatie ontstaan. Maar let op: in termen van Kolmogorov zijn fractal-plaatjes niet echt complex! De recursie mogelijkheden in de samenstelling van digitoren kunnen ons nu ook helpen in combinatie met fractal-theorie om grip te krijgen op de complexiteit. Met geautomatiseerde patroonherkenning zouden we de bestaande software (ontwerpen) kunnen analyseren om inzicht te kunnen krijgen in de aanwezige legacy. Vervolgens kunnen we geautomatiseerd simpelere “fractal-software” produceren die (bijna) hetzelfde doet als de originele legacy, maar dan veel eenvoudiger!

Bovenstaande is niet even simpel te doen. Bovendien zit er nog een addertje onder het gras. Met het analyseren van de legacy gaan we hoogstwaarschijnlijk alleen de syntactische patronen herkennen. De vraag is of je ook de semantische patronen kunt ontdekken. Geautomatiseerd herkennen dat een COBOL en een Java programma op hoofdlijnen functioneel hetzelfde doen, lijkt mij in ieder geval nog een hele klus. Mogelijk moet je trouwens niet naar de beschrijving maar naar het daadwerkelijke gedrag van het systeem kijken. Dus dat wordt de volgende puzzel.

Be the first to write a comment

Only registered users can write comments.
Please login or register.

Share / deel