Drupal verkeerde keus voor overheidssites (opinie)

Misschien moet je gewoon niet één omgeving willen hebben die alles doet. Je kan prima verschillende web applicaties bouwen in andere omgevingen, die specifiek passen bij die applicatie. Je kan zelfs bestaande cloud diensten integreren in je aanbod.

Juist dat monolitisch denken is wat zorgt voor veel IT problemen bij de overheid en andere grote organisaties. Probeer functies te scheiden en denk goed na over de interfaces tussen de verschillende functies. Daarmee bouw je een veel beheersbaarder geheel.

Drupal-ontwikkelaar Bèr Kessels waarschuwt echter dat Drupal bij zulke grote overheidswebsites niet op zijn plek is. Het is namelijk een CMS.

Maar waarom noemt Drupal het dan zelf een mix tussen CMS en CMF?



Thus, it can be described both as a content management system (CMS) and a content management framework (CMF) - one system which strives to have the strengths of both, without their deficiencies.

FLOW3 ?

Het probleem wat Ber hier beschrijft, zegt meer over de gemiddelde incompentetie van een gemiddelde drupal ontwikkelaar dan over drupal zelf.

De meeste drupal ontwikkelaars die ik tegenkom blijven 'inside the box' denken, en denken dat je alles met community modules als views,context,panels etc etc. moet oplossen want anders is het geen drupal meer.

Wat dat betreft ben ik het 100% met TheReactor eens, monolitisch denken is de nekslag voor elk project drupal, wordpress of een framework.

Je moet gewoon de tools gebruiken die het beste aansluiten bij je probleem. Niet van de oplossing je probleem maken, door stug vast te houden dat alles met drupal moet.

Als je even verder kijkt, Drupal is gewoon PHP met 9 van de 10 keer MySQL, niet een of ander magische gesloten doos waar je niks mee kunt buiten om drupal.

Dus als je voor een randapplicatie iets met Zendframework, Symfonie of wat dan ook wilt maken is er niemand die je dat verbiedt, en als je dat later wilt koppelen met je drupal frontend, implenteer je een paar hooks, maak je desnoods paar eigen theme functies en je bent onderweg. Je hoeft niet perse data op te halen met views, of context te gebruiken of iets een node te maken. (en zelfs als je dat wel zou willen, is het ook goed te doen!)

Maar goed ik verwacht hier toch wel een hoop drupal=
=eng/evil/slecht/k*t reacties, en dan vooral vanuit de php community zelf. Want het is niet sjiek om te zeggen dat je drupal gebruikt en enger nog, zelfs leuk vind om te doen. als je jezelf serieus php ontwikkelaar wilt noemen.

Grappig dat de schrijver over het hoofd ziet dat 1 van de belangrijkste en meest aangevallen sites op het Internet op basis van drupal werkt: www.whitehouse.gov. Misschien iets beter orienteren? Of is wel de juiste drupal 'expert' aan het woord geweest?

Op het nationalistische front kun je natuurlijk ook refereren aan het feit dat Drupal een nederlands product is. Goed voor de kenniseconomie. En alles is beter dan Tridion natuurlijk.

Waar zou overigens Hippo zijn gebleven in dit hele verhaal?

Drupal niet geschikt? kijk even naar http://www.whitehouse.gov/
of naar http://www.economist.com/, of het hele intranet van de ziekenhuizen in de Orlando regio in Florida (USA) is Drupal, Drupal heeft ech meer in haar mars dan hier wordt gesuggereerd

Eerlijk gezegd zou ik ook geen Drupal gebruiken. Het is te omslachtig, te uitgebreid en daardoor niet overzichtelijk genoeg meer. Ik zweer bij maatwerk, omdat je op die manier een applicatie krijgt die recht-toe-recht-aan is.

Ik begrijp toch al niet waarom veel programmeurs de zaken ingewikkelder maken dan ze zijn. Je ontwikkelt een programma om een oplossing voor een specifiek probleem te bieden. Iedereen hodut van simpel en dat is al punt één waar Drupal niet aan voldoet.

Begrijp me niet verkeerd. Het is een prachtig systeem voor de programmeernono, die een website voor z'n voetbalvereniging op wil zetten. Als professioneel ontwikkelaar kun je beter zelf een CMS bouwen op basis van een zelf ontwikkeld of bestaand framework. Dan weet je tenminste EXACT waar je aan toe bent (en dat is toch wel een must, 'het werkt dus het is goed' is wat mij betreft niet goed genoeg).

Daarnaast brengt het zijdelings ontwikkelen van modules voor grote CMS'en (zoals bijvoorbeeld Drupal) ook andere problemen met zich mee. Ontwikkelaars hebben vaak geen tijd en/of zin om de complete documentatie van A tot Z uit hun hoofd te leren, dus die proberen gewoon wat. Met alle veiligheidsrisico's van dien.

Nu kunnen we gaan roepen dat dit aan de programmeurs ligt, maar je kan ook gewoon een baas hebben die in je nek zit te hijgen. (Been there, done that... was zelf ook niet trots op m'n halffabrikaten, vandaar dat ik voor mezelf begonnen ben.)

Eigen software lost dat probleem niet geheel op, maar wel voor een groot deel.

De ideale wereld bestaat niet, ideale software wel. En die zal je dan toch echt zelf moeten maken.

Het is sowieso niet logisch om een producttechnolgie vooraf vast te leggen.
Daarmee verminder je de concurrentie bij de aanbesteding omdat andere aanbieders die zich in een ander CMS hebben gespecialiseerd nu geen concurrerende aanbieding zullen doen.

Ik vind dat je niet kan zeggen dat de 2e kamer een verkeerde keuze maakt met Drupal als je niet de specificatie en afwegingen weet die tot die keuze heeft geleid. Als de specificatie goed doordacht is (functionaliteit,performance,uitbreidbaarheid etc) en de leverancier het eindproduct voor een goede prijs kan leveren dan zal het de afnemer een worst zijn of dit met Drupal ROR of bash gemaakt is. Idee voor een WOB-je ww?

Als iemand die persoonlijk is betrokken geweest bij de ontwikkeling van tientalle grote overheidswebsites (incl. WhiteHouse.gov en vele andere grote overheidswebsites in de VS), ben ik het niet eens met de conclusie van dit artikel. Drupal is steeds een prima tool gebleken voor de ontwikkeling van die sites, en heeft die organisaties toegelaten om meer te doen met minder geld en tijd. Drupal is een prima keuze voor veel complexe overheidswebsites. Dat wil niet zeggen dat elke overheidswebsite het best in Drupal gebouwd wordt.

De time-to-market van een Drupal site is meestal sneller dan die van traditionele commerciele oplossingen, en meestal sneller dan die van pure frameworks. Het weghalen van bepaalde functionaliteit is niet echt moeilijk. De innovatie en pre-build modules die je van Drupal krijgt, maken die tijd meestal ruimschoots goed.

In elk geval, ik vind het artikel niet echt gebalanceerd en een beetje kortzinnig, en de argumenten niet echt relevant voor de overheidssector.

De markt bewijst dat Drupal een goede keuze is. Wij zien meer en meer Drupal in de Amerikaanse overheid omdat iedereen wild-enthousiast is met de resultaten. Er zijn al honderden Drupal websites in the Amerikaanse overheid, en minstens een paar honderd in aanbouw.

--
Dries Buytaert
Founder and project lead Drupal
Chief technology officer Acquia

@Bèr Kessels: dank je wel voor een 'strak' artikel. Je punt is duidelijk. Vermijdt 'kant en klaar' als je noden slecht aansluiten bij 'kant en klaar'.

Wat mij bezighoudt is het volgende. Wat jij zegt, toegespitst op Drupal, geldt eigenlijk in z'n algemeenheid. Overigens bij CS software nooit aan de orde bij grote (overheids-)organisaties. Mensen weten dat ze het hebben te doen met de functionaliteit zoals geleverd en vindt het normaal de wereld aan Extract, Transform and Load interfaces te moeten schrijven om wel gedaan te krijgen wat nodig is. In mijn ogen gaat je punt alleen op bij OS waarbij je als aspirant gebruikers(organisatie) wel moet nadenken over hoe wil ik eventueel de zaak verbouwen.

Ik denk dat je als organisatie die geen software schrijft, onderhoudt of wat dies meer zij, altijd andere interesses hebt dan je software aanpassen. Je belang is om software te vinden die doet wat je nodig hebt om 'je ding' te doen. Daar ambtenaren sterk de neiging hebben om software zeer specifieke eisen op te leggen en dat ook geïmplementeerd te willen krijgen, kosten veel overheids ICT-trajecten regelmatig meer geld dan nodig is, mijn inziens.

Mijn punt hiermee is: vaak is al het maatwerk dat binnen gemeentelijke, provinciale en rijksoverheid wordt gerealiseerd geen werkelijke toevoeging. In die zin denk ik dat een bijzonder flexibel pakket als Drupal 'out of the box' eigenlijk heel vaak wel voldoende is. Blijft over de situatie waarbij het echt nodig is.

Blijf ik je punt: "Ga geen dingen ongedaan maken om je zin te krijgen binnen bestaande, maar dan verbouwde, kaders." sterk vinden. Ik vertaal dat naar: "Beslis sneller om nieuw te bouwen in plaats van toch proberen een succesvolle verbouwing te doen." Vanaf hier zou ik een splitsing willen voorstellen dan wel me kunnen voorstellen.

Wat nou als zich, bijvoorbeeld binnen Drupal, een uitbreiding van het CMF, het framework, zou bevinden die door, ik noem ze, powerusers kan worden gebruikt om Drupal wel om te vormen. Deze powerusers, of consultants, kunnen Drupal wel als basis gebruiken zonder dat ze bij de 'out of the box' functionaliteit hoeven te blijven en evenmin bestaande functionaliteit ongedaan aan het maken zijn of daar om heen aan het werken.

Het voordeel is: Drupal blijft gebruikt en alles wat oké is en zonder meer te gebruiken, neem je mee. Het voorkomt dat je vanuit je 'echte' framework zoals Ruby, Django, enzovoort eerst weer naar je bestaande functionaliteit toe moet werken en dan verder kan gaan. Ander voordeel is: je kunt op een hoger niveau blijven waar het gaat om wijzigen van je software functionaliteit. Nog een voordeel is: 'out of the box' baseer je gewoon op standaard keuze van het CMF.

Mocht het nu zo zijn dat Drupal hier heel makkelijk voor is aan te passen dan is een overheidsproject het ideale project om dat te doen. Het is namelijk gemeenschapsgeld. Wat dan eenmalig uitgegeven wordt om het iets meer open CMF te ontwikkelen en daarna Drupal nog eenvoudiger voor een bredere set van eisen beschikbaar maakt. De gemaakte kosten worden in een mum van tijd bij overige overheidsprojecten bespaard. Helemaal wanneer wij als (Nederlandse) gemeentelijke, provinciale en rijksoverheid het lef zouden hebben om alleen nog maar Drupal (in deze aangepaste vorm) te gebruiken.

Kortom: een stap tussen Drupal 'out of the box' en Ruby, Django, enzovoort inbouwen.

In het geval van de Tweede Kamer zal Drupal ingezet worden voor vijf websites van de Tweede Kamer die relatief standaard van opzet zijn (nieuws, agenda, achtergrondpagina's, dossiers, zoals de meeste websites hebben, zie de aanbesteding). Daar is Drupal uitermate geschikt voor zoals vele overheidssites reeds bewezen hebben. Doordat er gebruik wordt gemaakt van dit cms met een grote community is het bovendien mogelijk de websites met weinig kosten uit te breiden met extra functionaliteit door extra modules in te schakelen. Ook kunnen specifieke modules om bijvoorbeeld kamerstukken te tonen weer ter beschikking worden gesteld voor andere (overheids-)organisaties en bedrijven.

Door niet een eigen maatwerk cms te laten bouwen wordt voorkomen dat de websites in de toekomst moeilijker door andere leveranciers te wijzigen zijn en wordt zo een feitelijke vendor lock-in voorkomen. Drupal heeft in tegenstelling tot een eigen op maat gemaakt cms ook als voordeel dat er security-updates uitkomen, en dat er veel aan toegankelijkheid wordt gedaan.

Er is geen sprake van dat Drupal wordt gebruikt voor het beheer van parlementaire stukken, documenten, vergaderingen of andere software dat speciaal voor de Tweede Kamer ontwikkeld is. Onder meer wordt Microsoft Sharepoint gebruikt voor het Parlis informatiesysteem.

De parlementaire stukken zullen ontsloten worden via SDU op www.overheid.nl met volgens mij een eigen op maat gemaakt framework.
Drupal biedt momenteel inderdaad het nadeel dat het zich (momenteel) nog niet zo goed leent voor complexe ontwikkelomgevingen vanwege beperkingen op het gebied van onder meer OTAP, maar doordat het nu erg populair is bij grote enterprises lijkt een oplossing een kwestie van tijd.

Op maat maken van systemen bij de overheid lijkt me voor grote projecten (EPD, belastingdienst, rekeningrijden, stemcomputers, OV-chipkaart etc) te verkiezen boven het inzetten van standaard cms-en, maar dat lijkt me evident.

Wel zou ik er voor willen pleiten dat deze projecten gebruik maken van open source en open standaarden en ook de ontwikkelde code weer grotendeels online beschikbaar stellen. Op die manier ontstaat externe review van de code wat de kwaliteit van de overheidsprojecten ten goede kan komen.

De technische aspecten, waaronder migratie binnen je OTAP zorgen zeer zeker voor hoofdpijn (hoewel wij hierin al een groot deel hebben geautomatiseerd, net als andere Drupal bouwers).

De randaspecten die horen bij grotere project voor de overheid zijn echter een wezenlijk aspect van de "vier nullen" in de begroting. Soms zelfs de helft. Ik heb het over het proper managen van een project en het managen van de verwachtingen. Dit zijn zaken waar in de overheidsprojecten die wij hebben gedaan, zwaar op ingezet wordt. En die kosten tellen ook mee. Hierbij speelt een functioneel ontwerp een belangrijke rol. Te vaak heb ik gezien dat specificaties op een "bierviltje" keihard terugkomen bij ons als ontwikkelaar: "Ik mag toch aannemen dat ik een export kan draaien van de aankopen [met allerlei randvoorwaarden] of "Jullie zijn de expert. Er staat niet dat je het niet bouwt". Dan moet je wel een PM hebben die door het gehele traject heen op de verwachtingen stuurt. Volgens mij staat dit los van de technologie.

Visueel hebben klanten ook veel eisen. Terecht, als je ziet wat er allemaal op het web te vinden is. De theming engine van Drupal leent zich voor uiteenlopende dingen. Maar ik zie ook wel eens ontwerpen voorbij komen die de ontwerpburo's van onze opdrachtgevers hebben gemaakt en die je eerst goed tegen de functionaliteiten en de bestaande componenten moet aanhouden en moet inschalen op basis van een begroting. Nu ligt mijn focus ook primair op Drupal, maar ik kan mij niet voorstellen dat dit ook niet geldt voor andere platformen/CMF's.

Voor http://www.begrijpelijkeformulieren.nl is de helft begroot op de realisatie. De rest is alles eromheen. Dit zie ik bij veel grotere projecten.

Het type klant speelt ook nog een rol. In mijn beleving zijn het juist de overheden die eerder geneigd zijn 'volgens de spelregels' te spelen en te begrijpen wat er kan worden verwacht (mits juist gemanaged) en de kleinere projecten die kostbaar worden doordat deze opdrachtgevers verwachtingen hebben die horen bij 'enterprise trajecten', maar zelf low key budgetten hebben. En al die opvolging wordt dan wel verwacht van de web ontwikkelaar.

Dank voor je reactie Bèr. Let wel, "is ongeldig" geldt wellicht op basis van jouw ervaring. Er zijn ook andere ervaringen. Dit even voor de oriënterende lezer die dat was "is" voor gospel aanneemt.

Bij het project voor BZK is de helft besteed (niet opgegaan; Dat suggereert verspilling) aan beheersaspecten. Omdat zij dit wilden. Daarmee zijn de verwachtingen bijna volledig gestuurd. Of dit *nodig* is kun je over twisten.

Wij houden in elk geval in ons ontwerpproces al rekening met de technologie, ondanks dat men op school (RAD) leert dat je los van technologie ontwerpt. Als wireframes van tafel worden geveegd "omdat het niet handig is in de technologie die *naderhand* wordt gekozen, zeg ik: Mee eens, niet slim. Er zijn wellicht argumenten die zeggen: Je moet met elke bouwtekening naar een aannemer kunnen. Ik durf te wedden dat niet iedere aannemer de klus van het nieuwe Feijenoordstadion zal aannemen, simpel omdat zij dat niet aankunnen. Belangrijker nog, de architect heeft al overleg met de aannemer.


Ben het met je eens: Het juiste gereedschap kiezen is belangrijk.

Als programmeur denk ik niet dat als je een dergelijke site wilt opzetten dat je moet uitgaan van een CMS dat na installatie een weblog biedt.
Overigens vind ik het nadeel van zowel frameworks als CMS-en dat de url's via een .htaccess bestandje worden vastgelegd en als je in je ontwikkeling een vooraf vastgelegde subdomein- of directory structuur moet hebben, je tot over je oren in de stront zit.
Drupal heeft als bijkomend groot nadeel dat de opeenvolgende versies principieel niet compatible zijn - voor developpers een goudmijn maar voor klanten een nachtmerrietje.
Daarnaast zit ik me als developper constant helemaal groen en geel te ergeren als een klant net iets anders wil dan de standaard modules bieden; waar ik in een maatwerk CMS in tien minuten klaar ben moet ik in Drupal allerhande functies gaan zitten uitpluizen om die vervolgens te gaan overschrijven.
Het is ongetwijfeld een kwestie van ervaring, maar het gaat zo tegen m'n eigen ontwikkelintuïtie [lean & mean] in dat ik het helemaal overboord heb gegooid.
Ik heb een site van een stichting gerund waar 20000 bezoekers per dag kwamen en die op een Pentium 400 liep. Toen er subsites met Wordpress en Drupal bijkwamen ["Je kan er heel veel mee, hoor"] kwam er een grotere bak maar liep de boel toch steeds vast [13 queries voor een voorpagina van een weblog?] en toen er een extra serverruimte werd bijgehuurd t.w.v. mijn maandsalaris en er een loadbalancer bij kwam waren de sessions [Zijn die echt nodig voor elke bezoeker? Moeten die echt in een tmp-filesystem worden geschreven?] zoek.

Inderdaad: er kan heel veel mee. Maar tegen welke prijs?

Voor overheden geldt nog een extra drempel: de webrichtlijnen.
Hoewel het idee & de filosofie van de webrichtlijnen bijzonder goed zijn, zijn een groot deel van de regels beperkend in de keuze.
Drupal past kennelijk goed in de richtlijnen.
(www.webrichtlijnen.nl draait overigens zelf ook op Drupal)

Dit artikel slaat volgens mij de spijker op de kop. Ik ben blij verrast dat ook Drupal hierop reageert. Ik zou graag willen weten in welke orde van grootte we moeten denken bij succesverhalen van Drupal. Hoeveel afbeeldingen in de databank bijvoorbeeld.
Werkt de afbeeldingengalerij ook nog soepel als je er 1.000.000 afbeeldingen in zet? Hoeveel downloadables zijn te managen? 10 pdfs werkt prima. Maar 10.000? En kun je dan die 10.000 nog terugvinden? Weggooien als het weggegooid moet? Versiebeheer erop nahouden? Exports van de inhoud en de metadata?
Frameworks zijn uiteindelijk ook niet de oplossing als elk bedrijf op eigen houtje een framework moet bedenken. Je vraagt wel van de developers om de tekstverwerker steeds opnieuw uit te vinden.

Verder: kritiek tegen drupal voor overheden staat los van open source. als alles open source was, was dit type probleem niet ontstaan.
Dan was de broncode van MS Word open voor ontwikkeling in framework toepassingen.
Dan deelden uitgevers hun frameworks met alle liefde aan cms developers. Dan deelden tijdschriften hun databases voor de gemeenschappelijke wereldvrede en de erkenning van facebook als zin van het bestaan.
Zolang als dat open source een randverschijnsel blijft, wordt het alleen kleinschalig ontwikkeld, zodat het een randverschijnsel blijft, zodat het kleinschalig wordt ontwikkeld, ad inf.