Rotterdamse TerugMeld Faciliteit

Transcriptie

1 Presentatie NOIV congres, 24 maart 2011 Jaap Dekker CIO-office Rotterdamse TerugMeld Faciliteit

2 2 Agenda Waarom dit verhaal? Digimelding (voorheen TerugMeld Faciliteit). Rotterdamse TerugMeld Faciliteit (RTMF). Open source beheermodel voor doorontwikkeling en hergebruik. Conclusies en Vervolgaanpak.

3 3 Waarom dit verhaal? Rotterdam onderschrijft open standaarden en open source. Programma's Basisregistraties en Dienstverlening. Ontwikkeling in eigen beheer op basis architectuur. Softwareontwikkeling betaalt met gemeenschapsgeld. Hergebruik door andere overheden en derden. Snelheidswinst en kostenbesparing, niet 2x wiel uitvinden. Beschikbaar stellen onder open source. Ervaringen tot nu toe met u delen.

4 4 Digimelding Stelsel van Basisregistraties (o.a. GBA, BAG). Eenmalig vastleggen, meervoudig gebruiken. Betrouwbare gegevens. Onjuistheden melden aan bronhouder -> Digimelding Ontwikkeld door ICTU programma Renoir In beheer bij Logius. Zie: voor meer info.

5 5 Digimelding

6 6 Rotterdamse TerugMeld Faciliteit Rotterdam heeft Digimelding uitgebreid. 1 interface voor terugmelden. Functioneel: Terugmelden landelijke basisgegevens Terugmelden Rotterdamse kerngegevens Tonen actuele waarden gegevensmagazijn. Geen aanpassingen Digimelding en koppeling. Meerdere partijen hebben interesse voor de RTMF getoond.

7 7 Rotterdamse TerugMeld Faciliteit

8 8 Rotterdamse TerugMeld Faciliteit ICTU / Logius Digimelding, ongewijzigd ICTU / Logius Digikoppeling, ongewijzigd Externe services

9 9 Rotterdamse TerugMeld Faciliteit Rotterdams Zakenmagazijn RTMF = service die berichtenverkeer tussen Digimelding en -koppeling afvangt t.b.v.: Terugmelden Rotterdamse kernregistraties Tonen actuele waarden uit gegevensmagazijn Rotterdams Gegevensmagazijn

10 10 Open Source Beheermodel Rotterdam wil RTMF als open source beschikbaar stellen (EUPL). Maar Rotterdam wil niet in de rol van leverancier / consultant. In gesprek met NOIV en King en commerciële dienstverleners. King: RTMF voldoet aan high level architectuur Gemma. King: (op dit moment) geen operationele rol.

11 11 Berheermodel: nog veel vragen Belangstelling van andere gemeenten is er maar wat stel je precies beschikbaar? Idee, ontwerp, software? En hoe doe je dat? Doorontwikkeling community? Kwaliteitsborging, versiebeheer? Centrale regie nodig? Consultancy en implementatie diensten, marktpartijen? SLA's? Kosten en financiering? En nog veel meer beren op de weg?!

12 12 Centraal of gedistribueerd model? Keuze o.a. afhankelijk van toepassing, doelgroep, functionaliteit, kwaliteit. Keuze heeft impact op spelregels van de community. Vergelijk App store en Android market.

13 13 Centraal versiebeheer Wordt toegepast indien 1 versie van de code gewenst / noodzakelijk is. Hiërarchisch georganiseerd beheer. Ontwikkelaars krijgen na screening toegang tot versiebeheer (commitrechten). Indien een onafhankelijke versie nodig is, wordt repository geforked. Repositories gaan eigen leven leiden, later samenvoegen moeilijk. Meer regie nodig en minder flexibiliteit.

14 14 Gedistribueerd versiebeheer Diverse repositories, die onafhankelijk van elkaar beheerd en verbeterd kunnen worden. Geschikt indien meerdere organisaties onafhankelijk van elkaar verschillende versies willen kunnen uitbrengen. Verschillende repositories blijven altijd onderdeel van het grotere geheel. Ontwikkelaars worden niet gescreened om toegang te krijgen. Iedere ontwikkelaar ontwikkelt in eigen repository en publiceert wijzigingen. Andere partijen kunnen de wijzigingen toevoegen aan eigen repository.

15 15 Uitwerking gedistribueerd beheermodel

16 16 Concept beheermodel Community platform Lijst code wijzigingen Wiki, mailinglist, forum Centrale RTMF sourcecode repository (de echte waarheid)

17 17 Concept beheermodel Per klant (gemeente) kan leverancier aparte source versie onderhouden Iedere leverancier heeft eigen versie broncode

18 18 Concept beheermodel Per klant (gemeente) kan leverancier aparte source versie onderhouden Leverancier maakt executable voor klant. Dienstverlening en QA op basis SLA

19 19 Concept beheermodel (Generieke) wijzigingen worden door Leveranciers bijgehouden Wijzigingen worden na goedkeuring uit bron Leveranciers gehaald en centraal gemerged Leveranciers informeren andere partijen en bronhouder over verbeteringen en nieuwe functionaliteit

20 20 Voorbeeld gedistribueerd versiebeheer Repository 1 Bevat 1 status (aantal source files)

21 21 Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 2 maakt een kloon van repository 1 met alle statussen. Daarna maakt hij 2 aanpassingen, status sx en status sf

22 22 Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 3 maakt ook een kloon van repository 1, en maakt 2 andere wijzigingen

23 23 Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 1 vult na een review van de wijzigingen zijn repository aan met de wijzigingen uit repository 2

24 24 Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 1 vult vervolgens zijn repository ook nog aan met wijzigigen uit repository 3

25 25 Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 1 maakt vervolgens een nieuwe stand waarin de wijzigingen van ontwikkelaar 2 en 3 gecombineerd zijn.

26 26 Voorbeeld gedistribueerd versiebeheer Een repository is een bron van code. Repository 1 hoeft niet compleet te zijn. Een repository kan naar believen uitgebreid worden, of aangevuld met nodes uit andere repositories.

27 27 Conclusies en Vervolgaanpak Een begin maken met enthousiaste gemeenten en dienstverleners, niet te veel regels bij de start. Samenwerken moet voordelen opleveren voor alle betrokkenen, inclusief dienstverleners. Gericht op hergebruik, daardoor snelheidswinst en kostenbesparing. Geen belasting of extra kosten door centrale sturing (iedereen kan onafhankelijk de source code aanpassen). Zo veel mogelijk virtuele regie. Geen polderbijeenkomsten. Aanzet Beheermodel i.o.m. NOIV, King, Logius en dienstverleners uitwerken. Start maken met hergebruik.