In deze essay ga ik op zoek naar antwoorden op de bovenstaande vragen. Als eerste begin ik met een beschrijving van een fictieve casus

In hoeverre zijn architecten in de digitale wereld aansprakelijk?

Een verkenning naar de aansprakelijkheid en verantwoordelijkheid met betrekking tot de geleverde diensten van ICT architecten1 en de relatie met persoonsgebonden certificering. Als je het hebt over architecten in de digitale wereld is de link met bouwkundige architecten in de fysieke wereld snel gelegd. In dit essay probeer ik me absoluut niet in de discussie te mengen met betrekking tot de fel bediscussieerde beschermde status van de titel ‘Architect’ (Loohuis, 2003), maar beide typen architecten zijn verantwoordelijk voor het analyseren van klantbehoeften en het ontwerpen van een daarbij passende oplossing: bouwkundige architecten in de fysieke wereld ontwerpen gebouwen en architecten in de digitale wereld ontwerpen systemen in de breedste zin des woord (Wieringa, 2005). Indien een architect in de fysieke wereld een ontwerpfout maakt waardoor bijvoorbeeld de stevigheid van de structuur van het gebouw niet aan wettelijke normen voldoet, zal de architect, indien aangetoond kan worden dat de architect bij het uitvoeren van zijn opdracht beroepsmatig in gebreke is geweest, hiervoor aansprakelijk worden gesteld (“Architectenrecht”, 2005). Het is aan dan aan hem om de fout te herstellen. Deze aansprakelijkheid geldt gedurende een periode van 10 jaar na oplevering van de architectuur. Hoe is dit geregeld bij architecten in de digitale wereld? In hoeverre is de architect in de digitale wereld aansprakelijk indien hij bij het uitvoeren van de opdracht in gebreke blijkt te zijn geweest? Kun je hier ook op dit vlak de link leggen tussen de fysieke en digitale wereld? Voor architecten in de fysieke wereld bestaan diverse voltijd opleidingen op HBO en WO niveau. Een diploma zegt dus iets over de kennis van de architect. Door tijdens de opleiding diverse praktijkopdrachten uit te voeren zegt een diploma ook iets over de kunde van de architect. Maar vooral de gebouwen die hij heeft ontworpen zijn een afspiegeling van zijn kunde: ze zijn het visitekaartje van de fysieke architect. In Nederland zijn vooralsnog geen voltijd HBO of WO opleidingen die zich specifiek richten op architecten in de digitale wereld. Er zijn wel tal van (commerciële) opleidingsinstituten die ICT architectuur opleidingen met een bijbehorend certificaat of diploma aanbieden. Daarnaast zijn er organisaties die architecten in de digitale wereld certificeren. Er bestaat op dit moment nog geen Nederlandse norm voor het benodigde kennisniveau en ervaring ten behoeve van het certificeren van architecten in de digitale wereld. Wel zijn er initiatieven om de benodigde competenties van een ICT architect te beschrijven zodat deze vervolgens kan dienen voor een certificering (het Nederlands Architectuur Forum voor de digitale architect (NAF) beschrijft in http://www.naf.nl/content/bestanden/architectcompetenties.pdf de competenties waaraan volgens hun een ICT architect aan moet voldoen). Wat is de toegevoegde waarden van het certificeren van ICT architecten? In deze essay ga ik op zoek naar antwoorden op de bovenstaande vragen. Als eerste begin ik met een beschrijving van een fictieve casus. Casus Een bedrijf (ik noem haar Kantoor) verkoopt in Europa kantoorartikelen. Verkoop vindt uitsluitend plaats in winkels. Kantoor merkt dat de omzetgroei stagneert door toegenomen concurrentie. De concurrentie hanteert een geheel ander bedrijfsmodel: het verkoopt de goederen via Internet en geeft daar ook veel informatie over de producten die ze verkopen. Iets dat bij ‘cash and carry’ principe niet de prioriteit heeft. Door het andere bedrijfsmodel liggen de prijzen bij de concurrenten veelal een stuk lager dan bij Kantoor.

1

‘ICT architect’ en ‘architect in de digitale wereld’ zijn voor mij synoniemen en worden in dit essay door elkaar gebruikt

1

De directie van Kantoor besluit om hun artikelen, onder een andere merknaam weliswaar, via Internet aan te bieden. Om schaalvoordeel te behalen wordt het afzetkanaal via Internet ingepast in de huidige bedrijfsprocessen en ICT systemen. Om de impact te bepalen en het ontwerpen van de nieuwe processen en ICT systemen wordt een enterprise architect ingehuurd. Deze architect gaat voortvarend aan de slag en begint met het achterhalen van de principes en doelstellingen van Kantoor. Vervolgens stelt hij een architectuur op waarin naar zowel de business, informatie, informatiesystemen en technische infrastructuur wordt meegenomen. Ook worden de aspecten security en governance niet vergeten. Gedurende dit traject vindt regelmatig afstemming plaats met de opdrachtgever. Na het opstellen van de architectuur wordt er een transitieplan opgesteld en worden er diverse projecten gedefinieerd. Per project wordt van hetzelfde adviesbureau een projectarchitect aangesteld om er voor te waken dat de deliverables van het project binnen de kaders blijven die zijn opgesteld in de enterprise architectuur. Tijdens deze fase blijkt dat de enterprise architectuur fouten bevat: principes zijn niet goed ‘doorvertaald’ in de architectuur en onderdelen uit de geschetste informatiesysteem architectuur blijken technisch niet haalbaar te zijn. Deze fouten leiden tot een vertraging in de lancering van de internetwinkel en tot extra kosten omdat delen van projecten overgedaan moeten worden. Al met heeft Kantoor een schadepost van 2.000.000. Kantoor stelt de enterprise architect aansprakelijk omdat deze, volgens Kantoor, verwijtbare fouten heeft gemaakt: zij hadden toch een externe expert ingehuurd omdat ze zelf de kennis niet in huis hadden. Verschillende soorten ICT architecten In de digitale architectuur worden twee hoofdgroepen van architecten onderscheiden (Rijsenbrij et al., 2004): enterprise architecten en systeem architecten. Enterprise architecten vinden hun beschouwinggebied op het niveau van de organisatie en haar omgeving terwijl systeem architecten zich over het algemeen bezig houden met het beschouwingniveau van een systeem of een groep van systemen. Binnen deze laatste groep bevinden zich de business, informatie, informatiesysteem, technische infrastructuur, security en governance architecten. De enterprise architect dient kennis te hebben van alle van de kennisgebieden van systeem architecten. Naast de bovengenoemde groepen architecten wordt ook nog de project architect onderscheiden. Taakinhoud van een ICT architect De taakinhoud van enterprise en systeem architecten bestaat uit drie onderdelen (Rijsenbrij et al., 2004, p.136 ): • De architect representeert alle stakeholders en is regisseur van het besluitvormingsproces • De architect maakt en bewaakt het integrale concept • De architect zorgt voor een goed gedefinieerde opdracht richting de uitvoerder. Een enterprise c.q. systeem architect zal aan het begin van het traject op zoek gaan naar principes. Principes zijn essentiële beslissingen die belangrijk zijn voor (bijna) alle aspecten van de bedrijfsvoering (Rijsenbrij et al., 2004, p. 27). Principes beïnvloeden direct de uiteindelijke opgestelde architectuur. Foute principes kunnen desastreus zijn bij transformaties. Principes kunnen onderling ook tegenstrijdig zijn. Het is de taak van de architect om gedurende het traject diverse scenario’s uit te werken waarmee het effect van de principes op het uiteindelijke ontwerp duidelijk worden. Op basis van deze informatie kan de opdrachtgever de juiste keuzes maken. De taakinhoud van een projectarchitect bestaat uit het vertalen van de enterprise architectuur naar een architectuur voor een specifiek project en gedurende het project als ‘waakhond’ te fungeren zodat het resultaat van het project binnen de gestelde kaders van de enterprise architectuur past. Hier zie je dus een duidelijk onderscheid tussen de taakinhoud van een enterprise c.q. systeem architect en een projectarchitect: de eerste groep is vooral bezig met het ontwerpen van een oplossing en fungeert daarbij als regisseur van het besluitvormingsproces (de besluiten worden uiteindelijk door de 2

opdrachtgever genomen) terwijl de tweede groep vooral bezig is met het realiseren van het ‘eindproduct’. Je kunt dus concluderen dat de eerste groep ICT architecten puur besluiten voorbereidt terwijl de tweede groep ook besluiten neemt. De taakinhoud van een architect in de fysieke wereld is naar mijn mening een combinatie van besluitvoorbereider en besluitverantwoordelijke: samen met de opdrachtgever wordt er een ontwerp gemaakt (besluitvoorbereider) en wordt dit door de architect uiteindelijk uitgewerkt in een bestek (besluitverantwoordelijke met betrekking tot onder andere de constructie). Op het punt van besluitverantwoordelijkheid is er dus geen overeenkomst tussen een architect in de digitale wereld en een fysieke architect. Aansprakelijkheid van een architect in de digitale wereld Onder aansprakelijkheid wordt het volgende verstaan (Van Dale, 2005): 1. Vervolgbaarheid wegens veroorzaakte schade 2. Verplichting om zich desverlangd wegens zijn handelingen te verantwoorden Welke definitie(s) is (zijn) nu voor een architect in de digitale wereld van toepassing? Deze vraag beantwoord ik naar aanleiding van de theorie van Prof. Dr. Ir. A. Twijnstra (Twijnstra, 1997): de aansprakelijkheid van de organisatieadviseur. Deze vergelijking is naar mijn menig goed te maken omdat de ICT architect ook de rol van adviseur bekleed gedurende een architectuurtraject (hij bereidt besluiten voor, maar neemt ze niet). De aansprakelijkheid van de adviseur behoort juridisch tot het terrein van de beroepsaansprakelijkheid. Daaronder verstaat men de aansprakelijkheid van vrije beroepsbeoefenaren, zoals accountants, advocaten, artsen en notarissen. Deze beroepsaansprakelijkheid is te onderscheiden in aansprakelijkheid jegens cliënten/patiënten en die jegens derden. Bij adviseurs gaat het voornamelijk om de aansprakelijkheid jegens de cliënt omdat zij geen semi-publieke functie hebben, en naast de belangen van hun cliënten, niet de belangen van de buitenwereld behartigen. Maar waar is een adviseur nu eigenlijk aansprakelijk voor: het werk wat hij doet, de dienst die hij verleent is niet echt eenduidig vast te stellen. Inhoudelijk is het werk van de adviseur moeilijk vast te stellen: zijn dienst of product is niet scherp definieerbaar in de zin zoals dat bij producten of apparaten wel kan. Vanaf 1988 geldt er een toegenomen productaansprakelijkheid voor producten met gebreken. Volgens de wet is een product gebrekkig indien het niet de veiligheid biedt die men redelijkerwijs er van mag verwachten, alle omstandigheden in aanmerking genomen en in het bijzonder: de presentatie van het product, het redelijkerwijs te verwachten gebruik en het tijdstip waarop het op de markt is gebracht. De producent van een duidelijk gebrekkig product heeft voor de rechter aan te tonen – wil hij niet voor schadevergoeding worden veroordeeld – dat ten tijde van het in omloop brengen, wetenschappelijk en technisch onmogelijk was het gebrek te ontdekken. Een adviseur verplicht zich, na zorgvuldig overleg met de opdrachtgever in spe, niet tot het bereiken van een concreet resultaat. Juridisch gezien heeft de adviseur een inspanningsverplichting en geen resultaatverbintenis. Ondanks die inspanning kan het nog best zo zijn dat het beoogde resultaat niet, of niet naar verwachting wordt bereikt. De opdrachtgever kan bij tegenvallend resultaat, niets anders doen dan na te gaan wat ‘een redelijk handelend vakpersoon onder soortgelijke omstandigheden zou hebben gedaan’. Maar dit is toch vrij moeilijk te beoordelen. Bij alle professies zijn er gebieden aan te wijzen waarbij de beroepsuitoefening als ‘zonder meer juist’ valt aan te merken. Ook zijn er gebieden aan te wijzen als ‘zonder meer fout’. Het is nu juist in het gebied tussen ‘zonder meer goed’ en ‘zonder meer fout’ waarbij verschillende werkwijzen mogelijk zijn. Dit ‘tussengebied’ is relatief groot bij adviseurs waardoor het moeilijk is om hem aansprakelijk te stellen voor zijn werk. Een adviseur is alleen aansprakelijk voor fouten in het ‘zonder meer fout’ gebied. 3

Wat voor soort fouten vallen in dit gebied? Als eerste zijn dit fouten die rationeel ondubbelzinnig herkenbaar zijn: rekenfouten en/of zaken die in strijd zijn met de ratio, die dus door iedereen ondubbelzinnig als fouten worden herkend. Andere fouten die in dit gebied vallen zijn fouten die gemaakt worden bij de vaststelling (of het juist niet vaststellen) van feiten en gegevens. Een adviseur is verplicht om de juistheid en volledigheid van feiten en gegevens (steekproefsgewijs) te controleren. Een architect in de digitale wereld is dus vervolgbaar wegens veroorzaakte schade als gevolg van fouten in het ‘zonder meer fout’ gebied (het eerste deel van de definitie uit Van Dale). Voor fouten in het ‘tussengebied’ is de architect verplicht om zich desgevraagd zijn handelingen te verantwoorden (het tweede deel van de definitie uit Van Dale). Pas als dit onomstotelijk is vastgesteld is de architect in de digitale wereld ook aansprakelijk voor die fouten. De vraag is nu: hoe kun je het ‘tussengebied’ verkleinen? Dit kan mijn inziens wellicht door enerzijds het architectuurproces te normeren en van een keurmerk te voorzien en anderzijds door architecten te certificeren. Architectuurproces normeren In Nederland bestaan organisaties als KIWA (www.kiwa.nl) en KEMA (www.kema.nl) voor het certificeren van onder andere processen. Één van de bekendste is natuurlijk de ISO9000 certificering. Deze certificering geldt voor de interne processen bij bedrijven en is er op gericht dat deze processen beheerst verlopen. Waarom geen certificering van het ICT architectuur proces? Wat is de toegevoegde waarde? Voor mij zit de toegevoegde waarde in het feit dat de architect in de digitale wereld wordt ‘gedwongen’ om gedurende het traject volgens bepaalde richtlijnen te werken. De kans dat processtappen worden vergeten zal afnemen waardoor het voor de ICT architect makkelijker aan te tonen is dat hij zorgvuldig te werk is gegaan. Als ICT architect volgens een bepaalde norm zouden werken zal het ‘tussengebied’ kleiner worden. Daarnaast zal in het gestandaardiseerde proces ook aangegeven zijn wie waar verantwoordelijk voor is en wie moet op (en over) welke punten besluiten nemen. Door vervolgens ook de besluitvorming eenduidig vast te leggen kan deze ten aller tijde getraceerd worden en is het in een later stadium gemakkelijk te bepalen door wie en op basis van welke informatie de besluiten zijn genomen. Indien het blijkt dat de besluiten op onjuiste informatie genomen zijn kan vervolgens bepaald worden wie voor deze informatie verantwoordelijk was en hoe deze informatie is verkregen. De kwaliteit van deze informatie kan vervolgens gekwalificeerd worden als ‘zonder meer fout’, ‘zonder meer goed’ en ‘tussengebied’. Hieruit kan de aansprakelijkheid van de ICT architect bepaald worden (indien deze verantwoordelijk was voor deze informatie). Maar wie is er nu eigenlijk aansprakelijk bij fouten: de ICT architect zelf of het bedrijf waar de ICT architect voor werkt? Uit een analyse van de algemene voorwaarden van diverse consultancy bedrijven blijkt de aansprakelijkheid bij de werkgever te liggen. Dit is in mijn ogen de juiste plek: een klant schakelt immers een consultancy bedrijf in voor een stuk werk. Het in de verantwoordelijkheid van het consultancy bedrijf om de complexiteit van de opdracht in te schatten en hiervoor de meest geschikte ICT architect te vinden en de kans op fouten van hun medewerkers te minimaliseren. Dit kan door bijvoorbeeld het werk van een ICT architect verplicht te laten toetsen door een collega en ICT architecten te verplichten zich te laten certificeren. Binnen het werkgebied van ICT architecten worden diverse frameworks gebruikt zoals TOGAF, Zachmann, Integrated Architecture Framework (IAF) en Extensible Architecture Framework (XAF). Door het proces dat ICT architecten volgen bij het toepassen van één van deze frameworks volgens één ISO norm te certificeren kun je deze frameworks beter met elkaar vergelijken; zo wordt het voor de opdrachtgever makkelijker om een ICT architect te selecteren voor een opdracht: het maakt immers niet 4

meer uit welk framework door de ICT architect wordt gehanteerd, de kwaliteit van het proces dat hij zal volgen is conform een bepaalde standaard. Architecten certificeren Naast het certificeren van het architectuurproces lijkt het mij ook raadzaam om architecten in de digitale wereld persoonlijk te certificeren. Anno 2004 bestaan er 4 initiatieven voor het certificeren van enterprise architecten met een wereldwijde erkenning (Allega, 2004). Daarnaast zijn er bedrijven zoals IBM en Capgemini die zelf een ICT architectuur certificeringproces hebben opgezet. Het is echter niet mogelijk voor ICT architecten, behalve de medewerkers die bij de genoemde bedrijven werkzaam zijn, om zich te laten certificeren volgens deze norm. Een persoonlijke certificering zegt iets over de kennis van de ICT architect, maar vooral ook iets over zijn ervaring. Een persoonlijk certificaat is dus voor de opdrachtgever een garantie voor de kwaliteit van de ICT architect die ingehuurd wordt. Door de ICT architect regelmatig zijn uitgevoerde opdrachten door een commissie te laten toetsen blijft ook de waarde van de certificering gewaarborgd. Conclusie Ik begon dit essay met twee hoofdvragen: 1. In hoeverre is de architect in de digitale wereld aansprakelijk indien hij bij het uitvoeren van de opdracht in gebreke blijkt te zijn geweest? Kun je hier ook op dit vlak de link leggen tussen de fysieke en digitale wereld? 2. Wat is de toegevoegde waarden van het certificeren van ICT architecten? Een architect in de digitale wereld is dus zeker aansprakelijk voor een deel van zijn werk: dat deel waarvan onomstotelijk aangetoond kan worden dat deze ‘zonder meer fout’ is geweest. De ICT architect is alleen niet persoonlijk aansprakelijk: het bedrijf waar deze voor werkt is aansprakelijk. Om het gebied tussen ‘zonder meer goed’ en ‘zonder meer fout’ te verkleinen heeft een keurmerk voor het architectuurproces zeker een toegevoegde waarde: het vergroot het ‘zonder meer fout’ gebied. Het zou aanbeveling verdienen om verder onderzoek te doen naar een internationaal erkende norm voor het architectuurproces. Als deze norm bestaat kunnen de architectuur frameworks en de bijbehorende processen gecertificeerd worden. Een persoonlijke certificering van een ICT architect heeft naar mijn mening ook een duidelijke toegevoegde waarde omdat het voor de opdrachtgever een garantie is voor de kwaliteiten van de ingehuurde ICT architect. Er lopen over de gehele wereld een aantal initiatieven op dit vlak. Waarom niet één wereldwijde certificering voor ICT architecten? Er zou een initiatief gestart moeten worden om vanuit deze initiatieven tot één certificeringproces te komen voor architecten in de digitale wereld. Één certificering voor ICT architecten leidt zowel bij opdrachtgevers, maar zeker ook bij ICT architecten zelf, tot meer duidelijkheid. Door een persoonlijke certificering is het ook mogelijk om het gebied tussen ‘zonder meer goed’ en ‘zonder meer fout’ te verkleinen: de certificatie is een garantie voor de kennis en kunde van een ICT architect. Van ICT architecten met een bepaalde certificering mag je een bepaald niveau van werkzaamheden verwachten. Het zal dus bij fouten in de opgestelde architectuur eerder aantoonbaar zijn dat deze in het ‘zonder meer fout’ gebied liggen. Het dient dan echter voor aanvang van een architectuurtraject wel duidelijk te zijn wat het benodigde certificeringniveau is zodat ook de juiste persoon wordt ingehuurd. Naar mijn weten is er op dit vlak nog onvoldoende onderzoek gedaan.

5

Literatuurlijst • • • • • • •

Architectenrecht (2005, december), Vastgoedmarkt, p. 35. Loohuis, K. (2003). Titel architect taboe in ICT. Computable, 37, 1. Allega, P. (2004), Positioning Enterprise Architect Certification Effords, Stamford: META Group. Rijsenbrij, D., Schekkerman, J., Hendrickx, H. (2004), Architectuur, besturingsinstrument voor adaptieve organisaties (2nd ed.), Utrecht: Lemma BV. Twijnstra, A., Keuning, D. (1997), Organisatie-advieswerk (2nd ed.), Houten: Educatieve Partners Nederland BV Van Dale (2005), Groot Woordenboek van de Nederlandse taal (14th ed.), Utrecht/Antwerpen: Van Dale Lexicografie BV. Wieringa, R. (2005, november). Competenties van de ICT architect, p.5.

Auteur: Jeroen Cloo ([email protected])

6