VERA 3.0 koppelingen Versie: 3.0 Datum: 25-9-2014 Status: Definitief Stichting VERA Veenendaal 2014 http://www.stichting-vera.nl
Inhoudsopgave 1 Inleiding... 3 1.1 Resultaten... 3 1.2 Randvoorwaarden... 3 1.3 Context... 3 2 Aanpak... 5 2.1 Vraagstelling... 5 2.2 Realisatie... 8 3 Organisatie... 13 3.1 Rollen... 13 3.1.1 Proceseigenaar... 13 3.1.2 Gegevenseigenaar... 13 3.1.3 Gebruikersorganisatie... 13 3.1.4 Applicatiebeheerder... 13 3.1.5 Technisch beheerder... 13 3.1.6 IT-verantwoordelijke... 13 3.1.7... 14 3.1.8 Solution architect... 14 3.1.9 Informatieanalist... 14 3.2 Aanpak... 14 4 Varianten... 15 4.1 Standaard koppelvlak... 15 4.2 Standaard koppeling leveranciers... 15 4.3 Onderhoud... 16 5 RACI matrix... 18 6 Volledig stroomschema implementatieplan... 19 7 Begrippenlijst... 20 Versiebeheer Versie Datum Toelichting 3.0 17-06-2014 Creatie koppelingen 2
1 Inleiding In dit document is voor woningcorporaties een implementatieplan beschreven voor het realiseren van een VERA-koppeling. Het implementatieplan is een praktische handleiding die woningcorporaties hierbij ondersteunt en geeft uitgangspunten en/of aandachtspunten die hierbij gehanteerd kunnen worden door een woningcorporatie. In het implementatieplan is beschreven welke stappen er doorlopen moeten worden om een VERA-koppeling te realiseren en welke keuzes hierin nog gemaakt moeten worden door een corporatie. Het implementatieplan begint met een beschrijving van het beoogde resultaat en de randvoorwaarden die gelden. Vervolgens beschrijft het implementatieplan de stappen die genomen moeten worden. In dit implementatieplan wordt naar een koppelingontwerp verwezen. Een template hiervoor is als apart document bij het implementatieplan opgeleverd in bijlage E.2. Als afsluiting van het document wordt er ingegaan op een aantal varianten op de standaardaanpak van het implementatieplan. Dit implementatieplan begint wanneer er een behoefte is voor het realiseren van een koppeling. Dat betekent dat er een behoefte is om twee applicaties met elkaar te koppelen. Deze behoefte ontstaat uit een verandering (project) dat gestart is of gaat worden. 1.1 Resultaten Het beoogd resultaat van een project wat dit implementatieplan volgt is een koppeling volgens de VERA standaard. Deze gegevensuitwisseling is op een beheersbare manier tot stand gekomen en leidt tot een gestandaardiseerde en daardoor beter beheersbare koppeling. 1.2 Randvoorwaarden Voor het uitvoeren van dit implementatieplan is het randvoorwaardelijk dat een corporatie duidelijk heeft wat de functionele en niet-functionele eisen aan de koppeling zijn, deze zijn namelijk bepalend voor het ontwerp en de implementatie van de koppeling. Het implementatieplan verwacht dat er een beschrijving van de beoogde verandering beschikbaar is in de vorm van doelstellingen, procesbeschrijvingen (met informatiefuncties) en/of een business case. Daarin of aan de hand daarvan is bepaald welke koppelingen er nodig zijn en wat de kwaliteitseisen voor deze koppelingen zijn (tijdigheid, beveiliging, onderhoudbaarheid, analyseerbaarheid, enzovoort). 1.3 Context Om het implementatieplan voor een VERA-koppeling duidelijk te maken is het goed om eerst de context te duiden waarin dit implementatieplan is geschreven. In de hierna volgende figuur is deze weergegeven. koppelingen 3
Leverancier A Leverancier B Applicatie A VERA KV VERA KV Applicatie B Koppeling Koppelvlak Figuur 1 Context implementatieplan Een VERA-koppeling bestaat in principe uit de gegevensuitwisseling tussen de twee applicaties. Hiertoe bieden beide applicaties een VERA koppelvlak aan. In het implementatieplan wordt uitgegaan van minimaal drie partijen, te weten een woningcorporatie en twee leveranciers. Sommige rollen en verantwoordelijkheden kunnen echter uitbesteed zijn (bijvoorbeeld beheer) waardoor er sprake kan zijn van meerdere partijen die betrokken zijn bij de uitvoering van dit implementatieplan. In het vervolg van dit implementatieplan wordt hier in het benoemen van de rollen verder geen rekening mee gehouden. Het identificeren van koppelingen, het signaleren van onderlinge afhankelijkheden en het sturen op hergebruik zijn relevante aspecten aan koppelingen maar geen onderdeel van dit implementatieplan. Hiervoor zou een corporatie een architectuurproces ingericht moeten hebben. Bij de randvoorwaarden is al aangegeven dat een corporatie vanuit procesbeschrijvingen de functionele en niet-functionele eisen van de koppeling vaststelt. Het is belangrijk om bij het begin van het traject ook al nagedacht te hebben over de niet-functionele eisen in plaats van dit pas later te doen. Deze hebben namelijk veel invloed op de realisatie en implementatie van een koppeling door de leveranciers. Om die reden is er ook expliciet aandacht voor in het koppelingontwerp, ondanks dat deze als randvoorwaarde worden gesteld voor het implementatieplan. Er kan sprake zijn van een bestaand VERA koppelvlak op één van de twee (of misschien beide) applicaties. Identificatie van dit mogelijk hergebruik heeft voor de start van dit implementatieplan al plaatsgevonden. Bij de uitvoering van het implementatieplan betekent dit dat een aantal stappen door één van de twee leveranciers niet uitgevoerd hoeft te worden. Ook dit is iets wat geïdentificeerd kan worden in een architectuurproces. Dit implementatieplan beschrijft voornamelijk wat er inhoudelijk moet gebeuren bij het implementeren van een VERA-koppeling. Andere aspecten rondom (project)management bijvoorbeeld change management binnen een project, communicatielijnen binnen een project, training / opleiding van beheerders, zijn in deze versie van het implementatieplan niet verder uitgewerkt. koppelingen 4
2 Aanpak In dit hoofdstuk wordt de te volgen aanpak uitgewerkt in een aantal verschillende activiteiten. Per activiteit is een vaste set aan informatie te vinden: omschrijving, doel van de activiteit, resultaat en rollen en verantwoordelijkheden. Deze laatste zijn ook samengevat in een RACI matrix in hoofdstuk 5. De rollen die genoemd zijn worden nader toegelicht in paragraaf 3.1. Hierbij worden marktconforme rollen gebruikt die mogelijk niet op die manier ook altijd in de corporatie aanwezig zijn. De activiteiten zijn opgedeeld in twee fasen: vraagstelling en realisatie. In de eerste fase ligt het zwaartepunt bij de corporatie om uit te werken welke koppelvlakken nodig zijn. In de tweede fase ligt het zwaartepunt juist meer bij de leveranciers om de benodigde koppelvlakken en koppeling te realiseren. In hoofdstuk 4 bijlage D.1 Koppelvlakken is een voorbeeld opgenomen hoe een VERA service gerealiseerd kan worden door een leverancier. Per fase is een stroomschema van de activiteiten gegeven. De stroomschema s gaan uit van de zogenaamde happy flow. Feedback loops vanwege uitzonderingen e.d. zijn uit het oogpunt van eenvoud niet in de stroomschema s opgenomen. Wanneer bijvoorbeeld testen niet slagen en een koppelvlak aangepast moet worden is hiervoor geen pijl terug opgenomen. In de werkelijkheid bestaat de mogelijkheid natuurlijk altijd om terug te gaan naar eerder uitgevoerde activiteiten. Het stroomschema is daarmee vooral een indicatie van hoe activiteiten elkaar kunnen opvolgen en hoe deze ingedeeld kunnen worden. In hoofdstuk 6 is het volledige stroomschema van alle activiteiten weergegeven. De activiteiten zijn genummerd ter referentie. De nummering drukt verder geen expliciete volgorde uit. Wel is het zo dat alle activiteiten noodzakelijk zijn om tot een goed werkende VERA-koppeling te kunnen komen. In de naamgeving van de activiteiten worden twee termen gebruikt die een bijzondere betekenis hebben in de context van dit implementatieplan. Dit zijn de termen vaststellen en ontwerpen. Bij vaststellen gaat het er om te bepalen welke onderdelen uit de VERA standaard relevant zijn en gebruikt dienen te worden. Bij ontwerpen gaat het om het toepassen van concepten en richtlijnen uit VERA door een ontwerp te maken. 2.1 Vraagstelling 2. Ontwerpen referentiedata 3. Ontwerpen validatie Functioneel ontwerp Implementatie 1. Vaststellen VERA klassen en attributen Technisch ontwerp 4. Vaststellen interactiepatroon 5. Vaststellen benodigde VERA berichten 6. Opleveren koppelingontwerp Figuur 2 Activiteiten vraagstellingsfase koppelingen 5
1. Vaststellen VERA klassen en attributen In deze activiteit wordt aan de hand van de procesbeschrijvingen uitgewerkt welke VERA gegevens er nodig zijn voor de gegevensuitwisseling. Vaststellen welke gegevens uitgewisseld moeten worden. Een lijst op basis van het VERA gegevensmodel met de klassen en de attributen van die klassen die minimaal nodig zijn voor de gegevensuitwisseling. Deze lijst wordt opgenomen in het koppelingenontwerp. Informatieanalist Consulted Gegevenseigenaar / proceseigenaar 2. Ontwerpen referentiedata In deze activiteit wordt de voor de koppeling te gebruiken referentiedata ontworpen. VERA geeft alleen aan waar stamtabellen voorkomen maar geen invulling van de mogelijke waarden. Die invulling is wel nodig om de semantiek van de uitgewisselde gegevens verder te standaardiseren. Bij voorkeur wordt de referentiedata organisatiebreed ontworpen zodat er voor de invulling bij de corporatie één overzicht is. Indien dit al eerder voor andere koppelingen is gedaan kan deze stap worden overgeslagen. (Organisatiebreed) ontwerpen welke referentiedata er wordt gebruikt voor de VERA-koppeling(en). Het resultaat van deze activiteit is een opsomming van de toegestane waardes die er gelden voor de referentiedata in de klassen. Deze opsomming wordt opgenomen in het koppelingontwerp. Informatieanalist Consulted Gegevenseigenaar / proceseigenaar koppelingen 6
3. Ontwerpen validatie Consulted In deze activiteit worden de bedrijfsregels voor de klassen en attributen ontworpen op basis van de procesontwerpen, kwaliteitseisen en geldende definities binnen de corporatie. Dit kunnen eenvoudige bedrijfsregels zijn over bijvoorbeeld veldlengtes of uitgebreide regels over bijvoorbeeld toegestane combinaties van attributen en referentiedata. Kwaliteit van gegevens borgen. Opsomming van bedrijfsregels in het koppelingontwerp. Informatieanalist Gegevenseigenaar / proceseigenaar 4. Vaststellen interactiepatroon Solution architect Consulted Proceseigenaar In deze activiteit wordt aan de hand van het procesontwerp en de kwaliteitseisen (bijvoorbeeld actualiteit van de gegevens) bepaald wat het benodigde interactiepatroon voor de koppeling is. VERA (en StUF) kent zogenaamde interactiepatronen, bijvoorbeeld of het synchrone of asynchrone communicatie betreft. Overeenstemming over patroon van gegevensuitwisseling. Vastgesteld interactiepatroon. 5. Vaststellen benodigde VERA berichten In deze activiteit wordt bepaald welke VERA berichten nodig zijn op basis van het procesontwerp en de uitkomsten van activiteit 1 en 4. Hierbij worden de leveranciers geconsulteerd omdat zij aan kunnen geven welke van de VERA berichten op hun koppelvlak worden aangeboden en voor welke functionaliteit. Vaststellen welke VERA berichten er op beide koppelvlakken nodig zijn zodat dit voor beide leveranciers duidelijk is. Lijst van benodigde VERA berichten waarbij bericht is aangegeven welke plaats deze in het proces heeft. Solution architect Consulted Leveranciers koppelingen 7
6. Opleveren koppelingontwerp Consulted - Informed Leveranciers 2.2 Realisatie In deze activiteit worden de resultaten van de voorgaande stappen gebundeld in een document waarin het ontwerp van de koppeling is beschreven. In dit document worden ook de eisen die aan beide koppelvlakken worden gesteld uitgewerkt. Aan de hand van het ontwerp kan bijvoorbeeld aan beide leveranciers om een kostenindicatie worden gevraagd voor de volgende fase, intern akkoord met het voorstel gevraagd worden en/of aan eigen documentatiedoeleinden voldaan worden. Vraagstelling voor beide koppelvlakken bundelen en expliciet beschrijven. Een goedgekeurd koppelingontwerp. Solution architect 9. Maken beheerafspraken Implementatie Realisatie leverancier(s) 7. Ontwerpen mapping 8. Vaststellen benodigde WSDL 10. Inrichten berichten op service 12. Testen koppelvlak 13. Testen koppeling 14. Opleveren koppeling 11. Inrichten berichten op client Figuur 3 Activiteiten realisatiefase koppelingen 8
7. Ontwerpen mapping Leverancier Consulted Applicatiebeheerder In deze activiteit wordt door beide leveranciers ontworpen welke attributen en entiteiten uit het gegevensmodel van een applicatie gebruikt worden om het deel van het VERA gegevensmodel wat voor de koppeling gebruikt wordt te kunnen vullen. Daarin wordt ook mapping van de eerder ontworpen referentiedata meegenomen. Een deel van deze mapping is misschien al standaard beschikbaar bij de leveranciers. Traceerbaarheid tussen inrichting van een applicatie en de bijbehorende gegevensregistratie naar de uitwisseling van gegevens op een koppeling. Document per leverancier (koppelvlak) waarin is gedocumenteerd welke entiteiten en attributen uit de applicatie gebruikt worden voor de VERA entiteiten en attributen op het koppelvlak. 8. Vaststellen benodigde WSDL Leverancier Consulted Solution architect In deze activiteit wordt op basis van het vastgestelde interactiepatroon en de benodigde berichten de te gebruiken WSDL vastgesteld. Beide leveranciers (zender en ontvanger) moeten het eens zijn met de vastgestelde WSDL omdat er anders geen berichten uitgewisseld kunnen worden. Borgen technische interoperabiliteit door zelfde service definities te gebruiken. Een opsomming van de benodigde VERA WSDL( s). koppelingen 9
9. Maken beheerafspraken In deze activiteit worden door de corporatie met de leveranciers afspraken gemaakt over beheer van het koppelvlak. Hierin is aandacht voor change mangement, support, en prestatieafspraken over specifieke nonfunctionals als beschikbaarheid, analyseerbaarheid, enzovoort. Prestatieafspraken en verantwoordelijkheden voor beheer duidelijk beleggen en het waarborgen van de VERA standaard bij changes aan de applicatie. SLA of andere vorm van beheerovereenkomst voor beide koppelvlakken. IT-verantwoordelijke Consulted Leveranciers, Technisch beheerder, Applicatie beheerder 10. Inrichten berichten op de service Consulted - In deze activiteit worden door de leverancier de berichten ingericht op de service die de applicatie aanbiedt. Idealiter op een ontwikkelomgeving bij de leverancier, of als alternatief op een testomgeving bij de corporatie. Dit zijn de zogenaamde service berichten waarvoor in het koppelingontwerp is aangegeven dat de leverancier deze moet kunnen ontvangen en verwerken. Inrichten wil zeggen dat (voor zover dat nog niet standaard aanwezig is) de benodigde VERA berichten, mapping (waaronder referentiedata) en bedrijfsregels op het koppelvlak worden ingericht. Deze activiteit hoeft alleen uitgevoerd te worden indien de leverancier de desbetreffende berichten nog niet beschikbaar heeft op het VERA koppelvlak. NB: deze activiteit kan, afhankelijk van het procesontwerpen en de benodigde berichtuitwisseling, gelijktijdig door beide leveranciers plaatsvinden en in combinatie met activiteit 10. Realisatie van het koppelvlak. Een werkend koppelvlak (verwerking van berichten). Leverancier koppelingen 10
11. Inrichten berichten op de client Consulted - In deze activiteit worden door de leverancier de berichten ingericht die verstuurd moeten worden. In het koppelingontwerp is aangegeven wanneer en onder welke condities deze zogenaamde client berichten verstuurd moeten worden. Inrichten wil zeggen dat (voor zover dat nog niet standaard aanwezig is) de benodigde VERA berichten, mapping (waaronder referentiedata) en bedrijfsregels op het koppelvlak worden ingericht. Deze activiteit hoeft alleen uitgevoerd te worden indien de leverancier de desbetreffende berichten nog niet ondersteund op het VERA koppelvlak. NB: deze activiteit kan, afhankelijk van het procesontwerpen en de benodigde berichtuitwisseling, gelijktijdig door beide leveranciers plaatsvinden en in combinatie met activiteit 10. Realisatie van het koppelvlak. Een werkend koppelvlak (versturen van berichten). Leverancier 12. Testen koppelvlak Consulted - In deze activiteit wordt door de leverancier het individuele koppelvlak getest. Omdat de te gebruiken WSDL en de benodigde berichten bekend zijn kan dit door met zogenaamde stubs en mocks te werken. Hiertoe kunnen diverse tests uitgevoerd worden, bijvoorbeeld: functionele testen, load testen, stress testen, security testen, enzovoort. Het minimale wat gedaan moet worden zijn de in- en uitgaande berichten valideren tegen de VERA WSDL s. Valideren dat het koppelvlak van de leverancier voldoet aan de specificaties zoals beschreven in het koppelingontwerp. Testrapport van de uitgevoerde testen. Leverancier koppelingen 11
13. Testen koppeling In deze activiteit wordt getest of de werking van de koppeling conform de specificaties is. In tegenstelling tot de test uit activiteit 12 wordt hier de koppeling getest, met andere woorden de koppelvlakken van beide leveranciers wisselen berichten met elkaar uit in een testomgeving en er wordt getest of de gegevens juist verwerkt worden in de applicaties. Deze activiteit kan gestart worden indien het testrapport uit activiteit 12 voldoende garanties geeft dat de koppelvlakken werken. Ook hiertoe kunnen diverse tests uitgevoerd worden, bijvoorbeeld: functionele testen, load testen, stress testen, security testen, enzovoort. Meten van de kwaliteit van de koppeling en de koppelvlakken zodat er een onderbouwde keuze gemaakt kan worden om wel of niet te accepteren dat de koppeling gereed is voor livegang. Testrapport wat een beeld geeft van de kwaliteit van de koppelvlakken en de koppeling. Leveranciers Consulted Gebruikersorganisatie (zie ook 3.1.3) Informed Proceseigenaar / gegevenseigenaar 14. Opleveren koppeling Consulted Informed In deze activiteit wordt de koppeling opgeleverd (evt. aan een ander project / programma) zodat de koppeling in de bedrijfsvoering gebruikt kan worden. Daaronder vallen ook overdracht en oplevering van documentatie (voor zover dat niet al eerder is gedaan). Opleveren van de koppeling. Een werkende koppeling. Leveranciers Applicatiebeheerder / technisch beheerder Gebruikersorganisatie koppelingen 12
3 Organisatie 3.1 Rollen Bij de activiteiten in hoofdstuk 2 zijn rollen genoemd om aan te geven hoe de verantwoordelijkheden liggen. In deze paragraaf zijn de omschrijvingen van de verschillende rollen gegeven. Voor deze rollen geldt dat ze binnen de corporatie belegd kunnen worden of van een externe organisatie betrokken kunnen worden. Deze rollen kunnen allemaal door verschillende medewerkers van corporaties of externe organisaties ingevuld worden, maar het is ook goed mogelijk dat sommige rollen gecombineerd worden door één medewerker. Het is belangrijk om de functionaris(sen) binnen de corporatie te zoeken waarvan de functiebeschrijving het beste aansluit bij de hieronder uitgewerkte beschrijvingen van de rollen. 3.1.1 Proceseigenaar De rol van de proceseigenaar wordt ingevuld door een medewerker van de corporatie die bepaalt hoe processen in de corporatie eruit zien. De proceseigenaar heeft ook mandaat om besluiten te nemen over het ontwerp en de implementatie van processen. 3.1.2 Gegevenseigenaar De rol van de gegevenseigenaar wordt ingevuld door een medewerker van de corporatie die verantwoordelijk is voor de datakwaliteit van de gegevens. De gegevenseigenaar bepaalt welke kwaliteitseisen er aan gegeven gesteld worden (bijvoorbeeld met betrekking tot vertrouwelijkheid of integriteit). De gegevenseigenaar heeft ook mandaat om besluiten te nemen over de kwaliteitseisen. 3.1.3 Gebruikersorganisatie De rol van de gebruikersorganisatie is een verzamelnaam voor alle medewerkers in de corporatie die gebruik gaan maken van de koppeling. Vaak wordt hiervan een representatieve selectie gemaakt om te testen en te accorderen dat de koppeling voldoet aan de wensen van de gebruikersorganisatie. 3.1.4 Applicatiebeheerder De rol van applicatiebeheerder wordt ingevuld door een medewerker van de corporatie die verantwoordelijk is voor de functionele werking van een applicatie. Deze medewerker heeft diepgaande kennis over de inrichting en de werking van een applicatie. 3.1.5 Technisch beheerder De rol van technisch beheerder wordt ingevuld door een medewerker van de corporatie of een externe organisatie die verantwoordelijk is voor het technisch functioneren van de omgeving waarop de applicatie draait. Denk bijvoorbeeld aan netwerken, gebruikers accounts, file shares, servers, enzovoort. 3.1.6 IT-verantwoordelijke De rol van IT-verantwoordelijke wordt ingevuld door een medewerker van de corporatie die de IT(-afdeling) bestuurt en hiervoor eindverantwoordelijk is. De IT-verantwoordelijke is over het algemeen ook degene die de overeenkomsten met leveranciers afsluit. koppelingen 13
3.1.7 De rol van projectleider wordt ingevuld door een medewerker van de corporatie of een externe organisatie die verantwoordelijk is voor het succesvol realiseren van de VERA-koppeling namens de opdrachtgever. Een hier bedoeld project wordt gestuurd op vier parameters: functionaliteit, tijd, geld en kwaliteit en het is de verantwoordelijkheid voor de projectleider om binnen de op deze parameters gestelde grenzen het beoogde resultaat te bereiken. Vaak is er ook sprake van projectleiders bij de leveranciers die het proces bij de leverancier managen en optreden als contactpersoon tussen de corporatie en de leverancier. De projectleider in dit implementatieplan werkt vaak samen met projectleiders van de leverancier. Uiteindelijk is er één iemand eindverantwoordelijk voor het project. Die rol wordt in dit implementatieplan bedoeld. 3.1.8 Solution architect De rol van solution architect wordt ingevuld door een medewerker van de corporatie of een externe organisatie die de structuur van een oplossing voor een business probleem beschrijft, waarbij mogelijk meerdere applicaties en technologieën gecombineerd moeten worden. In de context van dit implementatieplan beschrijft de solution architect de structuur van de koppeling en hoe de verschillende applicaties hierin met elkaar samenwerken en integreren om het proces optimaal te ondersteunen. 3.1.9 Informatieanalist De rol van informatieanalist wordt ingevuld door een medewerker van de corporatie of een externe organisatie die verantwoordelijk is voor het verzamelen en beschrijven van de functionele eisen die aan een koppeling gesteld worden. De informatieanalist is in staat om bestaande en nieuwe eisen en wensen vanuit de gebruikersorganisatie te vertalen naar concrete eisen aan koppelingen. 3.2 Aanpak Zoals ook uit de activiteiten blijkt is het verstandig om de realisatie van een koppeling projectmatig te organiseren. Deze organisatievorm geeft de mogelijkheid om een duidelijk resultaat te definiëren en daarbij de benodigde funding en resources te organiseren. Het vraagstellingsgedeelte van de aanpak kan door de corporatie zelf uitgevoerd worden, of kan eventueel uitbesteed worden aan een externe partij. Het resultaat hiervan zou een goedgekeurd en geaccordeerd koppelingontwerp moeten zijn. Het realisatie gedeelte zal over het algemeen onder regie van de corporatie (of eventueel uitbesteed) door de betrokken leveranciers uitgevoerd moeten worden. Op basis van het koppelingen ontwerp kan voor deze fase een projectplan opgesteld worden. Bovenstaande onderscheid (met name in opdrachtverstrekking) is voor alle koppelingen relevant, ongeacht de omvang. Wel zal de zwaarte en besturing hiervan meegeschaald moeten worden met bijvoorbeeld de omvang of het (technisch) risico van een koppeling. koppelingen 14
4 Varianten In de voorgaande hoofdstukken is het implementatieplan beschreven om een koppeling op initiatief van een corporatie te realiseren op basis van (standaard) koppelvlakken die de applicaties aanbieden. Ditzelfde implementatieplan dient ook in enkele andere varianten gebruikt worden. 4.1 Standaard koppelvlak In deze variant besluit een leverancier eigenhandig om een standaard koppelvlak op zijn applicatie voor te bereiden en te realiseren. Een uitdaging hierbij is dat VERA niet op alle details standaardisatie geeft, bijvoorbeeld de te gebruiken referentiedata of hoe berichten zich tot een proces verhouden. De ontwerpstappen uit het implementatieplan kunnen in deze variant nog niet (volledig) ingevuld worden omdat dat hier alleen vanuit de context van een leverancier kan. Bij de realisatie moet er dus rekening mee gehouden worden dat er ruimte wordt gehouden voor inrichting of configuratie. De implementatie van een standaard koppelvlak door één leverancier kent net als bij de corporatie een procesbeschrijving. Hierbij zal de leverancier zelf het proces en de bijbehorende kwaliteitseisen moeten vaststellen. Aan de hand van deze procesbeschrijving kunnen de stappen van het implementatie plan uitgevoerd worden. Bijzondere aandacht moet daarbij geschonken worden aan de stappen: 2. Ontwerpen referentiedata: dit kan met de huidige VERA versie alleen per koppeling of corporatie vastgesteld worden. Dat betekent dat er bij de realisatie van het koppelvlak de mogelijkheid geboden moet worden om dit op een later tijdstip in een specifieke klantsituatie in te kunnen richten. 3. Ontwerpen validatie: hier bestaat de kans dat een corporatie, naast de door de leverancier gedefinieerde regels, zelf nog aanvullende of andere regels wil toepassen. Ook hier moet in de realisatie rekening mee gehouden worden. 4. Vaststellen interactiepatroon en 5. Vaststellen benodigde VERA berichten: de leverancier definieert zelf het proces en dus ook de benodigde interactie en berichten die hierbij horen. Hier kunnen in een klantsituatie subtiele verschillen in zitten. De project specifieke activiteiten 9. Maken beheerafspraken, 13. Testen koppeling en 14. Livegang kunnen in deze variant niet uitgevoerd worden omdat deze alleen van toepassing zijn in een projectcontext. Naast bovenstaande aandachtspunten geldt in algemeenheid dat een leverancier expliciet moet stil staan bij de onderdelen waarvan verwacht wordt dat deze afhankelijk (kunnen) zijn van de klantsituatie. De flexibiliteit in de inrichting van het koppelvlak die hiervoor eventueel nodig is moet meegenomen worden bij de realisatie. Dit biedt de mogelijkheid om met een bestaand koppelvlak een standaard koppeling in de context van de corporatie te realiseren en op termijn met volgende VERA versies in de context van de sector. 4.2 Standaard koppeling leveranciers In deze variant is er geen sprake van een specifieke klantsituatie maar besluiten twee leveranciers om in gezamenlijkheid een standaard koppelvlak te realiseren en op de markt te brengen. Ook koppelingen 15
hierbij is een uitdaging dat VERA niet op alle details standaardisatie geeft, bijvoorbeeld de te gebruiken referentiedata of hoe berichten zich tot een proces verhouden. De ontwerpstappen uit het implementatieplan kunnen in deze variant nog niet (volledig) ingevuld worden omdat dat hier alleen vanuit de context van beide leverancier kan. Bij de realisatie moet er dus rekening mee gehouden worden dat er ruimte wordt gehouden voor inrichting of configuratie. Omdat er sprake is van een VERA-standaard koppelvlak tussen twee leveranciers zou er ook een standaard inrichting voor ontworpen kunnen worden. In deze implementatie vullen één of beide leveranciers ook de corporatie rollen uit het implementatieplan in. Op die manier kan het implementatieplan in deze variant bijna onverkort worden gevolgd. Bijzondere aandacht moet daarbij geschonken worden aan de stappen: 6. Opleveren koppelingontwerp: dit is het ontwerp dat beide leveranciers samen afgestemd hebben en op basis waarvan zij beide de koppelvlakken en uiteindelijk de koppeling zullen realiseren. 9. Maken beheerafspraken: deze concentreert zich in dit geval op de afspraken tussen de leveranciers onderling. Een bijkomend resultaat van deze activiteit kan een standaard SLA zijn op de koppeling die bij inzet van de koppeling in een klantsituatie wordt afgestemd. De project specifieke activiteit 14. Livegang kan in deze variant alleen uitgevoerd worden wanneer beide applicaties als dienst uit de cloud worden geleverd. De huidige VERA kent zoals aangegeven nog enkele vrijheidsgraden. In combinatie met een volledig gestandaardiseerde koppeling, zonder inrichting, is er een groot risico dat de corporatie zelf, of leveranciers andere applicaties van de corporatie, andere keuzes gemaakt hebben. Beide leveranciers zouden hier expliciet over na moeten denken en identificeren op welke punten potentieel flexibiliteit nodig is. Die flexibiliteit vertaalt zich vervolgens in de realisatie in de mogelijkheid om in een specifieke klantsituatie dit soort aspecten in te kunnen richten. Door dit mogelijk te maken is de koppeling niet meer alleen standaard volgens de leveranciers maar kan deze ook als standaard binnen de corporatie ingezet worden. Bovendien zou dit er op termijn met volgende VERA versies ook toe moeten leiden dat de koppeling als standaard binnen de sector ingezet kan worden. 4.3 Onderhoud In deze variant is er sprake van onderhoud aan de koppeling vanwege het verschijnen van nieuwe VERA versies. Het verschijnen van nieuwe versies van applicaties valt hier expliciet niet onder, aangezien ook de nieuwe applicatie dezelfde (huidige) VERA versie zal gebruiken. Dit betekent dus geen wijziging aan de koppeling. In principe wordt bij het onderhoud het bestaande implementatieplan doorlopen. De stappen 1 t/m 5 gaan daarbij echter niet over ontwerp en vaststellen van de benodigde onderdelen, maar het uitvoeren van een impactanalyse op de genoemde onderdelen. Het resultaat is nog steeds een koppelvlakontwerp waarin de nieuwe VERA-koppeling is beschreven. Met dit koppeling ontwerp kunnen vervolgens de stappen 7 t/m 14 worden doorlopen waarbij de bestaande koppeling en koppelingen 16
koppelvlakken worden aangepast aan de nieuwe VERA versie zoals beschreven is in het koppelingontwerp. koppelingen 17
5 RACI matrix Figuur 4 RACI Matrix Proceseigenaar Gegevenseigenaar Gebruikersorganisatie Applicatiebeheerder Technisch beheerder IT-Verantwoordelijke Solution architect Informatieanalist Leverancier(s) 1. Bepalen VERA klassen en attributen C C A R 2. Ontwerpen referentiedata C C A R 3. Ontwerpen gegevensvalidatie C A R 4. Vaststellen interactiepatroon C A R 5. Vaststellen benodigde VERA berichten A R C 6. Opleveren koppelingontwerp A R I 7. Ontwerpen mapping C A R 8. vaststellen benodigde WSDL A C R 9. Maken beheerafspraken C C A R C 10. Inrichten berichten op service A R 11. Inrichten berichten op client A R 12. Testen koppelvlak A R 13. Testen koppeling I I C A R 14. Livegang I C C A R koppelingen 18
6 Volledig stroomschema implementatieplan 2. Ontwerpen referentiedata 3. Ontwerpen validatie Functioneel ontwerp Implementatie 1. Vaststellen VERA klassen en attributen Technisch ontwerp Realisatie leverancier(s) 4. Vaststellen interactiepatroon 5. Vaststellen benodigde VERA berichten 6. Opleveren koppelingontwerp 9. Maken beheerafspraken 7. Ontwerpen mapping 8. Vaststellen benodigde WSDL 10. Inrichten berichten op service 12. Testen koppelvlak 13. Testen koppeling 14. Opleveren koppeling 11. Inrichten berichten op client Figuur 5 Volledig stroomschema implementatieplan koppelingen 19
7 Begrippenlijst Begrip Bedrijfsregel Functionele test Load test Mocks RACI Stress test Stubs Een bedrijfsregel is een regel die een bepaald aspect van een gegeven definieert of beperkt. Het is bedoeld om de kenmerken van de business te handhaven of het gedrag van de business te beïnvloeden. Een bedrijfsregel komt onder andere voort uit het bedrijfsbeleid, uit wet- en regelgeving en uit branchestandaarden. In een functionele test wordt de applicatie als een black box getest op basis van de specificaties. In deze vorm van testen wordt input aan de applicatie gegeven en de uitkomsten gevalideerd tegen de verwachte output op basis van de specificaties. In een load test wordt een applicatie belast en wordt de performance van de applicatie (onder verschillende belastingen) gemeten. Componenten of objecten die voorgeprogrammeerd zijn waardoor gespecificeerd welke aanroepen er worden verwacht en welke antwoorden dit oplevert. Afkorting voor:. Verantwoordelijk voor de uitvoering.. Eindverantwoordelijk en bevoegd om goedkeuring te geven aan het resultaat. Consulted. Geraadpleegd voorafgaand aan beslissingen of acties. Informed. Geïnformeerd, wordt op de hoogte gesteld over beslissingen, voortgang, enz. Dit wordt vaak in een matrix vorm gehanteerd om de rollen en verantwoordelijkheden van de personen die bij een project of lijnwerkzaamheden betrokken zijn weer te geven. Deze vorm van testen is vergelijkbaar met een load test, echter wordt hierbij de applicatie tot ver over het maximum belast. Errors en foutmeldingen horen dan ook bij deze vorm van testen. Het doel is om te bepalen hoe de applicatie zich gedraagt onder (relatief) extreme belasting en hoe deze zich hier van herstelt wanneer de belasting weer afneemt. Een stub lijkt op een mock, maar geeft alleen voor gedefinieerde antwoorden op voor gedefinieerde vragen. Elke vraag die buiten deze set valt wordt niet van een antwoord voorzien. Soms houden stubs nog extra informatie vast, bijvoorbeeld hoeveel vragen er ontvangen zijn of welke vragen. Tabel 1 Begrippenlijst koppelingen 20