Een audit op informatiearchitectuur:

de EDP-Auditor nummer 3 2005

Een audit op informatiearchitectuur: waar te beginnen? Stel dat je als IT-auditor gevraagd wordt om een oordeel te geven over de kwaliteit van een informatiearchitectuur. Wat dan? Wat is een informatiearchitectuur? Waar moet je op letten? Wat kun je doen?

Ruurd Smildiger

Dat die vraag een keer komt is niet ondenkbeeldig. Bedrijven en overheidsinstellingen moeten snel kunnen reageren op marktontwikkelingen en wijzigende weten regelgeving. De aanpasbaarheid van de achterliggende systemen blijkt dan vaak beperkt te zijn en gaat met grote inspanningen, dus kosten, gepaard. Terwijl het management juist de noodzaak ervaart dat systemen snel en tegen relatief lage kosten aangepast zouden moeten kunnen worden. Dit stelt eisen aan het systeemontwerp. Vergelijk het maar met het ontwerpen van een huis. Als je de wens hebt om in de toekomst van het dak een dakterras te maken, zul je bij het ontwerp van de dakconstructie en het bepalen van de locatie van een raam (dat later een deur kan worden) al rekening moeten houden met het dakterras. Dat is flexibiliteit inbouwen. Een ander voorbeeld is dat een architect zoekt naar eenvoudige oplossingen indien hij een huis ontwerpt dat meerdere malen gebouwd moet gaan worden en relatief snel en gemakkelijk te bouwen moet zijn. Hij zoekt naar reductie van complexiteit in zijn oplossingen. In de praktijk zijn voor dit soort wensen bij systeemontwerp grofweg twee mogelijke strategieën: 1. Systemen kunnen zodanig worden ontworpen dat ze niet of weinig aangepast hoeven te worden. Dit betekent de realisatie van generieke systemen met een groot aantal parameters. Met deze parameters kan het

R. Smildiger is werkzaam bij de Auditdienst van het ministerie van Onderwijs, Cultuur en Wetenschap in de functie van auditor. Sinds 1995 is hij werkzaam als IT-auditor.

systeem worden ingesteld op een groot aantal specifieke situaties. Veranderen de omstandigheden, dan worden de parameters in overeenstemming daarmee aangepast. Denk hierbij aan de ERP-systemen. 2. Systemen kunnen zodanig worden ontworpen dat aanpassingen snel en tegen relatief lage kosten worden aangebracht. Deze wens van systeemontwerp heeft geleid tot de architectuurgedachte en de ontwikkeling van informatiearchitecturen. Over deze laatste strategie gaat dit artikel. Onder de kop ‘Maar wat is nu architectuur?’ zal ik een schets geven van wat informatiearchitectuur kenmerkt. In de paragraaf ‘Alignment’ leg ik uit wat wellicht de belangrijkste schakel is om een architectuurproject te doen slagen: communicatie met het management. Daarbij wordt de koppeling gelegd met de mogelijke doeleinden van een informatiearchitectuur, namelijk een offensieve of defensieve toepassing. Daarna wordt beschreven hoe een project van informatiearchitectuur past in een systeemontwikkelingsproject. In de paragraaf daarna volgen de aandachtspunten die – naast de communicatie – van belang zijn voor het doen slagen van de implementatie van de informatiearchitectuur. Dit betreffen procesmatige aspecten. Om een informatiearchitectuur te kunnen beoordelen volgen drie modellen die een hulpmiddel daarbij kunnen zijn. Tot slot is een door mijzelf ontwikkeld normenstelsel opgenomen om de kwaliteit van een informatiearchitectuur te kunnen onderzoeken en die ook specifieke normen bevat voor een project waarin informatiearchitectuur wordt ontwikkeld. Voor het toetsen aan die normen kan één of meer van de modellen worden gebruikt.

9

10


Maar wat is nu architectuur? Als over een architectuur wordt gesproken, wordt vaak meteen gedacht aan een ontwerp van gebouwen. Dit sluit ook aan op de definitie van architectuur die in de ‘Dikke van Dale’ te vinden is, namelijk: Bouwkunst, de kunst en de leer van het ontwerpen en uitvoeren van bouwwerken. Is een informatiearchitectuur ook een kunst en leer van het ontwerpen en uitvoeren van een informatiebouwwerk? Het Genootschap van Informatie Architecten (GIA) hanteert de volgende definitie van informatiearchitectuur: Een Informatie Architectuur is de architectuur van de informatiehuishouding van een organisatie. In deze definitie – tot stand gekomen na een brede discussie met vakgenoten – valt op dat er gesproken wordt over informatiehuishouding in plaats van de vaker gebruikte term informatievoorziening. Dit suggereert dat informatie een resultante is van een breder geheel binnen een organisatie dan de afdelingen die direct betrokken zijn bij de informatieverschaffing. Er is inderdaad sprake van een informatiebouwwerk en de hier gestelde vraag kan dus met ‘ja’ worden beantwoord. Kenmerken van architectuur Een informatiearchitectuur heeft een vijftal definiërende kenmerken. Deze kenmerken zijn een vertaling van de kenmerken die [SAND97] heeft gegeven aan architectuur. Een eerste kenmerk van architectuur is dat deze de structuur van het object beschrijft. Als er sprake is van een informatiearchitectuur wil dit zeggen dat dit het ontwerp van de informatiehuishouding van een organisatie (conform de definitie van het GIA) beschrijft. Dat wil zeggen, beschrijft • uit welke componenten de informatiehuishouding van het betrokken bedrijf(sonderdeel) is samengesteld; • wat hun functie is, welke bijdrage ze elk leveren aan de bedrijfsuitoefening; • welke bijdrage ze elk leveren aan de realisatie van de doelstellingen uit het beleid; • hoe de componenten samenhangen. Als tweede kenmerk is genoemd dat architectuur het instrument is om de kwaliteit van het geheel te sturen. Kijkend naar informatiearchitectuur wil dit zeggen dat de informatiearchitectuur een instrument is voor het sturen van de kwaliteit van de informatiehuishouding als geheel. Hiermee wordt bedoeld de mate waarin de informatiehuishouding de bedrijfsuitoefening ondersteunt en flexi-

bel is. Voor de informatiearchitectuur betekent sturen van de kwaliteit in de eerste plaats dat er een duidelijke en zo eenduidig mogelijke relatie is tussen de doelstellingen van het bedrijf en de informatiecomponenten die aan de realisatie ervan een bijdrage leveren. Ten slotte betekent sturen van de kwaliteit van het geheel: suboptimalisatie tegengaan. Naast een duidelijke afbakening van de informatiecomponenten is daarom een goede onderlinge aansluiting van belang. Met andere woorden: binnen de informatiehuishouding zijn geen overlappen ten behoeve van de informatievoorziening en er zijn geen witte vlekken. Het derde kenmerk van architectuur is dat ze uitdrukking dient te geven aan een visie. Daarbij gaat het bij de informatiearchitectuur om de visie die het bedrijfsmanagement heeft op zijn bedrijfsuitoefening en de verbetering van de bedrijfsresultaten. Deze visie dient het uitgangspunt te zijn bij het ontwerpen van de informatiearchitectuur. De concretisering ervan is meestal verwoord in het informatiebeleid. Het informatiebeleid beschrijft op hoofdlijnen de gewenste bijdrage van de informatiehuishouding aan het realiseren van het bedrijfsbeleid. Naast een goede aansluiting op het bedrijfsbeleid betekent dit ook de mogelijkheid snel in nieuwe informatiebehoeften te voorzien, zonder daarbij steeds grote delen van de informatiehuishouding te moeten vervangen. Als vierde kenmerk van architectuur is genoemd dat ze resultaat is van onderhandeling. Een informatiearchitect krijgt te maken met veel partijen, eisen en belangen. Deze eis heeft meer betrekking op de wijze waarop de architectuur tot stand komt, dan op de inhoud ervan. Het ontwerpproces moet je zodanig organiseren, dat alle belanghebbende partijen tijdig betrokken worden. Als partijen te laat betrokken worden, hebben ze geen mogelijkheid meer zelf een bijdrage te leveren aan de oplossing. Het risico is dat het commitment voor het resultaat gering zal zijn. Daarnaast is het ook noodzakelijk dat de verschillende eisen met elkaar in overeenstemming zijn gebracht en zichtbaar en helder geformuleerd in het ontwerp zijn verwerkt. Een architectuur beschrijft niet alleen de structuur en de opbouw van het object zelf, maar ook de ontwikkeling en de bouw ervan. Het vijfde kenmerk is dat de informatiearchitectuur een scharnier is tussen ‘wensen’ en ‘doen’. Voor de informatiearchitectuur betekent dit kenmerk dat het een scharnierfunctie dient te vervullen tussen het bedrijfs- en het informatiebeleid enerzijds en de systeemontwikkeling anderzijds. Dit betekent dat je zowel de strategische wenselijkheid van de informatiearchitectuur als de technische en projectmatige uitvoerbaarheid ervan moet vaststellen.


De onderdelen van informatiearchitectuur en hun doel De informatiearchitectuur kan worden opgedeeld in een aantal specifieke onderdelen [VREV94] die allemaal hun eigen functie hebben. De informatiearchitectuur bestaat uit een applicatiearchitectuur, een gegevensarchitectuur en een technische infrastructuur. Applicatiearchitectuur (ook wel informatiesystemen- of toepassingenarchitectuur) bestaat uit het definiëren van delen van systeemfunctionaliteit zodanig dat een deel bij meerdere systemen kan worden gebruikt. Waarom het wiel opnieuw uitvinden, als een functionaliteit een standaard is. Een voorbeeld hiervan is de functionaliteit om de printer aan te sturen. Het doel van een applicatiearchitectuur is verhoging van de efficiency van de systeemontwikkeling. Gegevensarchitectuur bestaat uit het definiëren van gegevens op een wijze dat een gegeven door verschillende systemen kan worden gebruikt. Neem bijvoorbeeld het definiëren van het gegeven ‘persoon’. Definitievragen die aan de orde komen zijn: Nemen we alleen natuurlijke personen op? Welke set van gegevens hoort tot ’persoon’? Hoe worden voorvoegsels verwerkt? Et cetera. Het doel van een gegevensarchitectuur is het gemeenschappelijk gebruik van gegevens door de informatiesystemen.

bedrijfsstrategie (alignment). De auditor zal bij een audit aan dit punt expliciet aandacht geven. In het normenstelsel dat in dit artikel is opgenomen is er sprake van slechts één norm op dit punt, namelijk ‘wordt bij aanvang van het modelleren van de architectuur rekening gehouden met de bedrijfsstrategie?’ Boer & Croon hebben hiervoor een denkmodel ontwikkeld. Het denkmodel werkt als een communicatiemiddel naar het topmanagement. Het legt namelijk de relatie tussen een informatiearchitectuur en met voor het topmanagement bekende elementen als strategie en organisatie. De boodschap voor het topmanagement is: Architectuur lijnt strategie, organisatie en ICT uit. Het model laat ook zien dat er sprake is van elkaar beïnvloedende entiteiten. Een veranderende strategie raakt de organisatie en de ICT. Architectuur helpt om dat inzichtelijk te maken en daardoor veranderingen te vergemakkelijken. Het denkmodel van Boer & Croon onderscheidt een offensieve én een defensieve toepassing van architectuur. Dit denkmodel kan worden gebruikt als hulpmiddel door degene die informatiearchitectuur als onderwerp met het topmanagement gaat bespreken. Voor de auditor kan het ook een hulpmiddel zijn bij zijn onderzoek. De begrippen offensieve en defensieve toepassing van architectuur worden hierna toegelicht.

Technische architectuur bestaat uit: • de databasearchitectuur – dit heeft te maken met de technische inrichting van de databases; • de apparatuurarchitectuur – dit heeft te maken met de technologie waarmee de systemen draaien; • de communicatiearchitectuur – dit heeft te maken met de wijze waarop systemen met elkaar en met de gebruikers kunnen communiceren.

Strategie

Alignment In de inleiding is geschetst dat managers de noodzaak ervaren dat systemen flexibel zijn en snel en tegen relatief geringe kosten kunnen worden aangepast. Losjesweg heb ik geconcludeerd dat dit eisen stelt aan het systeemontwerp en daardoor zelfs aan de informatiearchitectuur. Maar hoe komt het belang van een informatiearchitectuur voor het voetlicht van het topmanagement? Hierbij gaat het erom dat de ICT-manager duidelijk kan maken dat de informatiearchitectuur ondersteunend dient te zijn aan de

- Ambitie

Architectuur - Structuur

- Uitgangspunten - Mogelijkheden

Doel is het verbeteren van de toepasbaarheid en het verhogen van de flexibiliteit van het gebruik van de systemen. De technische architectuur wordt in dit artikel niet verder uitgewerkt.

11

- Huidige infra

- Regels ICT

- Afspraken

Organisatie

- Cultuur (normen, waarden, gewoonten) - Autonomie - Verandering

Figuur 1. Denkmodel volgens Boer & Croon Offensieve toepassing van architectuur Het topmanagement is vooral geïnteresseerd in de wijze waarop de bedrijfsstrategie kan worden behaald en hoe de informatiearchitectuur daarbij ondersteunend kan zijn. In het maken van de strategische keuzes dienen afwegingen te worden gemaakt die alleen het topmanagement kan maken. De informatiearchitectuur zal van deze keuzes dienen te worden afgeleid. Het topmanagement zal de consequenties van haar keuzes voor de informatiearchitectuur moeten kennen. Dit klinkt misschien wat abstract. Daarom volgen enkele

12


voorbeelden van strategische keuzes die van invloed zijn op de architectuur van de (toekomstige) systemen om het te verduidelijken: • Een onderneming wil enerzijds sterk groeien (omzetverdubbeling binnen drie jaar) door middel van acquisities en anderzijds ICT standaardiseren. Rijmt dit? • Een onderneming wil binnen drie jaar 90% van haar inkopen via het internet doen. Een vergeten vraag hier is: Waar leg je de verantwoordelijkheid voor het datamanagement van de grondstofgegevens? Bij de leveranciers of intern in de eigen organisatie? • Een onderneming wil de huidige situatie van lokale autonomie handhaven, maar wil tevens iets aan eBusiness doen. Er moet wel één gezicht naar buiten worden getoond. Hoe doe je dat? • ICT heeft de tendens te centraliseren, mede ingegeven door kostenoverwegingen. Past dit wel in de cultuur van de onderneming? Wat leg je dan centraal (synergievoordeel) en wat decentraal? Het aansluiten bij specifieke thema’s die leven bij het topmanagement is essentieel. De informatiearchitect communiceert erover hoe de informatiearchitectuur een rol speelt in deze thema’s. Hij laat zien hoe de architectuur ondersteunend is aan de strategische wensen van het management, maar misschien ook dat bepaalde strategische wensen met elkaar conflicteren. De conclusie luidt dat de informatiearchitect in de communicatie met het topmanagement over informatiearchitectuur veel aandacht zal moeten besteden aan de relatie met strategie en organisatie. Het aangeven van deze relatie is nodig om architectuur bij het topmanagement op de kaart te zetten. Defensieve toepassing van architectuur Het tweede motief om een informatiearchitectuur te ontwikkelen is de behoefte aan beheersing van (de gevolgen van) de complexiteit van de IT. Dit beheersingsprobleem wordt veroorzaakt door de veelvormigheid en omvang van de voorzieningen, maar ook door grote dynamiek in het aanbod. De belangrijkste missie bij de uitvoering van architectuur is die van richting geven aan en faciliteren van de ontwikkeling van de informatiehuishouding en van informatiesystemen. Om de complexiteit het hoofd te bieden moet de ICT-discipline op verschillende manieren de complexiteit te lijf. In de hele keten van het interne IT-bedrijf moet een proces op gang worden gebracht om de complexiteit te beperken en te beheersen. Dit begint met een bewustwording en een juiste perceptie van het probleem dat complexiteit met

zich meebrengt en als eerste moeten strategieën worden ontwikkeld, waarmee de complexiteit kan worden aangepakt. Deze strategieën kunnen zijn [HAMM98]: • het voorkomen van onnodige complexiteit; • het reduceren van de complexiteit van het bestaande en het nieuwe; • het toegankelijk maken van complexe concepten en de kennis/informatie over IT-voorzieningen; • het communiceren van de complexiteit om het bewustzijn daarvan te creëren. Het doel hiervan is bij te dragen aan de besluitvorming en realistische verwachtingen te scheppen. Hiermee is de ’defensieve’ rol van de informatiearchitectuur bepaald. De beperking van risico’s, veroudering, redundantie en ondoorzichtigheid zijn overheersend. De missie van de IT-functie in het bedrijf is om uit het aanbod aan IT-middelen en diensten op de langere termijn een stabiele, state-of-the-art, waardevaste, veilige, transparante, betrouwbare, schaalbare, koppelbare en ook nog kosteneffectieve structuur te bouwen. Voorwaar een ambitieuze doelstelling! Nadat de behoefte aan beheersing heeft geleid tot het organiseren van een alignmentfunctie en een architectuurdiscipline ontstaan concepten, richtlijnen en afspraken op hoog niveau over oplossingen, verantwoordelijkheden en processen. In een bewust uitgevoerd alignmentproces worden innovaties ontwikkeld en gestuurd vanuit een visie op de gewenste inrichting van de informatievoorziening, die via architectuurprocessen is uitgewerkt. Het bedrijfsmanagement is hierbij sterk betrokken.

Ontwikkeling informatie architectuur

Business eisen (High level) systeemeisen (High level) performance eisen

Systeemontwerp Componenten en services Interfaceontwerp Productkeuzen Ontwerprichtlijnen Ontwerpbeslissingen

Stakeholders

Systeem

Systeemontwikkeling

Organisatie Personeel Procedures

Figuur 2. Informatiearchitectuur in zijn context


Architectuur- vs. systeemontwikkeling Zoals uit figuur 2 blijkt, liggen de ontwikkeling van een informatiearchitectuur en van een systeem in elkaars verlengde. De informatiearchitectuur vormt immers de basis voor het te ontwikkelen systeem en uiteindelijk voor meerdere systemen. De ontwikkeling van een systeem zal aansluiting moeten vinden op de informatiearchitectuur. En deze aansluiting verloopt niet altijd even vlekkeloos. Er zijn enkele aandachtspunten die hierbij een rol spelen. Deze aandachtspunten zijn voortgekomen uit eigen ervaring bij een groot architectuurproject – dat helaas mislukt is – en strookt met ervaringen van anderen [DISS00]. Vervolgens doe ik enkele suggesties om de genoemde aandachtspunten te kunnen hanteren. Aandachtspunten Gescheiden projecten Het realiseren van een informatiearchitectuur en de systeemontwikkeling worden vaak in verschillende projecten uitgevoerd of zijn verschillende fases in één project. Dit kan een aantal complicaties tot gevolg hebben: • De mensen die aan de informatiearchitectuur gewerkt hebben zijn weg als er begonnen wordt met het systeemontwikkelingtraject. Voor een hedendaagse systeemontwikkelaar is het vaak belangrijk om te weten waarom bepaalde beslissingen genomen zijn. Om te vermijden dat beslissingen gedurende het ontwikkeltraject in twijfel worden getrokken (en dan ter discussie staan) en om commitment bij de systeemontwikkelaar te verhogen, is het belangrijk dat men inzicht krijgt in het hoe en waarom van beslissingen. • Het is lastig, zo niet onmogelijk, om een informatiearchitectuur neer te zetten die genoeg diepgang en detail heeft zonder de systeemarchitectuur of cruciale delen ervan te testen of te prototypen. Vaak blijkt, dat om uiteenlopende redenen een ontwerpbeslissing niet juist is geweest. Daarbij komt, dat bij de informatiearchitectuur meestal wordt uitgegaan van een ideale situatie en afwijkingen hierop meestal zijn ingegeven door de omstandigheden van de niet ideale praktijk. De architectuur wordt immers pas daadwerkelijk getest in de ontwikkelen uitrolfase. Miscommunicatie De communicatie tussen architecten en ontwikkelaars verloopt niet altijd even vlekkeloos als er al van communicatie sprake is. Miscommunicatie speelt zich af op een aantal vlakken en heeft verschillende oorzaken: • Het gebruik van verschillende methoden en technieken die niet op elkaar aansluiten is niet bevorderlijk voor de overgang van informatiearchitectuur naar systeemont-

wikkeling. De meeste tools zijn niet in staat om alle facetten van architectuur en ontwikkeling af te dekken. Als er verschillende tools worden gebruikt, kijk dan of ze onderling interoperabel te maken zijn. Ook de introductie van een ‘nieuwe’ manier van systeemontwikkeling legt een extra druk op de informatiearchitectuur. • Begrippen en definities worden door de twee disciplines vaak verschillend geïnterpreteerd. Mismatch van producten Architectuur is een relatief jonge loot aan de ICT-boom. Over de definitie van architectuur is nog geen overeenstemming binnen de ICT-gemeenschap. Laat staan over producten die de architectuur op zou moeten leveren aan de systeemontwikkeling. Het risico is aanwezig dat het eindproduct van de architectuur niet als startpunt van de ontwikkeling van het beoogde systeem kan dienen. De architectuur heeft niet de mate van detail waarmee richting kan worden gegeven aan de systeemontwikkeling. Dit is funest als de ontwikkeling van een informatiearchitectuur en de ontwikkeling van een systeem in de tijd gescheiden projecten zijn. Gebruikers zijn niet betrokken Het risico is aanwezig dat gebruikers niet bij het architectuurproject betrokken worden. Voor de gebruikers is een architectuur begrijpelijkerwijs abstract. De architectuur is in het eindresultaat, de applicatie, transparant. Toch is de inbreng vanuit de gebruikersorganisatie belangrijk. Waarom? De feitelijke kennis over een (toekomstig) systeem zit bij de gebruiker. Hij zal in deze fase al input moeten leveren op het gebied van de gewenste functionaliteit en de benodigde gegevens. In deze fase wordt echter nog geen functioneel ontwerp gemaakt. Toch is kennis over de functionaliteit en gegevens nodig. Met deze kennis zal gezocht moeten worden naar gemeenschappelijke functionaliteit en gegevensgebruik. Suggesties Hier volgen suggesties in verband met de aandachtspunten die hiervoor zijn genoemd. Continuïteit Het probleem van verschillende projecten of gescheiden trajecten kan eenvoudig worden opgelost door ervoor te zorgen dat enkele personen die geparticipeerd hebben in het architectuurtraject beschikbaar zijn tijdens de realisatiefase. Beter nog is het om een aantal personen vanuit de realisatiefase te laten participeren in de architectuurfase. Het spreekt voor zich dat dit geen lichtgewicht ontwikkelaars zullen zijn.

13

14


Architectuur en ontwikkeling parallel Een gedeelte van de architectuur kan parallel worden uitgevoerd met het ontwikkeltraject van het systeem (de realisatiefase). Een parallel traject kan om verschillende redenen worden uitgevoerd: • testen van concepten in de systeemarchitectuur; • validatie bij de gebruikersorganisatie; • aansluiting bij incrementele ontwikkeling; • migratie van een bestaand systeem waarbij delen in de tijd vervangen worden. Spreek dezelfde taal en begrijp elkaar • Dit is vooral van toepassing op de fase van de architectuur die het dichtst bij systeemontwikkeling ligt. De ervaring is dat een optimale situatie verkregen wordt als een systeemarchitect ruime ontwikkelervaring heeft en dat ontwikkelaars vertrouwd zijn met methoden die in de systeemarchitectuur gebruikt worden. Dit laatste kan bijvoorbeeld worden bereikt in de vorm van een introductiecursus. • Op het gebied van methoden en tools kan worden gekeken naar tools die op elkaar aansluiten. • Spreek heel goed af wat het bereik van de architectuur is en wat het bereik van systeemontwikkeling is. • Werk samen. Een architect dient samen te werken met het gehele projectteam. Dit is zeker belangrijk in de fase van de architectuur die het dichtst bij de systeemontwikkeling ligt. Op deze manier wordt er commitment verkregen van de systeemontwikkelaars. Immers, ze werken beiden aan hetzelfde doel. Betrek de gebruikersorganisatie er vroegtijdig bij Zorg voor gebruikers die vrijgemaakt zijn om het architectuurproject te participeren. Zorg er dan ook voor dat in voor gebruikers begrijpelijke taal het doel en de functie van een architectuur wordt uitgelegd. De keuze voor wie in een dergelijk project kan participeren, zal niet altijd eenvoudig zijn. Het zullen gebruikers moeten zijn met veel kennis over de applicaties en met affiniteit voor automatisering. In een organisatie zijn dit al vaak de medewerkers waar zwaar op wordt gesteund. Al met al zijn dit geen vernieuwende suggesties. Toch blijkt in de praktijk dat ze weerbarstig genoeg zijn. Het is raadzaam om ook over deze eenvoudige tips van te voren na te denken en er een oplossing voor te vinden.

tuur kan worden getoetst. Het hoofdstuk wordt afgesloten met een conclusie. Aan het eind van het artikel heb ik een normenset geformuleerd dat als hulpmiddel kan worden gebruikt. Wat is kwaliteit? In studierapport nummer 2 van de NOREA getiteld ’Een kwaliteitsmodel voor Register EDP-auditors’ wordt gezegd: ’kwaliteit is nooit een incident, het is altijd het resultaat van een intelligente samenwerking’. [NORE97] Deze definitie geeft aan waar het om gaat bij kwaliteit. Kwaliteit is geen incident, als zou het om een toevalligheid gaan. Kwaliteit is iets wat doelbewust moet worden nagestreefd. Kwaliteit is het resultaat van samenwerking. Ook bij het maken van een informatiearchitectuur gaat het om een nauwe samenwerking tussen de verschillende stakeholders. In de definitie is sprake van ’intelligente’ samenwerking. Dit betekent in de context van architectuur dat bij het maken van een architectuur rekening wordt gehouden met de (interne) omgevingsfactoren, het creëren van draagvlak en het verzorgen van een goede communicatie. Dit alles is al aan de orde gekomen. De kwaliteit van een informatiearchitectuur kan als volgt worden gedefinieerd: De kwaliteit van een informatiearchitectuur is het vermogen van een architectuur de niet-functionele eisen aan de te bouwen systemen te ondersteunen. Wanneer is een architectuur goed? Of anders gezegd wanneer is een architectuur goed genoeg? In deze context is ‘goed’ een betrekkelijk begrip, want om een architectuur te kunnen beoordelen, moeten we eerst de criteria vaststellen op basis waarvan we dat kunnen doen. Deze criteria zijn namelijk sterk afhankelijk van het doel wat met de architectuur wordt beoogd. Op basis van het doel kunnen de bijbehorende criteria en normering worden gedefinieerd waarop de resultaten worden beoordeeld. Door verschillende partijen zijn methodieken ontwikkeld om de validatie van de architectuur uit te voeren. In dit hoofdstuk zullen deze hulpmiddelen de revue passeren. Dit zijn achtereenvolgens: • Architecture Score Card van Cap Gemini; • architectuurreview van het Software Engineering Research Centre; • de architectuurbenadering van ATOS Origin.

Kwaliteit van architectuur Hoe kun je als auditor de kwaliteit van een architectuur toetsen? In dit hoofdstuk worden drie verschillende hulpmiddelen besproken waarmee de kwaliteit van architec-

Architecture Score Card™ De Architecture Score Card [ARCH00] is gebaseerd op een methodologische benadering van de verschillende architectuurproducten die voortkomen uit verschillende


Figuur 3. Relatie tussen architectuurgezichtspunten, aspectgebieden en abstractieniveaus architectuurprocesstappen. Op basis van een vooraf gedefinieerde normering voor alle architectuuraspectgebieden kan eenvoudig worden vastgesteld of de architectuurproducten aan de criteria voldoen. Alvorens in te gaan op de nadere details van de Architecture Score Card is het goed om de belangrijkste processtappen die hierbij worden gehanteerd te leren kennen. Cap Gemini heeft de aspectgebieden en de abstractieniveaus binnen het geïntegreerde architectuur raamwerk (IAF), verder uitgewerkt in een aanpak – Cap Gemini’s Integrated Architectural Approach (IAA). In deze benadering worden naast de genoemde architectuuraspectgebieden de vijf procesfaseringen onderscheiden, die in de IAA-aanpak vaak overeenkomen met de vijf abstractieniveaus: • Contextuele fase: wat zijn de missie en doelen van de organisatie, hoe wenst de organisatie te functioneren in zijn omgeving en hoe ziet de omgeving van de organisatie eruit, wat is de omvang van het architectuurtraject? • Conceptuele fase: wat zijn de randvoorwaarden, uitgangspunten, eisen en beperkingen die betrekking hebben op het architectuurtraject en die worden gesteld aan de architectuur? Een conceptueel architecturaal ontwerp. • Logische fase: hoe kan de oplossing worden gerealiseerd, een logisch architecturaal ontwerp? • Fysieke fase: waarmee kan de oplossing worden gerealiseerd, een fysiek architecturaal ontwerp? • Transformatie fase: wanneer kan de oplossing worden geïmplementeerd en wat is de impact op de organisatie en de ICT-omgeving? De methodiek achter de Architecture Score Card maakt gebruik enerzijds van de architectuuraspectgebieden en anderzijds van de verschillende procesfaseringen. Op basis van deze benadering is een meetmethodiek ontwikkeld die inzicht geeft in en overzicht geeft van de kwaliteit van een te beoordelen architectuur. Op basis van vragen over de aspectgebieden en de procesfasen wordt vastgesteld in welke mate de architectuur aan een aantal

criteria voldoet. Hierdoor kan een goed inzicht en overzicht worden verkregen van de kwaliteit van een architectuur. Specifiek wordt door de leverancier van het tool aandacht gevraagd voor de onderhoudbaarheid van de architectuur. Van belang daarbij is of de resultaten van de architectuurstudie op een zodanige manier zijn gedocumenteerd dat deze ook op de langere termijn onderhoudbaar zijn, ook door andere architecten dan de oorspronkelijke architecten. Het element van onderhoudbaarheid dient dan ook in de overall-beoordeling te worden meegenomen. Architectuurreview door het SERC Een tweede benadering is die van het Software Engineering Research Centre (SERC) [ZEIS96]. Door hen is een aanpak van architectuurreview ontwikkeld. Deze aanpak gaat uit van het toetsen van een architectuur aan de kwaliteitsattributen uit het Quint2/Extended ISO 9126 model. Het is de verantwoordelijkheid van de softwarearchitectuur om richting en (gedeeltelijke) invulling te geven aan de kwaliteitseisen die worden gesteld aan een systeem. Het SERC hanteert de Engelse terminologie. Afhankelijk van de bedrijfscultuur waar het model wordt toegepast, dienen de termen te worden overgezet naar de Nederlandse taal. De specifieke aanpak van een architectuurreview is erg afhankelijk van de situatie. Een belangrijke factor hierbij is het doel van de architectuurreview. De nadruk kan liggen op: • het bepalen van de kwaliteitseisen die aan een architectuur in ontwikkeling worden gesteld; • het bepalen van de kwaliteit van een architectuur en de bijbehorende artefacten; • het bepalen van de impact van wijzigingen op een architectuur. Om deze doelen te verwezenlijken kan een aantal middelen worden ingezet zoals workshops, interviews, productstudies en experimenten.

15

16


Functionality

Maintainability

Usability

Reliability

Portability

Suitability

Analyzability

Understandability

Maturity

Adaptability

Time-behavior

Accuracy

Changeability

Learn ability

Fault

Installability

Resource behavior

Interoperability

Stability

Operability

Tolerance

Conformance

Compliance

Testability

Explicitness

Recoverability

Replaceability

Security

Manageability

Customizability

Availability

Traceability

Reusability

Attractiveness

Degradability

Efficiency

Clarity Helpfulness

Figuur 4. Kwaliteitsattributen in het Quint2/Extended ISO 9126 model Een workshop heeft tot doel de (kwaliteits)eisen die aan het systeem worden gesteld in kaart te brengen en dient daarom te worden bijgewoond door alle bij het systeem betrokken partijen/stakeholders. Een workshop kan ook worden gebruikt om toekomstige wijzigingsscenario’s te bepalen. Interviews worden gebruikt om het beeld van de verschillende partijen van de architectuur te bepalen en om de te toetsen eigenschappen van de architectuur in kaart te brengen. Het voordeel van interviews is dat betrokkenen sneller geneigd zijn hun opinie over het systeem te geven. Het doel van een productstudie is om de kwaliteit van de architectuur en de bijbehorende documenten en producten te bepalen. Experimenten en prototypes kunnen de haalbaarheid van oplossingsrichtingen toetsen. Ook kunnen experimenten en prototypes worden gebruikt om belangrijke verbeteringen in bestaande knelpunten te demonstreren. De architectuurbenadering van ATOS Origin De derde benadering is de architectuurbenadering van ATOS Origin [POST]. In feite is deze benadering ook een review op de architectuur die wordt uitgevoerd door consultant/architecten. Toch kan ik mij voorstellen dat er ook een beroep wordt gedaan op een IT-auditor omdat hij een onafhankelijke partij is. De werkwijze is interessant genoeg om in dit artikel op te nemen. De uitvoering van deze methode kan als eventueel advies worden gegeven of de IT-auditor kan de onafhankelijke rol die in deze benadering wordt genoemd, op zich nemen. De methodiek benadert de vraag waarom de relatie tussen de niet-functionele eisen en een architectuur zo lastig te bepalen is met de invalshoek van organisatieverandering. Een succesvolle organisatieverandering stoelt op drie pijlers, namelijk techniek, politiek en cultuur. Vanuit technisch perspectief kan worden gezegd dat er inderdaad nog veel te leren is over de beïnvloeding van de niet-functionele eisen en de architectuur. Architectuur-

ontwikkeling lijkt nog teveel te worden gedaan op basis van intuïtie en ervaring van de architecten. Het speelt zich nog veel af in het hoofd van de architect en is nauwelijks objectief meetbaar. Tools en technieken voor architectuurassessments zijn nog niet verkrijgbaar. Architectuurbesluiten zijn vaak niet gedocumenteerd. Rond architectuur ontwikkelen zich ook ‘politieke’ invloeden. Dit is het logische gevolg van het feit dat een architectuur een strategisch belang heeft. Er zijn veel stakeholders bij betrokken terwijl een architectuur weinig zichtbaar is en vaak als abstract wordt ervaren. Er is een culturele beperking bij het leggen van een link tussen de niet-functionele eisen en de architectuur. Binnen organisaties is weinig bewustzijn voor de onderlinge relaties tussen afdelingen en werkzaamheden door de afdelingen. Iedere afdeling (marketing, productie, service, IT) ziet het maken van een architectuurproduct als niet transparant. Dit resulteert erin dat het (midden)management niet echt geïnteresseerd is in het definiëren van de nietfunctionele eisen. Doel van de architectuurbenadering is een systematische benadering van de architectuurmodellen waarbij de deelname van de stakeholders het uitgangspunt is. Doelstelling is de kwaliteit van de architectuur te bepalen en de mogelijkheden voor verbetering te identificeren. Kwaliteit is hierbij het vermogen van de architectuur in het realiseren van de niet-functionele eisen. Door het uitvoeren van het voorgestelde assessment in een vroeg stadium in het ontwikkelproject verkrijgt het management goed gedocumenteerd inzicht in de risico’s van de architectuur. Het moment dient zo gekozen te zijn dat correctieve acties tegen beperkte kosten mogelijk zijn. De basisfilosofie achter de assessment is een zelfevaluatie geleid door een externe partij. De architecten zelf en de andere stakeholders moeten de kwaliteit van de architectuurmodellen bepalen. De taak van de externe expert is


het assessment faciliteren. Zij vormen niet zelfstandig een oordeel over de architectuur; dit is alleen mogelijk met veel kennis van het applicatiedomein. Het assessment kent een aantal fasen. De volgende fases zijn te onderscheiden: Consensus over de eisen Identificeer de niet-functionele eisen en de prioriteiten door de stakeholders te interviewen. Deze interviewronde wordt gevolgd door een plenaire sessie met als doel consensus vast te stellen of te bereiken. De externe partij leidt de interviews en de plenaire sessie. De architecten spelen een meer passieve rol als geïnterviewden, net zoals de stakeholders van het management van marketing, productie, systeemontwikkeling, servicemanagement enzovoort. Analyse van de architectuur Dit is de fase waarin de architectuur wordt aangelegd tegen de niet-functionele eisen waarover het management het eens is. De architectuurbeslissingen worden geïdentificeerd en gerelateerd aan de eisen. Op deze manier kan worden bepaald in welke mate de architectuur de eisen ondersteunt. Dit wordt uitgevoerd door de architecten. Architectuurreview De resultaten uit de vorige fase worden gepresenteerd en bediscussieerd in één of meerdere plenaire sessies. Deze worden geleid door de externe partij. De sterke en zwakke elementen van de architectuur, risico’s en voorstellen van verbetering worden besproken. Dit is het belangrijkste onderdeel van het geheel. De resultaten van de interviews en de analyse komen hier samen, worden openlijk bediscussieerd en zal (moeten) leiden tot consensus over de kwaliteit van de architectuur en de eventuele uit te voeren verbeteringen. Rapportage De resultaten uit de vorige fase worden vastgelegd in een rapport. Dit rapport wordt gepresenteerd en wederom bediscussieerd in een plenaire sessie met daarin alle betrokkenen, inclusief het management. Deze fase wordt uitgevoerd door de externe partij. Hoe komt deze benadering tegemoet aan de eerder genoemde drie pijlers techniek, politiek en cultuur? De technische rationaliteit zal sterk worden vergroot door een systematische benadering op tafel te brengen die de nietfunctionele eisen expliciet en meer grijpbaar maken. Uiteindelijk worden ze allemaal bediscussieerd, gedefinieerd, gegroepeerd, geprioriteerd en toegekend in een open proces waarin veel experts hun zegje kunnen doen. Op deze manier worden veel van de overwegingen van de architecten die in

eerste instantie in hun hoofden zitten, gebaseerd op ervaring en intuïtie, expliciet voor alle andere betrokkenen gemaakt. Politieke tegenstand is een onderdeel van een bedrijf en kan zich sterk laten gelden rond architectuurproducten. Welke systematische benadering er ook is, dit is moeilijk te bestrijden. Als mensen niet willen participeren in een open discussie is het moeilijk hen aan tafel te krijgen. Desalniettemin, zaken zijn meestal niet zwart of wit. Het gebruik van een systematische benadering, maar ook de aanwezigheid van een externe partij kan helpen de spanning te reduceren. Het wordt moeilijker voor mensen de discussies te domineren of zelfs te manipuleren. Dit kan anderen weer aanmoedigen vrijer te spreken. Achterkamertjesgeregel en misbruik van macht zullen moeilijker zijn in dit proces. Voor het culturele perspectief is het duidelijk dat deze benadering leidt tot een toegenomen besef van de belangrijkheid van goede architectuurproducten. Zowel het management als de architecten raken betrokken in dit proces en zullen veel kunnen leren over de architectuur. Mensen krijgen een open uitnodiging om deel te nemen in de discussies en bij te dragen aan nieuwe ideeën. Conclusie bij deze drie methoden De Architecture Score Card geeft inzicht in de verbindingen tussen strategie en uitvoering enerzijds en de verschillende aspectgebieden anderzijds. De architectuurreview van het SERC is gericht op de eisen waaraan een informatiearchitectuur moet voldoen. De architectuurbenadering van ATOS Origin voegt daaraan toe de actieve participatie van stakeholders. Iedere van de genoemde methoden heeft zijn eigen invalshoek en zo vullen ze elkaar aan. De architectuurbenadering van ATOS Origin sprak mij aan. Hij lijkt op de knelpuntenanalyse projectmanagement zoals die in het handboek EDP-Auditing staat beschreven [SWIN]. In de praktijk heb ik daar zeer positieve ervaringen mee opgedaan. Met een relatief kleine investering komen de sterke en zwakke punten van het projectmanagement duidelijk naar voren. Projectmanagement is geen architectuur. Maar ook bij projectmanagement spelen cultuur en politiek een belangrijke rol. Ervaring en intuïtie van de projectleider vormen ook nog wel eens de basis voor de genomen besluiten. Door deze overeenkomsten verwacht ik dat deze architectuurbenadering goede resultaten kan opleveren.

Normen Normen voor het informatiearchitectuurproduct 1. Opdrachtgever en -nemer hebben overeenstemming over de ‘eisen aan de architectuur’, uit te splitsen naar: • afbakening van het systeem, van het ‘object’ van de architectuur.

17

18


Voorbeelden zijn: - alle processen, informatie-items, actoren en technologie-items gerelateerd aan de afdeling ‘Marketing & Sales’; - alle processen, informatie-items en actoren ondersteund door de softwareapplicaties die onder UNIX draaien; - alle processen, actoren en technologie gerelateerd aan klantinformatie; - de eisen aan dat systeem; - de wijze van beschrijving van het systeem en van de eisen daaraan. 2. De opdrachtgever dient aan te geven welke eisen aan dat systeem in de architectuur dienen terug te komen. De kwaliteitseisen in het model van het SERC kunnen hierbij een hulpmiddel zijn. Er zullen ook investeringseisen zijn, zoals: • kosten: eisen aan de kosten van het maken, onderhouden en exploiteren van het systeem; • baten: eisen aan de baten van het maken, onderhouden en exploiteren van het systeem; • risico’s: eisen ten aanzien van de getolereerde risico’s voor en als gevolg van het maken, onderhouden en exploiteren van het systeem. 3. De architectuur moet laten zien binnen welke eisen en randvoorwaarden ontwerpbeslissingen kunnen worden genomen. 4. Specifiek voor de gegevensarchitectuur: • Standaardisering van de betekenis van gegevens, dat wil zeggen ontdoen van de willekeur van de specifieke situatie. Het doel van de betekenisstandaardisatie is het verkrijgen van een ondubbelzinnige en uniforme betekenis van de bedrijfsgegevens. Het gebruik van gegevens voor meer doeleinden vereist een uniform gedefinieerde betekenis, dit wil zeggen ongeacht: - de representatievorm op media; - het gebruik; - het toepassingssysteem dat het betreft; - de organisatorische eenheden die de gegevens gebruiken of beheren. • Standaardisering van de vorm. Deze vormstandaards hebben betrekking op: - de schrijfwijze en maximale lengte van gegevenselementen; - de externe representatie van de gegevens. Dit leidt tot de keuze van codestelsels (bijvoorbeeld de ISOmuntcode). De interne representatie hoeft niet uniform te zijn. Gemeenschappelijk gebruik impliceert wel éénmaal waarnemen, verzamelen en registreren, maar niet noodzakelijk éénmaal opslaan; - de gewenste kwaliteit van de gegevens. Daarbij gaat het om de volgende aspecten:

Δ de juistheid en betrouwbaarheid; Δ de volledigheid van de gegevensverzameling; Δ de actualiteit. Hieronder wordt verstaan de tijd die verstrijkt tussen het plaatsvinden van een relevant feit en het moment waarop dat leidt tot een wijziging in de administratie; Δ de toegankelijkheid. • Koppel belang en verantwoordelijkheid = definieer, structureer en verzamel alleen gegevens die ook daadwerkelijk gebruikt gaan worden, zodat in het gebruik een gebrek aan kwaliteit tijdig kan worden opgemerkt. Leg de verantwoordelijkheid voor de gegevens en de gegevensbeschrijvingen bij degene die het grootste belang heeft bij de kwaliteit ervan. In geval van gemeenschappelijk gebruik van gegevens leg je de bevoegdheid en verantwoordelijkheid van de gegevens zoveel mogelijk bij degene die de hoogste eisen stelt aan de kwaliteit van de gegevens. • Gegevensbeheersystemen dienen een zodanige structuur te hebben dat ze gemakkelijk uit te breiden zijn. Een groeiscenario ligt hieraan ten grondslag. Zodra een nieuw applicatiesysteem ontwikkeld wordt, leidt dit zonodig tot aanpassingen en tot uitbreiding van de standaards. • Maak voor de juistheid van elk gegeven precies één organisatorische functie of eenheid verantwoordelijk. Dit is de functionele beheerder. De functionele beheerder is de enige die gemachtigd is een gegeven op te voeren, te wijzigen of te verwijderen. Bij toewijzing van het functioneel beheer gelden de volgende richtlijnen: - voor resultaatgegevens is degene verantwoordelijk, die het resultaat, waarop het gegeven betrekking heeft, tot stand brengt; - voor gegevens die afkomstig zijn uit de omgeving is degene verantwoordelijk voor wie vooral de kwaliteitseisen met betrekking tot actualiteit en volledigheid van het grootste belang zijn, ofwel degene die het gegeven als eerste nodig heeft. Een alternatief is de verantwoordelijkheid leggen bij degene die het grootste belang heeft bij de juistheid van het gegeven. Ook combinaties van beide zijn mogelijk. 5. Specifiek voor de gegevensarchitectuur De functionaliteit van een te bouwen architectuur dient volgens de volgende afbakeningscriteria opgedeeld te zijn: • relatieve autonomie: dit wil zeggen een clustering van processen met een sterke interne samenhang en zwakke koppeling met andere clusters van processen; • zelfstandig bestaansrecht: dit wil zeggen dat het (deel)systeem een bestaansrecht heeft onafhankelijk van andere (deel)systemen;


• projectmatige realiseerbaarheid: dit wil zeggen dat er een zodanige afbakening van het (deel)systeem is dat het ontwikkelingstraject op een succesvolle wijze is af te ronden. De volgende factoren bepalen het succes van projecten: - duidelijkheid van de doelstellingen; - kennis en ervaring met de toe te passen methoden; - kennis en ervaring met de toe te passen technieken; - omvang en complexiteit van het (deel)systeem.

• aspectgerichtheid: voor de beoordeling van de methode is het van belang welke aspectmodellen worden onderkend en hoe ze worden gebruikt. Literatuur [ARCH00] Architectuur en Infrastructuur (2000), nr. 4. [BURG]

Burg, H., Volwassenheid in een architectuurorganisatie.

[DISS00]

Disseldorp, J. van, A. Hendriks, R. Spijkerman en H. Vader (2000), Architectuur vs. realisatie -

Normen voor het proces bij tot stand brengen architectuurproducten 1. Vanaf aanvang van het architectuurproject dient rekening te worden gehouden met de bedrijfsstrategie en zullen de eventuele gevolgen voor de te ontwikkelen architectuur inzichtelijk gemaakt zijn. 2. Het (top)management dient vanaf de start van het architectuurproject actief erbij te worden betrokken. 3. Er zijn maatregelen getroffen om de kennis over de architectuur en ontwerpkeuzes te borgen. Denk hierbij aan: • ontwikkelaars zowel in de architectuur- als de realisatiefase laten participeren; • ontwikkelen en gebruiken van documentatiestandaards; • structureren van het keuzeproces in de architectuurfase. 4. In algemene zin dienen de juiste partijen te worden betrokken. Hierbij dient de gebruikersorganisatie niet te worden vergeten. 5. De ontwerpstrategie zal moeten voldoen aan twee belangrijke criteria: • de complexiteitsvermindering in de modellering: dat wil zeggen dat de werkelijkheid voldoende is vereenvoudigd om een overzicht te bieden en tegelijkertijd voldoende complex is om alle relevante delen van de werkelijkheid weer te geven. • de verifieerbaarheid van de modellen: dat wil zeggen dat de gebruiker aangeeft of de gewenste toekomstige situatie correct is uitgebeeld. Hiervoor is het nodig dat de gebruiker de modellen kan begrijpen en beoordelen. Deze bovenstaande criteria zijn te globaal om op basis hiervan methoden te toetsen. Hieronder volgt een aantal meer gedetailleerde criteria: • herhaalbaarheid: wanneer de activiteit nogmaals wordt uitgevoerd, moet hetzelfde product ontstaan, ongeacht de persoon die het werk verricht; • onderbouwing: de keuzen die in het modelleringsproces zijn gemaakt, dienen gemotiveerd en verifieerbaar te zijn; • doelgerichtheid: de methode dient aan te geven hoe de bedrijfsdoelstellingen moeten worden vertaald naar systeemeisen;

Ervaringen, Problemen en Aanbevelingen. [HAMM98] Hammer, D.K. (1998), Architectuur belangrijkste middel om complexiteit te bedwingen, in: Automatiseringsgids, 30 oktober. [NORE97] NOREA (1997), Studierapport nr. 2 – Een kwaliteitsmodel voor Register EDP-auditors – De eerste stap, juli. [POST]

Postema, H. en H. Akkermans, Managing architectural risks in product development – a casestudy from the electronics industry.

[SAND97] Sanden, W. van der en B. Sturm (1997), Informatiearchitectuur – de infrastructurele benadering, pp. 23-25. [SWIN]

Swinkels, G.J.P. en L.J.M.W. Gielen, Handboek EDP-auditing B 5.1.1.1. Knelpuntenanalyse projectmanagement, NOREA.

[VREV94]

Vreven, A.A. (1994), Methoden en hulpmiddelen voor de systeemontwikkeling pp. 38-40.

[ZEIS96]

Zeist, B. van, et al. (1996), Kwaliteit van software producten, praktijkervaring met een kwaliteitsmodel.

19

Een audit op informatiearchitectuur:

Recommend Documents