LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software. Versie 1

Transcriptie

1 LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software Versie 1

2 2 Gelijkegeschiktheid

3 Inhoud 1 Inleiding Doelstelling 4 2 Toetsing gelijke geschiktheid Total Cost of Ownership Functionele en niet functionele requirements Software maturity modellen Open source licenties 6 3 OSS verankering binnen Dictu Leveranciers, contracten en SLA Kwaliteitsborging OSS en sourcing OSS en kennisontwikkeling 7 4 Bijlage 1 Kwaliteitsaspecten Quint Bijlage 2 Open Source Maturity Model 8 6 Bijlage 3 OSS Kosten Model 8 blz Documenten DYA DYA : Stap voor stap naar professionele enterprise-architectuur, Berg, M. van den et al, Rijswijk, OSI Open Source Implementatie strategie, Winia, F. & M. van Nunen, Den Haag, POR Praktisch ontwikkelraamwerk, Wijnstok, M. et al, Den Haag, NOIV Nederland Open in Verbinding Een actieplan voor het gebruik van Open Standaarden en Open Source Software bij de (semi-) publieke sector, Ministerie van EZ, Den Haag, VOS Het verwerven van Open Source, Pianoo et al., S., Den Haag, Gelijkegeschiktheid 3

4 1. Inleiding In de open source implementatie strategienota voor LNV [OSI] wordt uitgewerkt hoe open source software wordt ingebed in de organisatie (bedrijfsvoering) van het ministerie van LNV. Voor een nadere uitwerking van de strategie zijn er operationele beleidskaders nodig. Deze operationalisering wordt gedaan in de actielijnen. De volgende actielijnen zijn benoemd: 1. Gelijke geschiktheid 2. Internetservice als verandermoment 3. Plaatsbepaling van OSS binnen POR 4. Herijkt beleid t.a.v. Vendor Lock-in 5. Strategiedocument voor infrastructuur 6. Communitybeleid 7. Criteria voor verantwoord teruggeven In dit document wordt actielijn 1 uitgewerkt Samenvattend is dit document een uitwerking van onderstaande stelling: - voor LNV het begrip gelijke geschiktheid concreet en toepasbaar uitgewerkt en in de inkoopprocedure verankerd, en - is de APM toets uitgebreid met Open Source Software van gelijke geschiktheid ten opzichte van bij LNV in gebruik zijnde software. Het resultaat is dat vaststaat welke bij LNV aanwezige software door OSS van gelijke geschiktheid vervangbaar is en hoe de toetsing geïmplementeerd wordt. 1.1 Doelstelling LNV conformeert zich aan het actieplan Nederland Open in Verbinding, dit geldt als uitgangspunt voor de LNV implementatiestrategie. Waar een keuze voor software gemaakt moet worden, wordt OSS meegewogen en bij gelijke geschiktheid bevoordeeld binnen LNV. Daarbij is LNV géén softwareleverancier, maar wanneer door (of in opdracht van) LNV software ontwikkeld is die, vooral binnen de overheid, breder gebruikt kan worden, dan overweegt LNV deze beschikbaar te stellen in lijn met de European Union Public Licence (EUPL). Onderstaand de concrete haalbare strategische doelen die bevordering van het gebruik van open source software integreren in LNV. In alle business cases wordt de afweging tussen open en gesloten source gemaakt volgens een binnen LNV vastgestelde uitwerking van gelijke geschiktheid. Open Source is verankerd in het inkoop-, software- en beheerbeleid. De maatwerktoepassingen met toekomst, zijn - voor zover mogelijk en zinvol - beschikbaar gesteld op basis van Open Source licentie. Het beleid ten aanzien van de vendor-lock-in voor de LNV essentiële closed software binnen LNV is herijkt en verankerd in de applicatieportfolio. De architectuur richtlijnen zoals opgesteld worden waar mogelijk getoetst in een pilot-, ontwikkel- of implementatietraject. 4 Gelijkegeschiktheid

5 2. Toetsing gelijke geschiktheid Gelijke geschiktheid is een aspect van software waarover veel discussie gevoerd wordt (zowel binnen als buiten LNV). De discussie omtrent het toepassen van OSS ontstaat doordat er nog geen beleid geformuleerd is waarin de term gelijke geschiktheid uitgewerkt is. Zie hieronder een tekst afkomstig uit een document van het voormalige ministerie van Economische zaken [NOIV] Het Kabinet wil dat bij aanbestedingen en inkooptrajecten van software voor nieuw- of verbouw en contractverlenging de aanbieders van open source software daadwerkelijk in de praktijk dezelfde kansen krijgen en bij gelijke geschiktheid voorlopig ook de voorkeur ter bevordering van de markt voor open source software in Nederland. Een document over aanbestedingen opgesteld door het NOIV voegt daar het volgende aan toe [VOS] Open source software geniet bij gelijke geschiktheid de voorkeur. Software is gelijk geschikt wanneer het dezelfde prijs heeft in het geval dat gekozen wordt voor de laagste prijs, of bij een gelijke uitslag in het geval dat gekozen wordt voor de economisch meest voordelige aanbieding. Beide stellingen bieden echter mogelijkheden voor zowel voor- als tegenstanders van Open Source Software. Twee (of meer softwareproducten) zullen nooit geheel gelijk geschikt zijn. Er zijn altijd verschillen te noemen welke gebruikt kunnen worden als argument om wel of niet voor een Open Source oplossing te kiezen. In dit document zullen we dan ook pogen om op basis van een aantal toetsen te formuleren wanneer een (open source) toepassing geïmplementeerd kan worden binnen het ministerie van LNV. De richtlijnen welke in dit document geformuleerd worden zijn daarom niet alleen gericht op Open Source Software maar ook op gesloten software. Bijvoorbeeld een software oplossing die ontwikkeld en beheerd wordt door één persoon zal binnen LNV niet toegepast kunnen worden, onafhankelijk van het feit of het gesloten of open software is. De beschrijvingen in onderstaande paragrafen kunnen gebruikt worden als toetsingsrichtlijnen voor selectie van softwareproducten. Hierbij kunnen de onderstaande toetsen toegepast worden om tot een gewogen keuze te komen. 2.1 Total Cost of Ownership Een belangrijk criterium om een bepaalde oplossingsrichting te kiezen is de waardering van aspecten als beschikbaarheid, performance etc zoals uitgewerkt in het Quint 2 model. Anderzijds zijn de kosten van implementatie van de oplossing een belangrijk criterium. Echter de kosten van een applicatie c.q. informatiesysteem zijn niet altijd nauwkeurig te bepalen. Dit geldt met name bij gedistribueerde en/of webbased toepassingen. Deels is dit te ondervangen door bij het vergelijken van oplossingen dezelfde kengetallen te gebruiken voor de verschillende oplossingen. In bijlage 3 is een voorbeeld opgenomen van een rekenmodel voor de Total Cost of Ownership. Gelijkegeschiktheid 5

6 2.2 Functionele en niet functionele requirements Software onderscheidt zich grotendeels door functionele en niet functionele kwaliteitsaspecten. Functionele aspecten zijn veelal zichtbaar, het geeft aan wat het software systeem doet. Zo zijn Open Office Writer en Microsoft Word software systemen welke functionaliteiten bieden om documenten op te stellen. Daarnaast zijn er non functionele kwaliteitsaspecten welke veelal minder zichtbaar zijn, maar niet minder belangrijk. Zo is bijvoorbeeld performance een non functional, echter als het 10 minuten duurt om een brief te open in Microsoft Word en in Open Office Writer 10 seconden, dan voldoet Writer beter aan de kwaliteitseis performance. Op deze wijze is het mogelijk om verschillende software systemen op basis van deze requirements met elkaar te vergelijken. Het quint 2 model is een raamwerk dat een trapsgewijze indeling biedt van relevante kwaliteiteisen. In bijlage 1 is een beschrijving van het raamwerk opgenomen. Deze bijlage kan als volgt gebruikt worden: 1. Selecteer in het raamwerk welke kwaliteitseisen voor het actuele project relevant zijn (kwantificeer waar gewenst de kwaliteitseisen) 2. Stel wegingsfactoren vast voor de geselecteerde (voor dit project relevante) kwaliteitseisen. 3. Beoordeel de geselecteerde (open en gesloten) software systemen en geef bij ieder product een score van 0 (voldoet niet) tot 5 (voldoet zeer goed) van het software systeem voor elke geselecteerde kwaliteitseis. 4. Bereken de totaalscore van de verschillende pakketten op basis van (som van) de score per item vermenigvuldigd met de wegingsfactor. 2.3 Software volwassenheidsmodellen Naast het vergelijken van software systemen op basis van kwaliteitseisen is het mogelijk om met name Open Source producten te scoren op basis van software maturity. Hierbij wordt gekeken naar extra eisen die aan software te stellen zijn, met name op het terrein van service, training, documentatie en support. In bijlage 2 is een uitwerking van een OSMM methode uitgewerkt, waarbij een software systeem een score krijgt op basis van een aantal eenvoudige vragen omtrent OSMM aspecten. De methode omvat een berekening en een indeling waarbij de scores binnen een aantal ranges gedefinieerd zijn. Op basis van de uitkomst kan bepaald worden of de geselecteerde oplossingsrichting bruikbaar is binnen LNV. Deze toets dient uitgevoerd te worden voor alle alternatieven die getoetst worden (dus ook de gesloten software). 2.4 Open source licenties Open Source Software kent een andere licentiestructuur dan gesloten software. Daarbij is het aantal soorten licenties dat aanwezig is zeer divers. Op de website is een overzicht te vinden met beschrijvingen van soorten licenties Bij intern gebruik van open source zonder het doen van aanpassingen geldt de vuistregel dat dit binnen de licentievoorwaarden toegestaan is. Het doen van aanpassingen in interne implementaties is veelal ook geen probleem bij het toepassen van software onder Open Source licenties. Echter bij het teruggeven van uitbreidingen en aanpassingen aan de community gelden wel een aantal regels. Met name welke licentie gebruikt mag worden is dan aan voorwaarden gebonden. Dat is ook logisch: het zou kunnen betekenen dat men door het teruggeven van software aan de community een licentie kan toepassen die meer beperkingen heeft dan de software die als uitgangspunt heeft gediend. Op de website van NOIV is hiertoe een licentiewijzer opgenomen. Bij een project waarbij de software teruggeven wordt kan men hiertoe kijken welke licentie men kan verbinden aan de op te leveren producten ( De toetsing is uitgewerkt in een webapplicatie die te vinden is via onderstaande link: 6 Gelijkegeschiktheid

7 3. OSS verankering binnen Dictu 3.1 Leveranciers, contracten en SLA Hierin ligt momenteel een knelpunt omdat de contractenstructuur momenteel grotendeels gericht is op licenties en leveranciers die licenties verstrekken op hun software, daarnaast zijn de contracten gericht op bestaande applicaties binnen al bestaande technologie en leveranciersverbanden. Daarnaast is een overzicht van de licenties welke in gebruik zijn binnen LNV nog in ontwikkeling. Hierdoor is nog niet duidelijk welke licenties in gebruik zijn. Dit vergroot het risico dat ten onrechte software licenties worden gebruikt c.q. aangeschaft. Echter vanuit DICTU Contractmanagement worden leveranciers bij nieuwe aanbestedingen reeds geattendeerd op het landelijke OSS beleid en wordt gevraagd om in de aanbiedingen rekening te houden met dit OSS beleid. 3.2 Kwaliteitsborging Introductie van OSS zal op het beoordelen van ontwerpdocumenten en het uitvoeren van tests op het uiteindelijke product geen invloed hebben. Wel veranderen wellicht de kaders waarop getoetst wordt bij de introductie van OSS als implementatierichting of (ontwikkel)omgeving. Tevens is een rol te voorzien voor kwaliteitsborging bij de review van de toetsen (functionals/maturity) uitgevoerd bij een pakketselectie op basis van zowel marktonderzoek als bij een aanbesteding. Een nadere uitwerking van deze rol is gewenst bij implementatie van de bijgestelde APM toets. 3.3 OSS en sourcing Binnen DICTU wordt momenteel gewerkt aan een sourcing strategie. De combinatie OSS en sourcing valt onder het gelijke geschiktheidsprincipe zoals beschreven in dit document. Daarnaast spelen de volgende aspecten een rol hierin Andere rol van Dictu (regie i.p.v. beheer); Eisen en beperkingen van leveranciers op ingebruikname (OSS) oplossing Beheerbaarheid en continuïteit bij sourcing. 3.4 OSS en kennisontwikkeling Kennis over technieken binnen OSS en OSS producten is op dit moment zeer beperkt aanwezig bij DICTU, Daarnaast heeft OSS een eigen organisatiestructuur met communities en samenwerkingsverbanden die alleen virtueel bestaan, verder is ook leiderschap en visievorming omtrent product en strategie anders dan bij gesloten software. Als laatste is de kennis omtrent de markt van OSS producten een punt. Deze kennis zal met name binnen de afdeling A&S en eventueel de dienstarchitecten ontwikkeld moeten worden om binnen een selectie traject een keuze te kunnen maken, of bij een aanbesteding te kunnen toetsen of het OSS product past binnen de functionele vraag. Omtrent de bovengenoemde aspecten van kennis op het vlak van OSS zal binnen Dictu beleid geformuleerd moeten worden bij welke functionaris (welke afdelingen) OSS kennis aanwezig dient te zijn voor het kunnen uitvoeren van dit OSS beleid. Gelijkegeschiktheid 7

8 4. Bijlage 1 Kwaliteitsaspecten Quint 2 (zie document OSS Quint2.doc en 5. Bijlage 2 Open Source Maturity Model (Zie document OSS Maturity Model.doc en 6. Bijlage 3 OSS Kosten Model (Zie document OSS kostenmodel en 8 Gelijkegeschiktheid

9 Deze brochure is een uitgave van: Ministerie van Economische Zaken, Landbouw en Innovatie Prins Clauslaan 8 Postbus EK Den Haag Rijksoverheid juli 2011