De Belastingdienst krijgt niet één service-oriented architecture (soa), maar meerdere. 'We splitsen alles in stukjes', zegt staatssecretaris Jan Kees de Jager in een vraaggesprek met Computable. 'We gaan wel verder met zo'n architectuur, maar niet een totale voor de Belastingdienst. Er komt er bijvoorbeeld eentje voor de douane of voor de toeslagen.' De afdeling IT Beleid let er op dat deze architecturen op elkaar aansluiten.
De Jager gaf in 2007 in een interview met Computable al aan dat hij denkt dat een service-oriented architectuur voor de Belastingdienst een oplossing is. 'We presenteren elk jaar op Prinsjesdag het belastingplan dat vervolgens pas in november plenair in de Tweede Kamer wordt behandeld, en in december in de Eerste Kamer, en dan in de Staatscourant staat en ingaat per 1 januari van het nieuwe jaar. Dan begrijpt u vast dat er uiterst hoge schaalbaarheidseisen aan de ict-omgeving van de Belastingdienst worden gesteld. Het verschil met grote systemen van andere organisaties is dat die veel meer tijd krijgen om een verandering in te zetten. Gezien onze uitgangspunten geniet zo'n flexibele ‘service-oriented architecture' mijn absolute voorkeur', zei de staatssecretaris in dat gesprek.
Meer aandacht aan infrastructuur
In een brief aan de Tweede Kamer schrijft de staatssecretaris dat hij meer aandacht gaat geven aan de infrastructuur bij de Belastingdienst. Er wordt momenteel te veel geld gestoken in applicatie-ontwikkeling. 'De infrastructuur moet gewoon goed zijn bij een service-oriented architectuur. Dat is een voorwaarde, anders gaat een soa nooit goed draaien.'
De Belastingdienst gaat de projecten die het doet minder groot maken. De projectduur mag maximaal een jaar zijn en het budget maximaal tien miljoen euro. Daardoor zijn projecten makkelijker te sturen en lopen ze minder makkelijk uit de hand, zegt de staatssecretaris. 'Daar is een soa uitermate geschikt voor.'
Hoe meer SOA-stukjes belastingdienst er bestaan, des te makkelijker is de huidige – monolitische – belastingdienst later bedrijfskundig op te splitsen in onderlinge en onafhankelijke units. Regeren is immers vooruitzien.
Een volledige SOA voor de belastingdienst is later juist prima op te splitsen. Verschillende services in je organisatie staan op zich en verhouden zich alleen op correct wijze naar anderen. Stukjes aan elkaar plakken is feitelijk hetzelfde doen als wat er zonder SOA gebeurt… Hmmmm… Ik hoop bijna dat ik het volledig verkeerd heb.
Beste Ronald Vermeij,
Ik weet niet wie jou salaris betaald, maar werk je ook wel eens overdag?
Gaat dit nog wel lukken nu de 500 externen recent de laan zijn uitgestuurd?
De kern van SOA is toch opknippen van bedrijfsfuncties in kleine services? Meerdere SOA’s klinkt dan een beetje vreemd. Of je richt je op het inrichten van services of je doet dat niet.
Misschien een architect die hier zijn/haar licht op kan laten schijnen?
Dus als ik het verhaal goed begrijp, en een PID (project initiation doc.) wijst uit dat een project 2 jaar en 20 miljoen kost. Dit project moet worden opgesplitst. Dan begrijp ik dat je een beter overzicht hebt, en dus met enig geluk geld zou kunnen gaan besparen. Risico is, naar mijn bescheiden mening, dat je funktioneel zaken/services gaat splitsen, terwijl we juist zouden willen dat de belastingdienst krimpt en niet nog meer eilandjes binnen eigen gelederen gaat creeeren en uiteindelijk communicatie problemen genereerd en op lange termijn meer geld gaat kosten.
Grappig toch hoe makkelijk je associaties krijgt bij teksten als “belastingdienst … totale Soa” . Wens vader gedachte, of ligt het gewoon aan mij?
Maar alle gekheid op een stokje – net als D’s commentaar, hoezo “meerdere Soa’s”? Dat maakt mij een beetje wantrouwig: de roep om intergale overall control is kennelijk bij de belastingdienst nog zo sterk aanwezig dat er niet echt gebroken is met het denken in ouderwetse megasystemen. Dan wordt het middel Soa gegarandeerd erger dan de kwaal.
De belastingdienst krijgt als ik het goed begrijp een niet samenhangende architectuur maar allemaal losse eindjes . . .
Is de belastingdienst bijvoorbeeld een vakantiepark met allemaal losse huisjes?
Een architectuur zorgt juist wel voor de samenhang; het fundament waar we jaren op kunnen bouwen; of gaat dat architectonische principe niet op bij ICT?
Het besluit om geen Belastingdienst brede SOA in te richten klinkt wel logisch. Immers niet alle bedrijfsprocessen hebben raakvlakken met elkaar. In het voorbeeld van Douane en Toeslagen kan ik mij dat bijvoorbeeld voorstellen. Beide architecturen hebben een andere doelgroep en dus weinig tot geen raakvlakken met elkaar. Het aan elkaar koppelen, en daarmee de architectuur onnodig complex maken, is dan ook een onlogische keuze.
Eerst eens de brief en de stukken lezen die naar de kamer zijn gegaan….
Daarin staat dat de tijd nog niet rijp is voor SOA. Eerst puinruimen. En alle vernieuwing even in de ijskast.
Wat onze zeer geachte staatssecretaris hier doet, is proberen te verhullen dat hij gestuurd heeft op de juiste dingen op het verkeerde moment.
Ik ben het volledig eens met de reactie van Michel. Ik denk dat het inderdaad verstandig is om de juiste begrenzing binnen je SOA landschap te hanteren. Keep it simpel.
SOA kan op zich al complex genoeg zijn. SOA kan op vele verschillende manieren geimplementeerd worden en het is verstandig om van te voren het concept te bepalen.
Ook het hanteren van het juiste ambitieniveau is belangrijk. Begin klein en bouw het later uit. Zorg dat je voorbereid bent op het totaal, maar niet alles hoeft direct/tegelijk.
Een goed begin is het halve werk.