Presentatie NOIV congres, 24 maart 2011 Jaap Dekker CIO-office
Rotterdamse TerugMeld Faciliteit
28-03-11
Agenda Waarom dit verhaal? Digimelding (voorheen TerugMeld Faciliteit). Rotterdamse TerugMeld Faciliteit (RTMF). Open source beheermodel voor doorontwikkeling en hergebruik. Conclusies en Vervolgaanpak.
2
28-03-11
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.
3
28-03-11
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: http://www.logius.nl voor meer info.
4
28-03-11
Digimelding
5
28-03-11
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.
6
28-03-11
Rotterdamse TerugMeld Faciliteit
7
28-03-11
Rotterdamse TerugMeld Faciliteit ICTU / Logius Digimelding, ongewijzigd
8
28-03-11
ICTU / Logius Digikoppeling, ongewijzigd
Externe services
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
9
28-03-11
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.
10
28-03-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”?!
11
28-03-11
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.
12
28-03-11
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.
13
28-03-11
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.
14
28-03-11
Uitwerking gedistribueerd beheermodel
15
28-03-11
Concept beheermodel
Community platform Lijst code wijzigingen Wiki, mailinglist, forum
16
28-03-11
Centrale RTMF sourcecode repository (de echte waarheid)
Concept beheermodel
Per klant (gemeente) kan leverancier aparte source versie onderhouden
17
28-03-11
Iedere leverancier heeft eigen versie broncode
Concept beheermodel
Per klant (gemeente) kan leverancier aparte source versie onderhouden
18
28-03-11
Leverancier maakt executable voor klant. Dienstverlening en QA op basis SLA
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
19
28-03-11
Voorbeeld gedistribueerd versiebeheer
Repository 1 Bevat 1 status (aantal source files)
20
28-03-11
Voorbeeld gedistribueerd versiebeheer
Ontwikkelaar 2 maakt een kloon van repository 1 met alle statussen. Daarna maakt hij 2 aanpassingen, status sx en status sf
21
28-03-11
Voorbeeld gedistribueerd versiebeheer
Ontwikkelaar 3 maakt ook een kloon van repository 1, en maakt 2 andere wijzigingen
22
28-03-11
Voorbeeld gedistribueerd versiebeheer
Ontwikkelaar 1 vult na een review van de wijzigingen zijn repository aan met de wijzigingen uit repository 2
23
28-03-11
Voorbeeld gedistribueerd versiebeheer Ontwikkelaar 1 vult vervolgens zijn repository ook nog aan met wijzigigen uit repository 3
24
28-03-11
Voorbeeld gedistribueerd versiebeheer
Ontwikkelaar 1 maakt vervolgens een nieuwe stand waarin de wijzigingen van ontwikkelaar 2 en 3 gecombineerd zijn.
25
28-03-11
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.
26
28-03-11
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.
27
28-03-11
