Difference between revisions of "3.4.2 SOA voor een Organisatie"

From Geonovum Wiki
Jump to: navigation, search
(Registraties en ‘data bij de bron’-principe)
 
m (1 revision)
(No difference)

Revision as of 09:56, 26 September 2009


Een SOA en de services die binnen een organisatie gebruikt worden, hebben in de basis geen andere levenscyclus dan de meer traditionele applicaties die door organisaties gebruikt worden. Toch zijn er een aantal verschillen die service oriëntatie anders maken en waar speciale aandacht noodzakelijk is die in een traditionele omgeving niet of veel minder speelt. Hieronder wordt daar op ingegaan.

Ontwikkelen

Bij het ontwikkelen van functionaliteit binnen een applicatie zijn de gebruikers bekend. In een SOA waar services ontwikkeld worden zijn de gebruikers niet altijd bekend. Een service zal initieel altijd gebouwd worden met een gebruiker in het vizier, maar om het nut van een service te optimaliseren is het noodzakelijk de service te ontwikkelen voor een bredere gebruikersgroep. Ofwel een service moet ontwikkeld worden met hergebruik als doelstelling. Dit betekent dat voor het ontwikkelen van een service gebruik gemaakt moet worden van gestandaardiseerde informatiemodellen, die door een brede gebruikersgroep wordt ondersteund.

Binnen de geografische wereld zijn dergelijke informatiemodellen beschikbaar in de vorm van Applicatie Contextmodellen. Het is aan te bevelen zowel de input als het resultaat van een service (functie en informatieverzoek) in te vullen met deze standaard informatiemodellen. Als bijvoorbeeld een service een bestemmingsplan oplevert, dan is het verstandig hiervoor het gestandaardiseerde bestemmingsplan informatiemodel toe te passen.


Doordat services niet alle gebruikers kennen en zeker niet de potentiële hoeveelheid gebruikers, zullen bij de ontwikkeling continue afwegingen gemaakt worden wat het gevaar is voor de leverende partij indien de service een groot succes wordt. Adequate maatregelen om deze risico’s te voorkomen moeten ingebouwd worden.
Zo kan het voorkomen dat een service informatie oplevert uit een kernsysteem van de leverancier. Doordat het aantal service afnemers te groot wordt kan dit ertoe leiden dat het kernsysteem niet meer reageert en de leverancier zijn kernproces niet meer kan uitvoeren. Tal van deze scenario’s met risico’s voor leverancier en afnemer zijn mogelijk. Deze zijn actief, proactief en passief op te lossen.

  • Actief zorgt ervoor dat de applicatie die de service levert voldoende schaalbaar is dat er geen last kan ontstaan. Dit kan gezien worden als een verzekeringspremie die wellicht nooit tot uitkering hoeft te komen.
  • De proactieve methode kan plaatsvinden door actief te monitoren op het gebruik en het aantal toegelaten actieve serviceverzoeken te beperken, of indien er een grenswaarde wordt overschreden de applicatie (en dus ook de service) op te schalen.
  • De passieve methode is afwachten en oplossen als het probleem zich voordoet. Doordat een service de grenzen van een applicatie verlegt van de organisatie naar de grenzen van het Internet speelt ook de behoefte aan 7x24 beschikbaarheid een rol.


Een eis die vanuit SOA gesteld wordt aan de service afnemers is dat deze minimale tot geen afhankelijkheden moeten creëren ten opzichte van de gebruikte services. Eventuele wijzigingen die aan een service worden aangebracht moeten zoveel mogelijk zonder aanpassingen aan de code geabsorbeerd kunnen worden. Zo zullen nieuwe informatie elementen die optioneel worden toegevoegd aan het resultaat er niet toe moeten leiden dat de applicatie van de service afnemer niet meer werkt.

Beheren (Governance)

Vanuit de ontwikkeling gezien mag de afnemer geen ‘last’ mag hebben van service wijzigingen. Vanuit de leverancier zal altijd de gebruiker geïnformeerd moeten worden over het wijzigen van een servicedefinitie. Deze definitie kan gezien worden als een bindend contract. Aangezien in de ultieme SOA de service aanbieder niet altijd op de hoogte hoeft te zijn van alle afnemers, is dit een gebied dat speciale aandacht vraagt. De rol die hier gevraagd wordt, is een rol van een sectorcoördinator die als centraal punt fungeert en service aanbieders en afnemers bij elkaar brengt. Vanuit deze overzichtsrol kan ook analyse uitgevoerd worden op welke servicegebruikers geraakt worden door wijzigingen aan services. Deze partijen kunnen vervolgens actief geïnformeerd worden.


Het principe 'contract is contract en services zullen nooit wijzigen' is geldig binnen de SOA context. Alleen is het in de praktijk onmogelijk om een service een oneindige levensduur te geven. Het is gebruikelijk om bij uitbreiding van een service deze als ‘nieuwe’ naast de bestaande aan te bieden en de gebruikers de mogelijkheid te geven een transitie te doen naar deze service. Door het aantal ‘onderhouden’ versies of de levensduur van een versie, nadat deze is vervangen door een nieuwe te definiëren, kan een oneindige levensduur en wildgroei voorkomen worden. Het vraagstuk rondom versiebeheer speelt niet alleen voor de daadwerkelijke service, maar ook voor het serviceregister waar de service beschrijvingen worden vastgelegd en beheerd. Het is van groot belang dat versies van service definities ‘oneindig’ bewaard blijven en zo wijzigingen in de tijd te kunnen traceren.


Een beheersrol, die in een normale applicatiecontext niet bestaat is het stimuleren van hergebruik. De beheerorganisatie heeft tot taak om SOA actief te promoten en het hergebruik van beschikbare services te stimuleren. Ook indien er verzoeken komen voor nieuwe services zal de beheerorganisatie actief moeten participeren in het definiëren van een service die in een brede context toepasbaar is. Een sectorcoördinator zou de rol van ‘verkopen’ van de service op zich kunnen nemen en vanuit de één loketgedachte een platform kunnen bieden om de aanbieders en vragers bij elkaar te brengen.


Registraties en ‘data bij de bron’-principe

Binnen iedere organisatie is voor interne doeleinden vele registraties en administraties te identificeren die van belang zijn voor een tal van (interne) afnemers. Daarbij is 'registratie' te omschrijven als: "het proces waarbij eenduidige identificatie plaatsvindt van het desbetreffende beheerobject op basis van een vaste procedure, veelal op basis van of resulterend in een uniek identificatiekenmerk of document".
Een directe afgeleide van de registratie is de duurzame vastlegging van de geregistreerde gegevens en/of de wijze waarop de afhandelprocedure is doorlopen in een administratie. Vrijwel iedere organisatie maakt voor registratie en administratie gebruik van automatiseringshulpmiddelen als applicaties en databases.


Voorbeelden van registratiefuncties en administraties die binnen elke organisatie voorkomen zijn:

  • de administratie van werkzame personen,
  • gebouw en/of kameraanduidingen,
  • kostenplaatsen,
  • debiteurnummers,
  • projectnummers.


Belangrijk principe bij het inrichten van dergelijke registraties is het zoveel mogelijk uitgaan van 'data bij de bron' dat daardoor zowel garanties biedt op efficiency als data-integriteit.


Binnen maar ook buiten de organisatie zijn verschillende afnemers van deze gegevens te onderkennen waarbij het vanuit het oogpunt van kosten en data-integriteit efficiënt is de functies zoveel mogelijk te centraliseren. Afhankelijk van inhoud, belang en omvang zal een specifieke functionaris of een specifiek organisatieonderdeel verantwoordelijk zijn voor het verloop van het gegevens verzamelproces en de juistheid van de data. Daarbij kunnen ook specifieke organisatorische of technische maatregelen van toepassing zijn als functiescheiding en (externe) kwaliteitscontroles door toezichthouder of auditor.


Het voorgaande geldt nadrukkelijker voor publiekgerichte organisaties aangezien registraties daar een bijzonder belang hebben vanwege:

  • de monopolistische en daardoor unieke positie van de publieke organisaties voor een bepaald werkgebied,
  • een brede afnemersgroep of een hoog volume aan afname.


Een voorbeeld van publieke registers is het register van ingezeten voor een bepaalde (staatkundige) administratieve eenheid die als consument tastbaar worden in documenten als een geboortebewijs, een bewijs van leven en een paspoort. Andere publieke registers zijn die van kentekens voor voertuigen en registraties voor vliegtuigen. Als consument worden dergelijke registraties meestal zichtbaar door een 'goedkeuringsprocedure' die kan bestaan uit een publicatie-, openbaarmakingfase en een bezwaarprocedure die uiteindelijk al dan niet resulteert in een document als een kentekenbewijs, een verblijfsvergunning, een huwelijksvergunning en woonvergunning.

Dit samenhangend stelsel van registraties, zowel basisregistraties als kernregistraties, is een fundamentele component in een nationaal stelsel van voorzieningen zoals een Geo-Informatie Infrastructuur (GII).



previous Services Oriented Architecture (SOA) next