Het IT-budget voor volgend jaar

Metri Budget

Indexeren huidige budget of doelgericht opbouwen

Op dit moment zijn veel organisaties bezig om het IT-budget voor het komende jaar definitief te maken. De methode die we in de markt het meest tegenkomen is baseline begroten. Hier wordt het budget of de realisatie van het huidige jaar als uitgangspunt genomen en worden de onderdelen geïndexeerd en soms nog even kritisch tegen het licht gehouden. Daar waar de IT-activiteiten van volgend jaar weinig verschillen van die van dit jaar, is dit een zinvolle keuze. Deze aanpak ligt minder voor de hand als er nieuwe dienstverlening wordt toegevoegd, na een fusie of een overname, na het afsplitsen van een bedrijfsonderdeel, of na het met spoed digitaliseren van het hele bedrijf als gevolg van COVID-19. Dit soort disrupties maken het budget of de bestedingen van dit jaar een volstrekt irrelevante graadmeter voor het budget van volgend jaar. In dat soort situaties is het goed om voor een andere aanpak te kiezen.

De coronabezem door het IT-budget

In een eerdere blog is er al voor gepleit om de disruptie die COVID-19 met zich meebrengt aan te grijpen om eens kritisch naar het IT-portfolio te kijken en daar de coronabezem door te halen. Iets vergelijkbaars geldt dan natuurlijk ook voor het IT-budget. Dit jaar hebben veel organisaties hun IT radicaal omgegooid vanwege COVID-19. Een enorme inspanning van veel IT-afdelingen heeft ervoor gezorgd dat vrijwel alle processen buiten de kantoormuren door kunnen draaien. Zo is ING in 7 dagen volledig digitaal gegaan. Dat had niemand vooraf durven plannen.

Dat wil uiteraard niet zeggen dat alles nu vlekkeloos draait. Veel organisaties zijn nu aan het nadenken wat het voor de lange termijn betekent als een groot deel van het werk vanuit de huizen van medewerkers wordt uitgevoerd. Dit vraagt extra investeringen in security, in bandbreedte om tijdens meetings ook video te kunnen gebruiken, maar ook versnelde investeringen in het naar de cloud brengen van (legacy) applicaties die een kritieke rol spelen binnen het primaire proces. Dat laat zich niet vangen in een indexering.

Zero Based Budgeting

Bij Zero Based Budgeting wordt niet gekeken naar de baseline van vorig jaar, maar wordt het budget vanaf nul opnieuw opgebouwd vanuit de huidige omstandigheden en behoeften. Zeker nu de IT zich  sneller ontwikkelt wordt de baseline van het afgelopen jaar voor een toenemend deel van het budget minder relevant. Dit is dus een heel andere benadering en vraagt met name een andere mindset van de mensen die het budget opstellen. Er wordt bottom-up gekeken naar de uitgaven die de beste Return on Investment hebben, zonder dat het budget van het lopende jaar daarbij in de weg zit.

Omdat er ieder jaar met een frisse blik wordt gekeken, biedt deze manier van begroten ook ruimte om niet-productieve kosten omlaag te brengen. Onderzoek van McKinsey liet zien dat die soms wel 10-25% van het budget kunnen bedragen. Iets wat vorig jaar nog een goede investering leek, kan onder de huidige omstandigheden alweer achterhaald zijn. Met Zero Based Budgeting wordt dat snel inzichtelijk en is de beslissing om er mee te stoppen makkelijker gemaakt. Doordat er bottom-up gekeken is vergemakkelijkt dit ook de communicatie over de beslissing om te stoppen.

Een frisse blik op het IT-budget

Door met een Zero Based Budgeting blik naar het IT-budget te kijken krijg je oog voor mogelijkheden om zaken effectiever of efficiënter te doen, zoals:

  • Het zichtbaar maken van de relatie tussen budgetonderdelen en de behoeften en voordelen
  • Het zichtbaar maken van de relatie tussen organisatiedoelen en het budget
  • Het elimineren van verouderde applicaties en/of infrastructuur
  • Het identificeren van mogelijkheden voor outtasking of outsourcing
  • Het identificeren van te zwaar aangezette onderdelen van het budget

Het nadeel van deze manier van werken is dat het vanaf nul opbouwen tijdrovender is dan het baselinen van het bestaande budget. Zeker voor nieuwe activiteiten is het soms lastig om te voorspellen wat dit gaat kosten en wat de verwachte Return on Investment is. Voor de meeste operationele technologieën kan de benchmarkdata van Metri hierbij helpen. De meeste organisaties die met Zero Based Budgeting werken, kiezen daarom voor een hybride vorm. De vaste onderdelen van het budget worden vanuit de baseline opgebouwd en de delen waarop de organisatie meer grip wil hebben of houden worden vanaf nul opgebouwd.

Meer grip op het budget

Binnen organisaties ziet Metri een toenemende behoefte aan inzicht in de cost-drivers, zodat onderbouwde beslissingen kunnen worden genomen om bepaalde kosten terug te brengen. Hiervoor is het nodig om de kosten die aan IT gemaakt worden, te relateren aan de diensten die de organisatie aan haar klanten, gebruikers of burgers levert, hiervoor kan gebruik gemaakt worden van bijvoorbeeld het TBM-framework.

Een toenemend aantal organisaties hanteert striktere processen voor Planning en Control. Dit kan alleen maar effectief zijn als het budget zodanig is opgebouwd dat er zinvol gemonitord kan worden. Terugkerende monitoring van de plannen zorgt ervoor dat geplande verbeteringen ook werkelijk worden doorgevoerd. Zero Based Budgeting kan hier een goede bijdrage aan leveren, als onderdeel van het hele Planning en Control proces.

Wat ook helpt om grip te houden op het budget is het hanteren van een expliciete maatvoering van het IT-budget. Is het IT-budget afhankelijk van groei in klanten/gebruikers of gebaseerd op omzet of winst. Hoe explicieter een budget is opgebouwd, hoe meer de aandacht en energie verschuift van het bewijzen waarom iets is zoals het is naar het actief op zoek gaan naar manieren om zaken beter, sneller of goedkoper te gaan doen. Dit zorgt voor het besef dat geen enkele uitgave te klein is om eens kritisch naar te kijken.

Ook behoefte aan een frisse kijk op uw budget? Laten we eens beginnen met een ‘digitale’ kop koffie.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Prijsschieten in de applicatiestack

Prijsschieten

Kwetsbaarheden in het applicatieportfolio worden een heet hangijzer. Hackers krijgen ruim baan, omdat traditionele beveiligingsmaatregelen, zoals functiescheiding en toegangscontrole bedrijfskritische systemen onvoldoende beschermen. De CIO moet er op toezien dat bij de bouw van nieuwe applicaties Security by Design expliciet wordt meegenomen. Ook in de bestaande applicatiestack moet de security naar een hoger plan. Transparantie is hierbij het sleutelwoord om tot aanvaardbare risico’s te komen.

Lange tijd hebben maakten hackers vooral dankbaar gebruik van fouten in webservers en desktopsystemen om bedrijfsnetwerken aan te vallen. Voor het uitbuiten van kwetsbaarheden richten zij zich in toenemende mate op de applicatiestack. Niet-gepatchte systemen en misconfiguraties van ERP-systemen zijn een nieuw, gewild middel om binnen te komen op een bedrijfsnetwerk zo blijkt uit het rapport ‘ERP Applications under fire’ van Onapsis. Standaard worden ERP-implementaties geacht onbereikbaar te zijn voor de buitenwereld door firewalls en het niet toestaan van directe internetconnectiviteit. Die maatregelen voldoen niet langer. En wat voor ERP geldt, is van toepassing op een brede verzameling business applicaties. Het is tijd om applicatiebeveiliging op een andere manier te benaderen.

Verraderlijke dreigingen

Hoog tijd. Zeker als je kijkt naar de hoge positie van applicatie issues. In de top twaalf van grootste bedreigingen van de Cloud Security Alliance prijken de kwaliteit van applicaties (interfacing) en de structuur van softwarecomponenten respectievelijk op nummer drie en vier. Die hoge plek komt ook doordat veel internationale standaarden voor informatiebeveiliging zich primair richten op de beveiliging van IT-infrastructuur. Applicatiebeveiliging is secundair. Daarnaast worden de nodige kwetsbaarheden over het hoofd gezien door de manier waarop software getest wordt.

Hoe groot het probleem is, wordt duidelijk uit het Crash Report van CAST Software. In dit onderzoek werd de veiligheid en kwaliteit van 1.850 business applicaties (in totaal 1,03 miljard regels softwarecode) onder de loep genomen aan de hand van ruim 1.200 architectuur principes voor robuuste en veilige software. Die principes zijn samengesteld uit de input van CWE, OWASP, SANS en US-CERT over veel voorkomende kwetsbaarheden in software die door hackers misbruikt worden voor hun aanvallen. Met gemiddeld 1 op elke 10,5 regels code bleek iets mis. Kijk je alleen naar security, dan is dat 1 op elke 108 regels code. Hoewel security maar een klein deel van de fouten vertegenwoordigt, ligt hier wel de oorzaak van de meeste bedrijfsschade.

Bestaande manier van testen onvoldoende

Hoe kan dat toch? De eerdergenoemde architectuurprincipes zijn openbaar toegankelijk en er zijn voldoende hulpmiddelen beschikbaar die direct bij het inchecken van nieuwe of gewijzigde softwarecode de broncode screenen. Zeker bij bedrijfskritische systemen wordt er bij de bouw serieus aandacht besteed aan het testen van applicaties. En ook het voorkomen van bekende security fouten krijgt de nodige aandacht in het ontwikkelproces.

Desondanks levert het gebruik van deze tools geen garantie op voor foutvrije software. Dat komt doordat de vele controleregels alleen toegepast kunnen worden op een deel van de applicatie en niet op het applicatieportfolio in zijn geheel zoals deze in een productieomgeving draait. De bestaande manieren van testen zijn niet in staat om kwetsbaarheden in de structuur van applicaties en het portfolio bloot te leggen. Ook de meeste code analysetools houden geen rekening met de systeemarchitectuur, waardoor onvolkomenheden in de samenhang tussen verschillende softwarecomponenten over het hoofd gezien worden. Dat is nummer drie op het eerdergenoemde dreigingslijstje van de CSA.

Verantwoordelijkheid

Security krijgt tijdens de ontwikkeling van software op dit moment niet de juiste aandacht. Het gaat dan niet alleen om onvoldoende aandacht. Ook het moment waarop dit gebeurt, is meestal niet goed gekozen. Veilige software wordt veelal gezien als een verantwoordelijkheid van de ontwikkelaar of de leverancier. Door de opdrachtgever worden nog vaak te weinig eisen gesteld op het gebied van Security by Design. Dit leidt ertoe dat zwakheden in de software, systemen of hun inzet in de productieomgeving pas laat aan het licht komen. De aangescherpte regels vanuit de AVG geven organisaties die software toepassen meer verplichtingen om datalekken te voorkomen. Voor het achteraf laten weghalen van kwetsbaarheden betaal je de hoofdprijs.

Het foutvrij maken van software is meestal een van de laatste stappen in het ontwikkelproces. Zo ontstaat een suboptimale situatie, omdat de dreigingen van vandaag nog niet bestonden toen de software werd ontwikkeld. Daarom is Security by Design zo belangrijk, het vanaf het begin secure ontwerpen van het geheel van software en de onderliggende IT-infrastructuur of clouddienst. Alleen dan worden risico’s op het misbruik van kwetsbaarheden geminimaliseerd.

Prioriteiten

Een pragmatisch onderdeel van Security by Design is het principe van een ‘defensible infrastructure’ zoals deze door de cybersecurity experts Joshua Corman en Gene Kim uitgewerkt is in hun model van een ‘security survival piramide’. Schadelijke praktijken van internet worden beschouwd als fact-of-life, niet alleen naar buiten toe, maar ook in de semi-veilige omgeving van een eigen datacenter. Geen enkele gebruikerssessie in een applicatie is te vertrouwen en de software heeft voorzieningen om de schade van misbruik tot een minimum te beperken. De ontwerpprincipes voor de structuur en de code vormen de basis van inherent veilige software. In de Metri whitepaper ‘Een business aanpak van security’ wordt dit principe uitgewerkt.

Business risico

Applicatiebeveiliging is nu hoofdzakelijk een technisch issue, terwijl het vooral aandacht moet krijgen als een business risico. Kwetsbaarheden in de software verhogen de kans dat de bedrijfsvoering wordt lamgelegd. Dit businessrisico kan inzichtelijk worden gemaakt door de structurele kwaliteit van software te relateren aan concrete business eisen zoals prestaties, onderhoudbaarheid, robuustheid en veiligheid. Deze scan rond risico’s voor de bedrijfsvoering is het beste uit te voeren op basis van gangbare industriestandaarden voor de kwaliteit van software, zoals ISO/IEC 25010 of OMG Automated Source Code Security Measure. Deze standaarden geven de scan en de risico’s die het blootlegt een objectief extern kader. Die transparantie stel je idealiter op een zo hoog mogelijk niveau vast. Want een brede scan van de totale broncode in een applicatiestack geeft inzicht in de zwakke punten in de digitale operatie van een organisatie. Een analyse op portfolio niveau legt onvolkomenheden in de samenwerking van de verschillende softwarecomponenten in de applicatiestack vast.

De business case

Hier zit ook een duidelijk verband met de onderbouwing van een eventuele businesscase. Ik zie u namelijk al denken: met dit soort scans van de applicatiestack gaat een nog groter deel van het IT-budget naar beheermaatregelen. Dat hoeft zeker niet het geval te zijn. In het eerder aangehaalde Crash rapport waarin de softwareportfolio’s van in totaal 329 organisaties geanalyseerd werden, werden ruim 97 miljoen overtredingen van architectuurregels ontdekt. Een tiende hiervan had impact op de security van de onderzochte applicaties en een honderdste had impact op de architectuur van de applicaties. Hoewel deze laatste categorie geen directe impact heeft op de security kunnen dit soort onvolkomenheden wel de helft van een onderhoudsbudget opslokken. Een Prio 1 incident brengt in Nederland gemiddeld een kostenpost van 80.000 euro met zich mee. De transparantie in de business risico’s die de scan inzichtelijk wegen al snel op tegen de besparingen door een verminderd aantal incidenten.

Aangezien software steeds meer het concurrerend vermogen van organisatie bepaalt, is het van belang om grip te houden op de veiligheid en kwaliteit van de opgeleverde software. Goed zicht op de structurele kwaliteit van een applicatieportfolio is hierbij cruciaal. Wilt u meer weten wat Metri voor u kan betekenen in deze aanpak van beveiliging van applicatieomgevingen? Kijk dan eens naar de voordelen van een Applicatie Portfolio Health & Risk scan of een Business Impact Assessment.

Kleine moeite, grote winst

IT kost veel geld. Vaak te veel als je het ons vraagt. Overal stijgen de kosten, want, zo is de redenering, alles wordt duurder en de vraag naar IT wordt door de vele veranderingen en vernieuwingen steeds groter. Toch laten veel bedrijven ook ontzettend veel geld liggen, zo blijkt uit onderzoek van Metri. Natuurlijk moet de focus altijd gericht zijn op het verbeteren en behouden van IT-diensten. Maar er zijn ook veel kansen op het besparen van kosten. Metri schotelt u er 10 voor.

Het (ver)(tr)(b)ouwen van applicaties

Steeds meer organisaties zien toegevoegde waarde in het Agile realiseren van specifieke op maat gemaakte oplossingen, waarbij standaard configuratie en maatwerk samen gaan. Hierbij gaan bouwen, verbouwen en vertrouwen, hand in hand.

Iedereen is er zich van bewust dan in de huidige maatschappij technologie onontbeerlijk is. Zonder de juiste automatiseringssystemen geen vooruitgang, continuïteit of bestaansrecht. Deze afhankelijkheid neemt inmiddels dusdanige vormen aan dat bij storingen er direct schade lijkt te ontstaan aan het bedrijfsresultaat. De marges zijn soms zo klein dat het verschil in een paar uur/dagen (of minder) gemaakt wordt. De ontwikkeling van dergelijke kritische oplossingen heeft hierdoor een enorme impact op de toekomst voor de korte en lange termijn van organisaties en daarmee mogelijk de gehele keten van dienstverlening.

Binnen veel sectoren staat of valt de dienstverlening door middel van controles op het totale bedrijfsproces om fouten te voorkomen. Laat de patiënt zelf met een stift aangeven welk been geopereerd dient te worden om de triviale fout van links en rechts te voorkomen. Iedereen begrijpt dat controles ervoor dienen om het totale proces te verbeteren. Kwaliteitscontroles zijn er om de afgesproken kwaliteit te garanderen en daar waar mogelijk te verbeteren. Maar hoe zit dit bij IT?

Natuurlijk zijn er allerlei controles om de kwaliteit te leveren, verbeteren en te garanderen. Niemand die daaraan twijfelt. En toch lijkt het regelmatig mis te gaan. In calculaties, uitvoering en beheer. Ergens in de voortbrengingsketen lijkt een kwaliteit issue te ontstaan. De IT-leverancier (intern/extern) lijkt zich op te stellen als de specialist van de materie waar de klant (intern/extern) toch geen verstand van heeft. Daarnaast zijn de gerelateerde kosten ook nog eens (te) hoog waardoor een Business Case al snel negatief wordt. Het drukken van kosten, verleggen van verantwoordelijkheden en sturen op eigen ‘controle’ lijkt een valkuil in zich te hebben. Door het wegvallen van onderdelen in de ‘externe’ controle en de Agile Way of Working neemt de kans op fouten in de uiteindelijke oplossing sterk toe. De kosten voor het oplossen van problemen in de gerealiseerde oplossing staan niet in verhouding tot de kosten die gemaakt moeten worden om ze te voorkomen. Maar waarom doen we dit dan niet?

Controle heeft in onze maatschappij een negatieve klank. Door het toetsen van de kwaliteit, en daaraan gerelateerde informatie, wordt inzichtelijk wie welke fouten heeft gemaakt. Dit is natuurlijk erg confronterend voor een maatschappij die er op gericht is om alles meteen goed te doen. Het aanwijzen van de ‘schuldige’ heeft al gauw een juridisch tintje. Terwijl dit in de realisatie naar de oplossing de gedeelde verantwoordelijkheid onderstreept en daarmee de weg naar het hekje voorkomen wordt. Door het meten wordt telkens weer inzicht verkregen in de mogelijke verbeteringen waardoor een ieder gemotiveerd wordt om het steeds beter te doen. Hiervoor is wederzijds vertrouwen van essentieel belang.

METRI heeft meerdere oplossingen in huis om op een volkomen onafhankelijk en objectieve wijze de verbindende factor te zijn om dit vertrouwen optimaal te faciliteren.

De groeiende risico’s van open source software

Open source is al sinds jaar en dag populair, vooral voor toepassingen als databases, storage, analytics, cloud management tools en in toenemende mate ook security. Hoewel open source vanaf de start juist werd geroemd om het hogere veiligheidsniveau zijn de risico’s door een combinatie van populariteit en een flinke toename van kwetsbaarheden flink gestegen. Het is tijd voor maatregelen.

Open broncode speelt tegenwoordig een belangrijke rol in grote vernieuwingsprojecten zoals digitale-transformatieprojecten. Volgens onderzoek van Red Hat speelt open source bij 40 procent van dit soort grote veranderingstrajecten een aanzienlijke rol. Dat open source serieuze business is geworden waarin grote bedragen omgaan, zie je ook af aan de recente aankoop van Red Hat door IBM. En wat te denken van de acquisitie van GitHub door het concern dat juist op gesloten software zijn succes heeft gebouwd: Microsoft.

Zorgwekkend

Er zit een flinke keerzijde aan de wijdverbreidheid van open source. De uitkomsten van een andere studie door open source security platform Snyk, onder 500 respondenten die verantwoordelijk zijn voor onderhoud van open source software, zijn zorgwekkend. Omdat sommige open source frameworks en applicaties veel in gebruik zijn, zijn ze uitgegroeid tot een aantrekkelijk doelwit voor hackers. Aan aanvalsmogelijkheden geen gebrek. In twee jaar tijd is er een groei van 88 procent waar te nemen in het aantal kwetsbaarheden. En alleen al in 2018 vonden onderzoekers 500 kwetsbaarheden.

Net als bij reguliere software denken veel gebruikers dat de ontwikkelaars security serieus nemen. Maar terwijl een zeer ruime meerderheid van gebruikers van open source verwachten dat ontwikkelaars prioriteit geven aan security in hun softwarecode, denken slechts drie op de tien ontwikkelaars dat ze voldoende kennis hebben van beveiliging. En bijna vier op de tien developers testen dan ook helemaal niet op security gedurende continuous integration (CI). Verbaast het dan nog dat het bij open source gemiddeld meer dan twee jaar duurt voordat een gesignaleerde kwetsbaarheid wordt verholpen?

Uitblijvende patches

Aan de gebruikerskant is het automatisch aanbrengen van patches problematisch. Voor op Windows en Linux gebaseerde applicatielandschappen zijn er tal van volwassen oplossingen voor automatisch patch management voorhanden. In veel gevallen worden deze volledig ondersteund door de softwareleverancier, zodat de window of opportunity voor kwaadwillenden beperkt blijft. Maar voor open source zijn deze oplossingen dun gezaaid, waardoor veel systemen onnodig lang gevaar lopen. Dit komt dus nog bovenop de al eerdergenoemde twee jaar voordat er een oplossing voor een fout opgeleverd wordt.

Zo kon het credit ratings bureau Equifax – en meer dan 140 miljoen argeloze consumenten in de VS, Canada en het VK – in 2017 slachtoffer worden van een van de meest omvangrijke datadiefstallen ooit, door een remote code execution die kon worden ingezet vanwege een ontbrekende patch in Java webapplicatie-software van Apache. Een inbraak die eenvoudig voorkomen had kunnen worden, ware het niet dat de relevante verantwoordelijken bij Equifax even niet zaten op te letten – en al helemaal niet beschikten over een automatische patch-oplossing.

Als de enthousiaste open source community daarom eens één procent van zijn tijd in volwassen patch-oplossingen zou investeren, zou zij die reputatie kunnen hooghouden, ofschoon het genoemde Snyk, dat ontwikkelaars helpt kwetsbaarheden vóór te zijn, zeker een stap in de goede richting is. Dit soort hulpmiddelen zijn onontbeerlijk om adequaat zicht te krijgen op de afhankelijkheden tussen open source softwarebibliotheken en de risico’s die hieruit voortkomen.

Intellectueel eigendom

Ook de onduidelijke intellectuele-eigendomsstructuur van open source is reden tot zorg. Zoals bijna alle software een opeenstapeling is van code afkomstig van diverse bronnen, is dit juist bij open source een complicerende factor. Wie commerciële software afneemt, is met één klik op de gebruikerslicentie van eventueel gedoe bevrijd.

Maar wie er zeker van wilde zijn dat er bij het gebruik van open source geen rechten worden geschonden, moest tot voor kort handmatig allerlei documentatie doorpluizen, omdat open source regelmatig op zogenaamde dual-licensed projects is gebaseerd. Sommige open source licenties verplichten organisaties die deze code voor hun project gebruiken het resultaat te delen met de community door de broncode openbaar te maken.

Broncode scannen

Als een organisatie voor een belangrijk deel gebruik maakt van open source software is het verstandig om met een scan van de broncode veiligheidsrisico’s in kaart te brengen. Frequente inzet van software composition analysis (SCA) kan hier een oplossing voor zijn. Daarmee verzeker je je ervan dat software die in ontwikkeling is of reeds wordt gebruikt, voldoet aan beveiligingsstandaarden, juridische vereisten én regulering.

METRI heeft in samenwerking met partner Cast een dienst ontwikkeld, die gebruik maakt van het product Cast Highlight. Deze SaaS-oplossing voert een scan van de broncode uit op applicaties die op open source gebaseerd zijn. De tool scant de werkelijke bron van de software die in gebruik is, en kijkt daarbij zowel naar compliance, kwetsbaarheden en verouderde code door de code te vergelijken met een enorme database van meer dan 20 miljoen open source componenten en 3 miljard file fingerprints.

Met deze informatie en check kan open source op een verantwoorde wijze een belangrijke rol blijven spelen in de vernieuwing van IT en digitalisering van de business.

Meer informatie over deze dienst en Cast Highlight.

Software ontwikkelen met Salesforce Lightning? Houd het beheersbaar!

Het zijn niet alleen low-codeplatformspelers als Bettyblocks, Mendix, Outsystems en Thinkwise die model gebaseerde softwareontwikkeling breed in de markt brengen. Ook een van de grootste SaaS-leveranciers, de marktleider in software voor klantondersteuning Salesforce, is met de Platform-as-a-Service programmeeromgeving Lightning een belangrijke aanjager van deze low-code trend. Organisaties doen er verstandig aan om goed na te denken over de inzet van de talrijke mogelijkheden die dit platform biedt om eigen applicaties te ontwikkelen. Bouwen is één ding, de eigen software assets moeten ook beheerd worden.Elke digitale transformatie begint en eindigt met verbetering van de klantervaring. Zeg een optimale digitale klantbeleving en je komt als snel bij Salesforce uit. Het is een belangrijke reden dat Salesforce op dit moment een groei doormaakt die sneller verloopt dan welke ander softwarebedrijf ooit. De omzet kwam in het vierde kwartaal uit op 3,6 miljard dollar, een stijging van 26% op jaarbasis.

Wind in de zeilen

Die groei zal de komende jaren flink doorzetten, is de verwachting. Aandeelhouders kregen van de top van Salesforce de harde toezegging dat de 13 miljard dollar uit het financiële boekjaar 2019, het komende jaar doorgroeit tot 16 miljard dollar. Deze jaar-op-jaar groei van 20 procent houdt de komende jaren aan. Het doel is een verdubbeling van de omzet tot 26 à 28 miljard dollar in 2023. In dit stabiele groeipad zie je de voordelen van het abonnementenmodel terug. Er zijn geen onzekerheden rond inkomsten uit licenties, waardoor er optimaal geïnvesteerd kan worden in de uitbouw van het platform en het ecosysteem eromheen.

  • Uitgaven aan SaaS in Nederland

Uitgaven aan SaaS in Nederland x miljoen euro | Bronnen: ABN Amro & Gartner

De komst van Lightning betekent dat er een nieuwe groep ontwikkelaars beschikbaar komt, die laagdrempelig bedrijfseigen toepassingen kunnen bouwen. “Low-code softwareontwikkeling stelt organisaties in staat om de slagkracht van hun digitale transformatie verder te ontwikkelen”, stelde Onno Tjeerdsma, regional vice president Northern Europe Salesforce platform, op de in maart 2019 gehouden Salesforce World Tour in Amsterdam. “De Lightning app builder heeft nieuwe voorzieningen zoals de mogelijkheid om een spreadsheet-bestand geautomatiseerd om te zetten in een Salesforce-pagina en een gebruikersinterface om een procesflow op te bouwen door visuele blokken te slepen. Dit verkort de ontwikkeltijd van een paar maanden naar een paar weken. En dat in een multi tenant omgeving die drie keer per jaar automatisch een update krijgt.”Op het evenement, waar zo’n 6 duizend bezoekers op afkwamen, lieten grote organisaties zoals Damen, Havenbedrijf Rotterdam en KLM Cargo zien hoe zij Salesforce inzetten. “Vandaag kun je met eigen ogen zien dat Nederland heel innovatief is”, vervolgde Tjeerdsma, “maar de verdiepingsslag rond digitalisering moet in veel organisaties nog komen. Als kennisland probeert Nederland graag dingen uit, maar als je kijkt naar een land als Finland dan zie organisaties al een stuk verder gaan met Salesforce.

Fabrikanten als Kone en Wärtsila zetten het platform op dit moment al in voor een brede ondersteuning van hun bedrijfskritische processen. Low-code draagt daaraan bij. Een brede verzameling bedrijfseigen apps wordt ingezet om werknemers optimaal te ondersteunen bij hun werkzaamheden. Dat kunnen tientallen applicaties zijn als het gaat om grotere organisaties als Shell en Unilever. Vanuit een strategische visie rond digitale transformatie kunnen dit soort business apps de productiviteit in de organisatie flink verhogen.”

UITGEGROEID

Het low-code platform van Salesforce wordt hoog aangeslagen door onderzoeksbureaus Forrester en Gartner. En ook in andere ranglijsten duikt Lightning meestal op in de top drie. Een belangrijke factor voor deze voorname positie is dat Salesforce een breed SaaS-aanbod aanvult met een low-code gebaseerde PaaS-voorziening. Bedrijven krijgen één platform voorgeschoteld dat een PaaS-SaaS-continuüm biedt van meer generieke functionaliteit tot specifieke, bedrijfseigen oplossingen. Salesfoce is niet de enige die deze combinatie maakt. ServiceNow en Microsoft met zijn Powerapps zijn andere bekende voorbeelden.
De sterke positie van SaaS-leveranciers in de low-codemarkt is een teken aan de wand dat ‘low-code’ de Wysiwig-toepassing anno 2019 is. Van inflatie is zeker sprake. Dus afgezien van het werken met modellen in een grafische abstractielaag om een applicatie te bouwen moeten er in een low-code omgeving optimaal middelen zitten voor het beheer en gebruik van data en content, identiteits- en toegangsbeheer. Klantorganisaties, die nu al op enige schaal de verschillende clouds van Salesforce inzetten, verstevigen en versnellen met Lightning hun digitale transformatie. Het is belangrijk om bij het vaststellen van deze toegevoegde waarde niet alleen naar de korte termijn te kijken, maar ook de mogelijkheden voor adequaat beheer van bedrijfseigen software assets te checken.

GOVERNANCE

Net als bij conventioneel programmeren wordt bij low-code de hoofdmoot van de kosten voor software niet bij de bouw maar tijdens de gebruiksfase gemaakt. Daarom hebben low-code omgevingen voorzieningen nodig om de governance van een applicatieomgeving goed te organiseren. Door al tijdens de bouw programmeurs bewust te maken van best practice aanwijzingen rondom een goede applicatie architectuur, worden later tijdens het beheer van deze applicatieomgeving problemen voorkomen. Het is één van de aanbevelingen in het METRI strategic report ‘De levenscyclus van low-code, TCO en governance van modelgedreven softwareontwikkeling’, waar breed gekeken wordt naar de low-code trend.

Veel low-code omgevingen zijn nog jong. De complexiteit van deze stack zal toenemen naarmate dit soort omgevingen vaker en langer worden gebruikt. Daarom moet het langere termijn beheer vorm krijgen meteen al bij het uitbouwen van het aantal applicaties. En dit is het punt waarop Salesforce met Lightning niet de hoogste rapportcijfers scoort. Salesforce is in daadwerkelijk gebruik van low code een aanzienlijke speler, maar dat komt niet door de brede functionaliteit. Het proces om een app uit te werken in Lightning zijn voldoende, maar het bedrijf loopt hierin niet voorop. Ook het doorvoeren van wijzigingen in apps is relatief omslachtig.

HOGE PRODUCTIVITEIT

En dan komen we uit bij een aandachtspunt waar maar weinig organisaties bij stilstaan als zij een versnelling doormaken van hun softwareontwikkeling met low-code. De Lightning-voorziening is niet de enige mogelijkheid om software te bouwen binnen het Salesforce ecosysteem. Naast Lightning heeft Salesforce ook mogelijkheden om applicaties te ontwikkelen met behulp van traditionele gecodeerde software. Hiervoor maakt het concern gebruik van Apex, een objectgeoriënteerde programmeertaal met Java kenmerken. Daarnaast heeft Salesforce ook nog de Heroku-PaaS-voorziening waarmee organisaties cloud native software kunnen ontwikkelen.

Softwareontwikkeling in het Salesforce ecosysteem kan op verschillende manieren vormgegeven worden. Het is essentieel om dit applicatiebeheer de juiste aandacht te geven en de Lightning voorziening hiervoor niet uit te zonderen. Op het eerste gezicht lijkt het alsof dat niet nodig is. Het onderhoud ligt tenslotte voor een groot gedeelte bij de leverancier van het low-code platform, die hiervoor licentiekosten in rekening brengt. Bij Salesforce zijn de licentiekosten gekoppeld aan het aantal programmeerobjecten die in apps gebruikt worden en de omvang van de doelgroep die met deze applicaties bediend worden.

Daarnaast is de productiviteit die in low-code omgevingen wordt gehaald, hoog. In low-codeomgevingen kost de bouw van één functiepunt een uur. In een programmeertaal als Java heb je voor eenzelfde hoeveelheid functionaliteit al snel 8 tot 10 uur nodig. Maar is dat ook altijd het geval? De praktijk leert anders. Onlangs was METRI betrokken bij twee teams binnen eenzelfde organisatie die elk softwareontwikkeling uitvoerden voor verschillende clouds. Het ene team gebruikte hierbij alleen visual modelling en haalde de productiviteit van één functiepunt per uur. Het andere team maakte gebruik van traditionele codering. Dit team haalde een productiviteit die vergelijkbaar is met het Java-gemiddelde.

CONTROLE MECHANISMES

Wijzigingen in de applicaties zijn gemakkelijker door te voeren, mits het om een overzichtelijk aantal gaat. Daarnaast ligt het leeuwendeel van het onderhoud bij de leverancier van het platform, die hiervoor licentiekosten in rekening brengt. Bij Salesforce zijn de licentiekosten gekoppeld aan het aantal programmeerobjecten die in apps gebruikt worden en de omvang van de doelgroep die met deze applicaties bediend worden. In een enterprise-omgeving zal een ongebreidelde groei van applicaties beheerissues veroorzaken met bijbehorend prijskaartje. Hier kunnen ook ongewenste security risico’s zitten.
Daarom is het een best practice om een app in beheer te geven bij IT op het moment dat deze door meer dan een business unit gebruikt wordt of op het moment dat een applicatie bijvoorbeeld toegang krijgt tot een productiedatabase. Door dit soort controlemechanismes zijn de kosten die gemoeid zijn met de inzet van het low-codeplatform in de hand te houden. Gebeurt dat niet of in onvoldoende mate dan zullen de relatief lage licentiekosten voor het low-codeplatform uit het begin gepaard gaan met groeiende beheerkosten. Klantorganisaties maken vanuit business oogpunt soms bewust, vaak onbewust bepaalde keuzes, waarvoor ze na enige jaren een flinke rekening gepresenteerd krijgen.

SCHAARSTE

Er is nog een factor van belang waar klantorganisaties stil bij moeten staan. Gezien de populariteit van deze SaaS-smaak zal er de komende jaren voor Salesforce kennis een premium prijs betaald moeten worden. In Nederland zijn een groot aantal partnerbedrijven actief met het vermarkten van hun Salesforce-kennis op een totaal van 1300 consultants. Dat lijkt voldoende, maar zal nog steeds voor schaarste en dus hogere prijzen zorgen als je kijkt het groeiend gebruik van Salesforce. Het inkopen van programmeerkennis voor ondersteuning bij Lightning en het bouwen van andere applicaties vanuit het Salesforce ecosysteem zal daardoor met relatief hogere kosten gepaard gaan. Gebruikers van Salesforce doen er goed aan om intern talent te ontwikkelen door opleidingen, door stages en informele vormen van coaching. Op deze manier is er een nieuwe golf van eigen ontwikkelaars en consultants klaar als het gebruik van Salesforce geïntensiveerd wordt.

Mede door Lightning is Salesforce het oorspronkelijke CRM-domein ver overstegen en uitgegroeid tot een platform waarin een business idee snel en efficiënt om te zetten is in business impact. Net als andere low-codeplatformen is Lightning erop gericht om snel functionaliteit te bouwen. In een low-code applicatieomgeving waarmee in de loop der tijd tientallen apps ontwikkeld worden zijn onderhoudbaarheid en kwaliteit van de codebasis belangrijke aspecten waar op gestuurd moet worden. Als gebruikersorganisatie zul je dit kwaliteitsaspect bij het beheer van deze applicatiestack moeten kunnen monitoren. Dat is een belangrijke voorwaarde om de positieve TCO voor low-code voor de langere termijn overeind te houden.

MEER INFORMATIE

METRI bracht eind vorig jaar een strategic report uit over de TCO van low-code ontwikkelomgevingen. Kijk voor meer informatie en voor een download op de landingspagina.

Digitalisering: scheid het kaf van het koren

Het uitvoeren van brede digitaliseringsprogramma’s staat bij veel CIO’s momenteel hoog op de agenda. In veel gevallen speelt software een essentiële rol. Op het eerste gezicht lijken bestaande applicatieportfolio’s één, groot brandend platform die het beste in zijn geheel vervangen kunnen worden. CIO’s die in hun transformatieprogramma code analyse toepassen, krijgen een instrument in handen waarmee waardevolle zaken van bijzaken te onderscheiden zijn. Deze onschatbare informatie onderbouwt strategische ingrepen in het applicatieportfolio en biedt adequaat zicht op de juiste prioriteiten in de roadmap voor softwarevernieuwing.

Voor veel CIO’s is applicatieontwikkeling een blackbox. Die situatie kan veranderen door het onzichtbare zichtbaar te maken, stelde Jean-Patrick Ascenci, senior solution specialist voor het Highlight-product van Cast Software. Ascenci was één van de sprekers op het seminar over het moderniseren van software, dat METRI en CAST op donderdag 4 april 2019 organiseerden in Bunnik om hun strategische samenwerking te onderstrepen. Door de softwarecode van maatwerk applicaties te scannen krijg je zicht op hoe robuust, veilig, efficiënt, overdraagbaar en onderhoudbaar applicaties zijn. Door dit scannen van code te combineren met vragenlijsten, waarin de toegevoegde waarde van applicaties voor de business duidelijk wordt gemaakt, ontstaat concreet zicht op de toegevoegde waarde en de risico’s in het applicatieportfolio.

Beide benen
De eerste spreker van de middag, Paul Thysens, ex-CIO BNP Paribas Fortis, zette zijn toehoorders van CIO’s en hoofden softwareontwikkeling even met beide benen op de grond. “Je zou met het huidige marketing geweld rond digitalisering de indruk kunnen krijgen dat vandaag de dag de grootste veranderingen plaatsvinden in IT”, aldus de door de wol geverfde CIO die na een lange loopbaan als IT executive in de bankwereld nu een adviesrol heeft. “Vanaf de start van het vakgebied draait IT om modernisering. Voortdurend komen er nieuwe zaken bij die als bij een ui met iedere nieuwe laag complexiteit toevoegen aan de stack. Als CIO ben je voortdurend bezig om die verandering te faciliteren. In het huidige digitale tijdperk verwachten consumenten eenvoudige systemen en processen, op maat getekend naar hun specifieke behoeftes en afgestemd op de kleine schermervaring van de smartphone. Dat is niet de enige uitdaging. Decennia oude systemen functioneren niet goed in de open omgeving van internet. Het ondersteunen van deze nieuwe security architectuur in bestaande systemen is een uitdaging, omdat er een grote schaarste is aan programmeertalent. De vraag is tien keer groter dan het aanbod. Deze klok tikt ook steeds harder, omdat programmeurs die de bestaande systemen kunnen onderhouden in toenemende mate de arbeidsmarkt verlaten.”

Vernieuwing van software is dus een belangrijk thema, maar dat is niet de enige prioriteit die zich aandient. Veel CIO’s zitten vast aan legacy en tal van andere zaken die om voorrang schreeuwen. “Als je als CIO bij de business voortdurend geklaag hoort over het innovatietempo en de kwaliteit van IT en tegelijkertijd een aanzienlijk veranderprogramma moet ondersteunen, kan het lastig zijn om een goede richting te vinden”, vervolgde Thysens. Hoe stel je vast of je als CIO op het goede spoor zit? Het verzamelde dagtarief van externe experts is een gegeven dat bijdraagt aan kostenbeheersing. Toch is het volgens Thysens geen adequate graadmeter in welke mate deze kennis bijdraagt aan de productiviteit van IT. De stabiliteit van de applicatie-omgeving en de gemiddelde doorlooptijd van projecten zijn wat dat betreft betere bakens voor de CIO die met grote veranderingen bezig is. De stabiliteit van applicaties is een belangrijk gegeven omdat het goed zicht geeft op de kwaliteit en het functioneren van applicaties. Doordat incidenten en onderbrekingen van applicaties rechtstreeks impact hebben op de gebruikerservaring, wint dit cijfer verder aan belang. De andere niet te missen indicator voor succes heeft te maken met de gemiddelde duur van projecten. Als je in een portfolio van honderden projecten een gemiddelde haalt van 15 maanden, moet je als CIO onderzoeken met welke maatregelen je de doorlooptijd kunt versnellen. Tot slot zijn ook gebruikerstevredenheidsonderzoeken goede graadmeters voor de algehele kwaliteit van de IT-dienstverlening.

Helikopterblik
Waarmee krijg je een alles overziende blik, een totaaloverzicht dat een brede kijk biedt op modernisering van het applicatielandschap? Het Highlight hulpmiddel van Cast biedt in een grafische weergave van het applicatieportfolio zicht op de veerkracht van applicaties en het gemak waarmee deze software over te hevelen is naar een cloudplatform. “Zo’n helikopterweergave laat zien in wat voor mate applicaties bijdragen aan het bedrijfsresultaat, welke software-onderdelen problematisch zijn en welke applicaties goed over te zetten zijn naar een nieuw platform”, vervolgde Ascenci. “Als een toepassing niet belangrijk is voor het bedrijf, veel bugs heeft en problematische softwarecode zijn dat belangrijke aanwijzingen om deze applicatie uit te faseren en naar een andere oplossing te zoeken. Anders dan bij andere methoden om de applicatie roadmap breed aan te vliegen, is bij de werkwijze van Cast wel de onderliggende softwarecode beschikbaar. Op die manier kun je een applicatie waarvan het beheer te kostbaar is, gedetailleerd bestuderen.”

Een andere mogelijke toepassing is een scan uitvoeren op mogelijk verkeerd gebruik van privacygevoelige data. Door op sourcecode niveau te checken of er manipulatie van data plaatsvindt, kunnen CIO’s vaststellen of software voldoet aan de AVG (Algemene Verordening Persoonsgegevens). Ook systemen die opgebouwd zijn met open source softwarecode zijn gedetailleerd te checken op kwetsbaarheden. Er wordt een link gelegd met bekende kwetsbaarheden in populaire frameworks. Ook problematische open source licenties komen boven drijven. Soms verplicht een open source licentie organisaties de code die zij verwerkt hebben in hun applicatie te publiceren. Ook dat risico wordt geïnventariseerd. Centraal thema bij het opmaken van de applicatie inventaris is de ondersteuning van cloud als leveringsvorm. Bij de scan komt er integraal zicht op de bouwblokken in de softwarecode die vernieuwing nodig hebben bij het overzetten van de applicatie naar een cloudplatform. Dit is een essentieel ingrediënt voor een cloud transformatie roadmap.

Van legacy naar digitaal
Centrale boodschap tijdens het seminar was dat organisaties die van legacy door willen groeien naar een digitaal bedrijf de huidige blackbox van softwareontwikkeling open moeten gooien. De feiten en informatie die hierbij boven water komt, hebben een adequate vertaler nodig vond Ascenci. “Bij Cast Software kunnen we spreekwoordelijk gezegd de deur van applicaties openen, maar je hebt een adviseur als METRI nodig om de aanbevelingen te concretiseren en op te kunnen volgen.” Iedere organisatie heeft weer andere criteria en voorkeuren voor het moderniseren van de applicatiestack. In dit verband is ook het 6R-model van AWS relevant, dat ook richting geeft bij de vervanging van maatwerksoftware door standaard SaaS-software. Sourcing vraagstukken zijn relevant. Uitdagingen rond het beheer van softwarecode, het vinden van de juiste onderhoudsteams en het minimaliseren van beheerkosten en vergroten van het innovatiebudget zijn belangrijke voorwaarden voor een CIO om verder te komen met een digitaliseringsagenda. En die modernisering gaat natuurlijk veel verder dan software alleen. Zo is de overstap op een database-as-a-service-concept een veel gemaakte eerste stap naar de cloud.

De metertjes in de softwarefabriek
Het meekijken in de softwarecode heeft ook zeker zijn waarde op het moment dat applicaties nieuwgebouwd worden. Dat liet senior consultant Harold van Heeringen van METRI treffend zien met zijn metafoor van de metertjes die in een fabriek die gebruikt worden voor procescontrole. Op een feestdag leidde een vriend hem rond in een lege fabriek. De grote verzameling meters, klokken en meetinstrumenten op het controlepaneel inspireerden hem om bij financiële analyses van softwareontwikkeling ook met gestandaardiseerde metrics en data te werken. “Software bouw je ook in een fabriek”, aldus Van Heeringen. “Het vreemde is dat binnen de tegenwoordig gangbare agile methode er bijzonder weinig meetgegevens over het functioneren van ontwikkelteams beschikbaar is. Er is een lage volwassenheid in meten, omdat bedrijven ervan uitgaan dat de experts zelf in voldoende mate weten wat ze moeten doen. Het voornaamste controlemechanisme is de producteigenaar die de verzamelde functionaliteit van de backlog in beheer heeft.”

Het is de vraag of die ingeslagen weg wenselijk is. Het produceren van software is tegenwoordig essentieel voor de toekomst. Bij agile zijn in veel gevallen de risico’s opnieuw volledig bij de klant komen te liggen doordat contracten time en material gebaseerd zijn. Dat levert voorspelbare kosten op doordat in de teams de functies en rollen schijnbaar overzichtelijk ingedeeld zijn. Maar wil je onafhankelijk vaststellen of je als klantorganisatie waar voor je geld krijgt, dan is deze methode niet transparant genoeg. Neem een functie in de applicatie die in verschillende sprints 3 of 4 keer opnieuw wordt gebouwd. Heb je niet de beschikking over dit soort detailinformatie rond de productiviteit, dan kun je kun niet sturen op deadlines en kosten. Voor de langere termijn hebben stakeholders inzicht in de productiviteit en kwaliteit van softwarecode nodig om omvangrijke agile projecten bij te kunnen sturen. Ook op dit punt kan code analyse bijdragen aan het productief maken van de software-industrie.

Meer informatie
Elke CIO en IT-beslissers moeten in staat zijn om het portfolio aan applicaties te analyseren en te beoordelen. Code analyse gecombineerd met de meer traditionele aanpak van surveys levert Software Intelligence op die de business value van software verhoogt, applicatiebeheerkosten verlaagt en vooral risico’s rond security verkleint. Dat is niet alleen voor legacy interessant. In de agile wereld wordt er continu nieuwe software in het portfolio geïntegreerd. Het is een absolute noodzaak om de structurele gezondheid te blijven monitoren om dure incidenten te voorkomen en de TCO behapbaar te houden, of zelfs te verlagen. Het Highlight product van CAST, waar METRI de financiële data analyse dienstverlening gedeeltelijk op baseert, maakt duidelijk wat de score is van applicaties ten aanzien van aspecten als agility, resilience en cloud readiness. Door te segmenteren wordt het mogelijk om snel onderbouwde keuzes te kunnen maken. In een kortdurend traject van maximaal enkele weken, wordt een integraal beeld geschetst van het portfolio, gebaseerd op facts en internationale standaarden, waar CIO’s en hun ontwikkelteams direct mee aan de slag kunnen. Zie voor meer informatie deze webpagina.

Opheffen BIT is risico maar ook een kans voor Rijks IT

Cloudkosten Metri

Er komt vooralsnog geen verlenging voor het Bureau ICT-Toetsing (BIT), die in opdracht van de Tweede Kamer, grote rijksbrede IT-projecten vooraf en tijdens de looptijd controleert. De kennis en ervaring wordt de komende twee jaar overgebracht naar de CIO Offices van ministeries zelf. Deze vrijblijvende verplaatsing van de controlefunctie lijkt op het eerste gezicht desastreus. Tegelijkertijd biedt het ook tal van nieuwe kansen voor versteviging van grootschalige IT-programma’s bij de rijksoverheid.

De positie van BIT als waakhond, die grote lopende en nieuwe projecten op onafhankelijke wijze screent, krijgt geen verlenging. Dat blijkt uit de ‘Strategische I-agenda Rijksdienst 2019-2021’ die minister Kasja Ollongren van BZK enkele weken terug naar de Tweede Kamer stuurde. Op zich is dit geen verrassende ingreep. Vanaf de start was bepaald dat BIT een tijdelijke organisatie is. Toch heeft deze bijna terloopse opmerking veel stof doen opwaaien, en terecht.

Gouden greep

Want het was destijds een gouden greep om een derde lijn van controle toe te voegen met als enige belang de Tweede Kamer te informeren hoe grote IT-projecten werkelijk verlopen. Het was de belangrijkste aanbeveling van de commissie Elias vijf jaar terug. BIT zou tussen de 5 en 7 jaar nodig hebben om een cultuuromslag te bewerkstelligen in de opzet en aansturing van grote Rijks IT-programma’s. Meerdere onderzoeken van BIT toonden aan dat zelfs tweede lijn controles van onafhankelijke externe adviesbureaus lang niet altijd de faalfactoren van projecten boven water kregen. Zowel in vraagstelling als in de antwoorden daarop bleven in dit soort onderzoeken tal van kritische vragen onderbelicht. Er is een levensgroot risico dat de praktijk van op feiten gebaseerde en onafhankelijke feedback zoals het BIT dat doet sterk verwatert als het ondergebracht wordt bij departementale CIO offices.

Als de onderzoeken van het BIT iets duidelijk hebben gemaakt, dan is het wel dat onafhankelijk kijken naar ICT-projecten van doorslaggevend belang is voor de slagingskans. Het verschil tussen succesvolle en falende ICT-projecten zit hem erin dat in de eerste lijn, bij het programmamanagement zelf, voldoende controlemechanismes aanwezig zijn om op basis van feiten programma’s bij te sturen. Die zijn er nu vaak niet. Veelal heeft een externe leverancier onder aansturing van een ingehuurde projectmanager een te grote vrijbrief om het functioneren van een programma te beoordelen. Beiden hebben een te groot belang bij het doorgaan van het project om onafhankelijk naar de faalfactoren te kijken. Want vergis je niet: voor flink bijsturen heb je een kritische blik nodig en de nodige moed. Een voorbeeld waar het advies van BIT deze effecten had was het schrappen van het Multi Regelingen Systeem van de SVB. Een falend nieuw systeem werd niet in productie genomen en de ontwikkeling gestaakt. In plaats daarvan werd er teruggevallen op de bestaande, bewezen functionerende systemen. Is het te verwachten dat de onafhankelijke kijk vanuit een opdrachtgever zelf komt in plaats van een onafhankelijk opererende waakhond.?

Basis op orde

Die kans wordt een stuk groter als de CIO offices vanuit een gezamenlijke basis gaan werken, waarbij tot op detailniveau gestandaardiseerde meetinformatie aanwezig is over productiviteit, kwaliteit en voortgang van programma’s. Succesvolle projecten hebben met elkaar gemeen dat er veel aandacht is voor de betrouwbaarheid van het systeem. Eén van de verdiensten van het BIT is dat ICT-projecten kleiner worden. Hierdoor veranderen de systemen op een meer gecontroleerde manier en blijft de betrouwbaarheid beter gewaarborgd. Maar het echt kijken naar de betrouwbaarheid van de code van systemen is nog geen gemeengoed. Bij software betekent dit dat je specialisten naar de code van applicaties laat kijken. De klantorganisaties, die deze moeite nemen, hebben een aanzienlijk grotere kans op goed werkende, samenhangende en robuuste ICT, blijkt regelmatig uit de adviespraktijk van Metri die dit soort controles veelvuldig uitvoert.

We staan niet alleen in deze mening. Professor Chris Verhoef, hoogleraar informatiesystemen aan de VU, waarschuwde voor een terugval als BIT als onafhankelijke waakhond opgeheven wordt. Toen hij de Tweede Kamer recent adviseerde over dit voorgenomen besluit, onderstreepte hij de zegeningen van een orgaan dat feitelijk en onomfloerst het parlement informeert over de risico’s van overheids IT-investeringen. Ook Verhoef noemde de transparantie op detailniveau waar BIT regelmatig op hamerde van levensbelang om de geformuleerde doelstellingen van betrouwbare, goedwerkende en samenhangende ICT voor elkaar te krijgen. Als je het aantal defecten in een applicatie per tijdseenheid consequent meet, krijg je een goed beeld van de betrouwbaarheid van het systeem en de risico’s die in deze applicatie zitten.

Juist door gedetailleerd te kijken in een breed aantal programma’s kunnen rijksoverheden leren van hun fouten en de juiste dingen doen om de betrouwbaarheid van software en data te verbeteren. Die kennis en kunde zou geborgd moeten zijn. De transparantie waar BIT regelmatig voor pleitte is juist op detailniveau van levensbelang om de geformuleerde doelstellingen van betrouwbare, goedwerkende en samenhangende ICT voor elkaar te krijgen. Dit moet doorlopend gebeuren en op een methodische manier die idealiter breed gedeeld wordt binnen de rijksoverheid.

Deskundigheid

Zo’n centrale en gedeelde aanpak van het portfoliomanagement is niet terug te vinden in de strategische I-agenda van de rijksoverheid. De deskundigheid die nu binnen en rondom het BIT wordt opgebouwd, kun je en moet je niet willen verdelen over dertien departementen. Het gaat om specialistische kennis die slecht past bij het profiel van de gemiddelde CIO offices die juist drijven op mensen met een meer generalistische insteek. Bovendien zullen de specialisten hun heil elders gaan zoeken als wordt aangekondigd dat hun werk voor het BIT eindig is. En dat is ontzettend jammer en een groot risico voor de rijksoverheid. De kennis en ervaring die BIT heeft opgedaan is uniek. Dat mochten we vorig jaar zelf ervaren toen het BIT tijdens een congres van het standaardisatie intiatief voor softwaremetrieken Nesma hun bevindingen deelde over het lerende vermogen van de Rijks ICT. Hun analyse was pittig en ambitieus zoals uit dit puntenlijstje blijkt:

  1. Bepaal een helder en gedragen doel. Wie veertig jaar geleden bedrijfskunde studeerde, leerde toen al dat dat belangrijk is. En toch blijkt dat in de praktijk lastig te bereiken;
  2. Kies een realistische aanpak. Hier wordt – echt waar – nog te weinig naar gekeken. Experimenteer klein en tuig pas een groot project op bij een bewezen aanpak. Deze methode van stapsgewijs ontwikkelen is een van de leerpunten die nu in de praktijk gebracht wordt;
  3. Zorg voor voldoende resources en een goede voortgangsbewaking. Dankzij het BIT heeft er op die bewaking een flinke verbeterslag plaatsgevonden. Dat smaakt naar meer;
  4. Zorg voor een goede krachtsverhouding met externe leveranciers. Hier is nog veel werk te doen, omdat veel opdrachtgevers niet voldoende professioneel omgaan met hun demand rol;
  5. Wees je bewust van de huidige status van het IT-landschap van een organisaties. Bedrijven worstelen al heel lang met hun IT-legacy en dat is voor een belangrijk deel onnodig want er zijn bewezen goede oplossingen voor dit issue;
  6. Wees geen one trick pony maar neem verschillende scenario’s in overweging. Dankzij het BIT zien we dit gelukkig wel steeds vaker gebeuren. Zorg voor een plan B voor als er zaken misgaan. Veel grote veranderprogramma’s zijn zeer gebaat bij dit soort realisme.

Cultuuromslag

Het zal nog zeker een generatie duren voordat de ICT-cultuuromslag waar de commissie Elias op hoopte een feit is, voorspelde de eerder aangehaalde professor Verhoef tijdens de commissievergadering. Hij heeft gelijk. Het BIT voortijdig opheffen gaat zeker niet helpen in het maken van die mentaliteits- en gedragsverandering. Toch is er ook bij deze beleidswijziging wel een kans om zaken die door BIT geagendeerd zijn te verbeteren en een logisch vervolg te geven. Zo ligt het voor de hand om de plannen en begrotingen van IT-projecten op realisme te checken. Ook dit soort kennis en kunde zou een nieuwe vorm kunnen krijgen als een basis controlemechanisme in de eerste lijn als onderdeel van het portfoliomanagement. Onze collega Harold van Heeringen behandelt binnenkort in een andere blog de mogelijkheden van Software Cost Estimation om begrotingen van grote programma’s realistisch in te schatten en projectrisico’s te verkleinen.

Nut en noodzaak van kwaliteitscontrole op Agile

sofware quality

Reageren op verandering is belangrijker dan het volgen van een vooropgesteld plan. Door deze vuistregel in het Agile Manifesto, is planning en kwaliteitscontrole het kind van de rekening geworden in agile softwareontwikkeling. Bedoeld als methode om met een klein team, kort op de bal software te ontwikkelen slaat dit dogma opdrachtgevers instrumenten uit handen om grip op kwaliteit en productiviteit te krijgen bij agile softwareprojecten.

De agile methode lijkt boven elke twijfel verheven nu het zelfs wordt ingezet bij bedrijfsonderdelen die niets met IT van doen hebben. Maar juist nu de wereld agile en masse omarmt, moeten we toch eens stilstaan bij de risico’s. Er zijn tal van signalen van senior-managers bij grote organisaties die niet tevreden zijn met de prestaties van hun agile teams. Agile is wat dat betreft toe aan een herbezinning.

Wildgroei

Die wildgroei ligt overigens niet alleen aan de teams zelf. Neem bijvoorbeeld het feit dat in agile development de risico’s bij de klant liggen. Dienstverleners lenen mensen uit op basis van uurtje-factuurtje, en na oplevering nemen deze partijen geen verantwoordelijkheid meer voor het resultaat. In de agile-wereld zijn er nu eenmaal nauwelijks resultaat gebaseerde contracten. Daar is de kwaliteit niet bij gebaat met alle risico’s van dien. Inferieure softwarecode kan het voortbestaan van je organisatie bedreigen. Zogenaamde ‘software intelligence’ is daarom een must, was de belangrijkste boodschap van het Software Intelligence Forum in Parijs van organisator Cast en andere experts, dat ik begin dit jaar bezocht.

Zelf mocht ik ook vertellen wat organisaties kan overkomen als zij de greep verliezen op hun applicatieportfolio en wat zij hiertegen kunnen doen. Mijn presentatie ging over het spanningsveld tussen agile werken, controle over het ontwikkelproces en de uiteindelijke softwarekwaliteit. Het verschil in output tussen softwareteams –dus niet alleen agile teams – kan zomaar een factor 10 verschillen. Een belangrijke oorzaak is dat er een groot gebrek is aan uniforme meetmethoden zoals die in veel andere industrieën gemeengoed zijn.

Ook aan de planning van projecten schort regelmatig het een en ander. Zowel de inschatting van kosten als de looptijd kloppen vaak niet. Omdat agile werken organisatorische veranderingen veronderstelt, is dat bijna een uitnodiging tot falen. Op een X-moment is gewoon niet alle benodigde functionaliteit beschikbaar.

De agile-methode geeft teams daarnaast veel invloed. Daar is op zich niks mis mee, maar omdat zij geen standaard metrieken hanteren waarmee hun output te meten is, is er op een hoger niveau geen overzicht. Teams gebruiken storypoint-based metrics, die prima functioneren binnen het team, maar buiten deze context hun betekenis verliezen. Hierdoor weet het hogere management niet waar het aan toe is. Managers hebben daardoor heel weinig controle over ‘hun’ teams, die vaak grotendeels worden bemensd door externen. Ook dit maakt de situatie er niet gemakkelijker op.

Spagaat

Het hoger management is wel verantwoordelijk voor de kosten en de waarde die agile teams moeten toevoegen. Daardoor zitten deze executives in een vreemde spagaat: ze moeten toezicht houden op het ontwikkelproces, maar hebben hier in de praktijk weinig tot geen zicht op. Zonder onderbouwde feiten is het een onmogelijke taak om hier verantwoording over af te leggen. In elke andere discipline is dit een recept voor mislukkingen te noemen.

Want het senior management moet over objectieve, met feiten onderbouwde informatie kunnen beschikken om de organisatie te leiden en teams de juiste kant op te sturen. Executives moeten niet alleen teams kunnen vergelijken op basis van hun output. Ze moeten de kwaliteit en de risico’s in het applicatieportfolio ook kunnen doorgronden. En in organisaties die agile ontwikkeling hebben omarmd, ontbreekt het hier regelmatig aan.

In het eerdergenoemde Agile Manifesto zijn genoeg aanknopingspunten om een duurzame softwareontwikkeling te bevorderen. Een van de twaalf stelregels schrijft voor dat de sponsoren, ontwikkelaars en gebruikers in staat moeten zijn om een constant tempo onbeperkt te kunnen handhaven. Hier is objectieve informatie over de productiviteit en de softwarekwaliteit die teams voortbrengen onontbeerlijk. Door de output van agile teams op een hoger niveau te monitoren krijgen opdrachtgevers weer grip op hun investeringen.

Agile: is er na de kost wel sprake van baat?

De pluspunten van agile softwareontwikkeling, waarbij de bouw van grote applicaties in korte, overzichtelijke iteraties wordt opgehakt, hebben de afgelopen jaren de meeste aandacht gehad. Het maakt grote softwareprojecten behapbaar en organisaties wendbaarder. Minpunten zijn er ook. Zo is het in veel gevallen onduidelijk of de kosten wel in balans zijn met de baten.

Het is niet verbazingwekkend dat de kosten van agile softwareontwikkeling bij menige organisatie behoorlijk uit de klauwen zijn gelopen, terwijl de baten achterblijven. Dat komt omdat een gedegen onderbouwing van een agile softwareproject doorgaans ver te zoeken is. Het lijkt wat dat betreft op de laatste dieetmode: veelbelovend, maar de resultaten blijven uiteindelijk toch vaak achter bij de verwachtingen ook al zet degene die af wil vallen zich toch zo in.

Waar je bij een dieet nog enige objectieve meetbaarheid hebt – calorieën en lichaamsgewicht – worden bij agile rekkelijke begrippen als klanttevredenheid en velocity ofwel ontwikkelsnelheid als concrete doelstellingen opgevoerd. Dat is veel te mager gezien de enorme investeringen die met deze softwareprojecten gemoeid gaan. Het is niet voor niets dat CFO’s aandringen op een betere meetbaarheid van de gehele agile-methodiek (zie ook deze blog)

Niet alleen vanuit het oogpunt van financiën moeten er meer harde feiten komen, ook het hogere management ontbreekt het meestal aan afdoende stuurinformatie. Er worden geen gestandaardiseerde meetmethoden binnen de agile werkwijze toegepast, terwijl deze er wel zijn. Sterker nog één van de basisprincipes van het ‘Agile Manifest’, is dat een team zelfsturend is en naar eigen inzicht verschillende teamleden bij het project betrekt. Schaalbaarheid is problematisch. Agile werkt het beste in teams van beperkte omvang (tussen 3 en 9 mensen) en teams werken tot in hoge mate zelfstandig. Opschalen doe je door meerdere teams naast elkaar te zetten. Ieder team doet dingen op een eigen manier, hetgeen een nadelige impact heeft op het geheel.

Dat gebrek aan meetbaarheid is niet zo vreemd, omdat het zwaartepunt bij agile nu eenmaal op de individuele teams ligt en niet op de aansturing en ondersteuning. Van teams wordt verwacht dat ze het zo veel mogelijk zelf uitzoeken en bijgevolg wachten deze nog wel eens te lang met hulp inroepen van senior expertise. Daar hebben snelheid en kwaliteit onder te lijden. Gevolg is dat de doorlooptijd van projecten vaak slecht wordt ingeschat terwijl er tegelijkertijd organisatorisch niet aan bepaalde knoppen te draaien valt.

Over kwaliteit gesproken, in de IT is het al decennialang gewoonte dat mensen langs de zijlijn in een QA-achtige rol worden toegevoegd om de kwaliteit van software omhoog te krijgen. Denk aan de hele testindustrie, ISO/ISAE-consultants en aan architecten voor wie QA gewoon een deel van hun werk is. Het is natuurlijk niet realistisch te verwachten dat agile-teams dat ineens zelfstandig gaan doen. Dus wie bewaakt de kwaliteit zonder dat dit ten koste gaat van de benodigde snelheid?

Net zoals bij het volgen van een dieet ligt vervallen in oude patronen op de loer. Organisaties denken dat ze met een dagelijkse standup en tweewekelijkse sprint agile bezig zijn. Maar als sprint 1 het basisontwerp is, sprint 2 het detailontwerp van de database, sprint 3 het detailontwerp van de rapportages en… sprint 8 de realisatie van de rapportagefunctie, hoe agile ben je dan werkelijk? Dan heeft het er alle schijn van dat de traditionele manier van werken in een agile keurslijf is geduwd. Met voorspelbare gevolgen: kostenoverschrijdingen, achterblijvende functionaliteit en kwaliteit en deadlines die standaard niet gehaald worden.

Het is hoog tijd voor een reality check op agile. Dat kan met gestandaardiseerde metingen op productiviteit en kwaliteit van softwareprojecten zoals METRI dit aanbiedt. Daarnaast is ook governance essentieel. Organisaties worden alsmaar afhankelijker van software. Je kunt binnen een paar dagen failliet zijn als een kritiek systeem faalt en er geen tijdige remedie te vinden is. De aansturing van agile softwareontwikkeling is dan ook aan een nieuwe benadering toe. Want binnen een paar dagen failliet gaan is misschien wel heel agile, maar niet volgens plan…

Aanmelden

METRI organiseert op donderdag 4 april van 13.30 tot 18.00 uur samen met Cast het seminar “How to use Software Intelligence to save cost and prove more business value”. Deze bijeenkomst geeft u meer inzicht in het applicatie portfolio van uw organisatie en de mogelijke risico’s die hierin verborgen zitten. Software Intelligence biedt niet alleen inzicht in de risico’s, maar levert ook concrete handvatten om de grootste risico’s uit te mitigeren. Volg voor updates de LinkedIn-pagina van METRI: https://www.linkedin.com/company/metri/

De top 10 van 2018

We starten het nieuwe jaar, dus is het traditiegetrouw tijd voor lijstjes. En wat zegt nou meer over het jaar dan de tien berichten die het afgelopen jaar het best gelezen zijn? Niets! Daarom heeft METRI  bij deze de top-10 meest gelezen berichten uit 2018 voor je verzameld.

10 Opkomende digitalisering jaagt tarieven van externe IT-ers omhoog

De Nederlandse economie heeft de stijgende lijn flink te pakken. In de zakelijke dienstverlening wordt weer volop geïnvesteerd in bijvoorbeeld digitalisering of andere bedrijfstransformaties, die in veel gevallen een ICT-component kennen. Het crescendo van de economie vertaalt zich in een duidelijke stijging in de tarieven van externen.

9 Managed security services verhogen weerbaarheid organisaties

Bestuurders van organisaties leggen security veelal in handen van hun technische experts, terwijl zij het zelf als een bedrijfskundige kwestie aan zouden moeten pakken. In het aanbod van managed security services is genoeg gerichte hulp van buiten te vinden waarmee de weerbaarheid effectief omhoog kan. Wat vooral nodig is, is een cultuurverandering in de directiekamer. Bestuurders moeten de agenda bepalen en security benaderen als hun probleem.

8 Low-code: reddingsboei of springplank?

Veel organisaties omarmen low-code applicatieontwikkeling om software gedreven innovatie op de rit te krijgen. Vanuit zijn expertise rond applicatiebeheer en softwareontwikkeling plaatst CAST Software vraagtekens bij de recente hausse rond low-code. Is deze nieuwe vorm van maatwerk een reddingsboei of kan het ook echt een springplank zijn voor een nieuwe toekomst?

7 Modernisering softwareontwikkeling met low-code

Op dit moment hebben veel organisaties low-code omarmd om hun software gedreven toekomstplannen te realiseren. Low-code is de benaming van een nieuwe generatie programmeerhulpmiddelen. Tot op een hoog niveau wordt de abstractielaag van modellen gebruikt om het proces van softwareontwikkeling te versnellen. Werknemers met hooguit wat basis programmeerkennis kunnen een aanzienlijk deel van de applicatieontwikkeling voor hun rekening nemen. Dat klinkt bedrijven in de huidige IT-arbeidsmarkt als muziek in de oren. Daarnaast is de ontwikkeling, het testen en het live brengen van applicaties volledig gestroomlijnd door een platform aanpak.

6 Zit na SLA nu XLA in ons DNA?

Is uw tevredenheid al eens gemeten? Wist u dat SLA achterhaalt is en XLA helemaal in? Het eerste staat voor Service Level Agreement, het tweede voor eXperience Level Agreement, ofwel het meten van de ervaringen over de geleverde dienstverlening. Is dit wel meetbaar? En zo ja, wat is dan het effect?

5 IT starts with the facts

In een samenleving waarin IT de ruggengraat is van iedere organisatie, is hoge kwaliteit van de onderliggende data – harde feiten – rond de consumptie van technologie cruciaal. Na vijftien jaar geleden te zijn gestart als specialist in IT-benchmarking, heeft METRI zich de laatste jaren bewezen als allround advisory voor alles wat met grote IT-projecten te maken heeft. Het draait hierin om de juiste kennis, de juiste mensen en feiten waarop organisaties hun strategie en beleid kunnen baseren. Het bedrijf helpt bij het verbeteren van de inrichting en besturing van de IT-infrastructuur en -consumptie.

4 IT FlexRates

METRI volgt al jaren de tarieven van veel voorkomende IT-rollen op de voet. Organisaties, die met een flexibele schil werken, hebben er belang bij om de inhuurtarieven transparant te maken. Betaal ik te veel of juist te weinig voor de verschillende IT-rollen is een kardinale vraag in een effectieve wervingstrategie. Met de tool ITFlexrate, gebaseerd op de uurtarieven database van METRI, krijg je inzicht.

3 Een Business aanpak van security

Organisaties hebben onvoldoende zicht op de impact van cyberdreigingen. Bij security wordt nu vaak gedacht aan technische oplossingen als firewalls en het toepassen van twee vormen van authenticatie bij het inloggen. Terwijl deze maatregelen in de praktijk beperkt effectief zijn om ongeautoriseerde gebruikers buiten het bedrijfsnetwerk te houden.

Er is een andere aanpak nodig, waarbij meer aandacht is voor organisatorische maatregelen. Aandacht voor het verbeteren van het beveiligingsbewustzijn bij alle medewerkers is een goed voorbeeld van zo’n voor veel organisaties nieuw accent. Door cyberdreigingen als bedrijfsrisico te verkennen en security beleidsmatig stap voor stap op een hoger plan te brengen, kunnen organisaties het tij keren.

2 Zicht op de flexibele schil

De IT-arbeidsmarkt vertoont veel tekenen van oververhitting door het aantrekken van de economie. De tekorten op de IT-arbeidsmarkt zijn inmiddels groter dan voor de crisis tien jaar terug. De toegenomen vraag naar specifieke IT-kennis en ervaring heeft zijn gevolgen voor de inhuurtarieven van extern IT-personeel. Het tarief van IT-flexkrachten die rechtstreeks vanuit een detacheringsovereenkomst of die als zelfstandige ingehuurd worden is sinds 2015 gemiddeld met 4% gestegen. De inhuur vanuit beheer of mantelcontracten geeft organisaties toegang tot lagere tarieven voor veel gevraagde rollen als database administrator of security specialisten.

1 Robotisering van de servicedesk

Praten tegen een virtuele assistent of routinematige handelingen als password reset door een robot laten afhandelen. Bij end user management heeft robotisering aantoonbare toegevoegde waarde, mits deze software robots niet als een gimmick worden ingezet maar vanaf het begin de business waarde centraal staat. De claims dat toepassingen op basis van kunstmatige intelligentie servicedesks veel beter laten functioneren zijn hard te maken als organisaties robotisering inzetten als onderdeel van een breder programma om servicemanagement te vernieuwen.

Impact digitalisering op het aanbesteden

2018 is het jaar dat digitalisering als trend voluit doorzet. Zowel aan de voorkant als initiatief vanuit de business als ook IT-afdelingen die flinke stappen in die richting zetten. Digitalisering begon een paar jaar terug allemaal vanuit de adoptie van trends als bijvoorbeeld Cloud First, Data Mining, Automation en IoT implementaties. Dit jaar zijn dit soort trends vanuit de business kant breed ingezet. Veel van de IT-leveranciers passen hun organisaties aan op deze vraag en kopen ontbrekende expertise en specifieke capabilities en domeinkennis rond thema’s als bijvoorbeeld customer experience, het digitaliseren van producten en diensten en data gedreven besluitvorming. Sourcing is uitgegroeid tot Strategic Sourcing: op continue basis de samenhang zoeken met de business doelen.

Het wordt de klant steeds duidelijker dat samenwerking noodzaak is, gezien de lappendeken aan benodigde expertises. Co-creatie, eco-systemen en wendbaarheid zijn de nieuwe toverwoorden. De klant heeft geen behoefte meer aan een ouderwetse end to end sourcing strategie maar aan een op business thema’s gerichte innovatie en strategie aanpak. Het karakter van de markt verandert hierdoor. De markt voor sourcing ontwikkelt zich goed, maar dat uit zich niet direct in grote deals. Eigenlijk zijn er dit jaar maar een paar echte grote deals die spelen in de markt. Dat zijn het Ministerie van Defensie en UWV.

Om echt het maximale uit de samenwerking met traditionele en nieuwe leveranciers te halen investeren klanten veel tijd en geld aan het opzetten van een regie organisatie die agile aansluit op de business behoeften. Die vraag wordt dynamisch vertaald naar beheersbare realisatie door de leveranciers. Langdurige strategische samenwerkingen met een paar kernleveranciers zijn daarin opvallende basiselementen. Zorgvuldig voorbereide contractverlengingen zijn aan de orde van de dag. Toetsing door een onafhankelijke partij van het te realiseren prijs- en kwaliteitsniveau hebben daarbij aan belang gewonnen.

Enkele specifieke trends:

Sourcen van applicatieontwikkeling

Bij contracten voor applicatieontwikkeling speelt de low-code trend een steeds grotere rol van betekenis. Een opmerkelijke bevestiging van de sterke opkomst van low-code is te zien in een marktuitvraag voor application-delivery-platform-as-a-service dienstverlening (aPaaS) door Surfmarket eerder dit jaar. Deze inkooporganisatie voor het hoger onderwijs (HBO en universiteiten) in Nederland sloot een mantelcontract met één leverancier, die de gestandaardiseerde softwareontwikkeling vanaf één PaaS-platform faciliteert voor alle organisaties die onder dit raamcontract vallen. Dat was niet de enige organisatie uit de publieke sector die met low-code aan de slag ging. De aanbestedingscasussen voor aPaaS van Prorail (Mendix) en gemeente Zaanstad (Bettyblocks) vielen ook op dit jaar.

Ruimte voor meer innovatie door low-code

Een aanzienlijk deel van de softwareleveranciers gebruikt low-codeplatformen als basis voor hun dienstverlening. IT-dienstverleners passen een bestaand onderhoudscontract aan en baseren de dienstverlening op een low-code platform om sneller te kunnen leveren en de onderhoudskosten naar beneden te krijgen. Met low-code verschuift de traditionele verhouding van 80% van het budget voor operationeel beheer van software versus 20% voor innovatie naar een verhouding van fifty-fifty. Door de lagere beheerkosten komt er meer geld vrij voor innovatie. Door de legacy bij een klant te transformeren, wordt onderhoud goedkoper en komt er meer ruimte voor innovatie zonder extra kosten voor de klant. Zo krijgt de populariteit van low-code platformen ook aan de aanbodzijde een impuls.

De adoptie door leveranciers gaat op dit moment hard. Atos heeft naast OutSystems ook een flinke poule consultants opgeleid om de low-code van Thinkwise te gebruiken. Mission critical Schuberg Philis, wil low-code als basis gebruiken om klanten te begeleiden in bredere digitale transformatie trajecten. Dit alles is te vinden in het strategic report over low code waar naast Thinkwise en Schuberg Philis ook Mendix, Outsystems en Cast Software aan mee hebben gewerkt.

Metri ziet de sterke opkomst van low-code softwareontwikkeling als een kans, maar tegelijkertijd ook als een risico. De wens vanuit de business om applicaties te bouwen is op een traditionele manier niet bij te benen. Low-codeplatformen helpen een business idee snel tot realisatie te brengen.

Risico’s

Maar hierin schuilt tegelijkertijd een risico. Als werknemers zonder formele IT-achtergrond applicaties op grote schaal gaan ontwikkelen of als er bedrijfskritische software met deze platformen gebouwd wordt, dan heb je waarborgen nodig rond kwaliteit en security. Best practices rond onderhoudbaarheid, performance of security kunnen uit beeld raken met alle gevolgen voor de kosten op de langere termijn. Ook bij low-code is daarom zicht op de kwaliteit nodig om de totale levensduurkosten beheersbaar te houden.

Meer dialoog

2018 is het jaar waarin het sourcen een nieuw gezicht leek te krijgen. De vorig jaar op rijksniveau begonnen trend van een dialoogfase in grote mantelcontracten dook dit jaar ook elders in de markt op. Zo ging Rijkswaterstaat met meerdere marktpartijen in overleg om de uitbesteding van netwerkdienstverlening voor te bereiden. Om optimaal aan te sluiten bij de trend van programmeerbare netwerken en een bijbehorende aanbestedingsstrategie kwam er een dialoog met meerdere marktpartijen over ontwikkelingen rond software defined networking. Deze dialoog leidde ertoe dat deze kavel in twee delen werd opgedeeld. Naast traditioneel operationeel beheer van het bestaande netwerk kwam er ook een kavel die tot doel had om het beheer van netwerkvoorzieningen tot in hoge mate te automatiseren.

Vliegtuigpassagier aan de stuurknuppel?

Is dat niet net zoiets als de business verantwoordelijk maken voor IT? Eerst naar de cockpit. Vliegen wordt steeds beter ondersteund door zogenaamde avionica: elektrische systemen aan boord, navigatietoepassingen en vluchtgeleiding. Betekent dit dan ook dat eenieder veilig van A naar B kan vliegen? Natuurlijk niet. Maar ik denk dat je met enige basiskennis en de huidige stand van de techniek een heel eind komt, als de omstandigheden meewerken tenminste.

De uitdaging start als het systeem niet meer aan de verwachtingen voldoet of de omstandigheden onvoorspelbaar worden. Om met het laatste te beginnen: een ervaren piloot heeft een grotere kans een toestel veilig rond een onweersgebied te navigeren. Maar ook bij systeemfalen kan een piloot nog veilig handelen, terwijl een leek waarschijnlijk de verkeerde beslissingen neemt.
Bij de inzet van IT lijkt een dergelijke vergelijking niet onrealistisch. Laten we nog even in hogere sferen blijven: als passagier zou ik graag bepalen waar en wanneer en volgens welke route ik van A naar B vlieg. Van alle gemakken voorzien, binnen mijn doelstelling, snel, maar natuurlijk ook veilig. Maar we begrijpen allemaal dat dit misschien niet de meest (bedrijfskritisch) verstandige invulling is voor het bereiken van mijn reisdoel.

Tot zover de analogie met de luchtvaart. Steeds vaker neemt bij de ontwikkeling van IT-oplossingen de business het roer over van centraal georganiseerde IT. Methodieken als agile en devops zijn hier volledig voor ingericht en lijken steeds meer invulling te geven aan de bedrijfsdoelstellingen. Het werken aan gewenste functionaliteit op het moment dat je het (bijna) nodig hebt klinkt logisch en effectief. En dit zal best zo zijn, maar…

Wat als de voorspelbaarheid van de onderliggende techniek niet voldoet aan de verwachting of als de omgeving tóch weerbarstiger is dan ingeschat?
In mijn beeld van de werkelijkheid kan het één – informatietechnologie – niet zonder het ander – de business: het is verstandig om de techniek een plaats te geven in de bedrijfsdoelstellingen. En gelukkig zijn er op dit vlak gunstige ontwikkelingen: er komt steeds meer tooling beschikbaar om de technische kant van applicatieontwikkeling door business-georiënteerde bestuurders te laten beoordelen. Het vroeg constateren van mogelijke problemen die zijn veroorzaakt door technische ‘fouten’ zal veel leed bij de business voorkomen, wat op de lange termijn meer waarde zal bijdragen voor alle stakeholders. Bewustwording hiervan lijkt het sleutelwoord.

METRI werkt al geruime tijd samen met software intelligence specialist CAST. Samen hebben we diensten ontwikkeld waarmee je op alle niveaus binnen de applicatie-ontwikkelketen inzicht verkrijgt. De tooling onderzoekt de technische bouwblokken van de door de business gevraagde oplossing. Dashboards en marktvergelijkingen geven inzicht in de technische kwaliteit en eventuele risico’s, en onderbouwen de businessdoelstellingen met op feiten gebaseerde marktwaarden. Echte samenwerking tussen techniek en toegevoegde waarde. Dus misschien toch een passagier in de cockpit, maar dan als goed geïnformeerde co-piloot. Zo kun je samen tot grote hoogte stijgen!