Steeds meer bedrijven komen terug van het idee om standaardpakketten aan te schaffen en hun IT uit te besteden. Ze willen de regie weer in eigen hand nemen en innovatie realiseren door zelf software te ontwikkelen. In toenemende mate worden hiervoor Rapid Application Delivery-platformen ingezet. IT-organisaties dienen zich hierbij wel te realiseren dat dit soort platformen niet automatisch tot betere oplossingen leidt. Integendeel zelfs: als het gebruik van moderne ontwikkelplatformen er in de praktijk toe leidt dat gebruikers en opdrachtgevers doorslaan in hun ontwikkeldrift, is de ellende niet te overzien.
Aan het eind van de vorige eeuw bestonden er feitelijk twee denkrichtingen over software. De eerste ging standaard uit van standaardpakketten, die met behulp van de nodige aanpassingen geschikt werden gemaakt voor de bedrijfsprocessen die ze moesten ondersteunen. In de andere stroming was maatwerk het hoogste goed. Alle oplossingen zouden volgens de aanhangers van deze stroming uit puur maatwerk moeten bestaan. Het ontwikkelen moest hierbij niet zelf worden gedaan, maar geoutsourced aan derden.
Beide stromingen bleken bij nader inzien echter niet de way to go als het gaat om bedrijfskritische en unieke processen. Standaardpakketten en outsourcing van het ontwikkelproces blijken in dat geval net iets te vaak net niet helemaal op te leveren wat men ervan had verwacht, zowel in termen van functionaliteit, kostenbesparing als tijdswinst.
De roep om slim geschreven, eigen applicaties die wel helemaal voldoen aan de behoeften werd luider. Dit leidde er toe dat men tools ging bedenken die het ontwikkelproces versnelden en vergemakkelijkten. Deze tools, met Gen en Oracle-developer als meest bekende voorbeelden, betekenden een flink stap voorwaarts. Deze tools zijn echter inmiddels een beetje achterhaald door de tijd. Want ga maar na, toen ze op de markt kwamen, bestond er nog geen web-omgeving waarvoor applicaties moesten worden ontwikkeld. Op een bepaald moment zijn de tools natuurlijk wel aangepast om ook in een web-omgeving te kunnen ontwikkelen, maar toch blijft dat op bepaalde punten nog steeds wat wringen.
Dit in tegenstelling tot de volgende generatie tools, bestaande uit Rapid Application Delivery (RAD)-platformen zoals Mendix en OutSystems die in navolging van ontwikkelmethoden als Agile en Scrum het levenslicht zagen. Deze platformen werden juist primair opgezet met het oog op het ontwikkelen van mobiele- en webapplicaties. Daarbij zijn ze ook nog eens heel volwassen, in die zin dat ze de hele applicatie-lifecycle afdekken en dat vele van de tekortkomingen van vorige generaties tooling in de moderne ontwikkelplatformen zijn opgelost. Zo laat OutSystems zich bijvoorbeeld kenmerken door geautomatiseerd versiebeheer, ingebouwde connectors voor het eenvoudig ontsluiten van legacy-systemen en veel gebruikte SaaS-applicaties en geïntegreerde security-functionaliteiten. Samen met het feit dat de onderliggende infrastructuur tegenwoordig standaard is geworden en met HTML5 en web services een eenduidige basis heeft, maakt dat ontwikkelaars zich volledig kunnen richten op het ontwikkelproces.
Maar hierin schuilt tegelijkertijd het gevaar. Omdat het met ontwikkelplatformen zo gemakkelijk is om nog wat extra functionaliteit te ontwikkelen, ontstaat de verleiding voor zowel ontwikkelaars als opdrachtgevers om maar door te gaan. Het is een beetje de kat op het spek binden. Een extra risico is dat de ontwikkelaars zich volledig verliezen in het ontwikkelen van software, juist omdat andere zaken en randvoorwaarden als OTAP-omgevingen, koppelingen en security verregaand geautomatiseerd zijn bij moderne ontwikkelplatformen. Doordat ze niet meer over dit soort zaken hoeven na te denken, kan het zo zijn dat het denken over het grotere geheel een beetje buiten beeld raakt. En dat terwijl het architectuurdenken (binnen welk applicatielandschap gaat het te ontwikkelen systeem op welke manier functioneren) nou net cruciaal is. Ontwikkelaars die zich enkel nog richten op het snel ontwikkelen van alsmaar meer software, gaan gemakkelijker voorbij aan belangrijke architectuurprincipes. Met desastreuze gevolgen.
De uitspraak van Oscar Wilde “de enige manier om van een verleiding af te komen, is eraan toe te geven” gaat hier dan ook niet op. Softwareontwikkeling blijft, alle hulmiddelen en tooling ten spijt, nog steeds gewoon een vak. Een ontwikkelplatform waarmee automatisch software gegenereerd kan worden, leidt niet per definitie ook automatisch tot goede software. Het zijn de ontwikkelaars die met hun kennis en ervaring het verschil bepalen tussen succes en falen. Ontwikkelaars zullen dan ook als vakmensen moeten acteren en weerstand bieden aan de verleiding die ontwikkelplatformen nou eenmaal altijd in zich hebben.
Eric ten Harkel,
Verhelderend stuk Eric. Dank! Vanuit beheersperspectief (het expertisegebied van de organisatie waar ik voor werk) is het absoluut zaak dat we niet voorbij gaan aan de infra en de daarbij behorende beveiliging. In dat licht zie ik een grote toekomst weg gelegd voor een nieuwe stroming, die van DevOps. Die zal/moet er voor gaan zorgen dat beide disciplines in een zeer nauwe samenwerking ieder hun eigen expertisegebied afdekken bij de ontwikkeling van software. Ben benieuwd hoe jij daar tegenover staat…
Beste Robèr,
Prikkelende reactie. Vraagt om meer tekst dan ik hier kwijt kan. Dus een prima onderwerp voor een volgende blog. Watch this space!