De toepassing van rapid application development (rad) zal in mijn ogen de komende jaren exponentieel toenemen en ik zal in dit artikel uitleggen waarom ik deze mening ben toegedaan. Organisaties zijn digitaal aan het transformeren en om onderscheidend en innovatief te zijn en te blijven spelen web- en mobiele applicaties een belangrijke rol richting stakeholders.
In mijn laatste artikel over de impact van DevOps op de it-architectuur heb ik mijn visie gegeven over de DevOps-beweging die veel gevolgen heeft voor de inrichting van it-afdelingen, software-ontwikkeling, de architectuurfunctie en de manier van werken met elkaar. Met name de ogenschijnlijke contradictie tussen DevOps en de architectuurfunctie blijkt een interessant discussieonderwerp. In dit artikel wil ik een stapje verder gaan, vanuit de optiek dat DevOps een benadering is van softwareontwikkeling die ervoor zorgt dat de ’time to market’ van applicaties en services korter wordt en meer ‘Agile’.
Deze benadering wordt ondersteund en versneld door de opkomst van zogenaamde rapid application development-platformen. Deze platformen worden veelal ‘as a service’ aangeboden. De zogenaamde platform as a service (PaaS)-concepten schieten als paddenstoelen uit de grond en zijn een logisch gevolg van het succes van software as a service (SaaS) en mogelijkheden door data-uitwisseling formaten en architectuurstijlen zoals Json en Rest.
Platformkeuze
Platformen als Salesforce, Mendix, Oracle APEX en OutSystems groeien in populariteit en hebben een aantal gemeenschappelijke delers. Ze worden bestempeld als zogenaamde low-code platforms waarmee mobiele- en webapplicaties op een snelle en efficiënte manier worden ontwikkeld, getest, gedeployed en gemanaged en toegankelijk zijn op alle devices. Deze platformen zijn veelal beschikbaar als cloudoplossing, maar kunnen ook on-premise draaien of als hybride vorm. Andere voordelen zijn de veelal open architectuur, integratiemogelijkheden met bestaande systemen en schaalbaarheid.
Dergelijke platformen vereenvoudigen/automatiseren het ontwikkelproces en programmeren wordt een meer procesmatige en functionele bezigheid, waardoor er minder vaak een beroep gedaan hoeft te worden op schaarse (en dus dure) expertise van ontwikkelaars met specifieke kennis. Het concept van rapid application development/low code development is overigens niet nieuw, maar lijkt steeds meer voet aan de grond te krijgen binnen enterprise omgevingen. Dit heeft zeker te maken met het feit dat we steeds minder op hardware programmeren en steeds meer op services en api’s (met alle gevolgen van dien). Uiteraard worden deze ontwikkelingen gedreven door cloud (adoptie)-strategieën van bedrijven en de voortdurende vraag vanuit de business naar een grote verscheidenheid aan apps.
Impact op softwareontwikkeling
Het cyclische proces van softwareontwikkeling wordt efficiënter door een betere samenwerking tussen afdelingen, betere integratie en een hoge mate van automatisering. Rapid application development-platformen zijn uitermate geschikt om bovengenoemde doelen te verwezenlijken. Dergelijke platformen versterken de DevOps beweging en beïnvloeden de architectuurfunctie. Development wordt door de opkomst van ‘low code’-applicaties namelijk steeds minder een it aangelegenheid vanuit noodzaak.
De kloof tussen it en business wordt aanzienlijk verkleind, omdat applicatie/app ontwikkeling steeds vaker belegd zal gaan worden bij business units en heeft derhalve een positief effect op business-it-alignment. Gelijktijdig geeft deze ontwikkeling uitdagingen op het gebied van regievoering, eigenaarschap, verantwoordelijkheden en benodigde expertise binnen de organisatie.
Holistische benadering
Onderwerpen als softwareontwikkeling, DevOps en architectuur worden traditioneel vaak te veel vanuit een ‘it-bril’ benaderd waarbij de discussie snel kan ontaarden in stellingen over bijvoorbeeld te gebruiken ontwikkeltalen, frameworks, cloudoplossingen en tooling. Niet zo raar natuurlijk wanneer deze discussie binnen de it-afdeling plaatsvindt en een ieder vaak specialistische kennis heeft binnen een of meerdere domeinen. Ontwikkeltalen, frameworks, librairies, tooling en ga zo maar door, zijn echter middelen om een doel te bereiken maar zeker niet een doel op zich. De snelheid waarmee beschikbare middelen toegankelijk worden, maar ook weer verouderen heeft bovendien tot gevolg dat eigenschappen als adoptief- en lerend vermogen minimaal zo belangrijk zijn als specialistische technische kennis.
Kijk bijvoorbeeld maar eens naar nieuwe ontwikkeltalen zoals Swift of Scala die razendsnel marktaandeel veroveren ten opzichte van traditionele ontwikkeltalen. Deze wetenschap is van belang bij hr-vraagstukken, zeker binnen it, waar nu al sprake is van schaarste binnen bepaalde vakgebieden.
Professionals die zich het best weten aan te passen aan de veranderende omstandigheden zullen excelleren in organisaties en binnen it-afdelingen in het bijzonder. Deze professionals zullen zich minder focussen op diepgaande kennis van specifieke ontwikkeltalen en technologieën, maar op zoek gaan naar oplossingen die breed toepasbaar zijn en rekening houden met integratie, snelheid, flexibiliteit en gebruikersgemak. Rad-platformen zijn relatief snel te leren voor nieuwkomers in het vak, maar zeker voor it’ers die al bekend zijn met applicatieontwikkeling.
Conclusie
Het is voor it-afdelingen niet altijd makkelijk om aan de eisen vanuit de business te voldoen. Snelheid van leveren en voortdurende innovatie kan conflicteren met zaken als security, stabiliteit en gekozen (doel)architectuur. Niet kunnen ‘leveren’ heeft in de praktijk toetreding van ‘externe’ it-leveranciers tot gevolg. Onder deze druk transformeren it-afdelingen voortdurend in de verwachting dat ze zich minder richten op de controle van it en meer op de governance van it. Het speelveld verandert dus snel en het gebruik van een rapid application-platform kan een optie zijn die de moeite van het onderzoeken waard is.
Architecten zouden hier een belangrijke rol in moeten spelen, waarbij ze zich terdege bewust moeten zijn van de risico’s die gepaard gaan met bovengenoemde PaaS-concepten. Afhankelijkheid van externe services is zo’n risico. Ik durf echter wel te stellen dat rad-platformen een prominente rol zullen gaan vervullen in de software industrie, vanwege de aanzienlijk kortere development life cycle, implementatietijd, flexibiliteit en effectiviteit. In veel gevallen is er dus zeker sprakevan toegevoegde waarde door het gebruik van een rad-platform.
RAD tools bestaan al minstens sinds 1986. Elke keer lijkt het veelbelovend en toch breken ze niet echt door. Ik heb recent naar outsystems gekeken en dat ziet er inderdaad goed uit. Juist de rol van de architect zal eerder afnemen dan toenemen want als je voor outsystems kiest kies je automatisch voor een bepaalde architectuur. Nadeel van outsystems is bv de prijs (50.000 per jaar) dit betekent dat dit alleen geschikt is voor de grotere projecten want je moet dit minimaal besparen per jaar op je ontwikkelkosten. Ook na oplevering zul je dit bedrag jaarlijks op moeten brengen om het onderhoud te kunnen uitvoeren. Daarnaast is deze tool met name geschikt voor de invoerschermen. Alle transacties achter de schermen zullen toch uitgeschreven moet worden. Of je hier nu een tool voor gebruikt en het een en ander aanklikt of de code intypt zal voor de ontwikkelsnelheid niet veel uitmaken. De logica zal toch op één of andere manier tot stand moeten komen.
Belangrijk is om, voordat je de tool in gebruik neemt, ook de beperkingen te onderzoeken. Een éénmaal gemaakte keuze voor een tool is wel bepalend voor de komende tijd hoe de software er uit komt te zien. Daarnaast is het zaak om zoveel mogelijk binnen de tool te blijven en er niet te veel omheen te programmeren want dat doet uiteraard het voordeel van de tool teniet.
Ik durf geen uitspraak aan of het verstandig is om niet ICT specialisten ‘vanuit de business’ de software te laten maken. Software ontwikkeling blijft een vak net zoals alle andere vakken, ongeacht de gebruikte tools.
Hey Daan, cool artikel. Mooi beschreven hoe RAD platformen de kloof tussen business en IT kunnen verkleinen. Echter; ‘a fool with a tool is still a fool’ (no offense naar onze klanten overigens…)
Of je nou de business naar de IT brengt en citizen developers van ze maakt of de IT een nieuw speeltje geeft in de vorm van een RAD-tool, de magie zit hem voornamelijk in de samenwerking. De focus moet op buiten liggen, dat is immers waar het geld verdiend wordt.
Middels ons op maat gemaakt ontwikkelproces – agile delivery – in combinatie met de RAD platformen ontwikkelen we snel applicaties die in 1 keer goed zijn, zoals de business het bedoelde. We starten met een inception deck waarin duidelijk wordt wat we gaan bouwen, waarom en voor wie. Ook wordt vastgelegd wat we gaan doen als de sh#t de fan gaat raken. Daarna volgt de basecamp fase, de rode loper naar de realisatiesprints. Resultaat van de dit alles is een geprioriteerde backlog met user stories, een definition of ready & definition of done plus een high level design.
@Floris Begrijp jij dat een klant jou soms niet begrijpt? Want eigenlijk gooi je met termen maar wat is de samenhang met dit artikel? Het enige wat ik eruit haal is ‘a fool with a tool is still a fool’
Citizen Developer, Haha.. Die moest ik opzoeken! Mooi man! Wat is de antoniem daarvan?
Die kende je wel:
https://www.computable.nl/artikel/opinie/development/5141883/1509029/citizen-developers-staan-voor-de-deur.html
Maar je was het weer vergeten.
Je bent immers een technicus.
@Corne: als je een architect minder nodig hebt, heb je die €50000 al snel terugverdiend toch? 🙂