Inleiding

Nagenoeg een jaar geleden begonnen we, De KennisFabriek, aan deze release van 360º Overheid. Hiervoor waren meerdere redenen:

• Onze klanten gaven heel waardevolle feedback. Zo had de gemeente Heerlen behoefte aan de registratie van zogenaamde 'Use Cases' en vroegen de Omgevingsdienst Groningen en RUD Drenthe om functionaliteit voor het vastleggen van vrije inhoud, bijvoorbeeld voor werkinstructies en veelgestelde vragen. En uit onze gesprekken met meerdere klanten ontstonden ideeën voor een verbeterde versie van de producten- en dienstencatalogus, zodat organisatiespecifieke aspecten (denk aan tarieven, kentallen, et cetera) ook per organisatie kunnen worden vastgelegd. 
• De basis (XWiki) onder het 360º Overheid-platform werd ingrijpend veranderd door de introductie van zogenaamde nested spaces. Daarmee werd de tweelaags-structuur van XWiki omgevormd naar een echte boomstructuur. Wij simuleerden - via een work-around - deze functionaliteit al via 'ouder-kind'-relaties, dus waren we erg blij dat de boomstructuur ook daadwerkelijk ondersteuning kreeg in de XWiki-basis. 
• Onze - talrijke - toevoegingen aan de XWiki-basis, waren lastig 'uit te rollen' en vergden veel handmatig beheer. Versie 3.0 van 360º Overheid implementeert deze toevoegingen volgens de systematiek van XWiki (via uitbreidingen - extensions - op de XWiki-basis), waardoor dit beheer veel eenvoudiger wordt.
• Onze technische infrastructuur vergde - naar onze mening - teveel handmatig beheer. De verschillende componenten (LDAP, database server, applicatieserver, webserver) moesten afzonderlijk worden geconfigureerd en beheerd. Het opbouwen van een nieuwe omgeving was daardoor zeer arbeidsintensief en foutgevoelig.
• Beveiliging was altijd al een belangrijk aandachtspunt - veel gebruikers vervloeken ons vanwege de uitgifte van 'sterke' wachtwoorden die ze niet zelf kunnen aanpassen, sorry daarvoor -, dus we wilden heel graag alle 360º Overheid-omgevingen beveiligen met SSL-certificaten.

Deze wensenlijst - die in de praktijk nog véél langer was - leidde ertoe dat we veel, heel veel, programmacode hebben herontworpen / herontwikkeld. Deze aanpassingen zijn niet altijd zichtbaar voor eindgebruikers en beheerders, maar stellen ons wel in staat 360º Overheid in de toekomst robuust en beheer(s)baar door te ontwikkelen. Hieronder beschrijven we achtereenvolgens de belangrijkste wijzigingen voor eindgebruikers en beheerders.

Wijzigingen voor eindgebruikers

Nested spaces

De oorspronkelijk 'platte' structuur van XWiki van mappen met daarin pagina's is volledig omgevormd naar een boomstructuur. Eindgebruikers merken hier niet veel van, omdat we in de vorige versie van 360º Overheid al een boomstructuur 'simuleerden' die technisch werd vertaald naar eerdergenoemde platte structuur. Het heeft voor ons wel betekend dat we de volledige programmacode die deze structuur simuleerde, moesten aanpassen aan de nieuwe structuur van XWiki.

Nieuwe functionaliteit

De nested spaces stellen ons in staat om flexibeler met de functionaliteit van 360º Overheid om te gaan. Zo hebben we de mogelijkheid gecreëerd (én bij een aantal klanten benut) om een gelaagdheid in de producten- en dienstencatalogus aan te brengen. Bij de Omgevingsdienst Groningen en RUD Drenthe konden we daardoor twee versies (2016 en 2017) van de producten- en dienstencatalogus naast elkaar laten bestaan en bij de Veiligheidsregio's in Brabant hebben we deze functionaliteit benut om een externe en een interne producten- en dienstencatalogus te onderscheiden. 

Wijzigingen in de User Interface

De nested spaces hebben ook geleid tot nieuwe mogelijkheden in de User Interface. Zo gebruiken we zogenaamde tree views op de homepage om gebruikers sneller naar de door hen gewenste informatie te laten navigeren.

Ook in de breadcrumbs (broodkruimels) die op elke pagina staan, is zo'n treeview geïntroduceerd:

Rechten

De nested spaces in combinatie met de fijnmazige rechtenstructuur waarover 360º Overheid beschikt, maakt het mogelijk onderdelen van de wiki beschikbaar te stellen aan specifieke groepen gebruikers. In de vorige versie van 360º Overheid maakten we onderscheid in twee groepen gebruikers: Beheerders en Gebruikers, beide van de gebruikende organisatie. Beheerders kunnen pagina's en objecten wijzigen, gebruikers kunnen pagina's en objecten bekijken en daar opmerkingen bij maken.

In deze nieuwe versie hebben we daar de groep Klanten aan toegevoegd, zodat we - in overleg met de gebruikende organisatie - medewerkers van opdrachtgevers (bijvoorbeeld gemeenten die opdrachtgever zijn van omgevingsdiensten en veiligheidsregio) toegang kunnen geven tot informatie die voor een gastbezoeker onzichtbaar blijft.

Binnen alle groepen gebruikers kunnen 'subgroepen' worden aangemaakt, zodat 360º Overheid-omgevingen die door meerdere organisaties worden gebruikt ook functioneel eenvoudiger kunnen worden gescheiden. Een goede casus daarvoor is de 360º Overheid-omgeving die door de Omgevingsdienst Groningen en de RUD Drenthe wordt gebruikt: daarin worden zowel gedeelde werkinstructies bijgehouden als werkinstructies die specifiek zijn voor elk van de organisaties. Door subgroepen aan te maken onder de groep Gebruikers, is het mogelijk de gebruikers van Omgevingsdienst Groningen alleen toegang te geven tot de werkinstructies van de Omgevingsdienst Groningen, en de gebruikers van de RUD Drenthe tot de werkinstructies van de RUD Drenthe. Alle Gebruikers houden uiteraard toegang tot de gedeelde werkinstructies.

• Groep 'Gebruikers': toegang tot 'Kennis en documentatie / Gedeeld'
  • Groep 'GebruikersGroningen': toegang tot 'Kennis en documentatie / Omgevingsdienst Groningen'
  • Groep 'GebruikersDrenthe': toegang tot 'Kennis en documentatie / RUD Drenthe'

Het beheer van dit soort rollen en rechten kan nog niet door de Beheerders van een 360º Overheid-omgeving worden uitgevoerd. Enerzijds niet omdat de basis voor die rollen en rechten moet worden gelegd in de LDAP-server en anderzijds niet omdat de XWiki-rechtenstructuur waarop de rechten voor 360º Overheid-omgevingen zijn gestoeld, complex zijn en daardoor fouten - waardoor gebruikers bepaalde functionaliteit of informatie niet (of juist wel, terwijl dat niet zou moeten) kunnen bereiken - eenvoudig kunnen worden gemaakt. Vooralsnog zal dit beheer van rollen en rechten dus door De KennisFabriek worden uitgevoerd. Dit stelt ons ook in staat kritisch te blijven kijken naar de functionele of technische noodzaak voor het aanmaken en gebruiken van rollen en rechten: naast alle goede en mooie dingen die met rollen en rechten kunnen worden gerealiseerd, is het namelijk ook heel eenvoudig om een 360º Overheid-omgeving (met honderden spaces en duizenden pagina's) volledig onbeheer(s)baar te maken door een té enthousiast gebruik van rollen en rechten.

Producten- en dienstencatalogus

De producten- en dienstencatalogus is qua structuur drastisch herzien. Hierover is lang nagedacht door De KennisFabriek en we hebben zelfs geaarzeld of we wel 'zo ver zouden moeten willen gaan'. Omdat er geen andere manier is om tot een zuivere - bedrijfseconomische - beschrijving van producten en diensten te komen, hebben we de complexe praktijk tóch geïmplementeerd in het model van de producten- en dienstencatalogus. Uiteraard kan elke gebruikende organisatie zelf bepalen tot op welk niveau dat model wordt gebruikt.

In de vorige versie van 360º Overheid was de structuur als volgt:

• Product A
  • Varianten
    • Variant 1
    • Variant 2
  • Onderdelen
    • Onderdeel a
    • Onderdeel b
• Product B
  • Varianten
    • Variant 1
    • …
  • Onderdelen
    • Onderdeel a
    • …

In de nieuwe versie is de structuur:

• Product A
  • Varianten
    • Variant 1
      • VariantKenmerken van organisatie I
      • VariantKenmerken van organisatie II
      • Bijdrage-varianten
        • Bijdrage-variant: Variant 6 (van Product B)
        • Bijdrage-variant: Variant 9 (van Product B)
      • Onderdelen
        • Onderdeel a
          • OnderdeelKenmerken van organisatie I
          • OnderdeelKenmerken van organisatie II
        • Onderdeel b
          • OnderdeelKenmerken van organisatie I
          • OnderdeelKenmerken van organisatie II
    • Variant 2
      • …
    • …
• Product B
  • Varianten
    • Variant 6
      • Variantkenmerken van organisatie I
      • Variantkenmerken van organisatie II
      • Bijdragevarianten
      • Onderdelen
    • …
    • Variant 9
      • …

Varianten en Onderdelen 'geknipt': kenmerken apart

Zowel de objecttypen 'Variant' als 'Onderdeel' zijn 'geknipt': de code en naam van een Variant of Onderdeel zijn attributen gebleven van het Variant- respectievelijk Onderdeel-object, maar de organisatiespecifieke kenmerken (zoals een kental of uurtarief) zijn een niveau lager gelegd in VariantKenmerken en OnderdeelKenmerken. Zo kunnen pér gebruikende organisatie van een 360º Overheid-omgeving andere kenmerken (kental, uurtarief, etc.) worden vastgelegd, terwijl ze tóch een gemeenschappelijke producten- en dienstencatalogus hanteren.

Let op: het was de bedoeling om al in deze release van 360º Overheid automatisch de juiste rechten te zetten op de Kenmerken van Varianten en Onderdelen. Dit opdat dit soort 'concurrentiegevoelige' informatie (met bijvoorbeeld uurtarieven en kentallen voor het aantal uren dat een specifieke organisatie besteed aan een product of dienst) alleen zichtbaar zou zijn voor specifieke groepen gebruikers (bijvoorbeeld de medewerkers of opdrachtgevers van organisatie I zien alleen de …Kenmerken van organisatie I). Tijdens het testen bleek deze functionaliteit tóch te fragiel / foutgevoelig, dus die hebben we moeten aanhouden voor een volgende release. Dit betekent dat Variant- en OnderdeelKenmerken nog niet zijn af te schermen en dus zichtbaar zijn voor alle gebruikers die de betreffende producten kunnen bekijken.

Onderdelen zijn 'kind' geworden van Variant

In de vorige versie van 360º Overheid had een Product 'Varianten' en 'Onderdelen' als kinderen. Daarbij was een Variant het 'kostprijsbepalende' element van een product en was een Onderdeel het optionele, kostprijsverhogende, element. Dat beide objecttypen op hetzelfde niveau waren gemodelleerd bleek in de praktijk niet handig: Onderdelen moesten specifiek kunnen worden gemaakt voor een Variant van een Product. Daarom zijn Onderdelen nu 'onder' een Variant gehangen. 

Let op: voor bestaande 360º Overheid-omgevingen waarin zowel Varianten als Onderdelen werden gebruikt, betekent dit dat elk Onderdeel dat in de vorige versie een 'kind' was van een Product, nu een 'kind' is geworden van elke Variant van dat Product. Dat is de enige manier om geen informatie te verliezen bij de migratie naar de nieuwe 360º Overheid-omgeving. Als er dus in de oude omgeving een Product bestond met 5 Varianten en 10 Onderdelen, dan heeft dat Product nu nog steeds 5 Varianten, maar heeft elk van die Varianten 10 Onderdelen! U zult helaas bij elke Variant moeten beoordelen of alle daaronder gecreëerde Onderdelen relevant zijn voor die specifieke Variant. Als dat niet het geval is, kunt u de betreffende Onderdelen gewoon verwijderen.

Bijdrage-varianten voor 'halffabrikaten'

Sommige Varianten kunnen zowel zelfstandig bestaan, als worden toegepast in het vervaardigen van een - Variant van - een ander product. Zie bijvoorbeeld de volgende - vereenvoudigde - casus uit het domein van Vergunningverlening, Toezicht en Handhaving:

• Product: Omgevingsvergunning
  • Variant: Oprichtingsvergunning milieu-inrichting
    • Onderdeel: Advies brandveilig gebruik (wordt 'extern ingekocht' bij de Brandweer)
• …
• Product: Advies
  • Variant: Advies Geluid
  • Variant: Advies Milieu
  • Variant: Advies Luchtkwaliteit
  • …

De Varianten van het Product 'Advies' kunnen direct door opdrachtgevers worden afgenomen (bijvoorbeeld voor het opstellen van een bestemmingsplan / omgevingsplan of het beoordelen van een Aanvraag Omgevingsvergunning met het zwaartepunt op de activiteit 'Bouwen' die zij zelf behandelen, maar waarvoor ze een advies van een omgevingsdienst nodig hebben). De adviezen kunnen echter ook door 'interne' afnemers (de behandelaar van de Variant 'Oprichtingsvergunning milieu-inrichting' wil advies op het aspect 'Geluid' en 'Luchtkwaliteit') worden besteld. Daarmee worden de Varianten van het product 'Advies' een halffabrikaat voor een ander 'eigen' product, de 'Omgevingsvergunning' in de Variant 'Oprichtingsvergunning milieu-inrichting'. En vormen zij dus ook een 'kostprijsverhogend' element: hoe meer adviezen nodig zijn voor de behandeling van zo'n aanvraag, hoe duurder het product wordt. In de vorige versie van 360º Overheid moesten deze 'eigen' halffabrikaten (Varianten van een ander Product) als Onderdeel worden gedefinieerd en moesten de kenmerken van die Varianten worden overgenomen in de Onderdeelkenmerken. Dat overnemen en gesynchroniseerd houden van die kenmerken gaat natuurlijk vroeg of laat mis. Bovendien is er geen relatie tussen een Onderdeel en een Zaaktype: die relatie wordt gelegd bij de Varianten van een product. 

Om dit soort halffabrikaten die in eigen huis worden geproduceerd op de juiste manier aan een samengesteld product te kunnen verbinden, is de Bijdrage-variant geïntroduceerd in deze versie van 360º Overheid. Daarmee wordt een relatie gelegd tussen de Variant die het samengesteld product levert (in dit voorbeeld: de Variant 'Oprichtingsvergunning milieu-inrichting' van het product 'Omgevingsvergunning') en een elders in de producten- en dienstencatalogus gedefinieerde Variant van een ander product (in dit voorbeeld: de Varianten van het Product 'Advies'). Met als belangrijkste voordelen dat de kenmerken van zo'n halffabrikaat maar op één plaats hoeven te worden gedefinieerd én dat de relatie naar het zaaktype (in dit voorbeeld: 'Advies verstrekken') van dat soort Bijdrage-varianten behouden blijft.

Deskundigheidsgebieden

In de vorige versie van 360º Overheid waren deskundigheidsgebieden vooral 'labels' die aan een Taak konden worden gekoppeld. Bovendien bood 360º Overheid slechts ruimte aan één 'lijst' van deskundigheidsgebieden. In deze versie van 360º Overheid zijn deskundigheidsgebieden ondergebracht in 'domeinen' (bijvoorbeeld: het domein 'VTH-kwaliteitscriteria') en 'subdomeinen' (bijvoorbeeld 'Generieke deskundigheidsgebieden' en 'Specialistische deskundigheidsgebieden accent milieu'). Daarnaast zijn de deskundigheidsgebieden 'verdiept' met zogenaamde Profielen, zodat voor specifieke activiteiten die door een organisatie worden uitgevoerd, ook een echt curriculum (met werkervaring, opleidingseisen, 'vlieguren', et cetera) kan worden beschreven:

De 'kenner' herkent in bovenstaande afbeelding ongetwijfeld de elementen uit de VTH-kwaliteitscriteria, maar deze zijn uiteraard even goed bruikbaar in andere domeinen. De KennisFabriek heeft nog niet alle deskundigheidsprofielen van de VTH-Kwaliteitscriteria ingevoerd; dat is een forse klus, maar gaat wel gebeuren. Het is bedoeling de volledige VTH-Kwaliteitscriteria vervolgens als afzonderlijk 'Content package' beschikbaar te stellen aan gebruikende organisaties. Uiteraard kunnen organisaties ook andere domeinen toevoegen of bestaande domeinen en subdomeinen wijzigingen. De KennisFabriek helpt graag bij het maken van de juiste structuur daarvoor (gebruik de Ondersteuningsverzoek-functie om daarvoor een verzoek in te dienen).

Overeenkomsten

Met de functionaliteit voor Overeenkomsten wil De KennisFabriek de mogelijkheid bieden aan gebruikende organisaties om de Dienstverleningsovereenkomsten (contracten) die zijn aangegaan met klanten / opdrachtgevers goed vast te leggen. DIt opdat ondubbelzinnig duidelijk is welke taken een specifieke klant / opdrachtgever aan de gebruikende organisatie heeft opgedragen, welke producten en diensten daarbij horen en welke afspraken er - bijvoorbeeld - zijn gemaakt over mandatering, et cetera. Omdat dit behoorlijk complexe materie is en we eerst ervaring willen opdoen met de gewijzigde producten- en dienstencatalogus, hebben we deze functionaliteit in de huidige release uitgeschakeld. 

Vertalingen en andere ondersteuning

De basis onder 360º Overheid is XWiki, een van origine Engelstalig product. XWiki biedt echter uitstekende ondersteuning voor 'vertalingen' van nagenoeg alle elementen van XWiki. De KennisFabriek heeft bijna alle elementen (vele duizenden!) van XWiki vertaald naar het Nederlands en weer 'teruggegeven' aan de XWiki-community zodat iedereen ervan kan profiteren. Sinds deze versie van 360º Overheid gebruiken wij dezelfde systematiek van vertalingen voor alle elementen die we in 360º Overheid aan gebruikers tonen. Daarmee kunnen we - althans in theorie - het 360º Overheid-platform ook relatief eenvoudig in een andere taal beschikbaar stellen (@Fumo: vertaling naar het Fries staat nog niet op de releasekalender! :-) ). Belangrijker - voor ons althans - was dat we zo geen teksten die op het scherm worden getoond, hard in de programmacode hebben opgenomen, maar in eenvoudiger te beheren vertaalbundels hebben gestopt.

Daardoor konden we ook betere gebruikersondersteuning in deze versie van 360º Overheid opnemen, zoals de tooltips die op nagenoeg alle elementen van 360º Overheid verschijnen als u er ongeveer anderhalve seconde de muispijl op laat rusten (hovering):

Waar mogelijk - bijvoorbeeld in de Zaaktypecatalogus - hebben we in deze teksten gebruik gemaakt van de teksten uit de landelijke standaarden.

Er zijn helaas altijd elementen in de XWiki-basis die wij nog niet hebben vertaald, bijvoorbeeld omdat die aan de nieuwste versie van XWiki zijn toegevoegd en wij pas na het verschijnen van zo'n nieuwe versie de vertalingen kunnen maken en aan XWiki kunnen aanbieden. Als u daarvan hinder ondervindt, kunt u ons altijd via een Ondersteuningsverzoek attenderen op ontbrekende vertalingen, dan zorgen wij dat de vertalingen worden gemaakt. Normaal gesproken zijn ze dan opgenomen in de eerstvolgende release van XWiki en/of 360º Overheid.

Wijzigingen voor beheerders

Uiteraard geldt al het bovenstaande ook voor Beheerders. Daarnaast beschikken Beheerders over onderstaande nieuwe / aangepaste functionaliteit in deze nieuwe versie van 360º Overheid.

Gewijzigde lay-out van invoerschermen

De lay-out van invoerschermen is aangepast, enerzijds om deze minder 'onrustig' te laten ogen, maar vooral om ruimte te creëren voor permanente uitleg / ondersteuning (via de teksten uit de tooltips die hierboven ook zijn genoemd) bij het invoeren van nieuwe gegevens:

Gewijzigde WYSIWYG-editor

Voor de invoer van gegevens met opmaak wordt in deze nieuwe versie van 360º Overheid gebruik gemaakt van een nieuwe WYSIWYG-editor. De 'oude' editor was technisch gedateerd en niet heel erg gebruiksvriendelijk. De ontwikkelaars van XWiki zijn nog druk doende met een nog betere integratie van de nieuwe editor, dus in volgende versies zullen ongetwijfeld nieuwe features zijn toegevoegd. Deze nieuwe editor is zo'n component die we nog niet helemaal hebben kunnen vertalen.

Let op: Een enkele keer overkomt het ons dat de nieuwe editor een 'spinning wheel' laat zien. Het opnieuw laden van de pagina lost dit probleem op.

Kopieer een zaaktype

Een zaaktype bestaat uit een heleboel elementen (een gemiddeld zaaktype bestaat al snel uit zo'n 100 objecten met bijbehorende pagina's). Het maken van een nieuw zaaktype 'vanaf scratch' is daarom ook best een klus. Daarom hebben we functionaliteit toegevoegd waarmee beheerders een bestaand zaaktype kunnen kopiëren. Dit kan zowel binnen één zaaktypecatalogus als van de ene zaaktypecatalogus naar een andere zaaktypecatalogus (alleen voor 360º Overheid-omgevingen waarin meer dan één zaaktypecatalogus wordt beheerd). Vervolgens kan het nieuwe zaaktype uiteraard worden bewerkt zoals elk ander zaaktype. In de volgende release van 360º Overheid zullen we ook de kopieerfunctie hebben uitgebreid naar het kopiëren van zaaktypen vanaf de 360º Overheid Marktplaats, zodat u ook zaaktypen kunt kopiëren die zijn gemaakt in omgevingen van andere 360º Overheid-gebruikers.

Let op: Bij het kopiëren van een zaaktype 'springt' de voortgangsbalk soms heen-en-weer (in bepaalde situaties zelfs tot 100% en dan weer terug). Dit heeft te maken met de verschillende jobs die worden gestart voor het kopiëren van een zaaktype. Helaas is het in deze release niet gelukt de progressie - van die jobs - in één consistent voortgangsoverzicht te vatten. Naar de oorzaak van dit probleem zoeken wij nog. Voor de gebruiker / beheerder: er gaat dus niets mis: zodra u de terugkoppeling van de kopieeractie op het scherm ziet verschijnen, is het zaaktype gekopieerd.

Consistentie van roltypen controleren

Omdat roltypen niet - zoals informatieobjecttypen en besluittypen - centraal binnen de zaaktypecatalogus worden bijgehouden, maar per zaaktype moeten worden benoemd, is het lastig daarbij 'over zaaktypen heen' altijd consistent te blijven. Met deze functionaliteit kunt u de roltypen van alle zaaktypen tonen en ziet u in één oogopslag (nou ja, twee misschien) waar de verschillen zitten.

Consistentie van statustypen controleren

Voor statustypen geldt hetzelfde als voor roltypen: omdat ze per zaaktype worden gedefinieerd is het lastig statussen die hetzelfde beogen, consistente namen, doorlooptijden et cetera, te geven. Met dit overzicht is die consistentie eenvoudig te controleren.

Techniek (voor de nerds onder ons)

Als u het lezen tot hier hebt volgehouden bent u een held! En als u hier bent terechtgekomen via de hyperlink bovenaan deze pagina, heeft u vast een bovengemiddelde interesse in de technologie die De KennisFabriek toepast.

Gescheiden Ontwikkel-, Test, Acceptatie en Productie-omgevingen (OTAP)

Alles wat De KennisFabriek ontwikkelt, doorloopt een Ontwikkel, Test, Acceptatie en Productie-cyclus (OTAP) in - functioneel en technisch - van elkaar gescheiden omgevingen. Hiermee zorgen we we ervoor dat wijzigingen na Ontwikkeling (in een separate omgeving) en het Testen van die ontwikkeling (in een separate omgeving) Acceptatie door de gebruikende organisatie (in een separate omgeving) kan plaatsvinden voordat de nieuwe / gewijzigde functionaliteit in een Productieomgeving wordt geïmplementeerd. 

OTAP-omgevingen op PaaS / CaaS-omgevingen in Nederlandse datacentra

Alle omgevingen van 360º Overheid worden gehost in Nederland in een Tier-3 datacenter. De Test-, Acceptatie- en Productieomgevingen zijn geïmplementeerd op een Jelastic-platform (Platform as a Service, PaaS), waardoor 360º Overheid-omgevingen zowel eenvoudig verticaal (lees: door toevoeging van meer CPU-capaciteit, meer geheugen, meer opslag) als horizontaal (lees: door toevoeging van meer nodes/servers voor één of meer componenten) kunnen worden 'geschaald'.

De KennisFabriek was één van de de aanjagers en early adopters van de mogelijkheid om  - bovenop het Jelastic Platform - servercomponenten te implementeren op basis van Docker-images. Deze functionaliteit is inmiddels toegevoegd aan het hostingplatform, waardoor alle Ontwikkel-. Test-, Acceptatie- en Productieomgevingen op basis van door De KennisFabriek gestandaardiseerde en volledig geconfigureerde, Docker-images zijn opgebouwd. Dankzij deze - aan het Jelastic-platform toegevoegde - technologie, is de volledige infrastructuur van de OTAP-omgevingen van 360º Overheid-omgevingen container-based (Container as a Service, CaaS).

Architectuur microservices

Voor het ontwikkelen, testen, accepteren en in productie nemen van 360º Overheid-omgevingen, wordt te allen tijde het hierboven beschreven OTAP-proces doorlopen. Alleen zo kunnen we garanderen dat alle waarborgen voor een goed functionerende 360º Overheid-omgeving zijn getroffen. Om die 'OTAP-straat', zoals dat in programmeurs-termen heet, consequent en reproduceerbaar te kunnen doorlopen, hebben we alle componenten die daarvoor nodig zijn gestandaardiseerd o.b.v. eerdergenoemde 'Docker-images'. Die architectuur van microservices ziet er als volgt uit: