Architectuur voor ICT kwaliteit: veeleisend zijn moet en kan

De informatievoorziening is anno 2015 een complexe technologische en organisatorische constructie met een grote impact op het functioneren van mensen en organisaties. Dat stelt hoge eisen aan de kwaliteit van ICT. Neem je het managen van de ICT kwaliteit serieus, dan kan de moed je snel in de schoenen zakken. Wat begint met een paragraafje non-functionals in een project start architectuur groeit zo maar uit tot katernen vol met principes, eisen en normen. Een nachtmerrie voor projectleiders en bestuurders doemt op: moeten we aan al die eisen voldoen? Tijd voor architecten om te helpen!

In februari schreef ik over kwaliteit van ICT onder architectuur. Aan de hand van de ISO/IEC standaarden in de 25000:2014 reeks SQuaRE is een balans te onderkennen tussen verschillende perspectieven van kwaliteit: bezien vanuit de mens (de gebruiker), het systeem (het product) en de informatie (data kwaliteit). En met een Archimate implementatiemodel is de eerste schrik van managers wat te nuanceren door te laten zien dat kwaliteit kan - en moet - groeien. Een model voor de maturity ontwikkeling van capabilities, in dit geval van systemen. Dat klinkt bekend toch (CMM): geen geheel nieuw gedachtengoed, gelukkig.

Ook in mijn eigen werkpraktijk, de digitalisering van de rechtspraak, is dit onderwerp vol aan de orde. Zo debatteerde op 1 april 2015 de Tweede Kamer over de business cases Kwaliteit en Innovatie “met het oog op de digitalisering”. Het bestuurlijk debat gaat vooral over geld (het kost veel en meer geld en moet vervolgens geld besparen). Op de werkvloer gaat het debat vooral over kwaliteit: kan ik snel, gemakkelijk, veilig, efficiënt en effectief, in samenwerking met mijn omgeving en goed geïnformeerd mijn doelen realiseren? En omdat we zo afhankelijk zijn van techniek: kan ik op de ICT vertrouwen?

De realiteit is daarmee onvermijdelijk: ja, we zijn terecht veeleisend als het gaat om de kwaliteit van ICT. We maken onszelf en onze samenleving dermate afhankelijk van digitale voorzieningen dat we daar hoge kwaliteitseisen aan moeten stellen! Om al die eisen behapbaar te maken helpt het om te structureren en te visualiseren. En het helpt om te duiden waarom we zo veeleisend zijn. Kerncompetenties van architecten en architecturen kunnen in deze situatie bijdragen: duiden, structureren en visualiseren.

Op basis van de SQuaRE documentatie is de volgende clustering aan te brengen in de kwaliteitseisen voor ICT:

  1. Functionele kwaliteit
  2. Productiekwaliteit diensten: o.a. beschikbaarheid, snelheid en capaciteit (harde non-functionals)
  3. Kwaliteit ontwikkeling of ontwikkelstraat
  4. Kwaliteit informatiebeveiliging
  5. Kwaliteit gebruikservaring (user experience en business waarde)
  6. Gegevenskwaliteit

Functionele kwaliteit

De functionaliteit heeft over het algemeen wel onze aandacht. Alhoewel: ook het expliciteren en prioriteren van eisen aangaande de functionele kwaliteit blijkt in de praktijk nog best lastig te zijn. De gedaante van functionele kwaliteitseisen kan ook sterk verschillen. De vorm is anders in situaties waar je zelf ICT ontwikkelt en beheert (maatwerk) dan wanneer je standaard oplossingen implementeert of gebruik maakt van clouddiensten. De ISO normen onderscheiden drie kwaliteitsaspecten van functionele geschiktheid: de functionele compleetheid, de functionele correctheid en de mate waarin de functionele werking geschikt is voor de context waarin de voorzieningen gebruikt wordt. Met name de aandacht voor context is nog vaak onderbelicht, terwijl het belang van context groeit (zie ook de bijdrage van Jan van Til over context-modellering!)

Productiekwaliteit

Een tweede gebied van kwaliteitseisen zijn de “harde non-functionals”. Dit betreft eisen die we stellen aan het functioneren van de ICT voorzieningen in de productieomgeving. In de termen van ISO/IEC 25010:2011 zijn dat de performance efficiency, met als deelaspecten snelheid, capaciteit en middelengebruik, en betrouwbaarheid, met als deelaspecten beschikbaarheid, herstelbaarheid, foutbestendigheid en volwassenheid.

Hoe afhankelijker we worden van ICT hoe hoger onze eisen aan de productiekwaliteit. Helaas blijkt deze simpele regel in de praktijk maar al te vaak een harde leerschool te zijn. Zijn die lessen te voorzien? Ja, dat zijn ze. Zijn die lessen te voorkomen? De praktijk wijst vaak uit van niet (gelukkig zijn er positieve uitzonderingen).

Kwaliteit van ontwikkeling

De kwaliteitseisen die de ontwikkeling betreffen liggen dicht bij het terrein van de IT architecten. Voor bestuurders en gebruikers zijn deze eisen verder van hun bed. Zij hechten vooral aan de resultante van dit eisenpakket samen te vatten als flexibiliteit. Toch is het ten onrechte dat deze kwaliteitseisen vaak minder aandacht krijgen. Veel problemen en frustraties in grote IT projecten vinden juist hun oorzaak in een of meer van deze kwaliteiten. Zo gaat het vaak mis omdat systemen moeilijk te testen zijn, het installeren tegenvalt, systemen niet goed aansluiten op andere oplossingen of moeilijk aan te passen zijn.

De flexibiliteit, die de kwaliteit van ontwikkeling moet opleveren, is in te delen in compatibiliteit, overdraagbaarheid en onderhoudbaarheid. De compatibiliteit betreft zowel co-existentie (naast elkaar kunnen bestaan en functioneren) als interoperabiliteit (met elkaar samen kunnen functioneren). De overdraagbaarheid bestaat uit installeerbaarheid (bij herhaling in veel situaties), aanpasbaarheid (aan verschillende technische contexten van functioneren) en vervangbaarheid (door alternatieve services). Bij onderhoudbaarheid zien we kwaliteiten die ook als principes voor een servicegerichte aanpak bekend zijn: modulariteit, herbruikbaarheid, analyseerbaarheid, wijzigbaarheid en testbaarheid.

Kwaliteit informatiebeveiliging

Voor de informatiebeveiliging bestaan kwaliteitsstelsels en normen als een zelfstandig gebied. Toch is het goed om niet “simpel” te verwijzen naar de security discipline. De ISO/IEC 25010:2011 norm biedt als onderdeel van de productkwaliteit een goed aanknopingspunt voor het security domein. Het maakt dat je de beveiligingseisen kunt afwegen in relatie tot andere kwaliteiten. De beveiligbaarheid (als capability) van een systeem is samen te vatten met de aspecten vertrouwelijkheid, integriteit, onweerlegbaarheid, herleidbaarheid en authenticatie.

Kwaliteit gebruikservaring

En dan is er dat lastige vraagstuk van mens en techniek. Waarom snapt de eindgebruiker niet gewoon hoe de techniek functioneert? Waarom snappen de technici niet hoe eindgebruikers willen werken? Waarom stellen verschillende stakeholders conflicterende eisen? Wat doen we met de wetenschap dat mensen verschillend zijn en verschillend functioneren: uniformeren of personaliseren? En dat terwijl we met beperkte middelen hoge ambities waar willen maken.

Binnen het gebied van de kwaliteit van de gebruikerservaring vallen zowel de “quality of use” (kwaliteit van de informatievoorziening vanuit het perspectief van de mens) als de bruikbaarheid van de “product quality” (de gebruiksvriendelijkheid vanuit het perspectief van het systeem). Binnen de quality of use is te onderscheiden de kwaliteit vanuit het perspectief van management en bestuur (effectiviteit, efficiëntie en organisatie risico’s) en de kwaliteit vanuit het perspectief van de medewerker (voldoening, context dekking en persoonlijke risico’s).

De quality of use in de ISO/IEC 25010:2011 norm richt zich op “outcomes of interaction with a system” en wordt zowel bepaald door de capabilities van het system als die van “users, tasks and social environment”. De definities zijn een doorontwikkeling van de oude ISO/IEC 9126-1 norm. Vanuit het perspectief van de medewerker is voldoening opgebouwd uit het gebruiksnut, vertrouwen, comfort en plezier dat een medewerker bij het gebruik ervaart.

De context dekking bestaat uit de flexibiliteit van de informatievoorziening om in veranderende contexten van dienst te kunnen zijn en de compleetheid van het aantal situaties die een medewerker tegenkomt waarin de informatievoorziening bruikbaar is. De kwaliteit context dekking staat met name onder druk in projecten met een strikte scopebeperking die toch met proces management tools en business rules het menselijk handelen willen bepalen. Een ideaal dat bij controllers en systeemdenkers nogal eens bestaat (zie bijvoorbeeld de bijdrage van Alcedo Coenen over de zelfrijdende overheid).

De organisatie en persoonlijke risico’s zijn tot kwaliteit benoemd door de “vrijheid van risico” te definiëren. Deze vrijheid van risico bestaat uit economische risico-mitigatie, omgevings-risico-mitigatie en persoonlijke risico mitigatie wat betreft veiligheid en gezondheid.

De bruikbaarheid (usability) van het systeem bestaat uit de “herkenbare toepasselijkheid”, leerbaarheid, hanteerbaarheid, bescherming tegen gebruiksfouten, esthetiek van de gebruikers interface en de toegankelijkheid.

Laat je dit spectrum aan kwaliteitseisen met betrekking tot de gebruikservaring op je inwerken dan is het voorwaar geen sinecure. Gelukkig helpen benaderingen zoals User Centric Design en User Experience (UX) om in samenhang aan deze kwaliteiten te voldoen. En dan moet je dat natuurlijk toepassen in een servicegerichte architectuur om ook de ontwikkelkwaliteit te borgen. En ondertussen niet vergeten om ook te blijven voldoen aan de informatiebeveiliging met zijn hele set aan securitykaders! En, oh ja, we waren begonnen met waar een project meestal om draait en op is begroot: de functionele kwaliteit en de productiekwaliteit.

Gegevenskwaliteit

Tja, en dan denk je dat je er bent. De hele ISO/IEC 25010:2011 norm toegepast. De productkwaliteit en de gebruikskwaliteit zijn in beeld. En dan ook nog letten op de gegevenskwaliteit? Ook voor deze bijdrage wordt dat wel heel veel. Een kleine sneak preview van de ISO/IEC 25012 norm vind je in onderstaand totaalplaatje. De uitleg daarbij is voer voor een aparte bijdrage.

Het complete plaatje

Breng je alle kwaliteitsaspecten zoals hiervoor beschreven bij elkaar in één model dan onstaat het volgende beeld. Het is een schema waarvan ik hoop dat architecten het kunnen begrijpen en gebruiken. Buiten deze doelgroep wil ik het niemand aandoen. Hoe andere doelgroepen (zoals bijvoorbeeld management en materiedeskundigen of product owners) dan wel te helpen de kwaliteit van ICT te overzien en te beheersen: daarover een volgende keer.

Weergaven: 647

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden