Volledig open architectuur is een illusie

Op deelgebieden heeft openheid meer voor- dan nadelen

De pogingen om een open architectuur gemeenschap in brede zin op te richten, analoog aan de open source gemeenschap, zijn niet levensvatbaar. Op deelgebieden zijn de voordelen echter groter dan de nadelen. Architecturen die geen concurrentiegevoelige informatie bevatten bijvoorbeeld, en architecturen van publieke organisaties, kunnen baat hebben bij verdere ontwikkeling vanuit een open gemeenschap.

Architectuur en oss
Oss (open source software) is software waarbij de gebruiker kan beschikken over de broncode, onder licentievoorwaarden die hem vrijheden bieden om de programmatuur aan te passen en te distribueren.
Enkele voordelen daarvan zijn:
  • doordat de broncode beschikbaar is, kan de gebruiker zelf verbeteringen in de software doorvoeren;
  • deze verbeteringen kunnen opgenomen worden in de programmatuur, zodat iedereen ervan kan profiteren;
  • inzicht in de broncode biedt mogelijkheden om te leren (welke keuzes heeft de programmeur gemaakt, welke algoritmen zijn toegepast, hoe werkt het);
  • hergebruik van de broncode is mogelijk in andere software; je hoeft het wiel niet steeds opnieuw uit te vinden.
In praktijk zie je dat niet alleen de broncode, maar ook (vaak technische) documentatie beschikbaar gesteld wordt, soms expliciet vormgegeven in een architectuurbeschrijving. Dit betreft dan de applicatie-architectuur; de principes en richtlijnen die gehanteerd zijn om de structuur en samenhang van de softwarecomponenten in de applicatie te beschrijven als kader voor het ontwerp.
Als de architectuur niet expliciet beschreven is, valt deze vaak wel af te leiden uit de andere technische documentatie of de broncode. Elk stuk software heeft immers een architectuur. Elk stuk open software heeft dus een open architectuur.
Voor bedrijfsarchitecturen ligt dit anders. Een bedrijfsarchitectuur bevat juist de principes en richtlijnen die een kader vormen voor de inrichting van de totale informatievoorziening, gerelateerd aan de organisatie en haar processen en marktproducten. Dit omvat dus veel meer dan softwarecomponenten. De implementatie hiervan is niet vergelijkbaar met broncode van een informatiesysteem. De parallel met open source gaat voor bedrijfsarchitecturen dus niet op.
De gemeenschap van ict-architecten wordt snel professioneler. De architect verandert op diverse manieren van 'onnavolgbaar ambachtsman' in 'transparante professional'. Er is veel discussie gevoerd over de reikwijdte van de titel 'architect'. Sinds dit jaar bestaat er een Europees Register Informatie Architecten (Eria). Onlangs is aan de Radbouduniversiteit in Nijmegen de Masteropleiding 'Architect in de digitale wereld' gestart.
Een initiatief van een heel andere orde is het Nederlands Kampioenschap ICT-architectuur. Dit NK is vorig jaar voorafgaand aan het Landelijk Architectuur Congres gehouden. Het doel van die competitie was om te stimuleren dat er architectuurbeschrijvingen van echte systemen gepubliceerd zouden worden. Zolang die openheid ontbrak zouden architecten niets van elkaar kunnen leren, was de gedachte van de initiatiefnemers. Het publiceren van architecturen, wat wij hier in navolging van 'open source software' 'open architectuur' noemen, zou voorkomen dat veel geld en energie verloren gaat met architectuurconcepten waarvan elders al bewezen is dat ze problemen opleveren. Een interessante gedachte, maar werkt dit ook in de praktijk?

Breed of smal

Het is niet moeilijk om meer voordelen dan het leereffect te bedenken van een 'open architectuur gemeenschap'. Architectuur wordt minder mysterieus, waardoor de discussie over architecturen meer inhoud krijgt. Het publieke debat verhoogt de professionaliteit van ict-architecten verder. De kwaliteit van implementaties van systemen neemt toe omdat de kwaliteit van de architecturen beter is. Er ontstaat sneller een 'lingua franca' voor architecten, waardoor ze elkaar beter gaan begrijpen en mogelijk ook begrijpelijker zullen worden voor niet-architecten (hoewel architecten nog meer moeten doen om goed begrepen te worden). Er ontstaan voor iedereen zichtbare 'best practices', waar productleveranciers rekening mee kunnen houden. Dit maakt op termijn de implementeerbaarheid van architecturen groter en drukt de kosten.
Werkt het ook echt zo? Om die vraag te beantwoorden moeten we eerst kijken naar de betekenis van architectuur voor organisaties. Belangrijk hierbij is of je een brede of een smalle definitie van architectuur hanteert. Aan de ene kant van het spectrum zien we de applicatie-architectuur, die de samenhang van de onderdelen van één applicatie beschrijft (smal). Tegenpool hiervan is de bedrijfsarchitectuur, die de samenhang van een hele organisatie en haar informatievoorziening en technische infrastructuur beschrijft (breed).

Dure missers voorkomen

De smalle architecturen hangen zo sterk samen met het functioneren van één applicatie dat een discussie over de openheid ervan erg zal lijken op het debat over oss (open source software). Open source-producten hebben vanwege hun aard per definitie een open architectuur, zij het dat deze meestal impliciet is gelaten (zie kader 'Architectuur en oss'). Hoe meer een organisatie gebruik maakt van oss, hoe meer haar applicatie-architecturen openbaar zijn. De voordelen van het publiceren van applicatie-architecturen spelen niet organisatiebreed, maar blijven beperkt tot die ene applicatie.
De openheid van de brede bedrijfsarchitecturen is veel interessanter. Een bedrijfsarchitectuur is een integrale blauwdruk van de samenhang van organisatie, bedrijfsprocessen, informatie, applicaties en technische infrastructuur (zie kader 'Bedrijfsarchitectuur'). De impact van een dergelijke architectuur op het succes van een organisatie is veel groter dan die van een applicatie-architectuur. De voordelen van het publiceren van bedrijfsarchitecturen hebben daarom meer betekenis voor organisaties.
Diverse argumenten pleiten voor het openbaar maken van architectuurbeschrijvingen. Met de terugkoppeling uit de gemeenschap kan je jouw architectuur verbeteren en

Bedrijfsarchitectuur
Een bedrijfsarchitectuur is een integrale blauwdruk van de samenhang van organisatie, bedrijfsprocessen, informatie, applicaties en technische infrastructuur. De architectuur geeft inzicht in de status-quo van de informatievoorziening en schetst het punt aan de horizon waarheen de informatievoorziening zich moet bewegen. Door het vaststellen van principes, richtlijnen en standaarden zal op veel punten duidelijkheid zijn over de te gebruiken technieken en producten om de inrichting van de organisatie en haar informatievoorziening te realiseren.
Een architectuur kan organisaties veel opleveren:
  • vermindering van de 'time-to-market' (omdat over bepaalde zaken minder per geval nagedacht hoeft te worden);
  • vergroting van de flexibiliteit;
  • een communicatiemiddel tussen ict en bedrijfsactiviteiten;
  • inzicht in de samenhang tussen ict en bedrijfsactiviteiten;
  • betere keuzes en prioriteitsstelling in projecten;
  • inzicht in en overzicht over de informatievoorziening voorkomt functionele en technische doublures of lost ze op, wat de homogeniteit vergroot en de kosten verlaagt;
  • standaardisatie levert schaalvoordelen op bij kennisinstandhouding, beheer, uitbesteding en dergelijke, wat op de langere termijn de totale ict-kosten verlaagt.
doorontwikkelen. De visie van anderen helpt je te voorkomen dat je 'leergeld betaalt' (dure missers). De organisatie streeft naar transparantie (dit kan vooral gelden voor organisaties die hun taken met publiek geld uitvoeren). Als andere organisaties onder jouw architectuur gaan werken, kan je hun ervaringen weer gebruiken in jouw situatie. Je kunt uit ideële overwegingen anderen willen helpen met jouw kennis. Je kunt het imago van je organisatie neerzetten en versterken (trendsetter, kwaliteitsimago).

Concurrentiegevoelig

Jan Turk stelde in 'IT-architecten moeten werk publiceren' (Automatisering Gids, 30 juli 2004) dat organisaties er niet toe komen architecturen te publiceren omdat ze niet weten hoe ze een architectuur moeten opstellen. Volgens ons is dat niet de werkelijke reden. Natuurlijk hebben veel organisaties koudwatervrees als het gaat om architectuurbeschrijvingen, maar een substantieel aantal is al goed bezig. Ook zonder thuis te zijn in Ieee 1471 (http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html) kan je met behulp van enig abstract denken en helder decomponeren een bruikbare architectuurbeschrijving maken. Organisaties houden hun architectuur niet geheim uit onkunde; daar hebben ze heel andere redenen voor.
Allereerst bevatten architecturen concurrentiegevoelige informatie. Uit de bedrijfsarchitectuur van de bestaande situatie is de adaptiviteit van de organisatie af te lezen. Uit de toekomstige architectuur is mogelijk de lange termijn strategie van de organisatie af te lezen. De architectuur geeft inzicht in de bedrijfsprocessen, ofwel hoe een organisatie haar werk doet.
Verder verschaft de architectuur inzicht in de kwetsbaarheden van de organisatie en haar informatievoorziening. Dit maakt organisaties kwetsbaar voor fraude en andere risico's. Het koppelen van registraties bijvoorbeeld beperkt de fraude-mogelijkheden. Omgekeerd zal dus het ontbreken van een koppeling tussen registraties juist fraude mogelijk maken. De oss-gemeenschap heeft inmiddels veel ervaring met dit risico en is er op bedacht. Bij open architecturen is dit risico echter veel groter dan bij oss, omdat een architectuur zich immers niet zo eenvoudig laat 'patchen' als software indien een kwetsbaarheid aan het licht komt.
Bovendien bevat de architectuur van een organisatie veel historische componenten (legacy), die een helder zicht op de gedachte achter de architectuur ontnemen. Er is veel contextuele informatie nodig om de architectuur werkelijk goed te kunnen beoordelen of in een andere situatie toe te passen. De terugkoppeling die de gemeenschap geeft op een dergelijke architectuur heeft vermoedelijk beperkte waarde, omdat juist de kennis over die context in de gemeenschap ontbreekt. Dit probleem is minder groot, maar nog altijd aanwezig, als er open architectuur gemeenschappen zouden ontstaan die zich georganiseerd hebben rond branches of sectoren. Het nadeel van een dergelijke segmentatie is dat het moeilijker wordt om voldoende kritieke massa te bereiken in elke sector.
Tot slot valt uit de huidige en toekomstige architecturen een indruk te krijgen van de professionaliteit en het innovatievermogen van de organisatie op het gebied van ict. Deze indruk kan wel eens behoorlijk strijdig zijn met het imago dat de organisatie heeft of wil hebben. De informatievoorziening van sommige banken bijvoorbeeld is helemaal niet zo solide en goed geolied als je wellicht zou verwachten.

Geneigd te delen

Niet elke bedrijfsarchitectuur is even concurrentiegevoelig. Het hangt af van de reikwijdte van de architectuur. Hoe ruimer de reikwijdte van de architectuur is, hoe meer de visie, strategie en bedrijfsprocessen van de organisatie terug te vinden zijn en hoe meer concurrentiegevoelige informatie aanwezig is. Openheid is wel mogelijk bij (deel)architecturen die niet concurrentiegevoelig zijn, bijvoorbeeld in de ondersteunende processen.
Ook bepaalt de aard van de organisatie de concurrentiegevoeligheid van de architecturen. Bij organisaties in het publieke domein zal het concurrentieargument veel minder spelen (in tegenstelling tot de fraude en imagorisico's). Publieke organisaties zijn van nature geneigd informatie te delen met andere publieke organisaties. Ook willen ze graag zorgvuldig en onverwijtbaar handelen. Ze zullen dus bereid zijn terugkoppeling te vragen aan een gemeenschap van experts, als die er is.
Een open architectuur gemeenschap heeft onmiskenbaar voordelen, maar de belemmeringen zullen voor de meeste private organisaties te groot zijn om hier hun bedrijfsarchitectuur aan toe te vertrouwen. Voor publieke organisaties gelden die belemmeringen minder. Je ziet dan ook dat veel publieke organisaties al onderling samenwerken en informatie over architecturen delen. Soms wordt het architectuurmodel van de ene organisatie een soort sjabloon voor andere (we zien dit op provinciaal niveau, met onder meer de provincie Groningen als pionier). Een ander scenario is dat een architectuurraamwerk centraal ontwikkeld wordt voor gemeenten (architectuur voor de 'elektronische overheid').

 
Erik van Ginneken, senior consultant, Reinier Balt, consultant ict-adviesbureau Verdonck, Klooster & Associates

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2005-03-25T00:00:00.000Z Erik van (e.a.) Ginneken
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.