Follow Us on Twitter

Omgaan met externe interfaces in een veranderende omgeving

Juli 2013 - Veel ICT projecten zijn beperkt tot een enkel bedrijf. Regelmatig is er echter ook een externe partij betrokken. Er moet bijvoorbeeld informatie van of naar deze externe partij gaan om de klant te bieden wat deze wil. Er moeten bijvoorbeeld betaalbestanden naar een bank gestuurd worden, en bestanden met transactiegegevens komen van de bank, en moeten verwerkt worden om te controleren of facturen (uit)betaald zijn.

Vaak wordt de communicatie tussen de partijen van te voren helemaal uitgedacht en afgesproken. De definitie van deze communicatie noemen we een interface. Het komt vaak voor dat de afgesproken interface niet geheel in staat blijkt te voldoen aan de wens van de opdrachtgever. In deze gevallen zal de interface dus aangepast moeten worden.

Dit Whitebook verkent een aantal mogelijkheden om met de wens om te veranderen om te gaan.

Weerstand tegen verandering

Omdat een interface een afspraak is tussen twee partijen is, is het vaak niet mogelijk deze zomaar te wijzigen. Niet elke partij zal exact dezelfde wens hebben waardoor het lastig is om tot overeenkomst te komen welke wijzigingen exact gedaan moeten worden. Het is dus zaak om afspraken te maken hoe er met wijzigingen omgegaan wordt, en op welke manier deze gedaan worden.

Omgaan met veranderingen in interfaces

Er zijn een paar gangbare strategieën om om te gaan met veranderende interfaces:

  1. De nieuwe interface vervangt de oude interface welke na conversie niet meer beschikbaar is (vervangen)
  2. Een interface zo ontwerpen met ruimte voor extra informatie. (flexibel)
  3. Verschillende versies van de interface naast elkaar aanbieden. (versioneren)

Het vervangen van een interface

De optie om te vervangen is de meest ingrijpende. Op het moment dat de aangepaste interface actief wordt, kan programmatuur die van de oudere interface uitgaat niet meer werken. Het kan zijn dat dit noodzakelijk is, bijvoorbeeld als de werkwijze dusdanig veranderd dat de oude interface niet meer relevant is. Ook kan het zijn dat er maar een beperkt aantal partijen gebruik maken van de interface waardoor een omschakeling nog gezamenlijk gemaakt kan worden. Hoe meer partijen er gebruik maken, hoe complexer deze omschakeling wordt.

Een voorbeeld waarbij een bestaande interface vervangen wordt door een nieuwe is het “nieuwe marktmodel” (NMM) voor de energiemarkt. Tientallen partijen zijn (soms al meerdere jaren) bezig om op 1 augustus gezamenlijk van interface over te gaan. Het NMM geeft meteen ook al het risico van deze strategie. Origineel moest er op 1 april overgegaan worden, doordat veel partijen niet op tijd klaar waren is dit enkele maanden opgeschoven.

In het onderstaande voorbeeld is de structuur van de XML veranderd.

Oud:

    <persoon>
        <voornaam></voornaam>
        <achternaam></achternaam>
        <straat></straat>
        <huisnummer></huisnummer>
    </persoon>

Nieuw:

    <persoon>
        <voornaam></voornaam>
        <achternaam></achternaam>
        <adres>
            <straat></straat>
            <huisnummer></huisnummer>
        </adres>
    </persoon>

Het gebruik van een flexibele interface

Omgaan met veranderingen bij een flexibele interface, is minder ingrijpend, in plaats van het wijzigen van de interface wordt de extra ruimte gebruikt om aan de veranderende wens te voldoen. Alhoewel hierdoor de interface niet aangepast moet worden vereist dit wel afspraken over hoe er met die ruimte omgegaan wordt. Als een partij extra informatie meestuurt naar een andere partij, dan moet die dit wel begrijpen, en kunnen verwerken.

Deze optie wordt momenteel gebruikt in de “Single Euro Payments Area” (SEPA). Hier worden gestandaardiseerde bestanden gebruikt (iso-20022) voor financiële operaties, zoals betaalopdrachten. In deze bestanden is veel extra ruimte beschikbaar om flexibel met de bestanden om te kunnen gaan. Helaas heeft dit ook een belangrijke keerzijde. Vrijwel elke (nederlandse) bank heeft een andere invulling gegeven aan hoe de bestanden ingevuld moeten worden. Standaard software die met elke bank moet werken heeft hier dus een grote uitdaging.

Een voorbeeld van een flexibele interface staat hieronder.

<persoon>
    <voornaam></voornaam>
    <achternaam></achternaam>
    <attributen>
        <waarde naam="straat" type="xsd:string"></waarde>
        <waarde naam="huisnummer" type="xsd:int"></waarde>
    </attributen>
</persoon>

Het versioneren van interfaces

Het versioneren van interfaces, laat toe dat er veranderingen in de interface zijn zonder dat bestaande gebruikers direct in de problemen komen, en zonder dat er (te) veel onduidelijkheid komt over de inhoud. Soms worden meerdere interfaces permanent naast elkaar aangeboden, maar meestal wordt er een einddatum op de oude versie gezet waarna deze niet meer beschikbaar zijn.

Twitter gebruikt bijvoorbeeld deze methode waardoor applicaties die Twitter gebruiken op een eigen gekozen moment over kunnen schakelen. Er zijn twee mogelijke interfaces naar Twitter. De oude versie 1.0 is binnenkort niet meer beschikbaar. Het is dus wel zaak om gebruikers van de oude interface duidelijk te maken dat er overgestapt moet worden.

Hieronder een voorbeeld van twee versies waarbij het versienummer in de XML staat. Het versienummer kan ook in het url gezet worden. Bijvoorbeeld http://www.example.com/interface/v1.0.

Versie 1.0:

<persoon versie="1.0" xmlns="nl.whitehorses.interface.1.0">
    <voornaam></voornaam>
    <achternaam></achternaam>
    <straat></straat>
    <huisnummer></huisnummer>
</persoon>

Versie 1.1:

<persoon versie="1.1" xmlns="nl.whitehorses.interface.1.1">
    <voornaam></voornaam>
    <achternaam></achternaam>
    <adres>
        <straat></straat>
        <huisnummer></huisnummer>
    </adres>
</persoon>

Op basis waarvan kiezen

Zoals hierboven al gelezen kan worden is er niet een enkele strategie die duidelijk beter is dan de andere. Om toch te kunnen bepalen welke strategie (of combinatie van strategieën) het beste past, moet de situatie eerst bekeken worden.

Over het algemeen bepaald de aanbieder van de interface hoe veranderingen in die interface gedaan worden. Er zijn uiteraard wel uitzonderingen zoals het eerder genoemde SEPA. In SEPA is er op europees niveau besloten welke interface er gebruikt moet worden. Een enkele bank heeft daar vrij weinig invloed op. Indien het niet mogelijk is om invloed uit te oefenen om de strategie van verandering (mede) te bepalen, dan zal de verandering als dusdanig geaccepteerd moeten worden. Dit Whitebook gaat er vanuit dat er invloed uitgeoefend kan worden danwel doordat de interface zelf aangeboden wordt, danwel doordat de aanbieder van de interface beinvloed kan worden.

Als er dan gekeken wordt naar de zaken die belangrijk zijn om te bepalen welke strategie te volgen dan zijn dat voornamelijk:

  1. Historie van de interface;
  2. Aantal en diversiteit van aanbieders van de interface;
  3. Aantal en diversiteit van afnemers van de interface.

Historie van de interface

Als een interface nog niet actief gebruikt wordt dan zijn de mogelijkheden om deze te veranderen veel groter dan als deze al jaren in gebruik is. Het is sowieso niet mogelijk om flexibiliteit later aan een interface toe te voegen. De flexibiliteit moet er vanaf het begin in zitten, of via een van de andere twee opties toegevoegd worden. Versionering wordt veel makkelijker en duidelijker als er vanaf het begin al een versie nummering in de interface definitie zit.

Bij een bestaande interface zal er dus over het algemeen uitgegaan worden van de bestaande manier van veranderen. Tenzij de bestaande manier van veranderen niet voldoet. Bij nieuwe interfaces is de keuze uiteraard vrij aan de partijen die de interface bepalen.

De aanbieder(s) van de interface

Het maakt nogal uit of er een of meerdere aanbieders zijn van een interface. Bij een enkele aanbieder zijn alle opties prima. De optie van vervangen zal bij de aanbieder zelf het minste impact hebben. Flexibele interfaces, en versioneren zijn beide complexer om uit te werken en te beheren.

Als er meerdere aanbieders zijn dan worden de voor en nadelen anders. De vervangen optie wordt vele malen complexer omdat de verschillende aanbieders gezamenlijk om moeten gaan wat veel organisatie vergt. Bij versionering kunnen de verschillende aanbieders dat in hogere mate zelf bepalen.

Als er meerdere aanbieders zijn dan kan een flexibele interface wenselijk zijn omdat de aanbieders verschillend om willen gaan met de informatie die via de interface verstuurd wordt. Voor de afnemers geeft dit uiteraard weer meer complexiteit.

De afnemer(s) van de interface

Ook het aantal afnemers is belangrijk. Als er maar een afnemer is, dan zijn alle opties goed mogelijk. De vervangen optie kan redelijk eenvoudig afgestemd worden, en ook een flexibele/geversioneerde interface kan zonder al te veel problemen gebruikt worden.

Bij meerdere (en diverse) afnemers wordt het anders. Het veranderproces voor het vervangen van de interface wordt erg complex, dus in die situatie is het versioneren of flexibel maken van de interface wenselijker.

De keuze

Uiteraard kan het zijn dat er speciale omstandigheden zijn die een bepaalde keuze noodzakelijk maken. Hier gaan we echter uit van de meest realistische keuzen.

Aanbieder Afnemer Vervangen Flexibel Versioneren
Enkele aanbieder Enkele afnemer geschikt geschikt optie
Meerdere afnemers ongeschik optie geschikt
Meerdere aanbieders Enkele afnemer ongeschikt optie geschikt
Meerdere afnemers ongeschikt optie geschikt

Een paar opmerkingen bij de bovenstaande tabel:

  1. Eigenlijk is het vervangen alleen goed geschikt voor een 1 op 1 situatie. De complexiteit van omschakelen schiet omhoog op het moment dat het aantal partijen groeit.
  2. Een flexibele interface leverd ook extra complexiteit op naarmate er meer partijen zijn. Verschillen in interpretatie van de interface leveren over het algemeen snel problemen op. Als dat echter goed beheerst wordt, is het zeken een goede optie.
  3. Het versioneren van interfaces is eigenlijk altijd een goede keus. Bij een een op een situatie levert het echter wel extra complexiteit op omdat er meerdere versies onderhouden moeten worden terwijl er door de afnemer waarschijnlijk maar een enkele versie gebruikt wordt.

Conclusie

Het is verstandig om bij het bepalen van een interface van te voren al na te denken over veranderingen van deze interface.

Als de interface tussen twee partijen is dan kan een nieuwe interface prima de oude vervangen. Het is goed te doen om een gezamenlijk overschakelmoment af te spreken zonder al te veel impact. Terwijl het niet nodig is om meerdere versies tegelijk te beheren.

Bij meerdere partijen heeft het de voorkeur om met versies van de interface te werken waarbij er een (tijdelijke) overlap is van de verschillende versies. Het is dan wel zaak om goed te bepalen wat de overlap periode is, en om dat goed te communiceren.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.