Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Service-oriëntatie is nuttiger dan ooit tevoren

 

Computable Expert

Ad Gerrits
Enterprise architect, AG4IT | gemeente Nijmegen. Expert van Computable voor de topics Infrastructuur, Overheid en Maatschappij.

Service-oriëntatie is een benadering waarbij gedacht wordt in termen van diensten die partijen uitwisselen. In een wereld waarin samenwerking alsmaar belangrijker wordt, kan service-georiënteerd denken en doen nog bruikbaarder worden dan het altijd al was.

In ict-kringen wil de afkorting SOA (Service Oriënted Architecture) nog wel eens werken als de spreekwoordelijke rode lap op een stier: het is luchtfietserij van ivoren toren-architecten ('SOA-klutsers'), die in de praktijk vooral leidt tot dure en onbeheersbare spaghetti. Om misverstanden te voorkomen: onder de vlag van 'we doen SOA' is het inderdaad prima mogelijk om er een puinhoop van te maken. Maar is dat niet iets dat voor iedere benadering geldt?

Diensten

Wat maakt dan dat ik, na meer dan 25 jaar ervaring met projecten waarbij it een rol speelt, service-oriëntatie zie als de geschiktste manier om veel veranderuitdagingen aan te gaan? Voor een deel zit hem dat in het ogenschijnlijk simpele begrip 'dienst'. Iedereen weet immers wat diensten zijn. De hele dag door hebben we er mee te maken. Van de wekker die ’s ochtends zijn rinkeldienst levert, tot de cateraar die de lunch verzorgt, tot Netflix, die ’s avonds de volgende aflevering van Suits levert. Naast dienstenafnemer, ben je ondertussen ook nog eens doorlopend leverancier van diensten. Bijvoorbeeld wanneer je op aanvraag een product levert of simpelweg wanneer je voor collega’s koffie haalt.

Niks bijzonders dus, diensten. Toch blijkt het opzetten van een dienstenbril bij complexe veranderprocessen heel nuttig te kunnen zijn. De ene keer om te snappen hoe een systeem werkt, de andere keer om te bepalen hoe een systeem het beste met collega-systemen kan gaan samenwerken. Waarbij je 'systeem' in de ruimste zin van het woord mag lezen.

Helaas wordt het begrip 'service-oriëntatie' vaak beperkt tot de inzet van technologie. Bijvoorbeeld wanneer het gaat om de inzet van een enterprise servicebus of het gebruik van webservices. Dat mag uiteraard, maar het is goed te bedenken dat het slechts een stukje van de werkelijkheid is waar het dienstenmodel bruikbaar is. Ook een bedrijf, of een groep van bedrijven, is bijvoorbeeld te zien als een systeem. Eentje dat zijn bestaansrecht zelfs ontleent aan het leveren van diensten (waarbij it overigens steeds vaker een rol speelt, dat dan weer wel).

Werken aan samenwerken

Om maximale resultaten te bereiken wordt service-oriëntatie toegepast binnen verschillende bedrijfsdomeinen. Binnen ieder domein zijn afspraken nodig over te leveren diensten en de voorwaarden waaronder dit gebeurt. Afhankelijk van het domein zijn er andere uitvoerders bij betrokken en verschilt de aard van de afspraken. Het doel is in de kern echter vaak hetzelfde: het mogelijk maken van goede samenwerking tussen partijen.

Juist dat aspect, het ondersteunen van samenwerking, maakt dat service-oriëntatie voor mij als benadering waardevoller is dan ooit tevoren. Want alles zelf willen doen, is tegenwoordig steeds minder een optie. Niet voor bedrijven, niet voor bedrijfsprocessen en niet voor applicaties. Samenwerken is daarmee nauwelijks nog een keuze, maar eerder een noodzaak om te overleven.

In de praktijk blijkt samenwerken, zowel bij mensen als bij softwaresystemen, veel lastiger te zijn dan het aanvankelijk vaak lijkt. De uitdagingen die er bij horen. worden helaas niet opgelost door service-georiënteerd naar de wereld te gaan kijken. Maar het helpt wel om meer helderheid te creëren en stelt je daarmee in staat om te zorgen dat aan essentiële randvoorwaarden is voldaan. Zodat duidelijk wordt wie het beste wat kan gaan doen en welke partners het beste bij je passen.

Alive and kicking

In tegenstelling tot wat wel eens wordt beweerd, is service-oriëntatie wat mij betreft dus niet dood maar juist springlevend. Niet als heilige graal waarmee alles goed gaat komen, maar als benadering die goed past bij de richting waarin onze maatschappij zich ontwikkelt.

Als een volgend artikel wil ik beschrijven hoe service-oriëntatie in de praktijk kan helpen bij de naderende overdracht van rijkstaken naar gemeenten per 1 januari 2015. Een enorme operatie, waarbij het succes voor een belangrijk deel zal gaan afhangen van de mate waarin het lukt om goed te gaan samenwerken.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5178763). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Een artikel met een dergelijke abstractie illustreert perfect waarom SOA nooit een succes is geworden.

Hallo Ad,

Ik ben het volledig met je eens. Je ziet in het algemeen dat het "hebben" van dingen en het zelf uitvoeren van dingen steeds minder belangrijk wordt. Het gaat erom dat diensten worden geleverd aan afnemers.

Het helpt overigens wel als deze diensten vervolgens ook op een generieke wijze worden vertaald naar oplossingen. Dit stimuleert hergebruik en dat heeft ook veel met samenwerking te maken. Door samen IT diensten te gebruiken kunnen organisaties (zoals gemeenten) veel geld besparen.

Hey Ad, leuk stuk, wel wat "high over", maar daardoor niet minder waar. Dit is alvast mijn korte reactie want ik vermoed dat er nog reacties zullen volgen.

"In tegenstelling tot wat wel eens wordt beweerd, is service-oriëntatie wat mij betreft dus niet dood maar juist springlevend."

Precies dat. En heel goed regie snappen, want dat die heb je nodig om de boel in de klauw te houden. Dat je er een oerwoud van kan maken is alleen maar een indicator dat het dus heel krachtig is.

Zelf ben ik nagenoeg 100% Service-oriented. Weg met de monolithische systemen!


@henri: klopt, behoorlijk "high-over". Zeker in "Computable" waar het vaak over de inzet van ICT gaat. Ik wil in het vervolg dan ook aan de hand van een actueel voorbeeld toelichten waar ik de grote voordelen van zo'n benadering zie. Zeker ook wat betreft inzet van ICT die er daarbij anders uitziet dan nu vaak het geval is.

@kj: ik hou wel van korte heldere reacties (ook als we het niet eens zijn). "SOA nooit een succes is geworden" maakt het wel lastig om op te reageren. Afhankelijk natuurlijk van wat je onder "SOA" verstaat, zijn er denk ik volop voorbeelden te noemen waar service-oriëntatie tot succes in de praktijk heeft geleid. Zoals gezegd: in het vervolg een aantal praktijkvoorbeelden.

Leuk stukje Ad, ben het ook 100% met je eens.

Zelf gebruik ik een framework binnen Delphi wat sterk leunt op een services concept. Daar geef ik ook regelmatig lezingen over bij gebruikersgroepen en het voorbeeld van diensten laten samenwerken (in plaats van services) helpt vaak bij het uitleggen van het concept.

Waar ik het vaak fout zie gaan zijn de koppelvlakken tussen de services, de API's. Je ziet daar vaak gebeuren dat onderdelen heel strak aan elkaar gekoppeld worden (en dus kennis van elkaar moeten hebben) in plaats van een los, stateless en bij voorkeur asynchroon koppelvlak. Door zo'n strakke koppeling krijg je nooit een schaalbare en herbruikbare oplossing.

Wat is jouw ervaring met die koppelvlakken?

@Ad. Zie de definitie en kenmerken onder :
http://nl.wikipedia.org/wiki/Service-ori%C3%ABntatie

In de ERP wereld waar ik in werk is SOA nooit een succes geworden omdat een SOA implementatieproject gewoonweg veel te kostbaar is. Je hebt het immers over de implementatie van een architectuur, een compleet frame-work in plaats van de implementatie van een standaard oplossing. Als je het hebt over een standaardoplossing voor een Enterprise Service Bus (ESB) dan kan je denken aan een produkt als SAP PI ( http://help.sap.com/saphelp_nwpi711/helpdata/en/70/e6b9f493bd4cba98b469bb698e2c88/frameset.htm ) dat wel een succes is te noemen.

Echter, iets simpels als een Remote Function call (RFC), voldoet ook aan de kenmerken van SOA. ( http://en.wikipedia.org/wiki/Remote_Function_Call ). Het is een gewoon een functie die in een ander systeem wordt aangeroepen en wat data retourneert. Het SOA concept is in feite oeroud maar binnen de architectuurwereld is het geworden tot een abstractie. SOA kan slechts overleven via bruikbare implementaties en niet als concept.

@benno: de kwaliteit van koppelvlakken is uiteraard sterk mede bepalend voor de kwaliteit van een service. Mijn ervaring daarmee is goed. Het ligt natuurlijk aan het type service, maar bij veel services die ik ben tegengekomen zijn er prima (stabiele) interfaces die volop mogelijkheden bieden voor divers (her)gebruik. Feitelijk zou ook een van drijfveren van de maker moeten zijn als hij zijn afnemers goed wil bedienen. Het heeft me vaker verbaast hoe eenvoudig je services kunt gebruiken en hoe goed ze werken. Dit terwijl ik echt geen meester-programmeur ben.
@kj: het lijkt alsof we een beetje langs elkaar heen praten; in mijn stuk had ik het bewust over service-orientatie om het beladen begrip "soa" te vermijden daar heel verschillende invullingen aan worden gegeven. Dat het concept oeroud is ben in helemaal met je eens. Dat je een 'compleet framework' zou moeten implementeren om met SO-principes te werken ben ik niet met je eens. Als dat nodig zou zijn en er is een praktisch alternatief via een standaardoplossing zoals je dat beschrijft, zou ik daar zeker ook voor kiezen.

@Ad
Leuk verhaal maar bij veel SOA implentaties van de overheid gaat het om service naar de ambtenaar in plaats van de belastingbetaler. Gezeur over participatiemaatschappij is ook niet meer dan het continueren van eigen incompetentie onder een andere vlag.

Kijkend naar boekhoudingen laat al dat automatiseren bij gemeenten geen dalende lijn zien maar belastingen wel een stijgende. Als ik even een aantal standaard diensten ga benchmarken tussen gemeenten dan zie ik toch opmerkelijke verschillen in simpele administratieve processen.

Let wel dat we het hier hebben over retributies wat de nodige vragen van de ACM zou moeten oproepen. Misschien wordt het dus gewoon tijd om de gehele overheid te offshoren, voor de communicatie maakt het toch niks uit.

@ewout ik weet niet precies wat je met "SOA implementaties bij de overheid" bedoeld, maar ik vind dat er de laatste 10 jaar -juist op terreinen waar service-georiënteerd werken een rol speelt- veel vooruitgang is geboekt. Bijvoorbeeld in de vorm van een aantal basisvoorzieningen (http://www.e-overheid.nl/onderwerpen/over-de-e-overheid/basisinfrastructuur-i-nup) die het technisch mogelijk maken dat al die overheidsinstellingen beter gaan samenwerken. Voorzieningen als DigiD/eHerkenning en basisregistraties leveren dagelijks enorme voordelen op (oa financieel!) t.o.v. het 'ieder automatiseert voor zich' dat tot 10 jaar geleden nog plaats vond.

@Ad
Misschien dat je eens het schrijven van WRR aangaande de i-Overheid moet lezen, de burger verliest meer dan dat deze wint:

"Het koppelen en uitwisselen van informatie gaat gepaard met de erosie van schotten tussen beleidsterreinen, tussen overheidsorganisaties en in relatie tot de private sector. Deze schotten worden in toenemende mate – ook in de publieke opinie – gezien als een sta-in-de-weg voor bestuurlijke daadkracht. De populariteit van gegevensuitwisseling binnen ketens en netwerken, gefaciliteerd door unieke nummers (Burgerservicenummer) en authentieke registraties, maakt dat informatie eenvoudig over traditionele grenzen heen vloeit – dit ondanks het feit dat de verantwoordelijkheid voor de kwaliteit en betrouwbaarheid daarvan niet zijn meegeëvolueerd. Informatie verspreidt zich en wordt door vele overheden gebruikt en bewerkt. Overheidsorganen met zeer verschillende taken en doelstellingen maken steeds vaker gebruik van dezelfde ‘gepoolde’ informatie. De verantwoordelijkheid voor (de juistheid van) informatie is echter niet scherp belegd waardoor burgers er rekening mee moeten houden dat ‘hun’ informatie in publieke en private handen een eigen leven kan gaan leiden."

Hoewel dit maar één passage uit rapport van 2011 is lijkt het me toch een wat ander beeld te schetsen en mijn eerdere reactie wat meer te onderbouwen.

Laat ik de vragen andersom stellen:

Welke middelen zijn er om te communiceren met diensten van derden?
Hoe leggen we goede verbindingen met de interne IT infrastructuur en de toename van cloud diensten?

Hoe maken we de samenwerking van tools van verschillende bedrijven mogelijk?

Hoe minder ERP hoe meer integratie, hoe zet je die integratie op een gemakkelijke, veilige en beheersbare manier op?

Dit lijkt me een prima pallet aan vragen voor de criticasters van service-orientatie. Ik ben oprecht benieuwd naar de oplossingen.

@ewout volkomen terecht dat je kritisch bent op hoe organisaties, juist overheidsorganisaties, met gegevens en gegevensuitwisseling omgaan. Zeker wanneer het om persoonsgebonden gegevens gaat. Ik zie service-oriëntatie geschreven als een neutrale benadering, die ook op dit punt een bijdrage kan leveren omdat afspraken over verantwoordelijkheden en gebruik er onlosmakelijk mee verbonden zijn. Zie bijvoorbeeld de landelijke basisregistraties, waar de beheerafspraken en voorwaarden voor gebruik heel helder zijn. En nee, het zorgt er niet voor dat alles in praktijk vervolgens altijd zorgvuldig gebeurt dus kritisch volgen blijft nodig.

In november komt Thomas Erl's Next Generation SOA uit. Een aanrader (ik was één van de Tech reviewers). Helder uitgelegd dat SOA nu belangrijker is dan ooit. Inclusief real-World case study.

Volgens mij is SOA in het wild juist aan populariteit aan het groeien. Maar zoals met alles is het maar net hoe je er mee om gaat.
En voor beleidsmensen is SOA vaak een abstract woord met een heel hoog abacadabra gehalte. Afhankelijk van de daadwerkelijke kennis hiervan is het maar af te vragen of deze goed genoeg is om op hoog niveau de risico's in te schatten. En bij de overheid kan je rustig stellen dat op een enkeling na de kennis zwaar onvoldoende is.

Verder is er ook nog een bijkomstigheid als je SOA gaat gebruiken dat bepaalde informatiestromen min of meer 'onzichtbaar' worden en alleen techneuten nog onder de motorkap kunnen kijken of alles wel naar behoren loopt.

En als het netwerk verkeer niet versleuteld is, is het redelijk eenvoudig om de content uit te vissen voor degenen die het netwerkverkeer kunnen onderscheppen.

En wat Ewout aansnijdt is eerder een specifiek probleem. Maar in deze context wel interessant. Want het gebruik van SOA binnen de overheid is wel leuk en aardig. Maar het heeft ook duidelijk kanttekeningen voor een bijvoorbeeld 'feature creep' of de integriteit van de data als er een typ fout wordt gemaakt en je een inval team door je voordeur heen krijgt omdat je naam nu exact overeenkomt met een notoire gezochte crimineel.
In die zin vrees ik ook dat de overheid een te mooi beeld wordt voorgehouden zoals het bekende filmpje van PinkRokkade.
Vandaar ook dat het van groot belang is om vanaf het begin het veiligheidsaspect zwaarwegend mee te nemen en dat als uitgangspunt van elke SOA hoort te zijn die gebruikt maakt van privacy gevoelige gegevens.

Vacatures

Stuur door

Stuur dit artikel door

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

×
×