VERA 3.1. Hoofddocument. Versie: 3.1 Datum: 16-06-2016 Status: Definitief. Stichting VERA Veenendaal 2012-2016 http://www.stichting-vera.



Vergelijkbare documenten
VERA 3.0. Hoofddocument. Versie: 3.0 Datum: Status: Definitief. Stichting VERA Veenendaal

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties

Managementsamenvatting CORA 3.0

VERA 3.2. Release- en Versiebeleid. Versie: 3.2 Datum: Stichting VERA Veenendaal

VERA 3.0. Verkenning - Release- en Versiebeleid. Versie: 3.0 Datum: Status: Definitief

VERA 3.0. Bijlage E.1 Implementatieplan koppelingen. Versie: 3.0 Datum: Status: Definitief

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag.

DATAMODELLERING SIPOC

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

BeheerVisie ondersteunt StUF-ZKN 3.10

VERA Ontwikkeling VERA afgelopen en komend jaar

VERA 3.0. Bijlage D.2 - Leeswijzer StUF. Versie: 3.0 Datum: Status: Definitief

DATAMODELLERING BASIS UML KLASSEMODEL

OVERZICHT ACTUELE DOCUMENTATIE EN COMPLIANCE

Convenant. Samenwerkingsovereenkomst Stichting VERA en gebruikersverenigingen, samenwerkingsverbanden en leveranciers

VERA 3.0. Bijlage D.4 - Keuzen verstuffing. Versie: 3.0 Datum: Status: Definitief

DATAMODELLERING BEGRIPPENBOOM

DATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING

Digikoppeling adapter

Resultaten gesprekssessie 1 Elektronische Productinformatie

Business case Digikoppeling

DATAMODELLERING DATA MAPPING MODEL

Voorbeelden generieke inrichting Digikoppeling

Dat we scherpe en compacte schema s kunnen maken voor berichten in koppelvlakken, en die ook kunnen beheren. Dat we op een consistente manier

De impact van de basisregistraties op de informatievoorziening van gemeenten

DATAMODELLERING CRUD MATRIX

Handleiding voor aansluiten op Digilevering

Business-to-Business

Technische architectuur Beschrijving

Methodiek. Versie: 16/05/ :42:35

VERA. Best practice Bulk Data. Datum: Status: Definitief. Stichting VERA Veenendaal

RESTful API Een RESTful API is een gebaseerd op de Representational state transfer (REST) is een softwarearchitectuur.

Procesmanagement. Waarom processen beschrijven. Algra Consult

Mogelijk onvolledige datum

Functionele Specificatie van GRCcontrol. Rieks Joosten

DATAMODELLERING ARCHIMATE DATAMODELLERING

Het BiSL-model. Een whitepaper van The Lifecycle Company

ISRES. De Datarotonde Platform voor bouwen aan business

TROWA. Visie en scope Informatiemodel Waterschapsverordening. Datum : : 2.0, definitief

Informatieobjecten zijn systematisch beschreven

E. HOE REALISEREN WE DE DIGITALE

De beheerrisico s van architectuur

Gebruikershandleiding. StUF Testplatform Versie 1.3.0

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Technisch Ontwerp W e b s i t e W O S I

Realisatie Programma e-dienstverlening 2e fase

Functioneel Applicatie Beheer

Registratie Data Verslaglegging

ADDENDUM. Regie- en Zaakservices 1.0. Kwaliteitsinstituut Nederlandse Gemeenten. Leveranciers. tussen KING en Leveranciers

StUF: Waar gaat het heen? M. van den Broek

De Digitale Corporatie

nemen van een e-depot

Advies voor het verwijderen van Dimensions v1.0 van de pas toe of leg uit lijst en het wijzigen van het functioneel toepassingsgebied van XBRL v2.

SIG Power BI werkgroep Wonen

afkijken nadoen EGEMwijs Roadmap StUF SOA Op weg naar een service-georiënteerde architectuur

StUF in een notendop. Opsteller: Henri Korver Datum: 21 september 2005 Versie: 0.1 CONCEPT

Implementatieplan. Registratie Instellingen en Opleidingen (RIO) vo. Versie mei Implementatieplan RIO vo 1

SETU Wijzer. U wilt met de SETU-standaard werken, maar waar moet u beginnen?

Informatiemodel Natuur

Archimate risico extensies modelleren

Woningcorporaties bezig in de praktijk met RGS en SBR

Introductie ArchiMate

Context Informatiestandaarden

Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.'

RESTful API Een RESTful API is een gebaseerd op de Representational state transfer (REST) is een softwarearchitectuur.

Ontwikkelaars van BIR Open BIM Standaarden en softwareleveranciers

Praktisch Implementeren van EA bij Gemeenten

Vernieuwing gegevens en berichtenstandaarden. Plan van aanpak vernieuwing standaarden - Project breakdown - Voorgestelde route 2017

Benny Prij. NAF Insight 6 juli 2009

Visiedocument Regie over informatie: BIM voor woningcorporaties

Stakeholder behoeften beschrijven binnen Togaf 9

Uitbreiding van UM Aquo cluster metingen, toevoegen optioneel attribuut Identificatie waarnemingssoort aan klasse WaardeReeks MIDDELGROOT

KlantVenster. Klantgericht werken met KlantVenster LAAT ICT VOOR U WERKEN! Een veelzijdig platform ter ondersteuning van uw bedrijfsdoelstellingen

Data Governance van visie naar implementatie

Leveranciers bijeenkomst

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

DATAMODELLERING TOEPASSEN DATA ANALYTICS

DATAMODELLERING RACI MATRIX

Het succes van samen werken!

Ligt uw uitdaging in het aansluiten op de voorzieningen en de distributie van basisgegevens?

DECOS EN STUF-ZAKEN VOOR FRONTOFFICE FUNCTIONELE BESCHRIJVING V2.1

ENERGIE BEDRIJVEN EN ICT

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

WSO2 ebms adapter. Yenlo WSO2 ontbijtsessie. Ministerie van Infrastructuur en Milieu. 1 DEFINITIEF, 18 september 2012

Referentie Architectuur Onderwijs Versie 2.0. Samenwerkingsplatform Informatie Onderwijs

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Betekent SOA het einde van BI?

Beheer van de EML_NLstandaard

Beheerste transformatie met behulp van Enterprise Architectuur

Procesmanagement. Hoe processen beschrijven. Algra Consult

Verduurzamen en onderhoud: de rol van digitalisering CorpoNet, Albert van Heugten en Jan Fock

Proces to model en model to execute

PROGRAMMA VAN EISEN PROGRAMMA VAN EISEN LAS/LVS (V)SO

Ordening van processen in een ziekenhuis

Roadmap. RIE Manager

Agenda. Informatievoorziening relevant. Convenant. Presentatie SBR wonen Roadshow juni 2018

Conclusie: voor elke organisatie die dit nastreeft is het goed besturen en beheersen van de bedrijfsprocessen

Kenmerk: MS/IV/2016/

ADDENDUM. Regie- en Zaakservices 1.0. Kwaliteitsinstituut Nederlandse Gemeenten. Leveranciers. tussen KING en Leveranciers

Last but not least. Hoofdstuk 35. Bijlagen

Transcriptie:

VERA 3.1 Hoofddocument Versie: 3.1 Datum: 16-06-2016 Status: Definitief Stichting VERA Veenendaal 2012-2016 http://www.stichting-vera.nl

Inhoudsopgave Hoofddocument Colofon... 4 Voorwoord... 5 1 Inleiding... 6 1.1 De verhouding tussen CORA en VERA... 6 1.2 Overzicht belangrijkste wijzigingen... 7 1.3 Documentopbouw... 7 2 Toenemende integratie en standaardisatie... 9 2.1 Effectief en efficiënt integreren met VERA... 9 2.2 De standaard in beweging... 10 2.3 De standaard richting de toekomst... 11 3 Hoe te gebruiken?... 12 3.1 Door de corporatie... 12 3.2 Door de leverancier... 12 3.3 Door de sector... 13 4 Principes en uitgangspunten... 14 4.1 Principes... 14 4.1.1 P01 VERA sluit aan op CORA... 14 4.1.2 P02 VERA is technologie en platform onafhankelijk... 14 4.1.3 P03 VERA gebruikt bestaande open methodieken, technieken en standaarden... 15 4.1.4 P04 VERA is een open standaard... 15 4.2 Uitgangspunten... 15 4.2.1 U01 StUF als standaard voor berichtenverkeer... 15 4.2.2 U02 UML wordt gebruikt om modellen in VERA op te stellen... 16 4.2.3 U03 koppelvlakken maken gebruik van XML... 16 4.2.4 U04 Voor kengetallen gaat VERA voor het meest bruikbare model... 16 4.2.5 U05 VERA houdt zich bezig met het verzamelen van gegevens voor kengetallen... 16 4.2.6 U06 De kengetallenmethodiek is bruikbaar voor alle corporaties... 16 4.2.7 U07 Kengetallen sluiten aan bij de VERA klassen... 17 4.3 Standaarden en richtlijnen... 17 5 De inhoud van VERA... 18 5.1 Onderdelen en onderlinge samenhang... 18 5.2 Detaillering van de onderdelen... 19 5.2.1 Gegevensuitwisseling voor processen... 20 5.2.2 Gegevensuitwisseling voor procesinformatie... 21 5.3 Verdere uitwerking van de onderdelen... 21 6 Toepassing en beheer van de standaard... 23 6.1 VERA implementatie... 23 6.2 Releasebeleid... 23 6.3 VERA-compliant... 24 7 Over de Stichting VERA... 26 8 Begrippenlijst... 27 9 Auteurslijst... 30 10 Bronvermeldingen... 32 11 Overzicht van figuren en tabellen... 33 11.1 Figuren... 33 11.2 Tabellen... 33 Hoofddocument 2

Inhoudsopgave Bijlagen Bijlage A - Standaarden en richtlijnen Bijlage B Gegevensdomeinen: Bijlage B.1 - Algemeen Bijlage B.2 - Relaties Bijlage B.3 - Vastgoed Bijlage B.4 - Overeenkomsten Bijlage B.5 - Onderhoud Bijlage B.6 Woonruimteverdeling Bijlage B.7 Financiën Bijlage B.8 - Dossier Bijlage B.9 - Klassendiagrammen Bijlage C Kengetallen: Bijlage C.1 Prestatiemeting Bijlage C.2 Uitwerking indicatoren Bijlage D Koppelvlakdefinities: Bijlage D.1 - Koppelvlakken Bijlage D.2 - Leeswijzer StUF Bijlage D.3 - XSD s en WSDL s Bijlage D.4 - Keuzen verstuffing Bijlage E Implementatie: Bijlage E.1 Implementatieplan koppelingen Bijlage E.2 Template koppelvlakontwerp Bijlage F Vertikaal sectormodel: Bijlage E.1 Woonruimteverdeling Bijlage E.2 Referentiedata Versiebeheer Versie Datum Toelichting 1.0 27-09-2012 Creatie 2.0 26-09-2013 Herschreven, h4 en h5 bevatten onderdelen uit vorige versie 3.0 17-06-2014 Aanpassingen: Bijlage D.4 uit vorige versie is samengevoegd met huidige bijlage D.1 Bijlage D.5 uit vorige versie is D.4 geworden Figuur 5.1 overzicht gegevensdomeinen in VERA h1.2 en h2.2 herschreven h6 herschreven Kleine tekstuele aanpassingen n.a.v. laatste stand van zaken Hoofddocument 3

Nieuw: Bijlage B.7 en B.8 Bijlage C.2 Bijlage E Verkenning release- en versiebeleid en verkenning compliance aanpak 3.1 13-01-2016 Aanpassingen: Bijlage A Aanpassing GM11 Sleutelgebruik. Aanpassing 3.4 versies, Uitbreiding met methodiek verticaal sectormodel en methodiek Referentiedata. Bijlage B.1 Toevoeging sturingslabel, verwijderen voorbeelden referentiedatasoorten. Bijlage B.3 Toevoeging postadres, buitenlands adres, energieprestatie, sturingslabels en informatieobjecten bij eenheid en cluster. Bijlage B.6 Toevoegen Huidigegebruiker en kandidaatstatus. Bijlage B.9 Klassendiagram Vastgoed aangepast met wijzigingen van Bijlage B.3. Nieuw: Bijlage F.1 en Bijlage F.2 Colofon VERA is een initiatief van de Stichting VERA en is mede tot stand gekomen door de inhoudelijke betrokkenheid van de volgende organisaties bij deze versie of voorgaande versies: Aareon, BDO, Caesar, Cegeka, Centric, De Key, Dudok, Info Support, Itris, KPMG, Kubion, Mitros, Motion10, NCCW, Ordina, Portaal, QplusO, QVision, Reasult, Skarp, SOR, Stadgenoot, Techxx, Vestia, Vivare, WoningNet, Woonbron, Ymere, Zig websoftware. Hoofdstuk 9 bevat een uitgebreid overzicht van auteurs en reviewers. Hoofddocument 4

Voorwoord Dit is VERA 3.1. In deze versie wordt het eerste VERA verticale sectormodel 'Woonruimteverdeling' in de standaard opgenomen. Op basis van de CORA bedrijfsprocessen, is voor woonruimteverdeling het ketenproces tot in detail uitgewerkt. Hiermee is het eerste plug-and-play VERA ketenproces beschikbaar. Vraag uit de markt Na het uitbrengen van VERA 3.0 ontstond een sterke behoefte aan VERA toepassingen. Waarbij de toepassing zodanig was uitgewerkt dat uniforme uitwisseling van gegevens mogelijk werd. De VERA community is hiermee aan de slag gegaan voor Woonruimteverdeling. Het verticale sectormodel Woonruimteverdeling is nu een grote stap vooruit in de toepasbaarheid van VERA. Plug and play Het procesmodel is in detail uitgewerkt. Alle benodigde elementen zijn uitgewerkt en in detail beschreven zodat universele gegevensuitwisseling mogelijk wordt. Bedrijfsvoering: De werkprocessen voor woonruimteverdeling zijn in duidelijke stappen beschreven in aansluiting op de corporatie praktijk. Koppelingen: De koppelingen tussen systemen, voor ondersteuning van de werkprocessen zijn benoemd. Zodoende is voor elke processtap duidelijk welke gegevensuitwisseling via een koppeling nodig is. Berichten inhoud: Via een koppeling wordt een bericht verstuurd en daarmee worden gegevens uitgewisseld. De inhoud is gedetailleerd beschreven aan de hand van de VERA definities. Technische specificaties: Binnen de VERA standaard wordt de StUF (Standaard UitwisselingsFormaat) gevolgd. Op basis van StUF zijn de technische specificaties bepaald. Daarmee staat vast hoe een bericht eruit ziet en op welke wijze een bericht wordt verstuurd en ontvangen tussen twee systemen. Toegestane waarden: De benodigde keuzelijsten (list-of-values), zijn uitgewerkt in de referentiedata. (Bijvoorbeeld in exploitatiereden, woonvorm ) VERA werkgroep Woonruimteverdeling Vanuit de VERA is een werkgroep samengesteld met: NCCW, WoningNet, Info-Support, Cegeka-dsa en Itris. Zij hebben het ketenproces uitgewerkt en de verschillende producten opgeleverd. Begin dit jaar is dat door een brede groep besproken en gereviewd. Hierbij waren zowel leveranciers (Aareon, Centric, Motion 10, Q-vision, Kubion, Skarp, Ordina) als corporaties (Dudok, Mitros, de Key, Portaal, Vestia) bij betrokken. Hierbij dank ik alle participanten aan VERA 3.1; we hebben een mooi product gemaakt! Jan Fock Voorzitter bestuur Stichting VERA info@stichting-vera.nl Hoofddocument 5

Inleiding Deze versie (VERA 3.1) is een uitbreiding op de derde versie van de Volkshuisvesting Enterprise Referentie Architectuur. Hiermee zet VERA weer een belangrijke stap in de richting van een verbeterde toepasbaarheid en completering van de standaard. Voor het ketenproces woonruimteverdeling is een volledige uitwerking in ontwerp en techniek toegevoegd aan de standaard. Deze technische uitwerking is direct toepasbaar voor het realiseren van koppelingen tussen betrokken ketenpartijen. Met deze toevoeging is een methodiek ontstaan die herbruikbaar is bij de uitwerking van VERA voor andere ketenprocessen en ketenautomatisering zoals ontwikkelen eenheden en leefomgeving, onderhouden eenheden, verhuren eenheden, verkopen eenheden enzovoort. In dit hoofddocument wordt VERA geïntroduceerd en toegelicht en vindt u informatie over de inhoud van de diverse bijlagen. 1.1 De verhouding tussen CORA en VERA VERA is de technische uitwerking van de Corporatie Referentie Architectuur (CORA) en heeft als belangrijkste doelgroepen corporaties, leveranciers en ketenpartijen. Organisatie Informatie/ Communicatie Technologie CORA Strategie (richten) Processen Principes Bedrijfs- en Informatie Planning VERA Keten informatisering Applicatielandschap Structuur (inrichten) Diensten Zaaktype en zaakgericht werken Prestatiemeting Kengetallen Gegevenshuishouding Gegevensmodel Uitvoering (verrichten) Koppelvlakken Figuur 0.1 Positionering CORA en VERA binnen het Amsterdams Informatiemanagement Model In Figuur 0.1 is weergegeven hoe de onderdelen van VERA samen met de CORA 3.1 focusgebieden (SIG-CORA, 2012) gepositioneerd worden. CORA en VERA zijn complementair aan elkaar en hebben een wisselwerking op elkaar. In CORA worden referentiemodellen, architectuurvraagstukken en de daarbij behorende principes en standaarden beschreven, met name vanuit een business oogpunt. Daar waar in CORA sprake is van gegevensuitwisseling is VERA de aangewezen standaard die voor uitwerking en realisatie gebruikt kan worden. De VERA standaard is een invulling vanuit technisch oogpunt om gegevensuitwisseling Hoofddocument 6

te standaardiseren binnen de kaders die CORA biedt. In de technische vertaling van CORA in VERA en het detailniveau wat dit met zich meebrengt ontstaat weer input voor CORA. 1.2 Overzicht belangrijkste wijzigingen De wijzigingen van 3.1 ten opzichte van 3.0 zijn primair een uitbreiding met betrekking tot het verticale sectormodel Woonruimteverdeling. Naar aanleiding van deze uitbreiding en in op basis van ingediende RFC's zijn ook wijzigingen in het horizontale model doorgevoerd. Overige toevoegingen: Sturingslabels: Een uitbreiding op alle klassen, welke het mogelijk maakt om verantwoordingsinformatie over een klasse vast te leggen en te communiceren (bijvoorbeeld dvi voor Corpodata) Energie index toegevoegd Maatschappelijk label: Daeb, niet-daeb, zowel bij de eenheid als de huurovereenkomst. Postadres: Postbus- en antwoordnummer toegevoegd Referentiedata: de eerste set referentiedata Zie voor de gedetailleerde wijzigingen de verschillende bijlagen per domein. 1.3 Documentopbouw Het document is grofweg in een leesgedeelte en naslag gedeelte gesplitst. Hier is bewust voor gekozen om de leesbaarheid te vergroten en de verdeling naar doelgroepen te kunnen maken. De eerste zeven hoofdstukken zijn opgesteld om aansluitend door te lezen. Het hoofddocument bevat alle noodzakelijke informatie om de omvang en inhoud van VERA te kunnen begrijpen. De uitwerkingen van de verschillende VERA onderdelen zijn verspreid over een aantal bijlagen. Elke bijlage kent een specifieke uitwerking of een specifiek aandachtsgebied. In Tabel 5.1 in hoofdstuk 5.3 is de opbouw van de bijlagen beschreven. Deze opdeling dient twee doelen: enerzijds de documentstructuur overzichtelijk en logisch geordend houden en anderzijds de lezer de mogelijkheid bieden om het document per specifiek aandachtsgebied te raadplegen. Zodoende hoeft niet het hele document gelezen te worden en is het gemakkelijker op tablets te raadplegen. Voor wie dat wil, is het ook eenvoudiger in delen af te drukken. Op deze wijze is het relatief eenvoudig tot de kern door te dringen en een relatie met bijvoorbeeld het procesmodel en de meeste informatiefuncties uit CORA te leggen. Het document als geheel beschouwd, met uitzondering van de verkenningen, biedt een volledige weergave van de VERA 3.1 standaard. De afzonderlijke onderdelen bieden ieder een compleet maar opzichzelfstaand deel. De verdeling is zo gemaakt dat de verschillende doelgroepen de voor hun interessante delen logisch gerangschikt bijeen vinden. Om een goed beeld te krijgen van de VERA Hoofddocument 7

standaard vindt u in onderstaande tabel de belangrijkste hoofdstukken per doelgroep. De uitwerking van modellen en diagrammen is in de vorm van losse bijlagen per gegevensdomein opgesteld (bijlagen B.x), waarbij de modelleerconventies in de eerste bijlage (A) zijn opgenomen. De verkenningen bieden relevante informatie en/of achtergrond bij de VERA standaard. Op termijn krijgen onderwerpen die in de verkenningen opgenomen zijn een plek als officieel onderdeel van de VERA standaard. Doelgroep Hoofdstuk(ken) (architectuur) perspectief Iedereen 8 Begrippenlijst Management 1 t/m 3 en 7 Strategie Informatiemanagers en functioneel beheerders Applicatiearchitecten Applicatiebeheerders en technisch beheerders Softwareontwikkelaars Deelnemers doorontwikkeling VERA 1 t/m 7 en bijlage E Informatiearchitectuur en beheer Specifieke bijlagen 4, 5, bijlage A, specifieke bijlagen en verkenningen Tabel 0.1 Leeswijzer per doelgroep Technische architectuur en toepassing Beheer / doorontwikkeling Hoofddocument 8

2 Toenemende integratie en standaardisatie Woningcorporaties worden mede door externe factoren als het economisch klimaat en de politiek gedwongen om effectiever en efficiënter te gaan werken. Het verhogen van de (interne) samenwerking en integratie van de informatievoorziening leveren hieraan een grote bijdrage. VERA is speciaal ontworpen voor gegevensuitwisseling conform de Corporatie Referentie Architectuur (CORA) (NetwIT, 2012). Eén van de doelstellingen van CORA is om harmonisatie te bereiken op het gebied van bedrijfsprocessen, de sturing op bedrijfsprocessen en in uitwisseling van gegevens in samenwerkingsketens. Een andere doelstelling is om leveranciers te prikkelen tot het ontwikkelen van gestandaardiseerde oplossingen die een betere koppelbaarheid hebben. De integratie van de informatievoorziening is dus zeer belangrijk. Informatiesystemen moeten met elkaar samenwerken en veranderingen kunnen ondersteunen en bijhouden. In de toekomst moeten applicaties die gebruik maken van de VERA-standaard de juiste gegevens op een gestandaardiseerde wijze met elkaar uitwisselen. Verschillen in interpretatie behoren dan tot het verleden. Dit leidt tot de doelstelling van VERA om gegevensuitwisseling te standaardiseren. Het toepassen van de VERA standaard leidt tot eenvoudiger en beter beheersbare integratieprojecten en een beter beheersbare informatievoorziening. 2.1 Effectief en efficiënt integreren met VERA Klanten van corporaties willen bepaalde producten of diensten afnemen. Hiervoor zijn bedrijfsprocessen ingericht. Elke stap in het bedrijfsproces draagt informatie over aan de volgende stap om aan de klantvraag te voldoen. Bijvoorbeeld een opzeggingsformulier dat binnenkomt, wordt een huuropzegging die vervolgens weer leidt tot mutatieonderhoud. Een aantal processtappen kan door een andere partij dan de corporatie uitgevoerd worden, bijvoorbeeld woonruimteverdeling. In dat geval spreken we over ketenintegratie. Deze processen worden ondersteund door applicaties. De applicaties bieden informatiefuncties die gegevens verwerken en deze weer beschikbaar stellen aan de processen voor afhandeling. In Figuur 2.1 is dit schematisch weergegeven. Procesinformatie Procesinformatie Procesinformatie 2 Klantvraag Werkproces Informatie Werkproces Informatie Werkproces Geleverd product / dienst Informatiefuncties Informatiefuncties Informatiefuncties Applicatie 1 Applicatie Figuur 2.1 Processen en informatie ondersteund door applicaties De informatie-overdracht tussen werkprocessen is impliciet wanneer de werkprocessen door dezelfde applicatie ondersteund worden. Wordt de informatie tussen twee applicaties uitgewisseld zoals weergegeven in situatie 1 in Figuur 2.1 dan is dit expliciet. Dit kunnen uitwisselingen zijn met Hoofddocument 9

operationele, ondersteunende en/of sturende processen binnen of buiten de corporatie. Met de VERA-standaard kunt u dit soort gegevensuitwisselingen realiseren. Ook procesinformatie behoort tot de mogelijkheden (zie situatie 2 in Figuur 2.1). Hiermee kunnen corporaties hun processen inzichtelijk maken zodat zij deze processen tijdig kunnen bijsturen. Deze procesinformatie moet uiteindelijk uit de registratie binnen de applicaties komen, wat in theorie voor één bedrijfsproces meerdere applicaties kunnen zijn. VERA doet geen uitspraken over de interne werking of registratiewijze van een applicatie. De architectuur en het ontwerp van applicaties zijn buiten scope voor standaardisatie door VERA, net als keuzes voor specifieke applicatie- en technische infrastructuur. 2.2 De standaard in beweging VERA heeft belangrijke stappen gezet om het gewenste toekomstbeeld verder in te vullen. Met name is er veel aandacht besteed op het gebied van toepasbaarheid. Zo biedt VERA bijvoorbeeld nu al de mogelijkheid tot het gebruik van uniforme begrippen in een gegevensuitwisseling. Ook is bijvoorbeeld het formaat om gegevens uit te wisselen gestandaardiseerd. Dit is terug te zien in een aantal gebieden waarop VERA uitwerkingen bevat. VERA onderkent 9 verschillende gegevensdomeinen. Van zeven gegevensdomeinen (relaties, vastgoed, overeenkomsten, onderhoud, woonruimteverdeling, financiën en dossier) en een algemeen domein zijn onderstaande uitwerkingen opgenomen: Logische gegevensmodellen o Klassen (entiteiten) met definities, toelichting en voorbeelden o Attributen op de klassen o Identificatie van referentiedata (zogenaamde keuzelijstjes) Data georiënteerde service definities en koppelvlakken op basis van StUF Bij de service definities en koppelvlakken is uitgewerkt hoe de architectuur van een VERA-koppeling er uit ziet. Ook is er een voorbeeld opgenomen. Het implementatieplan vormt de praktische handreiking om een VERA-koppeling volgens deze architectuur te realiseren. Voor de prestatiemeting is een methodiek uitgewerkt die beschrijft hoe indicatoren en kengetallen uitgewerkt worden in VERA. Daarbij is uitgewerkt hoe de benodigde informatie afgeleid kan worden uit de VERA gegevensmodellen en hoe dat zich vertaalt in verschillende vormen van VERA adapters. Aan de hand van deze methodiek zijn alle indicatoren die in CORA zijn opgenomen uitgewerkt in VERA adapters. De invulling van de referentiedata is niet uitgewerkt, wat betekent dat er voor de geïdentificeerde lijstjes nog geen uitwerking is van de waarden die toegestaan zijn in een lijstje. Ook doet VERA geen uitspraken over validatieregels, zoals veldlengtes of formaten van data. Wel zijn alle attributen getypeerd, dat wil zeggen dat er is aangegeven of het bijvoorbeeld een datum, getal of tekst is. Ook voor deze versie geldt dat leveranciers hier onderlinge afspraken blijven maken tot VERA hier wel invulling aan geeft. Deze onderlinge afspraken kunnen ook weer als input worden gebruikt bij de uitwerking in VERA. Hoofddocument 10

2.3 De standaard richting de toekomst Voor VERA is praktische toepasbaarheid belangrijk. De toekomstige ontwikkeling van VERA staat daarom in het teken van dit aspect en het gebruik van VERA. De toekomst van de standaard wordt mede beïnvloed door het indienen van RFC s. Echter VERA staat niet op zichzelf. VERA is gerelateerd aan andere standaarden (CORA en StUF), waardoor ontwikkelingen van deze standaarden ook invloed hebben op de toekomstige ontwikkelingen van VERA. Uiteindelijk is het de keuze van het bestuur van de stichting welke onderwerpen er in volgende versies van VERA opgepakt gaan worden. Voor de doorontwikkeling van VERA wordt gedacht aan de volgende onderwerpen: Certificering Ondersteuning andere protocollen naast SOAP/XML Uitwerking en toetsing VERA en CORA in concrete scenario s Koppelvlakken aansluitend op het CORA procesmodel inclusief procesgeoriënteerde servicedefinities en koppelvlakken Standaardiseren stamtabellen (referentiedata) en uitwerken van validatieregels voor attributen Hoofddocument 11

3 Hoe te gebruiken? De belangrijkste doelstelling van VERA is het standaardiseren van koppelingen en daardoor reduceren van de complexiteit. Het werken onder architectuur bij het ontwikkelen, aanschaffen en implementeren van koppelingen, zorgt voor betere onderlinge samenwerking tussen de applicaties. De VERA standaard is een hulpmiddel dat architecten helpt bij besluitvorming en het beheersen van de samenhang tussen oplossingen waardoor veranderingen sneller kunnen worden doorgevoerd en systemen eenvoudiger aan elkaar gekoppeld kunnen worden. VERA kan hierbij helpen en biedt hiertoe meerdere handvatten in de vorm van architectuurprincipes, uitgangspunten, standaarden en richtlijnen. VERA biedt tevens uitgewerkte logische gegevensmodellen en technische kaders voor berichtuitwisseling op deze modellen. Hiermee kunnen systemen beter en sneller op elkaar worden aangesloten. 3.1 Door de corporatie VERA biedt corporaties de mogelijkheid om de CORA referentie architectuur en uitgewerkte processen toe te passen binnen de eigen organisatie, ICT en informatiearchitectuur. Zowel bij de eigen ICT ontwikkeling als de aanschaf van software kan de VERA standaard duidelijkheid verschaffen over de samenhang en samenwerking van de technische - en informatiecomponenten. VERA kan ook worden gebruikt om van objecten en attributen de bronadministratie vast te stellen. Door de VERA standaard te hanteren bij de eigen ICT inzet zijn de ontwikkelde producten eenvoudiger aan te sluiten op andere VERA compliant producten. U kunt van uw leveranciers verlangen alleen koppelingen met hun producten te leveren volgens de VERA richtlijnen. Hierdoor ontstaat een betere samenwerking met alle producten die u gebruikt. Dit leidt tot lagere kosten voor deze veelal complexe en tijdrovende integratietrajecten. Ook bij de aanschaf van nieuwe producten die u wilt integreren binnen uw eigen organisatie kan VERA compliance, in de toekomst 1, een onderdeel zijn van de pakketkeuze. Adviesbureaus die bij uitbestedingstrajecten en pakketselecties een rol spelen kunnen dit ook in hun overwegingen meenemen. 3.2 Door de leverancier VERA stelt leveranciers in staat oplossingen te bieden die beter binnen de samenhang van de processen en informatievoorziening passen. Leveranciers kunnen toelichten hoe zij voldoen aan de informatiearchitectuur, logische gegevensmodellen en technische berichtenstandaard van VERA. Door het bieden van standaard VERA-koppelingen en het toepassen van de CORA principes en de VERA standaard voor de eigen oplossingen ontstaat een concurrentievoordeel ten opzichte van leveranciers die nog niet voldoen aan deze standaarden. Ook kunnen deze standaard VERAkoppelingen eenmalig worden ontwikkeld en door alle afnemers gebruikt. Door dit schaalvoordeel kunnen deze afnemers de kosten van de ontwikkeling delen. Zo kunnen de koppelingen goedkoper worden aangeboden waarbij dit tot meer afnemers van diensten kan leiden. Bij voorgenomen uitbreiding van diensten kan VERA helpen om te bepalen waar de leverancier zelf unieke functionaliteit wil leveren en welke mogelijkheden er zijn om andere processen via VERA te 1 Zie ook paragraaf 6.3. Hoofddocument 12

benaderen. Dit kan leiden tot specialisatie in plaats van verbreding van het dienstenpakket van de leverancier. 3.3 Door de sector VERA biedt handvatten voor ketens waarvan corporaties onderdeel zijn. In het bijzonder de uitwerking van de kengetallen zal gestandaardiseerde basis voor rapportering mogelijk maken, richting toezichthouders, marktanalisten, gemeenten en andere overheidsinstanties. VERA maakt het, door gebruik te maken van een gedeeld logisch model, eenvoudiger om samen te werken met ketenpartijen, basisadministraties, gemeenten, belastingdienst, zorgverleners. Ook het uitbesteden van diensten aan gespecialiseerde leveranciers en shared service centers alsmede de bijkomende integratie vraagstukken worden eenvoudiger. Hoofddocument 13

4 Principes en uitgangspunten Om ervoor zorg te dragen dat VERA inderdaad op zo n manier gebruikt kan worden als in het voorgaande hoofdstuk is beschreven is een aantal principes en uitgangspunten gedefinieerd voor de totstandkoming en doorontwikkeling van VERA. Principes komen voort uit de visie en doelstellingen van VERA en zijn waar noodzakelijk verder geconcretiseerd met uitgangspunten. Naast de principes en uitgangspunten geldt een aantal standaarden en richtlijnen. Dit zijn keuzes over de manier waarop de standaard vormgegeven is. Dit vereenvoudigt het begrip van de standaard en bevordert de eenduidigheid van de standaard. Soortgelijke zaken zijn op een soortgelijke manier uitgewerkt. 4.1 Principes De uitwerking van VERA is gebaseerd op een aantal principes, welke in dit hoofdstuk zijn uitgewerkt. 4.1.1 P01 VERA sluit aan op CORA De VERA standaard is gericht op de woningcorporatiebranche. Binnen deze branche bestaat sinds 2010 de CORA, een bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties. CORA 3.0 (SIG-CORA, 2012) richt zich op een aantal focusgebieden: Bedrijfs- en informatieplanning Diensten Bedrijfsprocessen Zaaktypen, zaaktypencatalogus en zaakgericht werken Prestatiemeting Keteninformatisering (Bouw Informatie Model en Basisregistraties) Applicatielandschap (strategieën en informatiefuncties) Gegevenshuishouding Rationale VERA richt zich op gegevensuitwisseling in het domein van woningcorporaties. Door VERA te baseren op CORA wordt er aangesloten bij deze referentiearchitectuur en wordt een brede adoptie gerealiseerd. VERA is daarmee een concrete invulling van de kaders en definities die CORA geeft. CORA zelf biedt hierin geen standaardisering. Door aansluiting bij CORA worden huidige problemen met de kernsystemen (rondom flexibiliteit, ontkoppeling, kostenbeheersing, innovatie van dienstverlening en transparantie van informatievoorziening) aangepakt. Implicaties Brede adoptie van een eenduidige standaard. Gebonden aan CORA kaders. Gemotiveerd afwijken van CORA. 4.1.2 P02 VERA is technologie en platform onafhankelijk Met VERA is het mogelijk om verschillende autonome, heterogene systemen met elkaar te laten communiceren en interacteren. De standaard is toe te passen op koppelingen tussen verschillende technologieën van diverse leveranciers (Microsoft, Oracle, SAP) en applicaties die op een open source platform zijn ontwikkeld. De standaard moet dus applicatie-, platform- en technologie onafhankelijk zijn. Hoofddocument 14

Rationale Door uit te gaan van technologische en functionele standaarden die niet vastgeklonken zijn aan een specifieke applicatie wordt uitwisseling met nog onbekende partijen en applicaties eenvoudiger. Implicaties Breed toepasbaar, geen leveranciers op voorhand uitsluiten. Alleen de grootste gemene deler van technologieën kan gebruikt worden. 4.1.3 P03 VERA gebruikt bestaande open methodieken, technieken en standaarden VERA wil niet het wiel opnieuw uitvinden en gebruikt daarom de meest gangbare of best passende standaarden binnen de ketens waarin corporaties opereren. Rationale Door uit te gaan van bestaande open methodieken, technieken en standaarden ontstaat voor de hele corporatiebranche en ketenpartijen een uniforme basis van waaruit koppelvlakken worden vormgegeven. Het verhoogt de efficiëntie doordat er geen investering in een eigen standaard nodig is en bewerkstelligt effectievere uitwisseling met partijen buiten de sector. Implicaties Corporaties, leveranciers en andere ketenpartijen moeten middels de gekozen open specificaties en protocollen informatie kunnen uitwisselen. VERA krijgt een afhankelijkheid met externe standaarden en wijzigingsfrequenties die daarbij horen. 4.1.4 P04 VERA is een open standaard De VERA standaard moet een open standaard zijn. Dat wil zeggen dat deze publiek beschikbaar is en door iedereen te gebruiken is. Rationale Door VERA een open standaard te maken worden er geen extra barrières aangebracht om VERA toe te passen. Implicaties Methodieken, technieken en standaarden die op basis van principe P03 worden geselecteerd dienen ook vrij te gebruiken zijn. Verhoogde toepasbaarheid en adoptie. 4.2 Uitgangspunten Vanuit de voorgenoemde principes maakt VERA gebruik van uitgangspunten om de ontwikkeling concreter vorm te geven. Deze uitgangspunten worden door het bestuur bepaald. 4.2.1 U01 StUF als standaard voor berichtenverkeer VERA heeft gekozen StUF te hanteren als open standaard op basis van principe P03. De doelstelling van VERA om te komen tot uniformering en standaardisering op het gebied van gegevensuitwisseling komt overeen met de StUF doelstellingen. De StUF standaard (VNG/KING, 2013) is bewezen toepasbaar en wordt al gebruikt voor het koppelvlak met de basisregistraties. StUF wordt beheerd door het Kwaliteitsinstituut Nederlandse Gemeenten (KING) en standaardiseert de syntax en techniek van berichten. VERA maakt gebruik van deze standaard om de logische gegevensmodellen om te zetten in gestandaardiseerde services en berichten. Alleen het SOAP protocol wordt ondersteund voor uitwisseling van gegevens tussen systemen. Hoofddocument 15

StUF kent een eigen beheerprocedure. Door de keuze voor StUF adopteert VERA tevens het versiebeheer zoals StUF dit definieert. Iedere nieuwe versie van VERA voldoet aan de op dat moment geldende StUF versie. VERA 3.0 beperkt zich tot wat StUF het horizontale sectormodel noemt. Door deze keuze worden alleen CRUD operaties ondersteund in deze versie. Meer informatie over het gebruik van StUF in VERA is te vinden in bijlage D. VERA 3.1 is een uitwerking van wat StuF het vertikale sectormodel noemt voor het ketenproces van woonruimteverdeling. Vanuit dit model worden alle benodigde operaties en gegevensdefinities voor het ketenproces uitgewerkt. 4.2.2 U02 UML wordt gebruikt om modellen in VERA op te stellen Op basis van principe P03 wordt gebruik gemaakt van de Unified Modelling Language (UML) (Object Management Group, 2011) om VERA modellen op te stellen. UML is een modelmatige taal om ontwerpen en analyses van informatiesystemen te maken. De taal is sinds 1997 een ISO standaard en wordt de facto gebruikt bij het modelleren van informatiesystemen. Vanwege deze bekendheid in relatie tot ontwikkeling en implementatie van informatiesystemen wordt UML gebruikt om VERA modellen op te stellen. 4.2.3 U03 koppelvlakken maken gebruik van XML Als uitgangspunt voor de uitwerking van koppelvlak definities is vanuit principe P03 gehanteerd dat deze gebruik maken van XML. Dit is een standaard van het World Wide Web Consortium voor de syntaxis van formele opmaaktalen waarmee gestructureerde gegevens kunnen worden weergeven in de vorm van platte tekst. Deze presentatie is zowel leesbaar voor machines als leesbaar voor de mens. VERA heeft voor XML gekozen omdat dit formaat gestructureerde verwerking en validatie mogelijk maakt. Daarnaast is XML een wijdverbreide standaard die door elk technologisch platform ondersteund wordt. VERA bevat een uitwerking die gebruik maakt van StUF (U01). StUF bouwt verder op de open standaarden XML via SOAP. Faciliteiten voor REST/JSON zijn nog geen onderdeel van StUF en daardoor ook niet van VERA 3.1. 4.2.4 U04 Voor kengetallen gaat VERA voor het meest bruikbare model Eenvoud gaat voor architectonische elegantie. Om breed door de markt geaccepteerd te worden, is het belangrijk dat het model gebruiksvriendelijk is. Dit kan soms betekenen dat keuzes worden gemaakt ten koste van bijvoorbeeld volledigheid. 4.2.5 U05 VERA houdt zich bezig met het verzamelen van gegevens voor kengetallen Vanuit de doelstelling van VERA om gegevensuitwisseling te standaardiseren is de methodiek gericht op het koppelvlak met het VERA gegevensmodel ten behoeve van rapportages en analyses. Over het tonen van data in de rapportages en analyses worden geen uitspraken gedaan. 4.2.6 U06 De kengetallenmethodiek is bruikbaar voor alle corporaties De informatiebehoefte van kleine en grote corporaties kan aanzienlijk uiteen lopen. Ook de data- en informatiearchitectuur die hiervoor wordt opgesteld zal verschillen. Sommige corporaties zullen direct willen rapporteren op de gegevens uit VERA, andere corporaties zullen de VERA gegevens Hoofddocument 16

eerst historisch willen opslaan in bijvoorbeeld een datawarehouse en willen integreren met andere gegevensbronnen. Doel van de informatieuitwisseling is om gegevens uit VERA zodanig te ontsluiten c.q. aan te bieden dat ze zowel bruikbaar zijn voor corporaties zonder datawarehouse als voor corporaties met een datawarehouse. 4.2.7 U07 Kengetallen sluiten aan bij de VERA klassen De informatieuitwisseling sluit aan bij de VERA klassen: Er wordt dus geen nieuw klassenmodel gerealiseerd. Dit scheelt veel werk en door VERA-structuur en -terminologie te hergebruiken, wordt het gebruiksgemak van het model verhoogd. De verantwoordelijkheid voor de aanlevering ligt bij de leveranciers van applicaties. 4.3 Standaarden en richtlijnen Op basis van de hierboven geformuleerde principes en uitgangspunten zijn er standaarden en richtlijnen opgesteld die gebruikt zijn bij de (door)ontwikkeling van VERA. Er zijn standaarden en richtlijnen voor: - Modelleren - Diagrammen - Naamgeving - Koppelvlakdefinities - Kengetallen Deze staan beschreven in bijlage A. Hoofddocument 17

5 De inhoud van VERA Vanuit de vastgestelde principes en uitgangspunten is de inhoud van VERA vormgegeven. Zoals in hoofdstuk 2.1 is uitgewerkt, richt VERA zich op gegevensuitwisseling in processen en voor procesinformatie. Om dit te standaardiseren en mogelijk te maken is VERA opgebouwd uit een aantal verschillende onderdelen. In dit hoofdstuk worden de onderdelen nader toegelicht en wordt ingegaan op de samenhang tussen de onderdelen. Daarnaast kan dit hoofdstuk gebruikt worden als routekaart voor de bijlagen en in welke bijlage(n) de uitwerkingen van een onderdeel terug te vinden zijn. 5.1 Onderdelen en onderlinge samenhang Het vertrekpunt voor VERA is CORA. De modellen en kaders die CORA geeft (SIG-CORA, 2012) dienen als input voor de VERA gegevensmodellen, kengetallen (inclusief methodiek) en de koppelvlakdefinities. De uitwerkingen in VERA van de koppelvlakken en de kengetallen maken gebruik van de logische gegevensmodellen van VERA. Figuur 5.1 VERA gegevensdomeinen In Figuur 5.1 zijn de domeinen die momenteel in VERA onderkend worden opgenomen en welke hun oorsprong in CORA hebben. De domeinen in het gekaderde gedeelte zijn de domeinen die op dit moment onderdeel uitmaken van de VERA 3.1 standaard. De domeinen Sociaal en Incasso uit VERA2.0 zijn samengevoegd in Dossier en Financieel. Daarnaast bestaat er nog een overkoepelend domein Algemeen. Per domein bevat de VERA standaard een document dat het domein beschrijft. In deze documenten is vastgelegd welke gegevens er onderkend worden binnen de domeinen en welke definities eraan ten grondslag liggen. Ook is een toelichting opgenomen over hoe - en waarvoor de Hoofddocument 18

gegevens gebruikt kunnen worden. Daarnaast is beschreven welke attributen er bij ieder gegeven horen. De kengetallen worden samengesteld op basis van de inhoud van de gegevensmodellen. De koppelvlakdefinities geven technische definities van uitwisselingen in de vorm van fysieke schema s en servicecontracten. De technische definities worden ook samengesteld op basis van de inhoud van de gegevensmodellen. VERA bevat vanwege deze relatie tussen gegevensmodellen enerzijds en kengetallen en koppelvlakken anderzijds daarom ook methodieken voor het uitwerken van kengetallen en koppelvlakdefinities. De methodiek voor koppelvlakdefinities maakt gebruik van StUF. Al deze onderdelen zijn weergegeven in Figuur 5.2. CORA Koppelvlak Koppelvlak Koppelvlak Koppelvlak methodiek Gegevensmodel Gegevensmodel Gegevensmodel Kengetal methodiek Kengetal Kengetal Kengetal Fysieke schema s Servicecontracten StUF Figuur 5.2 VERA onderdelen 5.2 Detaillering van de onderdelen In de voorgaande paragraaf zijn de verschillende onderdelen van VERA benoemd. Zowel kengetallen als koppelvlakken worden opgesteld op basis van de gegevensmodellen en de CORA modellen. In deze paragrafen wordt toegelicht wat dit in detail betekent. In paragraaf 2.1 is beschreven dat VERA voor de gegevensuitwisseling twee situaties onderkent, namelijk in processen en voor procesinformatie. Beide situaties worden hier behandeld. Hoofddocument 19

5.2.1 Gegevensuitwisseling voor processen Proces Informatie Proces Domein VERA Koppelvlak om berichten te versturen of ontvangen Applicatie Applicatie Bericht met daarin gegevens Registratie Methodiek voor uitwerking techniek Registratie XML structuren voor berichten XSD Schema s WSDL definitie van koppelvlakken Web service contracten Figuur 5.3 Detaillering onderdelen VERA gegevensuitwisseling processen In Figuur 5.3 is de uitwerking van VERA voor gegevensuitwisseling in de processen weergegeven. Zoals de figuur laat zien richt VERA zich dus op de uitwisseling tussen applicaties. Daarbij zijn verschillende patronen mogelijk: bijvoorbeeld vraag/antwoord of kennisgeving. Of daarbij kopieën van gegevens opgeslagen worden is een architectuurvraag. Dit is in ieder geval niet noodzakelijk bij het gebruik van VERA, maar wel mogelijk. VERA gaat er hierbij vanuit dat een applicatie één of meerdere CORA informatiedomeinen afdekt. De berichtuitwisseling die in VERA wordt uitgewerkt voor de processen kan dus gezien worden als de berichtuitwisseling tussen de informatiedomeinen van CORA. Een applicatie kan vervolgens voor het informatiedomein dat deze afdekt zelf besluiten hoe de verschillende modules met elkaar communiceren aangezien VERA geen uitspraken doet over de interne werking van een applicatie. In VERA worden de logische gegevensmodellen gebruikt om berichten samen te stellen die twee applicaties met elkaar uit kunnen wisselen. Hiervoor definieert VERA naast de berichten ook de koppelvlakken die een applicatie aan zou moeten bieden om de berichten te kunnen verwerken. Deze beide componenten (berichten en koppelvlakken) zijn ook in de techniek vertaald. Als gevolg hiervan bevat VERA voor de gegevensuitwisseling in processen drie uitwerkingen. Fysieke schema s (XSD s) voor de berichtstructuren. In VERA 3.1 zijn zowel data als proces georiënteerde berichten. Berichten vanuit processen zijn alleen uitgewerkt voor woonruimteverdeling. Koppelvlak definities in de vorm van WSDL s. Beschrijving van de methodiek, hoe vanuit de gegevensmodellen met de context uit Figuur 5.3 deze technische uitwerkingen opgesteld kunnen worden. Hoofddocument 20

Methodiek voor uitwerking techniek 5.2.2 Gegevensuitwisseling voor procesinformatie CORA definities Rekenregels Bedrijfsregels Rekenregels Domein VERA Definitie Koppelvlak met standaard gegevensdefinities Bedrijfsregels Registratie Gegevens model Stermodel Kengetal Prestatieindicator Analyse ETL Modellen Basisadapter en steradapter Figuur 5.4 Detaillering onderdelen VERA procesinformatie In Figuur 5.4 is de uitwerking van VERA voor de procesinformatie weergegeven. Voor de procesinformatie zijn (prestatie)indicatoren en kengetallen vanuit CORA gedefinieerd met de bijbehorende bedrijfs- en rekenregels. Hiervoor is nog een vertaling naar de techniek nodig die VERA geeft. Deze vertaling bestaat uit stermodellen (feiten en dimensies) en een mapping die aangeeft hoe de feiten en dimensies tot stand komen op basis van de VERA entiteiten en attributen uit de logische gegevensmodellen. Om de gegevens voor het vullen van de stermodellen uit de bronsystemen te kunnen halen bevat VERA voor de bronsystemen een standaard koppelvlak op basis van de VERA logische gegevensmodellen. Dit koppelvlak kan gebruikt worden door een ETL proces om de analyse- en rapportageapplicatie te vullen op basis van de mapping en modellen die VERA geeft voor de procesinformatie. VERA beschrijft met name de methodiek om de definities die in CORA staan uit te werken zoals weergegeven in Figuur 5.4. Een resultaat van het volgen van de methodiek zijn drie soorten koppelvlakken, de zogenaamde adapters opgenomen: de basis-, ster- en datakluisadapter. Daarbij zijn uitwerkingen opgenomen van indicatoren zoals die in CORA zijn opgesteld. 5.3 Verdere uitwerking van de onderdelen In voorgaande paragrafen is toegelicht uit welke onderdelen VERA bestaat en hoe deze met elkaar samenhangen. De uitwerking van deze onderdelen is in verschillende bijlagen opgenomen. Ze vallen Hoofddocument 21

uiteen in drie groepen: technologie onafhankelijk, technologie specifiek en implementatie. NB: hoewel deze tweede groep niet technologie onafhankelijk is, zijn ze nog altijd platform onafhankelijk. Dit is van groot belang voor de gegevensuitwisseling. In onderstaande tabel is opgenomen welke onderdelen in welke bijlage terug te vinden zijn. In bijlage A zijn alle standaarden en richtlijnen verzameld die op de uitwerking van VERA van toepassing zijn. Onderdeel Toelichting Nummering Technologie onafhankelijk Logische gegevensmodellen Per gegevensdomein is een aparte bijlage opgenomen bij het hoofddocument. Per gegevensdomein is hierin uitgewerkt: Bijlage B.1-B.8 Klassen Samenhang tussen klassen in een diagram Methodiek kengetallen Methodiek referentiedata Methodiek sturingslabels Technologie specifiek Uitwerking CORA indicatoren Methodiek koppelvlakdefinities XSD schema s berichten WSDL web service contracten Methodiek vertikaal sectormodel Uitwerking Woonruimteverdeling Uitwerking Referentiedata Implementatie Implementatieplan koppelingen Attributen De methodiek die beschrijft hoe vanuit de CORA kaders de onderkende kengetallen uitgewerkt zijn zodat toekomstige uitwerkingen volgens dezelfde lijnen uitgevoerd kunnen worden. De methodiek die beschijft hoe men voor de berichten de referentiedata kan bepalen. De methodiek die beschijft hoe men informatie voor operationele sturing kan meesturen bij berichten. Een uitwerking van de indicatoren die in CORA 3.1 zijn opgenomen in VERA adapters. De methodiek die beschrijft hoe met behulp van StUF de berichtschema s en koppelvlakdefinities uitgewerkt zijn zodat toekomstige uitwerkingen volgens dezelfde lijnen uitgevoerd kunnen worden. De schema s voor de berichten worden conform de door StUF voorgeschreven documentstructuur opgeleverd. Deze bijlage is in de vorm van een.zip bestand opgenomen. De contract definities voor de web services zijn opgenomen in de vorm van een WSDL-bestand. Bijlage A Uitwerking van het verticale sectormodel voor woonruimteverdeling op basis van de methodiek. Uitwerking van referentiedata primair bedoeld voor de berichten van het verticale sectormodel woonruimteverdeling. Handleiding voor het implementeren van een VERAkoppeling met behulp van services. Tabel 5.1 Overzicht inhoud bijlagen Bijlage C.1 Bijlage A Bijlage A Bijlage C.2 Bijlage A par. 3.1 Bijlage D.1 Bijlage D.5 Bijlage D.3 Bijlage D.3 Bijlage A Bijlage F.1 Bijlage F.2 Bijlage E.1 Hoofddocument 22

6 Toepassing en beheer van de standaard Bij het uitbrengen van nieuwe versies van VERA hoort logischerwijs ook de vraag hoe en wanneer versies uitgebracht worden. Dit geeft inzicht in compatibiliteit tussen verschillende versies en inzicht voor leveranciers over bijvoorbeeld terugverdientijden van standaard koppelvlakken. Daarnaast is het voor corporaties en leveranciers relevant om te weten wanneer een koppeling VERA compliant genoemd mag worden na een bepaalde toetsing of toepassing. In dit hoofdstuk wordt daarom ingegaan op het release- en versiebeleid van VERA. Ook wordt toegelicht hoe compliancy ingevuld kan worden en op welke manier een VERA-koppeling tot stand komt. 6.1 VERA implementatie VERA bestaat uit een groot aantal verschillende onderdelen en modellen. Deze hebben onderlinge afhankelijkheden met elkaar, bovendien wordt niet alles letterlijk voorgeschreven. Wat betekent dit nu voor de implementatie van een VERA-koppeling? Om antwoord te geven op deze vraag is sinds VERA 3.0 een implementatieplan en een bijbehorende template voor het ontwerp van een koppeling opgenomen. Het implementatieplan is een praktische handleiding die woningcorporaties, leveranciers en ketenpartijen ondersteunt bij het realiseren van een VERA-koppeling. 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 en de template voor het ontwerp van een koppeling zijn onderdeel van bijlage E. N.B. Voor ontwerp van ketenproceskoppelingen is een aparte methodiek verticaal sectormodel beschreven. 6.2 Releasebeleid De verantwoordelijkheid voor het beheer van de standaard ligt bij de Stichting. Deze werkt met een vaste releasecyclus. Zowel uitbreidingen, wijzigingen als opgeloste defects worden via releases opgelost. De inhoud van een release komt voort uit input uit de community van VERA betrokkenen, gebruikers, het bestuur en de stuurgroep. Input vanuit de community wordt gegeven in de vorm van RFC s. In principe kan dus iedereen die met VERA te maken heeft een RFC indienen. Een RFC kan gaan over wijzigingen op bestaande inhoud en over verzoeken om nieuwe inhoud toe te voegen, bijvoorbeeld vanuit innovatie. Het indienen van een RFC gebeurt via een vast format dat beschikbaar is op de website van de stichting. Daarnaast bestaat er een LinkedIn groep van de Stichting (Stichting VERA, 2014), deze zou gebruikt kunnen worden om in de community een discussie te voeren over in te dienen RFC s. In VERA wordt onder release- en versiebeleid het volgende verstaan: Hoofddocument 23

Releasebeleid: Het (beheer)proces dat zorgt draagt voor een gecontroleerde, beheersbare en voorspelbare release van een verzameling configuratie items in een gedefinieerde versie richting belanghebbenden. Versiebeleid: Het (beheer)proces dat voorschrijft op welke wijze en in welke volgorde wijzigingen (changes) worden doorgevoerd op de verschillende onderdelen (configuration items) van VERA. Voor VERA 3.0 is er een verkenning uitgevoerd naar het release- en versiebeleid van VERA. De uitkomst van deze verkenning is geen officieel onderdeel van VERA 3.0 en 3.1, maar als apart katern gevoegd. 6.3 VERA-compliant Met de ontwikkeling van VERA is er ook aandacht geweest voor de vraag: wanneer wordt er voldaan aan VERA? Dit heeft ertoe geleid dat er een VERA convenant is opgesteld en een certificeringstraject is onderkend. Meer informatie hierover is te vinden op de website van de Stichting VERA: www.stichting-vera.nl. Het VERA convenant heeft als doel om de samenwerking tussen diverse partijen en de Stichting VERA te bekrachtigen. Het convenant verwoordt hiertoe een aantal doelen en bevat (werk)afspraken tussen de Stichting VERA en de ondertekenende partijen. Zo staan er bijvoorbeeld afspraken in over het delen van kennis en het toepassen van de VERA standaard. Voor VERA 3.0 is een verkenning uitgevoerd naar de compliancy aanpak. Hierin is een aanpak uiteengezet met aandacht voor het certificeringsproces, het auditproces en het benodigde normenkader. Certificeringsproces; beschrijft het algemene certificeringsproces van VERA met daarbij behorende hoofdlijnproces, doelstellingen en betrokken partijen. Auditproces voor certificering; beschrijft de stappen in een auditproces om tot certificering van een deelnemer tegen een VERA standaard te komen. Normenkader; beschrijft opbouw van het VERA-normenkader, de aanpak om het normenkader uit te werken en de kwaliteitseisen waar individuele normen aan moeten voldoen. De hierna volgende figuur beschrijft hoe het normenkader wordt opgebouwd. Hoofddocument 24

Figuur 6.1 Opbouw normenkader De uitkomst van deze verkenning is geen officieel onderdeel van de VERA 3.1 standaard. Deze is als apart katern bijgevoegd. Hoofddocument 25

7 Over de Stichting VERA De VERA standaard is eigendom van de Stichting VERA. De stichting voert het beheer op de standaard. Statutair is vastgelegd dat de Stichting VERA zich richt op een technische normalisatiestandaard voor gegevens. Het bestuur van de Stichting VERA heeft maximaal zeven leden, bestaande uit vier corporaties en drie leveranciers. De leveranciers in het bestuur rouleren en stellen hun zetel om de twee jaar ter beschikking. De corporaties hebben een meerderheid aan stemmen en vertegenwoordigen de sector in de breedte bij de ontwikkeling van de VERA standaard. De stichting heeft een stuurgroep. Hierin hebben drie leveranciers en twee corporaties zitting. De stuurgroep is verantwoordelijk voor de uitvoering van de doelstellingen die het bestuur en daarmee de stichting hebben gesteld. VERA 3.1 is tot stand gekomen in verschillende werkgroepen. In opdracht van het bestuur hebben de werkgroepen VERA 3.1 ontwikkeld. Meer informatie, zoals bijvoorbeeld statuten en huishoudelijk regelement zijn te downloaden op de site van de Stichting VERA: www.stichting-vera.nl. Fi guur 7.1 Organisati e Stichting VERA Hoofddocument 26

8 Begrippenlijst In de uitwerking van de VERA standaard wordt het onderstaande begrippenkader van technische termen gebruikt. Begrip Associatie Attribuut Basisadapter CRUD ETL Generalisatie / specialisatie ISO JSON Klasse Omschrijving Een relatie (verwijzing) tussen instanties van een klasse. (Object Management Group, 2011) Bijvoorbeeld: Relatie heeft een Adres. Informatie die onderdeel is van / hoort bij een klasse en waaruit de klasse is opgebouwd. Bijvoorbeeld: geboortedatum. Adapter die gegevens uit een niet verder gedefinieerde bron omzet naar voor VERA herkenbare entiteiten. Afkorting voor Create, Read, Update and Delete. Dit zijn de vier basisoperaties die op duurzame gegevens (meestal een database) uitgevoerd kunnen worden. Afkorting voor Extraction, Transformation and Load. Voor een uitgebreidere toelichting zie: Bijlage C Een klasse die een verbijzondering (subtype) is van een andere klasse supertype). Het subtype neemt alle attributen over van het supertype (Object Management Group, 2011). Een subtype kan daar zijn eigen subtype specifieke attributen aan toe. Bijvoorbeeld: NatuurlijkPersoon is een specialisatie van Relatie. Relatie is een generalisatie van NatuurlijkPersoon. Afkorting voor International Organization for Standardization. Een onafhankelijke organisatie, bestaand uit een netwerk van nationale organisaties voor het beheer van standaarden, uit 163 landen. Afkorting voor JavaScript Object Notation. Een lichtgewicht data-uitwisselingsformaat dat eenvoudig door mensen gelezen en geschreven kan worden en ook eenvoudig door computers gebruikt kan worden. Het betreft onderdelen van de Javascript programmeertaal. Logische verzameling van gegevens die van vitaal belang zijn voor een bedrijf. Deze ontstaan tijdens het uitvoeren van bedrijfsprocessen en zijn over het algemeen ook het eigendom van het bedrijf. Dit zijn ook typisch gegevens die bewaard moeten blijven na afloop van een bedrijfsproces. UML definitie: een klasse is een definitie van een verzameling potentiele objecten die dezelfde gegevens, gedrag en relaties hebben. Mapping Bijvoorbeeld: Adres of Verhuurbare Eenheid. Het systematisch vergelijken van termen in verschillende schema`s, om de mate van overeenkomst of verschil te bepalen. Hoofddocument 27