Artikel

Overheid en service-oriëntatie: beschrijving van een SOA audit

Van een eenvoudige kernvraag naar een “business logic”

Enige tijd geleden werd ik benaderd door een overheidsorganisatie die een audit wilde laten uitvoeren op haar ”service georiënteerde architectuur” (SOA). De kernvraag was of de ICT architectuur van deze organisatie in overeenstemming is met wat een service georiënteerde architectuur vereist. In dit artikel wordt ingegaan op wat service-oriëntatie is, en waarom een organisatie een SOA zou willen hebben. Tevens beschrijft dit artikel hoe de aanvankelijke relatief eenvoudige kernvraag onderdeel werd van een veelomvattende “business logic” voor de beantwoording van de onderzoeksvragen en de totstandkoming van het bijbehorende rapport.

Vragen vóór de kernvraag

Tijdens de voorbereiding van de audit werd al snel duidelijk dat, gegeven de doelgroep van het rapport zijnde het managementteam van de Divisie Middelen, er enkele vragen vóór de in de inleiding benoemde kernvraag beantwoord dienden te worden: wat is service georiënteerdheid? Wat is een service georiënteerde (ICT) architectuur? En waarom zou een organisatie een service georiënteerde architectuur willen hebben? Logische vragen. Daar waar de meeste enterprise en ICT architecten het begrip “service georiënteerd” al jaren kennen, is dat voor niet-ICT-ers en niet-architecten vaak niet het geval. En achter “wat is”-vragen zit natuurlijk altijd een “waarom”-vraag. Zeker bij Nederlanders.

Naar aanleiding van deze “wat” en “waarom” vragen kwamen al snel de ontwikkelingen onder de paraplu van “e-overheid” ter sprake. Hoe passen de e-overheid bouwstenen en initiatieven in een service georiënteerde architectuur? Hoe krijgt de e-overheid die service georiënteerdheid? En de NORA, PETRA, GEMMA en MARIJ referentiearchitecturen, zijn die dan ook service georiënteerd? Wederom logische vragen. En dus werd de beantwoording ervan opgenomen in de audit.

Vragen ná de kernvraag

Gegeven het bovenstaande lag het voor de hand om de huidige ICT architectuur van deze overheidsorganisatie niet alleen te beoordelen op het wel of niet in overeenstemming zijn met wat een service georiënteerde architectuur vereist, maar om ook meteen te kijken naar de mate waarin die ICT architectuur voldeed aan de van toepassing zijnde referentiearchitectuur. En daarbij te bepalen welke e-overheid bouwstenen relevant zijn voor de organisatie, en wat de status van de implementatie daarvan is.

Wederom logische vragen, cumulerend in de uiteindelijke eindvraag: “Wat kunnen wij verbeteren?” En zo werd de aanvankelijke relatief simpele kernvraag uitgebreid tot een “redeneerlijn”, een “business logic” die is weergeven in figuur 1.

Figuur 1: business logic voor de SOA audit

1. Wat is service georiënteerdheid?

Een service georiënteerde (“oriented”) architectuur, een SOA, is niet alleen een technische aangelegenheid, maar draait ook om het inrichten van een organisatie. SOA gaat over de informatiekoppeling tussen verschillende organisatieonderdelen, of tussen verschillende organisaties. SOA gaat dus over netwerken, over ketens van organisaties die weer kunnen deelnemen in meerdere ketens hetgeen de complexiteit zowel als het belang van die informatiekoppelingen vergroot.

Als mensen zich buigen over ketens van met elkaar samenwerkende organisaties komt het vaak voor dat gedacht wordt in termen van werkstromen. Koppelvlakken worden in dat geval beschouwd als overdrachtsmomenten. In SOA is een keten echter geen werkstroomketen, maar een keten van diensten. Een schakel in een keten is er niet primair om een deelproces uit te voeren, maar om toegevoegde waarde te leveren. Deze toegevoegde waarde definieert de rol van een schakel en wordt vastgelegd in een dienstverleningscontract.

Vervolgens dient elke schakel, elke dienst, zelf te bepalen hoe de dienst geleverd wordt en welke interne processen daarvoor ingericht dienen te worden. De focus ligt op de toegevoegde waarde en de manier waarop deze binnen de keten gecommuniceerd wordt. De schakel is vrij om te bepalen hoe hij die waarde levert.

De reden om organisaties in een keten te schakelen is dat de keten als geheel een dienst verleent aan zijn klanten. Er dient één verantwoordelijke aanbiedende partij te zijn. Deze partij kan de uitvoering zelf ter hand nemen, maar ook (geheel of gedeeltelijk) uitbesteden. Vanuit de afnemer gezien is deze eventuele uitbesteding liefst onzichtbaar. Alle benodigde coördinatie is een interne zaak van de aanbieder. En die verantwoordelijkheid kan niet worden uitbesteed.

Voor coördinatie in een keten bestaan twee modellen: operationele sturing en tactische sturing. Bij operationele sturing zit de aanbieder zelf in de operationele uitvoeringsketen. Hij bewaakt en regisseert de inhoud en volgorde van de bijdragen van alle schakels. De schakels behoeven onderling geen contact. Deze vorm heet ook wel orkestratie: de aanbieder is als een dirigent die bij de uitvoering van een muziekstuk continu de coördinatie voert. Bij tactische sturing besteedt de aanbieder de contacten tussen de schakels uit aan de schakels zelf. Dat heet choreografie: de aanbieder is als een choreograaf die de interactie tussen dansers weliswaar vormgeeft, maar niet deelneemt aan de dans zelf.

Informatie-uitwisseling tussen organisaties impliceert berichtenverkeer. In SOA worden service bussen gezien als de logistieke dienstenleveranciers die zorg dragen voor dat berichtenverkeer. Alle organisaties die aangesloten zijn op een service bus vormen daarmee een soort logistieke gemeenschap.

Dat wil niet zeggen dat aangesloten organisaties altijd zomaar van elkaars diensten gebruik
kunnen maken. En ook niet dat zij geen gebruik zouden kunnen maken van diensten van partijen
buiten deze logistieke gemeenschap (en andersom). Vergelijk het met alle bedrijven die een eigen aansluiting hebben op het spoorwegnet, zoals dat een eeuw geleden vrij gebruikelijk was. Zij zijn logistiek verbonden en kunnen dus in principe goederenverkeer met elkaar aangaan. Echter, zij hebben niet per se allemaal een zakelijke relatie. Andersom kunnen zij ook zaken doen met bedrijven die geen directe aansluiting hebben op het spoorwegnet. Daarvoor zijn overslagpunten ingericht, waar goederen kunnen wisselen van transportmiddel. In een SOA bestaan ook van deze overslagpunten, en men noemt dat (diensten)loketten. Een loket is een voorziening die diensten uit haar eigen “achterland” ontsluit voor de buitenwereld. Loketten maken gebruik van een dienstenregister om de door hen geleverde diensten te publiceren.

Op basis van het bovenstaande is een set van principes te definiëren die een architectuur tot een SOA maken. De SOA principes zijn weergegeven in tabel 1:

SOA principe Uitleg
“Standardized service contract” Services bieden zich aan via een “service contract”. Services hanteren een eenduidige definitie, opbouw en technische invulling van de samenwerkingafspraak tussen aanbieder en gebruiker. Service contracten dienen consistent, betrouwbaar en reguleerbaar te zijn.
“Loose service coupling” Services zijn zo opgebouwd dat afhankelijkheid van anderen zo laag mogelijk is. Er is een continue drang om de afhankelijkheid van de service implementatie een interne aangelegenheid van de service aanbieder te laten zijn. Zo zijn service gebruikers wel gekoppeld aan het service contract van een service, maar niet aan de implementatie van die service of aan de koppelingen met andere services.
“Service abstraction” Service contracten bevatten alleen de absoluut noodzakelijke (en dus de essentiële) informatie over de diensten (functies) die de service biedt. De gebruiker zal alleen deze informatie tot zijn beschikking hebben en hoeven te hebben om gebruik te kunnen maken van de service.
“Service reusability” Een service moet herbruikbaar zijn zodat andere services er keer op keer gebruik van kunnen maken. Het ontwerp van de service dient aandachtig bekeken te worden en getoetst te worden op herbruikbaarheid binnen de context van de architectuur.
“Service autonomy” Services dienen op de juiste wijze te kunnen beschikken over de resources en de omgeving waarin deze services draaien. Services waarvan andere services (in een keten) afhankelijk zijn dienen een groter niveau van autonomie te hebben.
“Statelessness” Services trachten de resources die ze gebruiken te minimaliseren door ofwel de informatie over de huidige status van de service niet zelf bij te houden, maar dit over te laten aan andere systemen, of de statusinformatie die door de service zelf wordt bijgehouden in ieder geval zo minimaal mogelijk te laten zijn.
“Service discoverablity” Indien een service gezien wil worden als een herbruikbare asset binnen het ecosysteem dient deze makkelijk te kunnen worden herkend en begrepen. Het gaat hier om de kwaliteit van de metadata die het service contract biedt. Het service contract dient kenbaar te maken welke functies en welk doel de service dient. Zo kan bij het zoeken naar herbruikbare services binnen de architectuur de service gemakkelijk worden gevonden.
“Service composability” Een service moet gemakkelijk gebruikt kunnen worden binnen een groter geheel van services, een keten. De eisen die aan het ontwerp van een service worden gesteld zijn gericht op het voorkomen dat een service binnen een bredere oplossing moet worden “gelepeld”. Van een service wordt verwacht dat ze gemakkelijk een rol kan vervullen binnen een keten, zonder dat daar bij het ontwerp van de keten expliciet rekening mee wordt gehouden. Het draait hier dus om “separation of concerns”.
“Service optimization” Wanneer meerdere services beschikbaar zijn die dezelfde functionaliteit bieden, gaat een service met een hogere kwaliteit boven de service met een lagere kwaliteit.
“Service relevance” Een service dient die functies aan te bieden die door een gebruiker ook als zinvolle functies worden gezien. Indien de functies te klein of juist te groot worden ontworpen dan daalt daarmee de waarde die de functies hebben voor de gebruikers van de service.
“Service encapsulation” Een service kan andere services inkapselen die niet in eerste instantie opgezet waren om te functioneren binnen een SOA. Denk daarbij aan legacy systemen en databases waarbij een SOA service de functionaliteiten van die systemen kan publiceren om zo deze functionaliteit te kunnen laten meedraaien in een SOA.
“Service location transparancy” Een service zou overal moeten kunnen werken ongeacht waar de service zich fysiek bevindt. Hierdoor is het uitwisselen van services over geografische, technische en organisatorische grenzen heen mogelijk. Het gebruik van een “enterprise service bus”, waarin logische services gekoppeld zijn binnen een infrastructuur die voor de gebruiker onzichtbaar (encapsulation) blijft, is onderdeel van dit principe.

Tabel 1: SOA principes

2. Waarom service georiënteerdheid?

“Alleen op de wereld”, en dan ook nog een wereld die amper verandert. Wat zou dat betekenen voor de informatiehuishouding van een organisatie? Een organisatie hoeft zich dan geen zorgen te maken over koppelingen met andere organisaties. Zij hoeft zich geen zorgen te maken over toekomstige veranderingen aan bedrijfsprocessen of informatiesystemen. Zij bouwt deze vanaf de bodem zelf op, zonder gebruik te maken van functies of componenten van derden. Het is niet nodig om scherp te zijn over wat een bedrijfsproces of informatiesysteem biedt, men komt toch wel naar die organisatie toe. Er is volledige vrijheid om bedrijfsprocessen aan te passen, en de technologie staat geen enkele wijziging in de weg.

Maar dat is niet de wereld waarin wij leven. Organisaties, en zeker overheidsorganisaties, worden vandaag de dag geconfronteerd met toenemende eisen voor klantgedreven dienstverlening, die betrouwbaar, proactief, transparant, toegankelijk en vindbaar dient te zijn. Nieuwe maatschappelijke kwesties, prioriteiten of wetgeving zorgen voor voortdurende wijzigingen in bedrijfsprocessen, informatievoorziening en applicatielandschap. Voortschrijdende technologie, maar ook een continue druk om efficiënter te opereren zorgen voor nog meer wijzigingen, ook in de onderliggende infrastructuur. En het toenemend belang van samenwerking en informatie-uitwisseling vraagt intensief overleg over communicatiestandaarden. Een uitdaging dus, voor organisaties in het algemeen en specifiek voor mensen binnen deze organisaties die verantwoordelijk zijn voor inrichting en beheer van bedrijfsprocessen en informatiesystemen.

Een voor de hand liggende manier om naar deze uitdagingen te kijken is door uit te gaan van het ideaal van een integraal ontworpen informatiefabriek, een zachtjes snorrend buizenstelsel waardoor informatie stroomt. Dat is een gevaarlijke metafoor omdat hiermee voorbij gegaan wordt aan autonomie die organisaties binnen een keten hebben, en omdat het volgens deze denkwijze een vereiste is dat er overzicht is, in de breedte en in detail, over alle ketens. Los van de vraag of deze mate van integratie en centrale sturing überhaupt wenselijk is, is de realiteit dat binnen maar zeer zeker ook tussen organisaties dit praktisch gezien niet mogelijk of niet haalbaar is.

Maar wat dan wel? Hoe kan er voor gezorgd worden dat er een structuur ontstaat die zo flexibel mogelijk kan inspelen op veranderingsimpulsen, of deze nou een contextuele oorzaak, een interne organisatorische oorzaak of een technologische oorzaak hebben? Hoe kan recht gedaan worden aan een bepaalde mate van autonomie van organisaties, en van organisatorische eenheden binnen een organisatie, maar wel gezorgd worden voor samenwerking? Dat is waar een service georiënteerde architectuur, een SOA, om de hoek komt kijken.

In SOA staan uitvoerings- en communicatieafspraken tussen “spelers in de keten” voorop en niet zozeer de interne werking van deze spelers. De werking van een organisatie of een informatiesysteem is er slechts om aan de afspraken te voldoen en dat is waar op gestuurd wordt. Een belangrijke vraag is dan wel wat er in zo’n afspraak zou moeten staan. Daarbij is het dilemma dat de afspraak strak en compleet genoeg moet zijn om het stelsel te laten functioneren, maar ook los genoeg moeten zijn om de spelers flexibel en autonoom te laten blijven, zowel ten aanzien van het inrichten van hun interne werking alsook het koppelen met andere partijen.

Het antwoord op dit dilemma heet in SOA een dienst, vastgelegd in een dienstverleningsovereenkomst. Zo appelleert SOA aan een perspectief waarin tegelijkertijd zowel de samenhang tussen als de beweeglijkheid van organisaties wordt gewaarborgd, transparantie en zakelijkheid wordt bevorderd - aangezien wordt gestuurd op basis van heldere uitvoeringsafspraken en niet op basis van interne werking van een proces of van technologie - en hergebruik van diensten en informatiesystemen wordt bevorderd.

Als gevolg van het bovenstaande geldt heden ten dage SOA als het overwegende paradigma om aan te slag te gaan met het organiseren van samenwerking, en dus van informatievoorziening, in en tussen organisaties. Dat geldt zowel voor vele bedrijfssectoren in ons land alsook voor overheden in Nederland en diverse andere landen.

3. Hoe krijgt e-overheid service georiënteerdheid?

Om met de deur in huis te vallen: service-oriëntatie is een onderwerp met een reikwijdte en diepte die zo groot is, dat de overheidsorganisaties gezamenlijk moeten optrekken om het te realiseren. Het is zoals eerder gezegd niet mogelijk om service oriëntatie als een technologische ontwikkeling af te doen en haar dienovereenkomstig te beleggen of uit te besteden. Er dient aandacht besteed te worden aan ketensamenwerking, aan diensten zoals geleverd door spelers in de keten, aan informatie-uitwisseling, aan semantiek en syntax van communicatie etc. Daarom geldt dat de Nederlandse e-overheid dient te werken onder architectuur om service-oriëntatie, oftewel een SOA, te implementeren.

In een SOA zijn de onderdelen van de e-overheid allemaal afnemers en/of aanbieders van diensten. Dat geldt zowel voor organisaties, voor afdelingen binnen organisaties, voor bedrijfsprocessen binnen afdelingen en over afdelingen heen, als voor gebruikte applicaties. Om een SOA te implementeren, moet van alle huidige en toekomstige werkzame onderdelen van de e-overheid een precieze dienstenbeschrijving gemaakt en onderhouden te worden. De verantwoordelijkheid daarvoor ligt bij de aanbieders van diensten. Om de samenwerking tussen organisaties mogelijk te maken en deze vervolgens efficiënt en effectief te maken, moeten zij kunnen beschikken over gezamenlijke principes, conventies en richtlijnen voor dienstenontwerp.

De e-overheid verleent diensten aan burgers en bedrijven. Organisaties die gezamenlijk die e-overheid vormen hebben veelal wettelijk vastgestelde taken. Overheidsorganisaties dienen te kunnen beschikken over richtlijnen en handreikingen over hoe wettelijke taken zich laten vertalen naar producten en diensten.

De inhoud van producten en diensten zal grotendeels sectorspecifiek, en zelfs organisatiespecifiek, zijn. Dat betekent niet dat de manier waarop de diensten worden gedefinieerd en worden beschreven anders dient te zijn. Sterker nog, een grote diversiteit beperkt de interoperabiliteit. Voor de ontwikkeling van een service georiënteerde e-overheid moet harmonisatie in gang worden gezet voor de manier waarop diensten beschreven worden, op basis van volwassen, open en internationale standaarden.

Dienstenregisters vervullen een sleutelfunctie in een SOA, en vormen de basis voor de uiteindelijke koppelingen tussen organisaties. Voor de hand liggend is dat individuele organisaties hun eigen dienstenregister hebben. Omdat echter de overheid niet is op te delen in een aantal geïsoleerde diensteneilanden, zullen die registers onderling dienstenbeschrijvingen moeten kunnen kopiëren of delen of onderling kunnen doorverwijzen. Ook hier geldt dat de toepasselijke standaarden zoveel mogelijk generiek dienen te zijn. Voor de ontwikkeling van een service georiënteerde e-overheid moet er harmonisatie zijn ten aanzien van de toegang en koppeling van dienstenregisters, en ten aanzien van de formulering van dienstpublicaties en -overeenkomsten.

Voor een service georiënteerde e-overheid is het van belang een beperkt aantal standaarden te hanteren voor de logistieke afhandeling van dienstenverkeer, op basis van (zoals eerder aangegeven) volwassen, open en internationale standaarden. Een service georiënteerde e-overheid vereist een samenhangend stelsel van servicebussen. Een dergelijk stelsel kan niet functioneren zonder de logistieke afhandeling van diensten te standaardiseren.

SOA bevordert de zakelijkheid, de externe oriëntatie, de openheid en het hergebruik binnen de e-overheid. Maar ook met een service georiënteerde ontwerpstijl en expliciete publicatie van dienstenregisters en dienstverleningsovereenkomsten blijven er nog flinke obstakels over. Wat nu als alle aanbieders volledig maatwerk zouden maken van al hun diensten? Of als alle diensten hun inhoudelijke begrippen anders zouden definiëren? Of als alle diensten andere technische protocollen zouden vragen? Dat zou zeker niet bijdragen aan de mate waarin afnemers en aanbieders elkaar eenvoudig, snel en goedkoop zouden vinden, tot een vergelijk zouden komen en wederzijds diensten zouden verlenen. Anders gezegd, dat zou afbreuk doen aan de interoperabiliteit.

Gelukkig is een groot deel van deze obstakels te bevechten door te standaardiseren, dat wil zeggen, door op allerlei aspecten en onderdelen ervoor te kiezen overeenkomstige behoeftes en problemen op overeenkomstige wijze te lijf te gaan. En dus, zoals gesteld aan het begin van deze paragraaf, dient de Nederlandse e-overheid onder SOA te werken om tot service-oriëntatie te geraken.

4. Zijn de referentiearchitecturen service georiënteerd?

NORA is de referentiearchitectuur voor de Nederlandse e-overheid. De afkorting staat dan ook voor Nederlandse Overheids Referentie Architectuur. NORA stelt zich tot doel de inhoudelijke samenhang te bevorderen tussen de grote hoeveelheid programma’s, projecten en voorzieningen die de e-overheid rijk is en nog gaat krijgen. NORA biedt ontwerpprincipes, modellen en afspraken voor het (her)inrichten van de e-overheid, geordend in een raamwerk. De manier waarop NORA naar de wereld kijkt, kenmerkt zich door:

  • Het beschouwen van de wereld als een steeds veranderend stelsel van werkzame onderdelen: organisaties (gerangschikt in sectoren en overheidslagen), afdelingen, applicaties, voorzieningen, infrastructuur en mensen. De werking van deze onderdelen is deels gegoten in software, maar voor een belangrijk deel ook niet;
  • De onderdelen van de e-overheid hebben interactie. Burgers en bedrijven nemen diensten af van de overheid. Organisaties en hun afdelingen werken samen in ketens en netwerken. Organisaties en hun mensen gebruiken applicaties. Applicaties gebruiken infrastructuur;
  • Interoperatibiliteit is een hoofddoelstelling van de e-overheid , en NORA spreekt hierover in termen van diensten en van dienstverlening;
  • NORA gaat niet alleen over de randen van de e-overheid waar diensten worden geleverd aan burgers en bedrijven, maar zeker ook over de binnenkant: de manier waarop overheidsorganisaties, hun afdelingen, applicaties en voorzieningen zich tot elkaar verhouden. NORA gaat dus ook over keten- en netwerksamenwerking, koppelvlakken, integratie en standaarden;
  • NORA ziet de e-overheid als een gemeenschap van onderdelen die elkaar diensten verlenen. Dienstverlening is niet alleen een operationele en technische aangelegenheid. Dienstverlening vindt plaats op basis van zakelijke afspraken tussen de werkzame onderdelen van de e-overheid. NORA gaat daarmee ook over tactische aspecten van de e-overheid, namelijk hoe deze afspraken eruit zien en hoe zij tot stand komen;
  • Een grote uitdaging in de e-overheid is om haar werkzame onderdelen samen te laten werken zonder daarbij de eigen manoeuvreerruimte van de onderdelen te veel geweld aan te doen. Daarvoor zijn losse koppelingen nodig, maar weer niet zo los dat de samenwerking aan waarde of kwaliteit inboet. Het dienstenbegrip wil een antwoord zijn op dit dilemma: een dienstenafspraak regelt precies dat wat op het koppelvlak nodig is, maar laat de interne aangelegenheden aan de individuele onderdelen zelf. In NORA wordt deze eis het subsidiariteitprincipe genoemd.

Op basis van de voorgaande paragrafen is duidelijk dat NORA gebaseerd is op SOA principes. Dat geldt ook voor “de dochters” van NORA, zoals PETRA voor provincies, GEMMA voor gemeenten, WILMA voor waterschappen, MARIJ voor rijksoverheidinstanties en ROSA voor het onderwijsdomein. In NORA verband hebben de zussen dan ook regelmatig contact met elkaar. Overigens is er nog wel een groot verschil in de volwassenheid van de diverse dochters, en blijkt het voor veel organisaties soms lastig om de generieke referentiearchitecturen aan te passen en in te passen in hun eigen architectuur. Veel elementen en componenten zijn niet of onvoldoende gedefinieerd om als kant-en-klaar raamwerk te dienen om een overheidsorganisatie haar eigen service georiënteerde architectuur te laten ontwerpen. Vanuit strategie, beleid en informatie management dient, met de principes uit de relevante referentiearchitectu(u)r(en) als kader, een eigen vertaalslag gemaakt te worden naar producten en diensten, naar bedrijfsprocessen, naar informatiestromen, naar een applicatielandschap en naar infrastructurele componenten.

5. Is de ICT architectuur in overeenstemming met wat een SOA vereist?

En daarmee komen we weer terug bij de kernvraag, de oorspronkelijk aanleiding, van de audit. De beantwoording van deze vraag werd opgedeeld in een aantal subvragen:

  • Voldoen de door de organisatie gedefinieerde ontwerpprincipes aan de SOA principes?
  • Voldoet de enterprise service bus (ESB) implementatie aan de SOA principes?
  • Voldoen de services aan de SOA principes?

Voldoen de door de organisatie gedefinieerde ontwerpprincipes aan de SOA principes?

Allereerst werden de door de organisatie gedefinieerde ontwerpprincipes getoetst aan de SOA principes. Voorbeelden van de gedefinieerde ontwerpprincipes zijn:

  • Applicatieberichten, en -exceptions, worden gelogd in de ESB;
  • Authenticatie vindt plaats op basis van Microsoft Active Directory;
  • Berichtenverkeer via de ESB wordt gelogd in de ESB;
  • Communicatie tussen front-, mid- en backoffice vindt plaats middels de ESB;
  • De communicatie tussen de servers en de ESB vindt plaats middels SSL;
  • De shared webservices zijn op basis van WCF gebouwd;

Het door de organisatie gebruikte technische framework (Windows Communication Foundation) bood een belangrijke basis voor het voldoen aan de SOA principes. Andere ontwerpprincipes hadden geen relatie met SOA, maar zijn wel ondersteunend in het verwezenlijken ervan. De principes die SOA niet direct ondersteunden, deden sowieso geen afbreuk aan de SOA principes.

De conclusie werd dan ook getrokken dat de door deze overheidsorganisatie gedefinieerde ontwerpprincipes een SOA ondersteunden.

Voldoet de enterprise service bus (ESB) implementatie aan de SOA principes?

De SOA wordt georchestreerd door een Message Broker met behulp van Universal Description Discovery & Integration (UDDI). UDDI is een op Extensible Markup Language (XML) gebaseerd register waarmee het mogelijk is voor organisaties om zichzelf en de services die ze leveren via het Internet te presenteren. Het uiteindelijke doel is het stroomlijnen van online transacties door het voor bedrijven mogelijk te maken elkaar te vinden, en om hun systemen te kunnen laten samenwerken.

De ESB en de Message Broker zijn geïmplementeerd door gebruik te maken van Microsoft BizTalk Server 2009. De ESB wordt gerealiseerd door de Microsoft BizTalk ESB Toolkit 2.0 implementatie op BizTalk. Er is een migratie gedaan van Microsoft BizTalk Server 2006 met Microsoft BizTalk ESB Toolkit versie 1.0 naar het huidige platform. De Message Broker is opgezet om alle in en uitgaande externe message handling te doen: dit is de enige plek waar informatie de organisatie in en uit gaat. De UDDI wordt geïmplementeerd door Microsoft UDDI services en bevat alle services en functies die via de ESB beschikbaar zijn. De conclusie werd getrokken dat de door de overheidsorganisatie geïmplementeerde Message Broker, EUDDI en ESB een SOA ondersteunen.

Voldoen de services aan de SOA principes?

Op basis van de onderkende hoofdprocessen en SOA applicatieketens, en de relaties hiertussen, werd vastgesteld welke hoofdprocessen reeds gebruik maken van een SOA applicatieketen, en welke niet. Voor de SOA applicatieketens werden vervolgens de gedefinieerde services in kaart gebracht . Overigens werd gebruik gemaakt van professionele architectuur tooling o.b.v. Archimate om de resultaten te analyseren en presenteren. De services werden stuk voor stuk beoordeeld op de SOA principes waarbij gebruik werd gemaakt van de technische implementatiedetails van elke ontsloten service.

De algehele conclusie voor de onderzochte SOA services was dat deze in hoge mate voldoen aan alle SOA principes, met uitzondering van de zeer beperkte functionaliteit van één specifieke service. Wel kan het “service discoverability” principe in sommige gevallen beter geïmplementeerd worden, waarbij dient te worden vermeld dat de huidige implementatie werkbaar is en ook effectief in gebruik is.

6. Voldoet de architectuur aan de van toepassing zijnde referentiearchitecturen?

De architectuur van deze overheidsorganisatie is getoetst op alle principes uit de van toepassing zijnde referentiearchitecturen. De belangrijkste van toepassing zijnde referentiearchitecturen zijn NORA en PETRA geweest. Hierbij zijn de principes van deze architecturen gehouden tegen de door de organisatie zelf opgestelde principes, eisen en wensenprogramma’s die zijn gebruikt voor het ontwikkelen van de ESB en gelieerde services. Wat duidelijk werd is dat de door de organisatie opgestelde principes veelal pragmatisch en ook technischer van insteek waren. Waar vanuit de meer applicatie en infrastructuur gerichte ICT verantwoordelijkheid gestuurd kan worden op de uitgangspunten en richtlijnen, heeft deze sturing plaats gevonden en vindt deze vandaag de dag nog steeds plaats. Echter, daar waar de verantwoordelijkheid voor de navolging van uitgangspunten en richtlijnen aan de functionele kant - ook wel de “informatiekant” of “business kant” genoemd - behoort te liggen, wordt hier door de organisatie (nagenoeg) geen invulling aan gegeven. Of, anders gezegd: de afdeling ICT doet wat zij kan doen, maar mist de interactie met een informatie management functie aan de gebruikerskant. En hiermee werd meteen de belangrijkste aanbeveling gevonden, waar verderop in dit artikel op terug zal worden gekomen.

7. Welke e-overheid bouwstenen zijn relevant en wat is de status van implementatie?

Op basis van een overzicht van alle bouwstenen, projecten, initiatieven en ontwikkelingen die onder de paraplu “e-overheid” geschaard kunnen worden, is bepaald welke bouwstenen etc. relevant zijn voor de overheidsorganisatie, en wat de status van de implementatie was.

De organisatie bevindt zich in een complex speelveld, zowel ten opzichte van andere overheidsorganisaties als voor wat betreft het maatschappelijk speelveld waarin zij opereert. Vanuit de overheid wordt hard gewerkt aan het implementeren van de “Andere Overheid”. De hiervoor aangereikte e-overheid bouwstenen zijn in grote getale relevant. De status van de huidige implementatie van deze bouwstenen laat ruimte voor verbetering zien. Met name op het gebied van DigiD, DigiD Machtigen, Digimelding en Digipoort dient een inhaalsslag gemaakt te worden. Ook verdient het aanbeveling om concreet aan de slag te gaan met e-Herkenning voor bedrijven, e-Inspecties, e-Formulieren en e-Facturen, alhoewel deze laatste drie e-overheidsbouwstenen geen verplichting zijn. Positieve uitzondering zijn de bouwstenen voor het gebruik en de verwerking van kadastrale gegevens.

8. Wat kunnen wij verbeteren?

Ten slotte werd als slotonderdeel van de audit een advies geformuleerd ten aanzien van de verbeteringen die deze overheidsorganisatie zou kunnen c.q. “moeten” doorvoeren.

Een van de belangrijke aanbevelingen betreft de implementatie van de e-overheid bouwstenen. Om enerzijds wettelijke aansprakelijkheden en sancties te voorkomen en anderzijds de e-dienstverlening te optimaliseren dient vanuit de functionele kant van de organisatie de koe bij de horens te worden gevat, en bepaald te worden op welke manier de diverse bouwstenen in met name de bedrijfs- en informatiearchitectuur, en uiteindelijk dus ook in de technische architectuur, geïmplementeerd gaan worden. Dit impliceert het formuleren van een hiërarchie van doelarchitecturen, de “soll”, zodat op basis van goede grip op de “ist” een migratiepad c.q. plateauplanning vastgesteld kan worden.

Om dit te bereiken dient aan de bedrijfsproceskant en informatiekant van “organiseren” explicieter invulling gegeven te worden. De informatie management functie van deze overheidsorganisatie is onvoldoende ingevuld. Vervolgens dienen alle te nemen stappen ten aanzien van de inrichting van de organisatie en de ondersteunende ICT architectuur plaats te vinden onder een duidelijke integrale sturing, primair vanuit bedrijfsprocessen en informatiemodellering en slechts secundair vanuit de applicatie- en infrastructuurhoek.

Overigens speelt dit ook een belangrijke rol bij het efficiënter laten opereren van deze overheidsorganisatie, wat een van de belangrijke doelstellingen voor de komende jaren is, gegeven de continue druk op kosten.

De conclusies van de audit worden op het moment van schrijven van dit artikel besproken in het managementteam van de Divisie Middelen van de betreffende organisatie.

Categorie:   
Auteur(s)
afbeelding van tomderidder
Tom de Ridder
ValueBlue - Principal Consultant

Tom de Ridder is principal consultant bij ValueBlue. Hij kan bereikt worden op tom.de.ridder@valueblue.nl.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.