Positiepaper voor de Menselijke Maat in de IT, Hans Oesterholt-Dijkema, Februari 2008
De menselijke maat in architectuur documentatie
In dit positie paper behandel ik de vraag: "Hoe kan de menselijke maat in architectuur documentatie worden ingebracht?". Ik richt me daarbij met name op het kaderstellende aspect van architectuurdocumentatie. Het stellen van kaders waarbinnen ICT voorzieningen moeten worden gerealiseerd behoort tot het repertoire van de architect om architectuur te operationaliseren. Kaders uit architectuurdocumenten kunnen worden gebruikt bij het formuleren van key performance indicators en kunnen met behulp van architectuur control worden bewaakt als onderdeel van de quality assurance van projecten en programmamanagement.
Over architectuurdocumentatie
In de Griekse oudheid was de archi-tecton de oudste timmerman op de werkplaats. Dit beeld van de architect vindt ik van toepassing voor de IT architect. De IT architect is gericht op het construeren van een ICT voorziening. Architectuurdocumentatie heeft in deze context wat mij betreft als doelstelling om de ICT voorziening als geheel in het geheel rondom deze voorziening te vatten. Dit betekent, dat, hoewel de architectuur zich met name richt op het concretiseren van een ICT voorziening, deze vanuit vele aspecten die ICT voorziening beschouwt en er daarmee voor zorgdraagt dat de ICT voorziening een evenwichtige oplossing spiegelt naar de wereld die zij mechaniseert.
Ik ben van mening dat de een prominent onderdeel van architectuurdocumentatie gericht moet zijn op het stellen van concrete kaders rondom het creëren van een ICT voorziening. Het beschrijven van de ICT strategie of het beleid van een organisatie is daarentegen in mijn optiek geen pure architectuur deliverable, hoewel de IT architect er wel bij betrokken hoort te zijn.
Duidelijk onderscheid tussen machine en mens
Om deze doelstelling te bereiken is een duidelijk onderscheid tussen datgene wat tot de ICT voorziening behoort en datgene dat tot de wereld daarom heen behoort van belang. Het gehanteerde begrip 'ICT voorziening' gaat in deze paper over het machinale deel van de totale organisatie; de technologie. De informaticus maakt machines waarmee gegevens kunnen worden gemanipuleerd. Het machinaal verwerken van gegevens wordt meestal vanuit een doelstelling in de levende wereld rondom de ICT voorziening gedaan. Bijvoorbeeld het ondersteunen van het betalingsverkeer bij een bank of het ondersteunen van de medewerker van een call center.
In mijn optiek is de machine geen aspect dat op zichzelf iets van doen heeft met de menselijke maat. Een machine is een object met een eigen interne logica, eigenlijk, een in zichzelf gekeerd ding. Het gaat om alle aspecten om zo'n machine heen die menselijke maat behoeven. Aspecten zoals, de maatschappelijke impact, indirecte gebruikers, de directe eindgebruiker, de beheerder (de machine bediende), de helpdesk, de support organisatie, de onderhoudsmedewerker, de ontwikkelorganisatie, de economische waarde, de nuttigheid, etc.
De architect is degene, die al deze aspecten vertaalt in kaders, die gehanteerd worden bij het construeren van de machine. Al deze aspecten vormen een balancerend geheel binnen de context of het domein waarbinnen de machine gaat functioneren. In het formuleren van de kaders ligt wat mij betreft de mogelijkheid om de menselijke maat tot uiting te brengen. Het doel zou altijd moeten zijn, het creëren van een machine die helder gepositioneerd is in het machinale domein ten opzichte van de menselijke aspecten.
Architectuurkaders
De architect formuleert kaders en projecteert visie, waarbinnen ontwerpers en ontwikkelaars in vrijheid de IT machine kunnen creëren. Een architect die rekening houdt met de menselijke maat, formuleert de kaders zo, dat hij weg blijft van dogma's. Met een dogma bedoel ik in deze context een besluit dat tot een onwrikbaar geloof wordt. Hierbij kan gedacht worden aan "Wij doen hier alles met messaging, omdat dat volgens de architectuur is.". Een kader zou derhalve een levend kader moeten zijn. Een levend kader is zo gegeven, dat degene die het kader toepast nog steeds zelf uitgenodigd wordt om na te denken en ruimte heeft tot verstandige invulling binnen de specifieke ontwerp context. Daarmee wordt het kader wel iets dat bewustzijn en betrokkenheid vraagt van degene die het toepast. Een voorbeeld van een levend kader kan zijn: "Een service wordt altijd gebouwd in de technologie die kan worden onderhouden door het service team dat de service in onderhoud krijgt". Dit kader laat technologisch gezien alle mogelijkheden binnen het strategisch ICT beleid open en helpt een team dat services ontwikkelt rekening te houden met degenen die uiteindelijk verantwoordelijk zijn voor het leveren van de service.
Balans
De architect is daarmee de persoon die in staat is om de verschillende stakeholders resp. aspecten van een ICT voorziening in balans te brengen vanuit het gegeven dat hij/zij verantwoordelijk is voor het ontwikkelen en in stand houden van een complete ICT voorziening. Daarbij zal hij/zij iedere keer verschillende aspecten centraal stellen in architectuurkaders. Een kader kan voortkomen uit een mogelijke maatschappelijke consequentie, of belangrijk zijn voor een indirecte eindgebruiker. Echter het kan ook zijn dat een kader juist beoogt om de ontwikkelorganisatie in een bepaalde stelling te brengen.
Casus Service Oriëntatie
Voor een grote klant wordt in een ICT programma getracht service oriëntatie in te voeren, om op deze manier de onoverzichtelijke kluwen van ICT voorzieningen en verantwoordelijkheden uiteen te rafelen. De grootste problematiek hierbij komt voort uit de enorme fragmentatie van ICT voorzieningen over verschillende ICT onderhoudsteams en het niet hanteren van duidelijke regels rondom afhankelijkheden van elkaar. Als architect hanteer ik hierbij de visie dat de ICT ontwikkel -en onderhoudsorganisatie het beeld van service oriëntatie in zich moet gaan dragen. De service oriëntatie moet dan overeen komen met de verschillende uitvoeringsafdelingen van deze organisatie. De architectuurkaders die worden gehanteerd bij het construeren van services zijn erop gericht om de organisatie te helpen bij de ontwikkeling naar service oriëntatie en moeten in de context van dit tijdsgewricht worden gehanteerd. Dat betekent dat de kaders van dit moment over enkele jaren niet meer zullen voldoen.
Over service oriëntatie
Service oriëntatie is op zichzelf niets meer of minder dan de omslag van een ambachtelijke of kunstzinnige werkhouding naar een dienstenorganisatie. Bij de ambachtelijke werkhouding wordt altijd gezocht wordt naar de 'precies passende oplossing', d.w.z. maatwerk. Bij service oriëntatie wordt daar vanaf gestapt. In plaats van het "maatpak" wordt het "confectiepak" gemaakt. Dat confectiepak wordt voldoende geacht, ook al zit het niet helemaal als gegoten.
Daarmee maakt service oriëntatie dat we van iets dat op individuele basis passend is gaan naar een algemeen goed. Op zich is deze beweging in orde, omdat het een aantal waarden brengt, zoals bereikbaarheid voor iedereen; maar het moet menselijk gezien worden voor wat het is. "Algemeen goed", betekent "niet afgestemd op mijn of uw individuele behoefte", het vraagt met andere woorden aanpassing van u en mij. Onderwerping aan de voorwaarden van de service leverancier is aan de orde.
Service oriëntatie moet niet verward worden, maar wordt dat wel vaak, met centralisatie van begrippenkader. Om het hergebruik dat met service oriëntatie wordt beoogd namelijk te laten werken, is het nodig dat centraal, voor iedereen in een organisatie, de te benutten services bekend zijn. Deze centrale catalogus kan, en doet dat ook vaak, een beweging in gang zetten, om dan ook meteen maar het gehanteerde begrippenkader te centraliseren; terwijl het voldoende is om per service of bovenliggende bedrijfsdienst de begrippen helder te definiëren in de daar gehanteerde ICT context. Centralisatie van begrippenkader heeft als gevolg dat ofwel concessies moeten worden gedaan aan de helderheid van de definitie van de begrippen ofwel de begrippen te nauw worden gedefinieerd. In het eerste geval worden de begrippen als zodanig onbruikbaar. In het tweede geval kan de interne logica van het machinale niveau de levende wereld gaan bestieren en zich indirect opleggen aan de maatschappij.
Enkele voorbeelden van kaders
Het begripsdomein is heilig: Een kader dat rekening houdt met de menselijke maat is dan ook dat begrippen binnen het domein van een bedrijfsdienst hun geldigheid hebben en dat het verboden is om dezelfde definities daarbuiten te hanteren. Bij het ontwerpen van service repositories, services en modellen dient daarmee rekening te worden gehouden.
Fragmentatie van de projectorganisatie is verboden: Een ander kader betreft het beleggen van verantwoordelijkheden. Als één van de doelstellingen is om de kluwen van project afhankelijkheden te ontwarren, dan is het van belang om verantwoordelijkheden helder te beleggen en niet te verdelen over een groot aantal projecten. Het mechaniseren van een proces heeft als gevolg het fragmenteren van zo'n proces in kleine stapjes (McLuhan). Voorkomen moet worden dat dit fragmenteren van het proces zich gaat spiegelen in de ontwikkel- en onderhoudsorganisatie. De mens denkt in gehelen. De machine fragmenteert. Concreet betekent dit dat op dit moment een service niet afhankelijk mag zijn van meer dan één releaseplanning. Dit kader hangt overigens nauw samen met het kader over versiebeleid.
Versies ontkoppeld: Services die van elkaar afhangen mogen geen één op één versieafhankelijkheid van elkaar hebben als niet beide partijen dit wensen. Een één op één versieafhankelijkheden tussen een service en al zijn afnemers is te rigide en levert stilstand op voor vernieuwing van de service. Ook mag het niet zo zijn dat één service tegemoet komt aan alle wensen van alle afnemers (ambachtsituatie), omdat dit verstikking van de onderhoudsorganisatie oplevert en daarmee tevens stilstand. Het bewegende midden is dus een situatie waarbij een beperkt aantal major versies van een service wordt onderhouden, backwards compatibility binnen een major versie wordt gehanteerd en waarbij afnemers onafhankelijk van het uitbrengen van een nieuwe versie van de service kunnen migreren naar een nieuwere versie van de service. Om dit voor elkaar te krijgen is overigens een vrijwel militair ICT besturingregime nodig.
Het overdrachtsprincipe: het is verboden om services voor een ander te ontwikkelen in technologie die niet door die ander in onderhoud kan worden genomen. Dit principe kan worden afgeleid uit het bovenstaande principe over het fragmentatie van de ontwikkelorganisatie.
Signalen moeten bevestigd worden: Als er gewerkt wordt met events, dan is het verplicht om op het niveau van gegevensverwerking zo'n signaal te bevestigen; ook al is de onderliggende technologie betrouwbaar. De betekenis die aan zo'n bevestiging ontleend moet kunnen worden, is dat het signaal geborgd is in het verwerkende (bedrijfs)proces.
Herinjectie verplicht: Het is verboden om aan te nemen dat er geen fouten zullen optreden in een verwerkingsproces die niet gedetecteerd worden binnen het eigen verantwoordelijkheidsdomein. Daarom zal er altijd een mogelijkheid zijn om een proces vanaf een gevalideerd punt in het proces opnieuw, of afwijkend te doorlopen.
Metadata onder een paraplu: ICT producten van teams die met metadata bezig zijn (begrippen, data modellen, service contracten, sno's) moeten worden ontsloten via één centraal ontsluitingsmechanisme. Teams die met metadata bezig zijn dienen zich te confirmeren aan de standaarden van het team dat verantwoordelijk is voor het centrale ontsluitingsmechanisme.
Bespreking van de voorbeelden
Het eerste voorbeeldkader bewaakt dat ICT definities van begrippen zich gaan vermengen met de maatschappelijke noties van begrippen. Een mens heeft geen moeite om vloeiend een begrip verschillende contexten te hanteren. Dit is de menselijke maat en het is van belang deze te respecteren.
Het tweede en derde kader bewaken dat kleine wijzigingen in systemen en applicaties een rimpeling veroorzaken door de een lange keten van ICT projectteams en onderhoudsteams met navenante doorlooptijden. Overigens wordt met deze kaders onderstreept dat het van belang is om continu energie te blijven stoppen in landschap van ICT voorzieningen.
Het overdrachtsprincipe bewaakt dat waar uit noodzaak geboren (tijdsdruk, kennisoverdracht, releaseplanningen, etc.) het ontwikkelen van een service wordt belegd bij een speciaal service ontwikkelteam, dit team een niet onderhoudbaar slagveld achterlaat voor de service leverancier. Het hebben van een speciaal service ontwikkelteam mag, mits deze dat zodanig doet dat de verantwoordelijken voor het leveren van de dienst de service in onderhoud kunnen nemen. Met het naleven van dit kader wordt tevens olievlekwerking van het gedachtegoed van service oriëntatie bewerkstelligd in de ICT organisatie.
Het kader over signalen bewaakt dat geen ongewenst leed wordt veroorzaakt voor individuen die de signalen betreffen. Concreet: als een signaal over een geboorte verloren gaat, zullen bepaalde systemen de uitkering van kinderbijslag niet regelen als het signaal niet doorkomt.
Het kader wat betreft herinjectie is een kader dat ik in mijn tijd in de afdeling externe communicatie en mediaverwerking bij de Belastingdienst heb gehanteerd. Het kader gaat er vanuit dat mensen fouten kunnen maken en dat deze pas aan het licht kunnen komen op het moment dat een volledig bedrijfsproces doorlopen is. Het voorbeeld dat ik altijd hanteerde was dat een programmeur bij een transformatie in de verwerkingsstroom van de binnenkomende aangifte berichten enkele niet verplichte velden zou kunnen vergeten af te beelden op het nieuwe formaat. De fout zou er pas uit kunnen komen op het moment dat een Belastingdienst medewerker bij het behandelen van aangiftes ongewenste uitworp zou zien. Dit kader houdt rekening met de menselijke maat in die zin dat mensen nou eenmaal fouten maken (programmeurs ook) en dat de aangiftestroom van de Belastingdienst de menselijke maat overstijgt. Het hanteren van dit kader heeft aardig gewerkt. In de loonheffingsketen konden duizenden aangiftes opnieuw in het verwerkingsproces worden gezet, toen bleek dat de verwerking verderop in het massale proces spaak liep.
Het laatste kader over metadata zorgt ervoor dat er een team van mensen belang heeft bij het samenwerken van teams die slechts indirect met elkaar te maken hebben. Het bewaakt de bruikbaarheid van de metagegevens voor mensen en geeft de gewenste centralisatie van metadata in een service georiënteerde architectuur.
Conclusie
In deze positie paper heb ik betoogd dat het mogelijk is om de menselijke maat met behulp van kaders, die worden ontleend aan architectuurdocumentatie, ingebracht kan worden bij het creëren van ICT voorzieningen.