Dagelijks geven we veel uit aan het realiseren van softwareoplossingen. Organisaties zien kansen om zich te onderscheiden en digitaal te innoveren met maatwerk. Deze software wordt tegenwoordig ontwikkeld met low-code-app-, -data- en -integratieplatforms en aangeboden door cloudleveranciers. De praktijk leert dat we zo op nog grotere schaal onbruikbare oplossingen produceren. Waar gaat het mis?
Een berucht artikel, ‘Why software fails‘ uit 2005 beschrijft dit in detail. Het is treurig te zien dat er nog niet veel veranderd is in de afgelopen vijftien jaar. In deze opinie belicht ik twee van de belangrijkste redenen voor het falen van softwareoplossingen:
- Unrealistic or unarticulated project goals: de strategie, aanpak en doelstellingen zijn niet duidelijk geformuleerd
- Badly defined system requirements : de wensen en eisen voor de oplossing zijn niet goed in kaart gebracht
Beide redenen zorgen ervoor dat je er op een laat moment in het traject achter komt dat de software niet brengt waarvoor het eigenlijk bedoeld was – en kun je waarschijnlijk grotendeels opnieuw beginnen. Een dure grap dus.
Platformstrategie en aanpak
Het inzetten van een low-code-platform om daarop maatwerk te realiseren is een strategische keuze voor elke organisatie. Maar met het aanschaffen van het platform is maar een klein hobbeltje genomen. Met welk doel gaan we dit platform inzetten? Welke leidende principes hanteren we? Welke bedrijfsdoelen gaan we helpen behalen? Hoe past het in het applicatielandschap en hoe gaan we om met informatiearchitectuur? Hoe gaan we deze verandering binnen de organisatie managen? Hoe meten we het succes?
Bij veel organisaties zien we nog steeds dat de it-afdeling hier een leidende rol speelt, terwijl het allemaal om business-oplossingen gaat. De business wenst zich te onderscheiden van de concurrenten en wil digitaal innoveren. Om zo een groter marktaandeel te behalen of de marges te verbeteren. Het innoveren van business-processen en daarmee verregaande optimalisatie door te voeren is iets wat niet thuis hoort in de ‘systems of record’. Dat zijn vaak robuuste, administratieve applicaties die ook eigenlijk commodity zijn. Steeds vaker zijn dit saas-applicaties. Iedereen gebruikt dezelfde.
Waar je het onderscheid kunt maken is in het slim aan elkaar koppelen van deze applicaties en cloudservices. Door data te verzamelen en verrijken en nieuwe inzichten te vergaren. Door het inzetten van kunstmatige intelligentie. En op de persona’s gerichte maatwerk-apps, die precies doen waar de betreffende persoon in het deel van het bedrijfsproces behoefte aan heeft. En liefst zonder al te veel in- of over te typen. Laat de gecombineerde data het meeste werk voor je doen.
Fouten gemaakt in strategie en architectuur (business-, applicatie- en informatiearchitectuur) kunnen dure gevolgen hebben. Hoe eerder je in het software voortbrengingsproces fouten weet te vermijden, hoe goedkoper het is. Zoals in het bovengenoemde artikel zo mooi is verwoord: als je een breifout hebt gemaakt en daar pas veel te laat achter komt, kun je bijna helemaal opnieuw aan de trui beginnen. Daarmee gaat veel tijd en geld verloren.
Het belangrijkste onderwerp om tot een goede strategie, aanpak en doelstellingen te komen is om workshops met de juiste stakeholders te organiseren. Begin hierbij altijd met een workshop die bepaalt welke stakeholders er precies nodig zijn en zorg ervoor dat ze genoeg tijd beschikbaar hebben. Als dit niet zorgvuldig gebeurd, is de kans op falen verderop in het proces veel groter.
User centered design
Als je het aan de eindgebruikers van softwareoplossingen vraagt hoe dingen beter kunnen, weten ze het meestal wel. Of, denken ze het te weten. De kunst is om de juiste gebruikers bij elkaar te krijgen en er naast te gaan zitten tijdens het uitvoeren van hun werkzaamheden.
Maar daarnaast is het belangrijk om van proceseigenaren te weten te komen hoe processen nu het best gedigitaliseerd en geoptimaliseerd kunnen worden. Vaak wordt nog gedacht in oude oplossingen; ‘in het huidige systeem gebeurt het zo’. Een gebruiker is in principe maar een klein radertje in het geheel, en heeft vaak geen zicht op het grotere doel van zo’n proces en hoe dingen echt verbeterd kunnen worden. Om echt innovatieve functionaliteit toe te voegen. Om die klant echt beter te kunnen gaan bedienen.
Er wordt nog veel te vaak inside out gedacht. De echte why (de vraag achter de vraag) is moeilijk te achterhalen. Dat vergt creativiteit van de ‘user experience’ (ux) designer. Het draait tegenwoordig om customer-centric ux en niet meer om organization-centric ux (zie ook ‘How ux is transforming business’ in Forbes). En het vertalen naar goede requirements is echt wel een vak, waar dit soort mensen goed in getraind is en veel ervaring mee heeft. Het zijn vaak niet eens ’techneuten’. Door eerst de gebruikersinteractie en procesflows uit te tekenen en eventueel in een prototype te gieten, kan er al heel snel met eindgebruikers en proceseigenaren afgestemd worden of het aan de eisen en wensen voldoet. En of het inderdaad een verbeterd proces oplevert.
Eigenlijk begint daar het change proces al; iedereen moet worden meegenomen in dit optimalisatieproces. Met de ontwikkelaars in het devops-team wordt vervolgens besproken of het technisch haalbaar is. Voordat er ook nog maar een regel code geschreven is. Dit kan allemaal prima gecombineerd worden met een agile aanpak, waarbij er met elke sprint weer waarde wordt toegevoegd. Op deze manier is fail fast mogelijk, en kan het in de volgende sprint bijgestuurd worden. Zo wordt het realiseren van innovatieve software oplossingen goedkoper en krijg je echt precies wat bijdraagt aan de in de strategiefase bepaalde doelstellingen. Doelstellingen die uiteraard ook customer centric moeten zijn!
Mooi verhaal Gijs. Ik herken veel van wat je schrijft.
Wat ook de in de afgelopen 20 jaar is gebeurd is dat met name die organisatie landschapsbeschrijvingen heel lastig zijn te communiceren. Het is nogal wat om wet- en regelgeving, functionele eisen en wensen, architectuurprincipes en standaarden, organisatieprocessen (niet verwarren met ITIL, dat hoor ik nou al zo vaak), producteigenschappen, functionele decomposities naar bedrijfsfuncties, werkinstructries, proceslogica, organisatielogica en uiteindelijk komt daar de ICT met zijn lage die in een technische decompositie naar ux, integratie, businessrules, procescontrol en uiteindelijke manifeste code in een overzicht inzichtelijke te maken.
Ik worstel daar mijn hele leven al mee en meerdere met mij. In het huidige tijdsbestek moet alles zogenaamd snel snel (vaak zonder enige concrete reden, omdat men zich geen houding kan geven) en vaak zie ik dat de nut- en noodzaak om een compleet organisatie-landschap te visualiseren en daarmee inzichtelijk te maken compleet genegeerd. De kunst van het over de schutting bij een ander vakgebied kijken is blijkbaar erg lastig. Het heeft ook te maken met typisch menselijk eigenschappen: niet in mijn keuken kijken. Het zou wel eens een zooitje kunnen zijn en dat is het vaak ook. Ook bij ICT hoor. Vraag een gemiddelde ontwikkelaar maar met het bijhouden en opleveren van documentatie. Antwoord: hier heb je de code (die herhalen ze dan in comment statements) of hier heb je de bijbehorende user story bij deze code.
Er moet nog heel veel water door ik weet niet hoeveel rivieren stromen, willen we dit hardnekkige probleem kunnen tackelen, zodat mensen gaan inzien dat complexiteit pas een geaccepteerde abstractie wordt zonder dat daar allerlei meningen zijn. En ik snap het wel. Niemand zal een discussie voeren over hoe een auto in elkaar gezet wordt, dat is tegenwoordig een complex apparaat geworden. Ja er wordt wel eens wat geroepen, maar uiteindelijk koop je dat ding en gaat ermee rijden en je verwacht dat hij ook doet wat je er enigsinds van verwacht.
Waar we het hier over hebben, is hoe een organisatie een concrete verandering kan doorvoeren. Vervelend genoeg zijn de mensen met wie deze verandering tot stand brengen op twee manieren betrokken bij de verandering. Wat betekent het voor mij in mijn dagelijks werk (en wat stelliger: heb ik nog wel werk) en wat kan ik bijdragen aan die verandering. Daar kom je volgens mij tot de kern van de zaak: willen ze echt de verandering en zijn ze in staat deze verandering vorm te geven.
Waar 40 jaar geleden uiteindelijk veel organisaties vonden dat projecten (ik noem het bewust geen ICT projecten, die bestaan voor mij niet) veel meer door de “business” (verzonnen term van ICT-ers!) moesten worden getrokken, want het ging toch om doelen en resultaten in de business, kom ik daar nu van terug. Stelling: ik ben niet meer van mening dat een gemiddelde afdeling zelfstandig een complexe organisatieverandering kan managen naast de going concern taken. Dat vereist een dermate hoog kennisniveau over al die zaken die aan het begin van dit epistel staat en die met name in relatie te brengen. Deze kennis en kunde is echt niet aanwezig binnen lijnorganisaties. Ik maak me daar zeker niet populair mee.
De eerste stap is maar eens een gemeenschappelijke taal ontwikkelen zodat we elkaar op dat grote (organisatie)schaakbord gaan vinden en vandaaruit de discussie gaat voeren wat je daar voor expertise voor nodig heeft. Ik zie voor de (enterprise)architect een grote rol weggelegd en voor een nieuwe rol die op het detailniveau van het organisatielandschap kan acteren en heel dicht bij de lijnafdeling zit (het liefst onderdeel daarvan is). Ik ben nog aan het verzinnen hoe je zo iemand moet gaan noemen.
Ach heren, kies dan voor een biologisch groeimodel, neem een klein plantje, geef het aarde, water en licht en laat het gekontroleerd groeien.
En vergeet “komplex” denk aan KISS, steeds opnieuw. Dan krijg je de neuzen vanzelf in dezelde richting.
Klinkt toch goed?
vroeger was alles beter
ook de requirements
eerste stap van de waterval
alleen dat deugde ook weer niet
het moest agile
want requirements zouden we pas weten na een protoype
een minimum viable product
het plantje van jantje
“iedereen moet worden meegenomen in het optimalisatieproces”
over “Unrealistic or unarticulated project goals” gesproken
gijs geeft een nieuwe interpretatie aan het begrip “low code”
waarde wordt toegevoegd “Voordat er ook nog maar een regel code geschreven is” 😉
stellen dat “dat er nog niet veel veranderd is in de afgelopen vijftien jaar”
en dan de oplossing van het requirements afstoffen en oppoetsen
maar dat dan weer mergen met agile/devops/sprint/innovatief/failfast/customercentric
ict is een dure grap
Daan Rijsenbrij heeft over het vergelijkbare onderwerp, maar dan bij de Nederlands overheid dit stuk recent gepubliceerd.
https://itexecutive.nl/wp-content/uploads/2020/09/Kanttekeningen-Digitalisering-Overheid.pdf
Een aantal dingen die in het artikel genoemd zijn kom je ook daar tegen.
Gijs,
Het is goed om achterom te kijken door te verwijzen naar een artikel uit 2005 maar ‘All People Seems To Need Data Processing’ gaat om een stack die door Internet gewijzigd is. Eveneens geldt dat voor samenwerkingen welke door de Systems of Engagement veranderd zijn want een moderne interactie met de data wordt gedreven door alle mogelijkheden van Internet waardoor data 24/7 toegankelijk is voor gebruikers. De Systems of Record gaan vooral om het vastleggen van de informatie en Salesforce is dus een systeem voor het vastleggen van de klantgegevens, Github een System of record voor de code en ServiceNow voor de IT-operaties om een paar voorbeelden te geven waar in 2005 niemand nog van gehoord had.
De essentie van het zeggen wat je doet, doen wat je zegt en dat bewijzen is tenslotte niet veranderd als het om de administratieve verplichtingen van het vastleggen gaat. En vol verwachting klopt hierin ons hart als het om innovatieve platformen gaat waarin overtreffende trap de Systems of Intelligence zijn met daarin een discussie over situationele of contextuele synthese van data en metadata als het om bronnen zoals de Systems of Record en de Systems of Engagement gaat. Want terugkijkend naar 2005 leefden we vooral in angst voor dodelijke vogelgriep en zeiden we ‘NEE’ tegen de Europese grondwet.
Ik denk dat MicroFrontends, zelfstandig werkende componenten in een georchestreerde interface, een oplossing kunnen bieden voor gestelde problematiek. Door verdeel-en-heers, langs slim gekozen lijn van geisoleerdheid en duidelijke afgebakende verantwoordelijkheden of domeinen of functionele contexts krijg je een groot aantal agile en makkelijker aan te passen applicaties die je eenvoudig kan integreren tot een groter geheel. Dat is veel meer agile werken binnen de Enterprise context dan sociale consensus bereiken door het verfijnen van requirements voordat daadwerkelijk bouwen begint, wat dit artikel lijkt te suggereren, en wat voor mij voelt als terug naar “Big Design UpFront” met alle gebruiksonvriendelijke oplossingen die uit die methodologie zijn voortgekomen? MACH – MicroSevices, API first (message protocol first), Cloud, Headless (componenten) gaat volgens mij niet alleen over de applicatie architectuur, maar zeker ook over de organisatiestructuur, het toekennen/delegeren van verantwoordelijkheden aan groepen mensen / teams en de wijze waarop die onderling samenhangend toch los van elkaar samenwerken?
Ik denk dat MicroFrontends, zelfstandig werkende componenten in een georchestreerde interface, een oplossing kunnen bieden voor gestelde problematiek. Door verdeel-en-heers, langs slim gekozen lijn van geisoleerdheid en duidelijke afgebakende verantwoordelijkheden of domeinen of functionele contexts krijg je een groot aantal agile en makkelijker aan te passen applicaties die je eenvoudig kan integreren tot een groter geheel. Dat is veel meer agile werken binnen de Enterprise context dan sociale consensus bereiken door het verfijnen van requirements voordat daadwerkelijk bouwen begint, wat dit artikel lijkt te suggereren, en wat voor mij voelt als terug naar “Big Design UpFront” met alle gebruiksonvriendelijke oplossingen die uit die methodologie zijn voortgekomen? MACH – MicroSevices, API first (message protocol first), Cloud, Headless (componenten) gaat volgens mij niet alleen over de applicatie architectuur, maar zeker ook over de organisatiestructuur, het toekennen/delegeren van verantwoordelijkheden aan groepen mensen / teams en de wijze waarop die onderling samenhangend toch los van elkaar samenwerken?
Ik ga nog maar eens water geven, dat is niet zo duur Dino.
Wat ik positief beoordeel is dat artikel en reacties mijn woordenschat op gebied van marketing kretologie toch weer vergroot heeft, Dankuwel heren!
Jan,
Fijn dat je woordenschat weer wat vergroot is, terugkijkend hoe de technologiemarkt zich in de loop van de tijd heeft ontwikkeld kent elk tijdperk namelijk zijn eigen dominante ‘marketing’ term welke mede resoneert door de dominantie van bepaalde bedrijven die veel geld besteden aan marketing:
1970–1985: Het “Silicon” – tijdperk (bijv. Intel, opgericht in 1968)
1975–1990: Het “Informatie” – tijdperk (bijv. Oracle, opgericht in 1977).
1985–2000: Het “Netwerk” – tijdperk (bijv. Cisco, opgericht in 1984)
1995–2010: Het “Internet” – tijdperk (bijv. Netscape, opgericht in 1994)
2000–2015: Het “SaaS” – tijdperk (bijv. Salesforce, opgericht in 1999)
2015-2030: Het “Systems of Intelligence” – tijdperk (hedendaagse digitale transformatie)
Heel wat IT-ers zullen de komende weken de geraniums op de vensterbank water gaan geven, de uitdrukking van het nietsdoend achter de plantjes zitten zal je waarschijnlijk ontgaan maar als we onderling samenhangend maar toch ook los van elkaar gaan werken waar Thijs Cobben het over heeft dan is er een ecosysteem nodig. De bovenstaande opsomming geeft je een idee hoe afgelopen 50 jaar ‘productieplatformen’ zich hebben ontwikkeld van stand-alone
PC’s tot de anytime & anywhere netwerkdevices aan de randen van de architectuur. Thijs Cobben heeft het over de zelfstandig werkende componenten in een georchestreerde laag wat dus naar mijn opine de Systems of Intelligence zijn binnen de digitale transformatie.
Ik wil je daarom wijzen op een verhaal over jagers en verzamelaars wat jezelf schreef in 2015 over het gebruik van metadata, het ‘All People Seems To Need Data Processing’ van het 7-laags OSI-model wordt omgedraaid met de belofte van AI. De moderne datasynthese gaat niet om (low)code maar het eigenaarschap van de informatie omdat hier de afgelopen 20 jaar een verdienmodel omheen is gebouwd. Oja, betreffende zaadjes zaaien in de grond van een ander schreef ik 2012 al dat de Dot.com economie veranderde in een Bedot.com economie als we de waarde van kennis onderwaarderen.
Oudlid, waarom kom je toch steeds met systemen aanzetten waar we behoefte hebben aan architectuur?
“Systems of Intelligence” is net zulke onzin als “digitale wereld”; het taalgebruik van de faalarchitecten.
Een begrip als ‘resonantie’ kun je wat mij betreft niet vaak genoeg herhalen, alleen al omdat je hiermee buiten de gebaande (en hier dus ook doodlopende) paden van het systeemdenken treedt.
In een reactie aan jou op 17 juni 2015 19:36 noemde ik de Systems of Engagement al “doodgewone onzin”, dus dit zijn inzichten die ik maar moeilijk tussen jouw oren krijg 🙂