Het is iets wat ik vrijwel dagelijks te horen krijg tijdens gesprekken met klanten: als de backlog van te ontwikkelen applicaties groeit, neemt de druk bij de it-organisatie om op te leveren met de dag toe. Managers en executives willen liever gisteren dan vandaag kunnen beschikken over nieuwe mobiele applicaties. En dat terwijl de it-organisatie al alle zeilen bij moet zetten om de reguliere beheer- en onderhoudstaken naar behoren uit te voeren.
Omdat de druk op it-organisaties van alle kanten toeneemt, zijn die naarstig op zoek naar manieren waarop ze de ontwikkeltijd terug kunnen dringen. Helaas is het zo dat dit streven vaak slechts tot een verschuiving van de problemen leidt.
Op het eerste gezicht lijkt het ontwikkelteam de remmende factor in de oplevering van applicaties te zijn. De weken vliegen voorbij, weken waarin de wachtrij van op te leveren applicaties maar blijft groeien en de business zich steeds vaker hardop afvraagt waar de door hen bestelde applicaties blijven. Het handmatig coderen van een mobiele applicatie voor één platform of besturingssysteem kost al snel weken en sommige gevallen zelfs maanden. En dan heb ik het nog niet eens over een applicatie die voor meerdere platformen wordt ontwikkeld. It-organisaties proberen dit probleem op te lossen door het proces van coderen te automatiseren met rapid application development (rad)-tools. En dit helpt, maar alleen tot een bepaalde hoogte.
DevOps-tools
Rad-tools stellen ontwikkelteams in staat om sneller applicaties te bouwen, waardoor ze sneller een volgend project kunnen oppakken. De ontwikkelde apps zijn echter niet automatisch geschikt om uit te leveren aan opdrachtgever en eindgebruikers. Ze moeten bijvoorbeeld nog worden getest en ingepast in het bestaande systeemlandschap van een organisatie. En dat zijn processen die niet geautomatiseerd zijn in een rad-tool. De DevOps-tools die in de markt voorhanden zijn voor de implementatie van continuous integration en continuous delivery moeten handmatig worden geconfigureerd en geïntegreerd met behulp van scripts.
Maar dit is nog niet alles. In sommige opzichten beginnen de problemen zelfs pas wanneer een applicatie in productie is genomen. Want gebruikers verwachten over het algemeen veelvuldig verbeteringen en regelmatig updates wanneer ze een applicatie gebruiken. En de verantwoordelijkheid om de mobiele gebruikerservaring verder te verbeteren, nieuwe functionaliteit op te leveren en bugs in bestaande applicaties op te lossen ligt ook bij het ontwikkelteam. En dit allemaal naast de verantwoordelijkheid om ook ‘gewoon’ voortdurend nieuwe applicaties te ontwikkelen. Het gevaar bestaat dat it-organisaties hierdoor alleen maar in een neerwaartse spiraal terechtkomen.
Afhankelijkheden
De sleutel om dit te voorkomen, is de applicatie-lifecycle in zijn geheel te bezien. In aanvulling op het versnellen van het ontwikkelproces via platforms voor automatische codegeneratie, zouden it-organisaties het hele delivery-proces moeten automatiseren. Van ontwikkeling, tot het testen en de productiefase. Een oplossing die al deze drie aandachtsgebieden combineert in een rapid application delivery-platform en bovendien rekening houdt met de afhankelijkheden tussen apps en infrastructuur, kan het delivery-proces op een snelle en efficiënte manier automatiseren, verifiëren en reguleren.
Het automatiseren van de complete applicatie-lifecycle helpt it-organisaties ook in de transitie naar een DevOps-cultuur. Omdat development-teams en operations-teams in de regel niet met elkaar praten, niet dezelfde doelstellingen hebben en niet dezelfde tools gebruiken, kan DevOps in de praktijk lastig in te voeren zijn. Een rad-platform adresseert de uitdagingen die hiermee gepaard gaan. Met één platform is het volledige change management-proces te sturen, waarbij Development en Operations elk een eigen rol hebben en waarbij de kans op fouten sterk wordt gereduceerd. Met andere woorden: een rapid application delivery-platform faciliteert het DevOps samenwerkingsproces zonder dat risico’s toenemen.
Mobiele applicatie
Een rad-platform heeft ook nog een ander interessant voordeel, in die zin dat het kan bijdragen aan de adoptie van een applicatie. Hoe vaak komt het in de praktijk niet voor dat gebruikers een nieuwe applicatie openen, het een- of tweemaal gebruiken en vervolgens verder gebruik laten afhangen van de vraag hoe vaak de applicatie wordt geupdate. Als een mobiele applicatie regelmatig wordt geupdate en verbeterd, wat mogelijk wordt door het gebruik van een rapid application delivery-platform, zullen gebruikers eerder geneigd zijn de applicatie consequent te gebruiken.
Voor het succesvol en efficiënt opleveren van nieuwe applicaties is het nodig dat it-organisaties de gehele applicatie-lifecycle meenemen. Het ontwikkelproces automatiseren zonder dat hetzelfde gebeurt voor operations, zorgt alleen maar dat het probleem verschuift. Het draagt niet bij aan waar het initieel om gaat: nieuwe applicaties in de handen van gebruikers krijgen. Het eigen maken van de DevOps-gedachte en de volledige lifecycle automatiseren met behulp van één geïntegreerd rad-platform doet dat wel.
Zeer herkenbaar verhaal!
Uiteraard afhankelijk van de omgeving, kan een app een schakel in een keten vormen. De app (maar dit geldt eigenlijk voor alle software) kan dan standalone misschien wel goed werken, maar het moet ook nog werken in de keten van clouds, *yod, *aas en allerhande andere services en platformen.
Een belangrijk aspect wat ik al meerdere malen ten grondslag heb zien liggen aan zulke problematiek is eilandjes of zuilen binnen een omgeving, iets waar op deze site ook al veelvuldig is geschreven.
De ontwikkelafdeling heeft het product keurig binnen tijd en specs opgeleverd misschien, maar zoals de auteur terecht opmerkt, wordt een deel van de problemen over de schutting meegeleverd en doorgeschoven naar een integratie- of beheersafdeling.
Voor het imago van de ontwikkelafdeling natuurlijk prima, maar je kun je afvragen of deze aanpak ten goede komt aan de hele organisatie.
Als we kijken naar assembly, de taal van de computer die het dichtst bij de kern ligt dan zie je dat je heel veel stappen moet maken om iets heel kleins te realiseren. Op basis van deze instructie set zijn “hogere” programmeertalen gemaakt een compilers om een beter te programmeren instructie set te vertalen naar assembly. Zo’n taal zoals C++ geeft “leverage” ofwel een hefboom functie aan de programmeur. Op dit principe draait de hele wereld en uiteindelijk hebben we talen gemaakt waarmee we met een enkele instructie al heel veel voor elkaar krijgen.
Uiteraard kan dit principe veel verder doorgetrokken worden naar systemen zoals OutSystems, iets wat door het bedrijf waar Mark werkt gemaakt wordt. Hiermee kun je op een generieke manier applicaties ontwerpen die voorspelbaar zijn, snel gerealiseerd kunnen worden en op een standaard manier veranderd en beheerd kunnen worden. Op papier dus een krachtige keuze wat voorborduurt op het principe wat ik hierboven beschreven heb.
Laat ik voorop stellen dat ik heel erg in dit principe geloof.
Waar ik echter in de praktijk tegenaan loop is de implementatie. Generieke systemen verplaatsen de complexiteit van code naar de inrichting en de vormgeving. Vaak zien dit soort systemen er vrij Spartaans uit zien en missen ze veel rijke functionaliteit en zijn noodzakelijke uitzonderingen bijzonder complex. Mijn ervaring is dus dat dit soort systemen maar beperkt bruikbaar zijn, het vervelende is dat je echter heel moeilijk terug kan gaan en het systeem kan verbeteren en de tekortkomingen kunt oplossen. Je moet dan weer helemaal terug naar het begin en die migraties zijn duur, duren lang en hebben veel risico’s.
Ik noem nu OutSystems, maar zo ver ik heb kunnen zien geldt dit voor alle (mobiele app) platformen. Een ander aspect wat ik zie is dat het voor 80% de gewenste lading dekt, en dat die overige 20% zeer lastig te realiseren is.
Het is eigenlijk een schaal : Hoe meer een platform levert hoe lastiger de overige 20% wordt, je hebt ook frameworks die minder compleet zijn, maar wel meer mogelijkheden bieden tot rijke functionalteit en last mile maatwerk.
Daarnaast moet je rekening houden met een lock-in, lock down en de lange life-cycle van het platform. De mogelijkheden verbeteren, maar het platform voelt als snel aan als legacy en kan niet mee komen, of het wordt een gedrocht.
Dus nogmaals, er is geen geldende waarheid, en ik geloof heilig in platformen, maar het is absoluut geen silver bullet oplossing en kent veel verborgen gevaren. Dit is ook de reden waarom de meeste platformen ook nooit breed geadopteerd worden. Want als het heel goed zou zijn, dan zouden we overspoeld worden in de voorbeelden en zou ieder bedrijf het doen…. toch?
Voor een applicatie als office365 heb je vast maar 1 commando / knop nodig om die te kunnen gebruiken en de updates gaan waarschijnlijk vanzelf.
In C++/.NET/Java zulke software schrijven, vergt meer geduld.
Mark begeeft zich er tussen in. Hij noemt de best of both worlds van zijn RAD platform oplossing, Henri is wat kritischer.
Tijd voor een RAD demo op die computable dagen ? Want zo schiet het niet op, he.
Heren,
Felix Graag, wanneer wil je dit hebben?
Henri we hebben veel klanten met complexe applicaties, waarbij integraties, performance en security belangrijke eisen zijn. Het kent geen lock-in omdat er altijd een ‘exit strategy’ mogelijk is, waarbij de source en werkende applicatie terug krijgt.
Een aantal publieke sites, in z’n geheel gemaakt met OutSystems zijn http://www.fly.com en http://www.wasco.nl en geeft een goed beeld over schaalbaarheid en integratiecapaciteit (Fly) en front-end opties (Wasco).
Mochten er nog vragen zijn dan hoor ik het graag.
Vriendelijke groet,
Mark