Wat kost een uurtje software ontwikkeling?

Laatst was een vriend van me op zoek naar een nieuwe schoonmaker (m/v) voor een dag in de week. Hij was daarbij uurtarieven aan het vergelijken en vond het vreemd dat er zo veel verschil in die tarieven zit. Ik werk natuurlijk bij een bedrijf dat aan benchmarking doet, dus hij vroeg aan mij hoe dit kon en welke hij moest kiezen. Op zich een uitstekende vraag! Het antwoord wat ik gaf komt later…

Metri wordt veel gevraagd om uurtarieven onderzoeken uit te voeren. Leveranciers die IT personeel, op basis van Time & Material (uurtarief), inzetten in de markt willen bijvoorbeeld weten hoe marktconform hun tarieven zijn. We zien ook veel contracten tussen klanten en leveranciers, waarin applicatie ontwikkeling wordt gecontracteerd op basis van uurtarieven. Dit is dan vaak een ratecard die per functie/rol en skill level aangeeft voor welk tarief een leverancier een bepaalde functies/rol wil leveren aan die klant. Dit zijn dus geen specifieke mensen, maar tarieven voor een aantal functie/rollen. Klanten vragen ons dan om de ratecard op marktconformiteit te checken. Iets wat we uiteraard graag doen, maar je kunt je afvragen hoe effectief dat is.

Met name als het gaat om het (door) ontwikkelen van software zijn de verschillen in productiviteit en geleverde kwaliteit erg groot. In de Agile Team Performance Monitor onderzoeken die we doen, zien we soms enorme verschillen in productiviteit en kwaliteit. Zie het volgende figuur voor de verschillen die we zien in de markt tussen ‘high performing’ en ‘low performing’ teams.

De eerste 4 metrieken geven de performance van het team aan, de laatste 5 metrieken geven aan wat de kwaliteit is van de opgeleverde code.

Gegeven deze verschillen in performance en kwaliteit, zou je dan niet liever een paar euro per uur meer betalen voor mensen die erg productief zijn en goede kwaliteit leveren? Je zou zelfs kunnen beargumenteren of het averechts werkt om te proberen zo goedkoop mogelijke uurtarieven of ratecards te contracteren voor dit soort werkzaamheden, want dan krijg je als klant waarschijnlijk niet de beste mensen geleverd. Gezien de grote verschillen, wil je voor het door ontwikkelen van bepaalde kritische applicaties, die veel business waarde genereren, misschien wel de allerbeste en dus duurste mensen hebben en dat zijn lang niet altijd de senior of managing skill levels.

Metri uurtarieven

Je kunt je ook afvragen of leveranciers belang hebben bij het zo productief mogelijk ontwikkelen, of juist meer belang hebben bij het zoveel mogelijk besteden van uren. Ze worden immers per uur betaald. Zeker in agile omgevingen, waar vaak toch al niet heel erg gestuurd wordt op productiviteit, zien we vaak dat de kosten gierend uit de bocht vliegen, de datum, waarop bijvoorbeeld het MVP klaar zou moeten zijn, bij lange na niet gehaald wordt en dan blijkt vaak ook nog dat de code kwaliteit bedroevend slecht is en vol risico’s zit.
Ik ben zelf voorstander van output of outcome based contracting. Spreek bepaalde targets af met betrekking tot productiviteit en kwaliteit en bepaal vervolgens wat de prijs is wat daarvoor betaald moet worden. Metri noemt dit Value Driven Contracting. De klant betaalt vervolgens extra bij performance die beter is als afgesproken en minder als de performance slechter is dan afgesproken. Om discussies te voorkomen moet de performance dan wel objectief gemeten worden uiteraard!

Ik heb mijn vriend geadviseerd niet zozeer naar de tarieven te kijken van de schoonmakers, maar iemand te kiezen die bereid is om voor een bepaalde prijs zijn huis schoon te maken en die daarbij garanties wil afgeven ten aanzien van het resultaat. Duidelijke afspraken over welke werkzaamheden worden uitgevoerd en het resultaat daarvan. Eventueel zou je kunnen afspreken wat extra te betalen als je super tevreden bent of wat minder als het resultaat minder is dan afgesproken. Dit heeft als voordeel dat een goede en productieve schoonmaker meer kan verdienen in minder tijd en dat het huis goed wordt schoon gehouden. Mijn vriend is superhappy en zijn schoonmaker doet echt zijn best om de extra inkomsten te verdienen. Een echte win-win dus!

Zicht op applicaties versnelt cloudmigratie

METRI Cloud Migratie

Het besluit is genomen: na een aantal experimenten en voorzichtige stappen heeft het hogere management besloten dat de organisatie naar de cloud gaat. Dan begint het echte werk pas. Een cloudmigratie die gebaseerd is op strategisch inzicht in het applicatieportfolio voegt de meeste waarde toe en kan zo’n verhuizing in een versnelling brengen.

Een migratie naar de cloud is voor de meeste organisaties een ingrijpende gebeurtenis. Processen, legacy-apparatuur en applicaties moeten tegen het licht gehouden worden. Passen ze nog in de cloud-strategie? Kunnen we ze vervangen door cloud-varianten of kunnen ze ‘lift and shift’ verplaatst worden? Het hele proces blijkt vaak een kwestie van experimenteren, migreren en transformeren.

De eerste stap is om de rest van de organisatie ook mee te nemen. Voor de meeste gebruikers is IT een basisvoorziening die het vooral moet doen. Een migratietraject dat voor hen geen meerwaarde oplevert, maar wel ongemak en risico’s, zitten ze niet op te wachten. Zonder degelijke uitleg vooraf, over het hoe en waarom, zal de bereidheid tot medewerking niet groot zijn.

Vervolgens worden applicaties die naar de cloud moeten in beeld gebracht. Dat is ingewikkelder dan het lijkt. Vaak is er binnen IT al geen eenduidig overzicht van de applicaties die er zijn, laat staan van alles wat er buiten IT om is gekocht of gebouwd.

Als het applicatieoverzicht er eenmaal is, is het van belang om vast te stellen hoe de applicaties gemigreerd zouden moeten worden naar de cloud. Het bekendste model hiervoor is dat van AWS: het ‘6R model’ (6 Strategies for migrating applications to the cloud) om het overzetten van applicaties naar cloud infrastructuur te versnellen. Applicaties worden in dit model langs de meetlat gelegd, om uiteindelijk in één van de zes ‘R’ bakjes te vallen:

  • Retire:
    De applicatie is niet meer nodig of levert te weinig waarde, ten opzichte van de kosten, en wordt daarom uit gefaseerd.
  • Retain:
    De status quo rond een applicatie blijft voorlopig gelijk. Deze keuze is relevant als een applicatie een beperkte levensverwachting heeft of ongeschikt is om naar de cloud over te zetten, bijvoorbeeld vanwege bijzondere eisen of eigenschappen van de applicatie, of technologisch zwaar verouderd. Retain moet altijd worden gezien als een tijdelijke oplossing; je zit er immers niet op te wachten om voor een beperkte verzameling applicaties een dure uitzonderingspositie te handhaven.
  • Rehost:
    De applicatie gaat één op één naar de cloud (‘lift and shift’). Dit is doorgaans een snelle, goedkope en relatief risico vrije manier om te migreren, maar levert ook geen meerwaarde op. Immers, bestaande problemen zullen ook één op één meegaan naar de cloud. In de praktijk brengt deze keuze vaak hogere infrastructuurkosten met zich mee voor de applicatie. Organisaties betalen de flexibiliteit van de cloud met een hogere uurprijs dan in een marktconform geprijsd datacenter.
  • Replatform:
    Voor de applicatie wordt een nieuwe infrastructuur gebouwd in de cloud, de software zelf blijft onaangeroerd. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvoor de organisatie alleen een gebruikslicentie heeft en geen eigendom van de broncode. Dit is bijvoorbeeld bij standaardpakketten het geval. Ten opzichte van een rehost is dit een complexere en dus duurdere en minder snelle manier van migreren. Het levert wel meerwaarde op doordat er optimalisaties gedaan kunnen worden en bestaande problemen opgelost kunnen worden. Zonder de software aan te passen zijn de mogelijkheden beperkt en zal ook de meerwaarde beperkt zijn.
  • Refactor:
    Voor de applicatie wordt een nieuwe, zo optimaal mogelijke, infrastructuur gebouwd in de cloud en wordt de software aangepast, zodat deze optimaal op de cloud infrastructuur draait. De functionaliteit verandert in principe niet. Vaak is er overigens geen sprake van een infrastructuur in de klassieke opvatting, maar van een PaaS platform waar de software op landt. Deze aanpak is vooral geschikt voor de migratie van applicaties waarvan de organisatie eigenaar is; bijvoorbeeld maatwerk. Ten opzichte van replatform is hier opnieuw sprake van een hogere meerwaarde. Dit loopt echter tegen zijn grenzen aan door de eigenschappen van de software.
  • Repurchase:
    De applicatie wordt in zijn geheel opnieuw aangeschaft of gerealiseerd. Hierbij kan maximaal gebruik worden gemaakt van de diensten van cloud serviceproviders, maar de weg is lang en kostbaar. Je praat immers over een totale vervanging, waarbij ook de functionaliteit zal veranderen en je dus ook de organisatie zal moeten aanpassen en trainen om van de nieuwe oplossing gebruik te maken.

Bovenstaand overzicht lijkt helder. Als je gedetailleerd naar de materie kijkt, is het veel minder eenduidig dan het in eerste instantie lijkt. Er is bijvoorbeeld niet één meetlat langs welke je de applicaties legt. Bijvoorbeeld: als ik een applicatie één op één verplaats, maar een instelling wijzig omdat de nieuwe omgeving dat eenmaal vereist (bijvoorbeeld een andere locatie voor de database), is het dan al een replatform? En als het er twee zijn? Of tien? Of als ik het meer recente versie van het besturingssysteem neem? Bovendien zijn de kosten meer dan één aspect: organisaties die al gebruik maken van de cloud ontdekken dat kostenbesparingen maar een beperkt deel zijn van de waarde die cloud biedt. De cloud biedt vooral ook mogelijkheden voor innovatie.

Strategisch inzicht in het applicatieportfolio kan een cloudmigratie in een versnelling brengen, omdat zo’n analyse business waarde en de kwaliteit van software in de beoordeling meeneemt. Veel organisaties hebben hier geen inzicht in. Zij managen het portfolio alsof alle applicaties gelijk zijn en/of gelijkwaardige problemen hebben. Daarnaast wordt er niet goed op waarde geschat wat het bedrijfsbelang van een specifieke applicatie is. Hierdoor is het lastig om de juiste prioriteiten te stellen. Met de Metri Applicatie Portfolio Strategizer wordt er per applicatie een passend migratieplan vastgesteld, die in een bredere cloudmigratie in te passen is.

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 gebruiker aan het roer

Verandering is de norm. Dat is al zo sinds het ontstaan van ons universum. Het ziet er niet naar uit dat daarin ooit stagnatie zal optreden. Sterker nog, verandering gaat – cultureel gesproken, voor de mensheid – steeds sneller. De hoeveelheid informatie die we nu op één dag verwerken schijnt overeen te komen met de informatie die onze voorouders in de achttiende eeuw per jaar te verwerken kregen. Blijkbaar hebben we een groot aanpassingsvermogen. En als we het over aanpassingen hebben, komen we al snel in de wereld van innovatie en IT.

Alles moet sneller, mobieler, gevarieerder, het moet overal kunnen en natuurlijk veilig zijn. En alles moet natuurlijk samen, moet gedeeld! In de wereld van sociale media is dit uiteraard het belangrijkst. Ik deel alles op één centraal punt en de rest van mijn sociale omgeving kan daar kennis van nemen. Vaak direct, of misschien iets later. Toch lijkt het erop dat we hier tegen de grenzen van ons verwerkingsvermogen oplopen. Hoeveel appjes, Facebook-updates, sms-berichten en e-mails kun je nu echt tot je nemen, naast al je werk en privé-verplichtingen? Een probleem dat schreeuwt om een slimme oplossing.

Ook op een andere dimensie, op het technische vlak, zien we spanning optreden. Aangezien de software van onze toepassingen zo snel mogelijk moet kunnen vernieuwen (continuous development) en direct beschikbaar moet zijn (continuous deployment) doet zich een betrekkelijk nieuw fenomeen voor. Iets wat nú werkt doet het misschien over twee minuten niet meer. Een door Apple gepushte update verstoort bijvoorbeeld de werking van mijn draadloze koptelefoon – van een ander merk. Ineens reageert de volumeknop niet meer.

Dit soort problemen zijn gemeengoed geworden, maar ze impliceren een draai van 180 graden. Voor ik het doorhad werd ik IT-beheerder van mijn eigen gadget en kon ik meerdere updates uitvoeren op mijn telefoon, koptelefoon (firmware) en instellingen. Het kan, dat is mooi. Een heel verschil met vroeger, toen eenmaal aangeschafte functionaliteit een hard, onveranderbaar gegeven was. Maar het geeft wel aan dat het beheer nog steeds ergens en door iemand uitgevoerd moet worden. Dat er blijkbaar ook continu analyses uitgevoerd moeten worden op de juiste werking van middelen. Nog een probleem dat schreeuwt om een oplossing. Waar zit hier het verdienmodel?

Benodigde aanpassingen die door derden in gang worden gezet zouden eigenlijk niet uitgevoerd hoeven te worden door de eindgebruiker, de laatste schakel in de keten. De laatste, beslissende stap bestaat uit het al dan niet installeren van de nieuwste softwareversie. Als je echter geen idee hebt van de potentiële negatieve gevolgen van een update, waarom zou je hem dan installeren? Moderne apps informeren de ontwikkelaars (met toestemming van de eindgebruiker) nu al automatisch over geconstateerde problemen. Bij goed gebruik en inrichting levert dit een schat aan informatie op waarmee de ontwikkelaar de kwaliteit kan verhogen.

Dit wordt ook wel noodzakelijk onderhand. Interactie tussen met name draadloze technologie maakt het monitoren op lokaal niveau essentieel: de bron van updates naast de functionele wijzigingen. De eindgebruiker moet hierover relevante informatie ontvangen in begrijpelijke taal, zodat hij goed geïnformeerde beslissingen kan nemen. Hoe dan ook, de realiteit is dat ik, als eindgebruiker, aan de knoppen kom te zitten van essentiële wijzigingen.

Dit is een trend die zich ook binnen grootzakelijke IT-oplossingen meer en meer aandient: de business aan het roer van IT-veranderingen. Dit is wel een diepgaande verandering, die veel van ons – gebruikers én leveranciers – gaat vragen. Want ik heb het over wijzigingen waarover de communicatie in één dag gelijk is aan wat we nu ongeveer in een heel jaar ontvangen, maar dan zonder dat we het merken.

Functionaliteit is het doel, de IT het middel. Hoe dan ook, de business gaat aan het roer van vernieuwing, waarbij het schip – de onderneming – zijn zeewaardigheid niet mag verliezen. Functionaliteit en kwaliteit gaan hand in hand, om ook op de lange afstand de juiste koers aan te kunnen houden.

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!

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?

Elke onderneming denkt na over innovatie. Bij een antwoord op de vraag hoe men vooruit wil komen in de digitale wereld is software vroeg of laat een essentieel ingrediënt in het antwoord. Applicatieontwikkeling wordt door veel bedrijven gezien als de motor achter nieuwe bedrijfsmodellen en marktkansen. Hoe laat je dat werken als de applicatiestack voor een belangrijk deel bestaat uit legacysoftware? Bedrijfsapplicaties met een aanzienlijke levensduur ondersteunen nieuwe platformen en devices slecht heeft de praktijk geleerd. En vooral: waar zijn de programmeurs om deze plannen te realiseren?

Abstractielaag

Op dit moment hebben veel organisaties low-code omarmd om hun software gedreven toekomstplannen te realiseren. Of zij zijn van plan om dit te doen. Low-code is de benaming van een nieuwe generatie programmeerhulpmiddelen die tot op een hoog niveau de abstractielaag van modellen gebruiken om het proces van softwareontwikkeling te versnellen. Een tweede pluspunt is een platform aanpak waardoor de ontwikkeling, het testen en het live brengen van applicaties volledig gestroomlijnd is. Deze twee zaken verhogen de productiviteit van softwareontwikkeling. Van een plan tot een werkende applicatie kost met een low-codeplatform minder tijd en moeite is het idee.

Daarnaast zorgt deze modelgebaseerde aanpak ervoor dat werknemers met hooguit wat basis programmeerkennis het grootste deel van applicatieontwikkeling voor hun rekening kunnen nemen. Dat klinkt bedrijven in de huidige IT-arbeidsmarkt als muziek in de oren. Een nieuwe groep ‘citizen developers’ die model gedreven software kan ontwikkelen, lijkt de innovatieplannen een impuls te kunnen geven. “Mijn gevoel bij zulke low-code platforms is vrij conservatief”, vertelt Lev Lesokhin. Hij is binnen CAST Software verantwoordelijk voor de software intelligence-strategie en de wereldwijde productmarketing. Lesokhin zit daarnaast in het bestuur van het Consortium voor IT Software Quality en de TMMI Foundation, twee internationale comités die een hogere kwaliteit en efficiëntie van softwareontwikkeling nastreven.

Het zwaartepunt voor toepassing van low-codeplatformen is verschoven van mobiele apps en workflow achtige toepassingen naar het vervangen van legacy software. “Organisaties die low-code inzetten zullen snel vooruitgang boeken”, vervolgt Lesokhin. “Zodra je met deze tooling op grotere schaal functionaliteit uitwerkt, zul je zien dat het applicatiebeheer strategische aandacht nodig heeft. Portfoliobeheer is belangrijk als je een grotere verzameling applicaties opbouwt en wilt onderhouden.

Zo zul je met het modelgedreven werken in het low-codeplatform niet alle benodigde functionaliteit kunnen realiseren. Het low-codeplatform zal gaandeweg met steeds meer specifieke wijzigingen te maken krijgen die niet met de modelfunctionaliteit is uit te werken. Dit wordt gerealiseerd inklassieke handgeschreven softwarecode, wat onderdeel wordt van het applicatieportfolio. Hier moet je op een structurele manier mee omgaan om het beheersbaar te houden. En je moet zicht hebben op de kwaliteit van de code zoals deze door het low-code platform wordt gemaakt bij de automatische vertaling van model naar softwarecode. “Neem het niet voor waar aan dat de softwarecode zoals een low-codeplatform dat genereert van zichzelf veilig en efficiënt is”, verduidelijkt Lesokhin. “Als je een omvangrijke verzameling aan applicaties aan het bouwen bent, moet je daar wel zekerheid over hebben. Applicaties moeten veilig zijn en efficiënt gebruik maken van het onderliggende platform.”

Kwaliteit en veiligheid

Low-codeplatformen zijn erop gericht om snel functionaliteit te bouwen. Op de lange termijn kan de kwaliteit en de veiligheid van deze applicaties een issue worden. “Grotere organisaties moeten grip houden op de onderhoudbaarheid van de codebasis om de kosten van het applicatiebeheer tijdens de gehele levenscyclus van een applicatie binnen de perken te kunnen houden”, vervolgt Lesokhin. “Vanuit de ervaring van CAST zien we dat sommige codegeneratoren die ingezet worden bij business procesmanagement een kwaliteit code genereren die van problematische kwaliteit is. Als gebruikersorganisatie zul je de vinger aan de pols moeten houden bij essentiële kwaliteitsaspecten ook als je met low-code applicaties werkt.”

Doe je dat niet dan krijg je vroeg of laat de rekening gepresenteerd. Het toevoegen van nieuwe software wordt lastiger en de onderhoudskosten springen hierdoor omhoog. Er is een reële kans dat de flexibiliteit waarmee je snel applicaties kunt bouwen het beheer van deze applicatiestack op de langere termijn lastiger maakt. Organisaties moeten zich daarvan bewust zijn als zij in low-codeplatformen een middel zien om hun legacy te vervangen.
De reële voordelen van low-codeplatformen, zoals het faciliteren van ‘citizen developers’ die op eigen kracht applicaties samenstellen, zijn een aantrekkelijke optie voor bedrijven. Maar organisaties moeten zich tegelijkertijd realiseren dat deze vrijheid gepaard moet gaan met bepaalde verplichtingen om het applicatieportfolio beheersbaar te houden. “Doe je dat niet”, waarschuwt Lesokhin, “dan zal low-code op termijn op zijn best een reddingsboei blijken en niet de springplank naar een nieuwe toekomst die je voor ogen had.”

Transparantie essentieel

Een uitgebreide applicatiestack kan niet zonder monitoring van de kwaliteit. CAST Software is een bedrijf dat transparantie biedt in de productiviteit en structurele kwaliteit van software en de risico’s die hiermee gepaard gaan. De analyses gaan verder dan componentniveau door de architectuur en structurele complexiteit van applicatiesystemen te onderzoeken om gedetailleerd inzicht te krijgen in de manier waarop individuele componenten het hele systeem beïnvloeden. Bij zo’n analyse op systeemniveau komt vaak nog het nodige naar boven omdat reguliere softwaretesten zich vaak beperken tot een specifieke subset van een toepassing buiten een productieomgeving.

Financial savings just the beginning for CIOs who understand code quality

Businesses need to understand the quality of the code in their applications if they are to avoid unnecessary costs and glitches.

Whether a multibillion-pound financial firm or an online training company, software is the lifeblood of an organisation. If core applications don’t work, business stops.

The move to digital business models puts pressure on software development teams to create and adapt software more quickly and at a lower cost, which in turn increases the risk of things going wrong. But while board-level directors might have blank faces when IT approaches them about the importance of understanding software code quality, there is hope for CIOs seeking extra resources to improve software quality. The ability to use metrics to back up anecdotal evidence will help CIOs win the argument.

At an event hosted by Cast, a company that helps its customers understand software quality, IT leaders from companies including a US financial services giant, Sony Pictures Entertainment, ING, Sita, and Dutch training and education organisation NCOI, described the benefits they have reaped by gaining visibility of the software code that underpins their business.

A recent Cast survey of 500 developers across four countries suggested that a third of developers are not held accountable for poor code quality. This is because businesses do not have information about it at their disposal.

It found that more than a third (37%) of developers are not graded on code quality. In France, this figure goes up to 45%, compared with 39% for Germany and the UK, and 27% for the US. Due to this lack of software intelligence across internal teams, businesses are paying for code that is below the required quality, and suppliers are not incentivised to improve.

IT downtime can be costly

The stakes are high. Toine van Eeden, CIO at NCOI, said a large proportion of customers find the company’s courses online, so if systems are down, the company’s business is, in effect, offline. A couple of hundred contact centre workers will simply be keeping seats warm as people looking for the right educational course go elsewhere. “Every hour we are offline means €100,000 in lost sales,” he said. Understanding software quality through a software intelligence program is the answer for Cast customers. By running their code through Cast’s application intelligence platform, they can get metrics about software quality.

NCOI, a 20-year-old organisation that offers online and campus-based training and education, started using the platform about a year ago. CIO van Eeden, who is not an IT professional by training, sits on the company’s board.

Despite the company’s relative youth, it has acquired companies that date back to the 19th century, hence it has had to integrate a host of software applications, including legacy systems, from the acquisitions. “When we acquire companies, we do not keep the legacy systems, but paint them in the colour of our company,” said van Eeden.

NCOI’s big applications, which take up the most development time, are its enterprise resource planning (ERP) system and a portal that supports students and 6,000 teachers. The student and teacher portal is currently being built, while the ERP system is being replaced, so there is a lot of software development work being undertaken. All of NCOI’s development is carried out by a supplier in a nearshore location in Romania.

Streamlining software development

When van Eeden joined the company, he quickly realised that its software development processes were inefficient. “When I entered the company two years ago, we had 80 people in Romania. We only turn over €256m, so this number seemed ludicrous. But the company was making so many changes to software that it needed them. After looking deeper, it became clear that this was not being managed,” he said.

“We used to just answer the suppliers’ questions and they would build it, and we would then ask them to test it because we were too busy. Then we would often get things back and find it was not what we asked for.” But over the past 12 months, using Cast’s platform to help it understand the software it has, NCOI has been changing this. “We make sure we are more involved, to ensure we don’t provide developers with loads of irrelevant information,” said van Eeden.

“We decided only to ask for something if we really knew what we wanted, otherwise you get a lot of bouncing backwards and forwards between the business and developer. These developers cost a lot of money, so we now only ask questions if we know they can deliver.” He said many companies think the suppliers manage everything, so they end up in a situation where nobody manages it and there is no incentive for the supplier to do the best it possibly can.

In the past, if NCOI wanted to do something new it would just request more developers. The people in control at the time had lost control, said van Eeden, so the company started using metrics to see how bad it was. “I am not really a tech guy, but I like to have facts so I asked around for help with the problem.” Working with a benchmarking company, van Eeden was put in contact with Cast, which now provides NCOI with a platform-based software intelligence service. “We hand them the code and they put it in a machine that analyses everything and tells us the quality in terms of productivity, security and other things, and then a benchmarking firm takes it and compares it to the market.

It is not just about cutting costs, but improving development productivity and code quality. In the past year, NCOI has fed code into the Cast system four times, but is moving to a contract to enable it to do so monthly to keep up with more regular software updates. “This is so we can refresh our portal every month,” said van Eeden. Ironically, since using the Cast system NCOI has been using more developers because it is doing more development. “For our core ERP application, we have doubled software development productivity,” said van Eeden. “My output doubled, and the quality in the sense of downtime and the number of bugs also improved dramatically.”

Van Eeden said he knows there have been no software outages since the company has been using the software intelligence platform, whereas previously it “didn’t even look at the robustness of systems”.

How to justify the cost of software intelligence

On the face of it, the NCOI story is a good use case. But convincing the non-technical board of a financial giant to change the firm’s software development processes is not an easy sell for CIOs.

For example, the financial services sector is heavily reliant on systems, with any downtime or security breach potentially highly damaging. But that isn’t always enough to entice the board to invest in software to measure the quality of code, according to one CIO at a large US financial services firm. He explained how his team succeeded in justifying a software intelligence investment and some of the benefits it has generated.

“If I go back to 2014 [before we measured software quality] and calculate the cost of the function points then compared to now, we have saved the company about $200m in an annual investment cycle, and that has gone straight back into capacity to build better systems and being agile as a company,” he said.

“I am a firm believer in better and faster, with lower risk, higher quality and faster output. You only get that if you invest a lot in engineering,” he said.

The company is using Cast in all of its processes, and is using metrics from the platform to justify its software development budget demands. “This is an ongoing journey, but we had a specific set of targets to meet in the business case. We were able to use the Cast numbers to convince the CFO [chief finance officer], CEO and board to prove that we had improved,” he said.

The company used Cast as part of a transformation of IT at the company, which was part of a bigger project. “As part of the big project, there was a CFO team looking at this to see if we were doing what we were supposed to [in software development]. They were looking at hundreds of metrics, so when we said software was better quality, better time to market, with more functionality and all those kind of things, they could see it was true. The close monitoring we had from the finance side generated confidence that we were moving in the right direction.”

He said when they went on to share details with the CEO and the board, they presented a more overall picture, with some anecdotal stories to help the board understand. The anecdotal evidence to get them in the door, and then delivering the enterprise view with the metrics later, with the CFO team confirming the team’s findings.

As an example of anecdotal evidence, the CIO said he reminded board members that resetting the mortgage rates in a big application, which had previously taken nine months and cost $1m, was more recently done in one week for $10,000. He said taking examples like that to the board helps them understand the value.

Koop geen kat in de zak met software-ontwikkeling

Veel organisaties ontwikkelen software niet in eigen huis, maar besteden deze activiteit uit aan gespecialiseerde dienstverleners. Het is algemeen bekend dat veel softwarerealisatieprojecten spaak lopen en minder rendement opleveren dan vooraf gedacht en gehoopt. Het is minder bekend dat de plank al misgeslagen wordt door keuzes bij de start van een project.

Een bekende lakmoesproef voor het succes van softwarerealisatieprojecten is het ‘Chaos report’ van de Standish group, een expert in projectmanagent die jaarlijks een rapport uitbrengt waarin informatie over budgettering, deadlines en resultaat van duizenden projecten verzameld is. Uit deze cijfers blijkt dat nog steeds meer dan de helft (52%) van de projecten averij oploopt en maar liefst 19% in zijn geheel mislukt.

Anticiperen

Deze uitkomsten zijn opvallend, omdat er door de sterke opkomst van agile werken een veel voorkomend struikelblok uit de weg geruimd is. Door scrum toe te passen is er een veel betere interactie tussen de business, IT en het ontwikkelteam. Toch gaat er nog steeds het nodige mis en dat komt vooral doordat in de contractering, het gekozen prijsmodel en afspraken met leveranciers te weinig geanticipeerd wordt op succes.

Het is staande praktijk dat organisaties een tender voor applicatieontwikkeling in de markt zetten waarin de wensen en eisen op zijn best op hoofdlijnen te ontwaren zijn. De specificaties zijn eigenlijk niet gedetailleerd genoeg om een realistische prijs te kunnen berekenen. Dat is geen belemmering voor marktpartijen om met een bodemprijs in te schrijven en het project te winnen. Het is gebruikelijk om tijdens de realisatie van het project met nieuwe facturen en deadlines te komen als er meer sprints nodig zijn. Klanten moeten zichzelf niet rijk rekenen met zo’n bodemprijs. Te weinig zicht op het op te leveren product gecombineerd met een onrealistische inschatting van budget en tijdspad plaatst klant en leverancier later voor dilemma’s. Daarom is een goed begin het halve werk.

Prijsmodel

Bij het agile ontwikkelen van software is het gebruikelijk om applicaties in nauw overleg met de opdrachtgever in meerdere stappen of sprints te ontwikkelen. Bij dit soort projecten is de prijs doorgaans gebaseerd op de omvang en de ervaring van het team bij de leverancier. Hierdoor heeft de leverancier alleen een inspanningsverplichting en komen wijzigingen in de omvang en de deadlines volledig voor rekening van de klant. Het is beter om het prijsmodel ook bij scrum-projecten te baseren op realistische productiviteitscijfers. De beste eenheid om dat te doen is de functiepunt. Deze objectieve en internationale meeteenheid is aangepast aan de moderne tijd en is ook geautomatiseerd in te zetten.

Lees meer hierover op METRI Research.