Grenzen aan agile?

Op het Agile and Software Architecture Symposium (ASAS 2015) gaven Gert Florijn en ik een presentatie. Veel organisaties die sterk afhankelijk zijn van informatietechnologie ontwikkelen zelf geen software – denk aan ziekenhuizen, gemeenten en sommige middelgrote bedrijven. Zij schaffen standaardpakketten aan die ze zo goed mogelijk in hun bestaande informatievoorziening inpassen. Dat leidt tot complexe landschappen die zeer moeizaam te veranderen zijn. Hoe kunnen zulke organisaties wendbaarder worden? Wat kunnen zij leren van agile software development?

Bekijk de presentatie op slideshare

ASAS 2015: Limits to agility?

Contact? <eelco.rommes@mxi.nl>

Architectuur voor leken

Artikel in de Automatiseringgids van 12 oktober 2015, geschreven met Jochem Schulenklopper. (PDF.) 

 

IT-architecten slagen er zelden in om hun ideeën helder uit te leggen. Collega’s en ontwikkelaars begrijpen hen vaak nog wel, maar vraag een architect niet om een groep gebruikers toe te spreken of om een besluit van het managementteam voor te bereiden. Niet-technisch publiek blijft vaak in verwarring achter, uitgeput door het jargon en de ingewikkelde modellen waarvan architecten zich bedienen. Het is allang bekend dat verschillende belanghebbenden verschillende dingen willen weten over een informatiesysteem. Omdat het onmogelijk is om alle aspecten van een complex systeem in één enkel overzicht weer te geven, zijn er dus meerdere perspectieven nodig. Architecten gebruiken vaak modelleertalen zoals ArchiMate, UML en BPMN om zulke perspectieven te tekenen. Maar in de praktijk is het communicatieprobleem daarmee niet opgelost. Wie met zulke modellen naar managers, gebruikers of beheerders stapt, oogst onbegrip. Voor nietingewijden zien al die perspectieven er namelijk hetzelfde uit: een imposante hoeveelheid abstracte symbolen, lijnen en jargon. Vaak reageren architecten op dit onbegrip door toe te lichten wat elk lijntje, symbooltje en pijltje in hun modellen precies betekent. Dan klinken zinnen als: ‘Een applicatie levert een dienst die wordt gebruikt in een of meer activiteiten in het bedrijfsproces.’ In feite legt zo’n architect dan een taal uit, in plaats van een architectuur. Dat leidt tot frustratie aan beide kanten en het is gewoon zonde van de tijd. Wie effectief communiceert, stemt boodschap én taal af op zijn gesprekspartners. Als een programmadirecteur van een gemeente een besluit moet nemen over een projectenportfolio, dan vraagt dat om een heel andere architectuurplaat dan wanneer een energiemaatschappij onderzoekt in welke systemen regelmatig storingen optreden.

Een goede architectuurplaat biedt inzicht en overzicht op een manier die met tekst alleen moeilijk te bereiken is. Het maken ervan vergt kennis van visueel communiceren. Jammer genoeg zijn psychologie, communicatie en grafische vormgeving nog geen verplichte vakken bij de opleidingen Informatica. We noemen vier gebieden waarvan architecten basiskennis moeten hebben om visualisaties te maken die begrijpelijk en aantrekkelijk zijn voor leken op IT-gebied.

1. Hoe verwerken we beelden?

Het menselijk brein kan beeld razendsnel interpreteren. Nog voor we ons bewust zijn van wat we zien, is het binnenkomende beeld al verwerkt en zijn de interessante stukken ons al opgevallen. Het brein doet dat op een luie maar slimme manier: het richt zich op patronen en pikt de uitzonderingen er feilloos uit. Zelfs kleine afwijkingen in bijvoorbeeld vorm, kleur, lijndikte en oriëntatie merken we direct op. Het is dus verstandig om in afbeeldingen te variëren in weergave als dat een direct doel dient. In een drukke plaat met weinig herhaling vraagt alles evenveel aandacht. In een rustige plaat kan variatie slim worden ingezet om het oog snel naar aandachtspunten te leiden en de kernboodschap over te brengen.

2. Hoe bepalen we wat bij elkaar hoort?

De Gestaltpsychologie verklaart hoe we onbewust losse onderdelen aan elkaar relateren om ze te beschouwen als één groter geheel. Mensen groeperen bijvoorbeeld elementen die in vorm, omvang, kleur of locatie op elkaar lijken. Architecten met talent voor visualiseren maken daar slim gebruik van door onderdelen die bij elkaar horen hetzelfde visuele kenmerk te geven. Bijvoorbeeld door webapplicaties dicht bij eindgebruikers te tekenen, door bedrijfsdomeinen met gestippelde rechthoeken te omsluiten of door kritische systemen van dezelfde dikke rode rand te voorzien.

Een verwant psychologisch principe is dat van closure: de neiging van het brein om dingen af te maken of te verbinden, zelfs waar dat in een afbeelding niet letterlijk zo wordt weergegeven. Wie een voorwiel achter een boom vandaan ziet komen, denkt de fiets er zelf bij. In architectuurplaten mogen elementen elkaar best overlappen en lijnen elkaar kruisen zonder dat dat direct tot verwarring leidt. Door vloeiende verbindingslijnen te tekenen, zijn ze makkelijker te volgen.

3. Hoe geven we kleuren betekenis?

Het is frappant dat formele modelleertalen zo weinig aandacht geven aan het gebruik van kleuren. Kleur kan een krachtige betekenis geven aan afbeeldingen. Dat hoeft zich niet te beperken tot culturele associaties van kleur of verwijzingen naar een bedrijfshuisstijl. Als van tien applicaties er negen grijs zijn ingekleurd en eentje felrood, trekt die laatste direct de aandacht. Blijkbaar is daar iets bijzonders mee aan de hand. Kleur is ook een krachtige manier om duidelijk te maken dat sommige dingen bij elkaar horen, ook als ze niet naast elkaar staan.

4. Hoe maken we dingen begrijpelijk?

Veel architectuurplaten leunen op vaktaal en abstracte symbolen. ArchiMate bijvoorbeeld, kent meer dan zestig verschillende abstracte symbolen met soms een subtiel andere betekenis. Dat is dodelijk voor de communicatie omdat het degenen die ArchiMate niet tot in de puntjes beheersen direct op achterstand zet. De meeste mensen zijn ook helemaal niet geïnteresseerd in het verschil tussen samenstellen en aggregeren of wanneer iets een doel, een eis of juist een beperking is. Variatie in abstracte symbolen kan dus simpelweg worden weggelaten. Deze vervangen door figuratieve plaatjes maakt een plaat aantrekkelijk en begrijpelijk. Daarbij hoeven metaforen en stereotypen niet geschuwd te worden: een boef stelt een hacker voor en goedgeplaatste bommen geven aan waar belangrijke risico’s zitten.

Overigens, ook tekst is een onmisbaar onderdeel van een architectuurplaat. Ook hier geldt: concreter is beter. Afkortingen en jargon zijn alleen toegestaan als ze onderdeel zijn van de taal van het publiek. Bij twijfel verdienen lekentaal en uitgeschreven woorden de voorkeur.

Voors en tegens

Formele talen, zoals ArchiMate, bieden voor dergelijke visuele uitstapjes nauwelijks ruimte en maken daarmee het begrijpen van architectuurbeschrijvingen moeilijker dan nodig is. In hun streven naar correctheid en compleetheid vergeten ze de menselijke maat en offeren begrip op. Een architectuurplaat hoeft niet compleet te zijn en voor elke persoon exact hetzelfde te betekenen, hij mag subjectief zijn en ruimte overlaten voor interpretatie omdat een plaat het startpunt is voor verdere communicatie, geen eindstation.

Het begrijpen en inzetten van principes uit vakgebieden als psychologie en grafische vormgeving helpt architecten om effectiever te communiceren. Het publiek begrijpt hun platen dan makkelijker en het kan zich concentreren op de boodschap zonder zich zorgen te maken over de precieze betekenis van een pijl of symbooltje. Nadelen zijn er ook. Platen zonder een vast formaat kunnen niet gegenereerd worden uit een digitaal architectuurarchief. Ze zijn lastiger te onderhouden, ze zijn incompleet en wie niet tot de doelgroep behoort, zal een deel van de betekenis missen.

Maar deze nadelen wegen niet op tegen dat ene grote voordeel: deze afbeeldingen stellen IT’ers en de rest van het bedrijf in staat om het met elkaar over de inhoud te hebben, in plaats van over de vorm.


Meer weten?

Er is veel beschikbaar over grafisch ontwerp, tekenen en het visualiseren van gegevens:
• Universal Principles of Design – William Lidwell e.a. Een bibliotheek met grafische principes, elk afzonderlijk uitgelegd en geïllustreerd.
• Design for Hackers – David Kadavy. De achtergronden, vuistregels en valkuilen van visueel ontwerp verklaard.
• The Sketchnote Handbook – Mike Rohde. Inspirerend leesvoer voor ‘sketchnoting’ – notities maken in de vorm van tekeningen.
• The Back of the Napkin – Dan Roam. Dit boek bevat een visuele methode om beslissingen met afbeeldingen te ondersteunen.
• The Visual Display of Quantitative Information – Edward Tufte. Een klassieker in het vakgebied van het visualiseren van data.

Blogs met praktische tips en goede voorbeelden:
Toegepast visualiseren – JAM visueel denken. Praktische tips voor visualiseren in het dagelijks werk:
Information is Beautiful – David McCandless.
Een verzameling van creatieve voorbeelden van het visualiseren van
informatie.
Flowing Data – Nathan Yau, Visualising Data – Andy Kirk.
Twee blogs met goede voorbeelden van datavisualisaties.
7 Rules for Creating Gorgeous UI – Erik D. Kennedy.
Tips over het ontwerpen van goede user interfaces; ook handig
voor anderen.

In vijf stappen afkicken van een principeverslaving

Verschenen als ‘Principeverslaving verzwakt architectuur’in de  Automatiseringgids van 18 juni 2015 (PDF.)

Aan het begin van de jaren negentig werkten honderden Microsoftprogrammeurs aan de ontwikkeling van Windows NT. Ze deden dat op PC’s die vol bugs zaten en om de haverklap crashten. Elk van die PC’s draaide namelijk op de laatste versie van Windows NT – het besturingssysteem dat ze juist zelf aan het bouwen waren. Ondanks de bugs, crashes en andere ongemakken die het werken met onvolwassen software met zich meebrengt, stond het interne gebruik van NT niet ter discussie: de teams waren ervan overtuigd dat het hen juist hielp om een beter product te maken. Ze handelden niet omdat het moest, maar uit principe.

Dat principe was enkele jaren eerder tot leven gewekt door een manager die zich hardop afvroeg waarom Microsoft zo weinig gebruik maakte van eigen software. Hoe kon je goede producten maken zonder ze zelf uit te proberen? Hij daagde zijn collega’s uit om ‘hun eigen hondenvoer te eten’. De kreet ‘eat your own dogfood’ werd een begrip en inspireerde niet alleen het NT-ontwikkelteam, maar vele anderen binnen en buiten het bedrijf.

Principes zoals deze vormen een krachtig instrument om keuzes vast te leggen en uit te dragen. Ze stellen anderen in staat om te toetsen of hun eigen gedrag in lijn is met de richting die de organisatie uit wil en om zich zo nodig aan te passen. Het is dan ook geen wonder dat principes een populair instrument zijn onder IT-architecten: architectuur gaat bij uitstek over het maken van fundamentele keuzes die richting geven aan het werk van anderen. Er is ook een keerzijde. Onvakkundig gebruik van principes levert veel ellende op: hoe krachtiger het gereedschap, hoe zorgvuldiger men ermee om moet gaan. In de praktijk worden principes vaak te losjes gehanteerd waardoor ze niet alleen aan kracht inboeten, maar een organisatie flink in de weg kunnen zitten.

Veel architectuurdocumenten staan bol van de vage principes die nauwelijks richting geven, niet inspireren en ook niet te handhaven zijn. Het opstellen ervan kost de auteurs al veel tijd en vervolgens moeten vele anderen zich door de woordenbrij heen eten, al was het maar om uit te kunnen leggen waarom ze deze principes links laten liggen. Als de architecten dan op hun strepen gaan staan, leidt dat tot frustraties en conflicten. De partijen graven zich in, het governanceproces loopt vast en iedereen ziet zijn favoriete vooroordeel bevestigd: architecten wonen in ivoren torens, bouwers zijn allemaal cowboys en managers snappen niets van de inhoud.

Hoe moet het dan wel? Door zich te beperken tot een handjevol principes en die strikt na te leven, kunnen architecten veel meer impact hebben. De kunst van het weglaten beoefenen, dus, en dat is nog niet gemakkelijk. We geven vijf stappen om effectief met architectuurprincipes om te gaan.

1. Stoppen en schrappen

Eerst moet er een rem worden gezet op de productie van nieuwe principes. De lange lijsten met zouteloze principes die in veel organisaties rondzwerven, kunnen de prullenmand in. Zulke documenten worden zelden écht gelezen en wekken voornamelijk ergernis. Wie weggooien zonde vindt, vervangt op zijn minst het woord ‘principes’ door ‘tips’ of ‘ter overweging’.

2. Kritisch kijken en keuzes maken

De volgende stap is om de tien principes te bepalen die, als ze consequent worden toegepast, werkelijk een groot verschil maken voor de organisatie. Dat is een hele opgave, het is makkelijker om honderd principes te verzinnen dan er tien te definiëren die echt waardevol zijn. Juist de beperking in het aantal betekent dat elk overgebleven principe raak moet zijn.

Omdat er veel bedacht en veel geschrapt moet worden, is het in dit stadium extra belangrijk om zo weinig mogelijk ballast mee te slepen. Een principe is in de eerste plaats een communicatiemiddel: een pakkende naam plus een korte uitleg is voorlopig voldoende. De templates die erop gericht zijn om principes heel precies te categoriseren en te documenteren zijn in dit stadium overbodig.

3. Maak het persoonlijk

Toen Time Warner en America OnLine (AOL) fuseerden, werd AOL’s eigen e-mailsysteem ingevoerd als de standaardoplossing in het nieuwe bedrijf. Dat leidde tot zoveel problemen en gemor onder het personeel, dat het systeem weer aan de kant moest worden geschoven. AOL’s eigen hondenvoer smaakte toch niet zo goed als dat van Microsoft.

Een principe is per definitie persoonlijk. Het is dus oppassen geblazen met referentie-architecturen en andere lijsten met algemene principes. Zulke lijsten zijn niet geschikt om een-op-een uit over te nemen: ze dienen slechts als inspiratiebron om uit te putten bij het opstellen van eigen, aangepaste principes. Het wiel opnieuw uitvinden is niet nodig, maar een kritische houding is belangrijk bij het overnemen van andermans principes.

4. Zie de pijn onder ogen

Een principe is een fundamentele keuze en moet daarom pijn doen. Mensen zijn bereid die pijn te lijden, mits zij serieus worden genomen. Vaak wordt aan de voordelen van een principe volop aandacht besteed terwijl de nadelen onderbelicht blijven. Een gemiste kans, want aandacht besteden aan de nadelen laat zien dat de keuze weloverwogen is gemaakt en dat maakt het makkelijker om de pijn te accepteren. Een goede manier om de pijn achter een principe te ontdekken, is hem grondig door te spreken met de beoogde gebruikers. Typisch zijn dat ontwikkelaars, beheerders, collega-architecten, lijn- en projectmanagers – iedereen die in zijn werk met deze principes te maken gaat krijgen. Roept een voorgesteld principe enkel schouderhalen op, dan kan het direct geschrapt worden: blijkbaar staat er niets op het spel en dan is het zonde om er nog tijd in te steken. Komt er juist weerstand, dan is het de moeite waard om aandachtig te luisteren en door te vragen. ‘Niet uit te voeren’, ‘te abstract’ en ‘open deur’ zijn argumenten die erop wijzen dat een principe het in de praktijk niet gaat redden, meestal omdat de vorm verkeerd gekozen is. Sommige principes zijn een en al vorm en geen inhoud en vaak wordt dat pas duidelijk in gesprek met anderen. Inhoudelijke tegenargumenten zijn het meest interessant. Zij helpen te bepalen of een principe de moeite van het invoeren waard is en als dat zo is, maken ze het makkelijker om het principe uit te leggen en te verdedigen.

5. Uitdragen en uitdagen

Een principe dat niet wordt nageleefd, is dodelijk voor de geloofwaardigheid. Wie neemt een verklaard vegetariër nog serieus als hij een halve plofkip bestelt als lunch? Hetzelfde geldt voor architectuurprincipes – als er één straffeloos met voeten kan worden getreden, boeten alle andere ook in aan kracht. Daarom is het belangrijk om principes uit te dragen, om steeds opnieuw uit te leggen welke principes er zijn en waar ze voor staan. Niet alleen de verantwoordelijke architecten moeten dat doen, maar juist ook mensen in andere rollen: managers, beheerders, testers, bouwers.

Veel organisaties richten een architectuurboard op om hun principes te handhaven. Als een soort welstandscommissie keurt zo’n board ontwerpen goed of af en deelt bouwvergunningen uit. Dat pakt gemakkelijk averechts uit. Architecten worden stempelaars en de principes blijven iets van een bureaucratisch eliteclubje. Het is effectiever om open en op voet van gelijkheid de dialoog aan te gaan: hoe worden de principes in de praktijk toegepast en wat zijn de effecten? Gaat het moeizaam of juist gemakkelijk, hoe komt dat en wat kunnen we daarvan leren? Door mensen serieus te nemen en hen uit te dagen mee te denken, wordt het na verloop van tijd normaal om de architectuurprincipes te gebruiken. In het beste geval gaan ze na verloop van tijd deel uitmaken van de cultuur: de principes zijn dan verinnerlijkt en er is geen externe motivatie meer nodig om ze af te dwingen.

Een echte vegetariër zal nooit een plofkip bestellen. Daar is geen governance of architectuurboard voor nodig, dat is een kwestie van principes.

Het falen van enterprise architectuur

Verschenen als ‘Agile development helpt enterprise architect’ in de Automatiseringgids van 22 oktober 2013 (PDF.)

Enterprise-architectuur wil maar niet volwassen worden. Bijna twintig jaar nadat TOGAF op de markt verscheen, maakt enterprise-architectuur de grote beloften van weleer nog altijd niet waar. In de praktijk zijn de succesvolle enterprise-architecten, de mensen die een verschil maken in hun organisaties, op de vingers van een hand te tellen. Dat is jammer, want de problemen die enterprise-architectuur wil aanpakken, blijven relevant. Informatiesystemen die slecht aansluiten op bedrijfsprocessen, IT-systemen die aan elkaar kleven als drop in een broekzak, hoge beheerkosten, trage veranderprojecten: in veel organisaties is het dagelijkse kost. Wat gaat er mis? En hoe kunnen enterprise-architecten effectiever worden? Architectuur bedrijven gaat grofweg in drie stappen. Stap 1 is het verzamelen van eisen en beperkingen. Waar wil de organisatie naartoe? Wat weerhoudt ons daarvan? Wat is onze uitgangspositie? De architect vangt deze eisen en beperkingen in tekst, platen en modellen die een beeld geven van de huidige situatie, de uitdagingen en de kansen die er liggen. De tweede stap is het ontwerpen van een doelarchitectuur. Hoe kan de informatievoorziening de bedrijfsstrategie ondersteunen? Hoe verlagen we de beheerslasten zodat er tijd en energie vrijkomt voor vernieuwing? De derde stap is veruit de moeilijkste. Tot nu toe is de architect louter op papier bezig geweest. Nu is het zaak om door te zetten en te voorkomen dat zijn prachtige plannen in een bureaula verdwijnen. Voor veel enterprise-architecten is de stap naar realisatie een brug te ver. Ze blijven in hun denken en doen steken op het abstracte niveau van modellen en platen. Sommigen hechten zich zozeer aan een model dat ze er niet los van komen. Anderen hollen van project naar project, overal schetsen van oplossingen achterlatend zonder dat er ooit iets gerealiseerd wordt. In beide gevallen voegt de architect geen enkele waarde toe. Sterker, dit gedrag kost de organisatie alleen maar tijd en geld. Om werkelijk iets te bereiken, moet een architect zich niet alleen verantwoordelijk voelen voor het maken van plannen, maar ook voor de uitvoering ervan in de praktijk. Hij moet de bouwplaats op om zijn ideeën toe te lichten en om toezicht te houden. Maar ook om vragen te stellen en actief kritiek op te halen zodat hij zijn plannen verder kan verbeteren. Op papier is ieder probleem oplosbaar, in de praktijk worden de onvermijdelijke denkfouten rücksichtlos zichtbaar. En misschien is dat nu juist wat veel architecten afschrikt. Veel enterprise-architecten zijn gewend om het slimste jongetje van de klas te zijn. Dan is het niet prettig om met je fouten geconfronteerd te worden.

Taboe

Enterprise-architectuur omvat de structuur van de gehele onderneming, inclusief bedrijfsprocessen, producten, organigram, gegevensstromen, IT-systemen. Zelfs wie zich beperkt tot de informatievoorziening op enterpriseniveau kan zich jarenlang uitleven op het beschrijven van de huidige architectuur en het verfijnen van blauwdrukken voor de toekomst. En dat is precies wat veel enterprise-architecten doen. De derde stap, het realiseren van hun plannen in de praktijk, laten ze achterwege waardoor hun invloed nihil is.

Het is niet verwonderlijk dat het geduld met enterprise-architectuur zo zoetjesaan opraakt. In sommige organisaties is het ‘a-woord’ zelfs taboe verklaard. Dat is in de architectengemeenschap niet onopgemerkt gebleven en er zijn twee grotere bewegingen in het veld te signaleren. De eerste is een vlucht naar voren: nog uitgebreidere raamwerken, nog betere modellen, modernere tools. Vooral meer van hetzelfde dus. Gelukkig is er ook een tegentrend zichtbaar die zich juist richt op het verwezenlijken van architectuur in de praktijk. Een term die in dit verband vaak opduikt, is agile architectuur.

Agile softwaredevelopment is aan het begin van de eeuw ontstaan als reactie op de klassieke watervalmethode. Projecten volgens die methode duurden te lang, kosten te veel of mislukten simpelweg. In gunstige gevallen werd er iets gebouwd dat net niet deed waar de klant lang geleden om gevraagd had. Zelden loste het systeem de actuele problemen op. Die pijnlijke situatie zette een aantal software professionals aan het denken en dat leidde tot een familie van ontwikkelprocessen, waarvan Scrum en eXtreme Programming de bekendste zijn. Sindsdien is agile development steeds belangrijker geworden.

Inspiratiebron

De problemen die agile development oplost, zijn deels vergelijkbaar met die waar enterprise-architectuur nu mee kampt: te lang blijven hangen in de probleemanalyse en ontwerpfase en een gebrekkige feedbackloop van realisatie terug naar analyse. De vraag is dus: kunnen we de lessen van agile development toepassen om enterprise-architectuur uit het slop te trekken?

Agile teams leveren werkende software op in korte iteraties, waarbij de klant aan het stuur zit. Dat vereist intensieve samenwerking tussen business en techneuten, zodat elke iteratie een werkend systeem oplevert met dat deel van de oplossing waar de klant het meest behoefte aan heeft. Dat is een recept dat elke enterprise-architect zich eigen zou moeten maken.

Aan de andere kant is schaalbaarheid nog altijd de achilleshiel van agile development, dat van nature gericht is op projecten, kleine teams en de korte termijn. Enterprise-architectuur gaat juist over projecten heen en bewijst zijn waarde pas op de langere termijn. Een agile enterprise-architect weet dat zijn scope enorm is, op het megalomane af. Hier geldt de vuistregel: hoe groter het gebied, hoe minder gedetailleerd de kaart. Een agile enterprise-architect stelt prioriteiten in samenwerking met al zijn stakeholders. Hij helpt ze hun problemen te verwoorden en bevordert het begrip voor de problematiek van hun tegenvoeters: om samen te werken zullen techneuten de business behoorlijk moeten begrijpen en andersom. Modellen kunnen daarbij een hulpmiddel zijn, maar alleen als ze passen bij de gesprekspartners en hun belangen. Met een financieel directeur (CFO) voer je een heel ander gesprek dan met een Oracle database-administrator.

Bovenal zoekt een enterprise-architect de praktijk op. Om te begrijpen evenzeer als om uit te leggen. Omdat hij weet dat het venijn in de details schuilt en dat de wereld is veranderd sinds hij zijn laatste ontwerp maakte. En omdat hij weet dat hier, op de bouwplaats, de echte waarde wordt opgeleverd. En daar wil hij aan meewerken.

Natuurlijk is dit alles makkelijker opgeschreven dan gedaan. Agile is geen wondermiddel dat enterprise-architecten in een klap effectief maakt. Het is geen kwestie van simpelweg principes kopiëren. Enterprise- architecten hebben hun eigen ontdekkingstocht te gaan. De lessen van agile development kunnen dienen als inspiratiebron, maar zijn zeker geen blauwdruk.

Slim snijden en slim investeren

Artikel met Matthijs Maat in de Automatiseringgids. (achter een paywall)

Er verschijnen al jaren berichten over misstanden in de IT. Maar hoe groot ook de mislukkingen, echte veranderingen hebben ze niet op gang gebracht. Een van de meest banale oorzaken waarom de IT-sector niet leert van zijn fouten is een overschot aan geld. Het doet gewoon niet genoeg pijn. Of beter gezegd: het dééd niet genoeg pijn. Van te veel geld is nu geen sprake meer.

De plotselinge pijn lokt twee reflexen uit die natuurlijk zijn en logisch lijken, maar in werkelijkheid contraproductief zijn.

De eerste is een typische managementreflex: in tijden van schaarste snijden in de uitgaven. Door de kaasschaaf over projecten en budgetten te halen of door drastischer in te grijpen, zoals alle externen buiten de deur zetten. Op korte termijn bespaart dat kosten zonder dat de productiviteit er zichtbaar onder lijdt. Maar de kaasschaaf haalt per definitie geen rotte plekken weg – hoogstens rotte plakjes. En wat is het nut van het bezuinigen op externen als vervolgens projecten falen of uitlopen door gebrek aan expertise? Schaven of snijden zonder voldoende inzicht laat inefficiënties bestaan en maakt wel waardevolle initiatieven kreupel.

De tweede is een typische IT-reflex: de vlucht naar voren. Betogen dat het juist nu de tijd is om te investeren in nieuwe technologieën die het bedrijf deze keer echt zullen verbeteren. Flexibelere systemen door inzet van SOA en SaaS. Betere bedrijfsvoering door investeringen in BPM, CRM of de nieuwe generatie BI. De vernieuwingshonger heeft goeds gebracht, maar ook veel slechts. Was er daarom al reden tot argwaan over grootschalige vernieuwing, in crisistijd klinkt de lokroep van groot en nieuw des te valser. Verstandige managers bekijken nieuwe technologieën daarom met argusogen. Als de kosten hoger uitvallen – of baten blijven langer uit – dan blijven zij achter met lege(re) handen.

Zonder inzicht snijden en luchtfietsen, dat zijn de twee crisisreflexen. Het probleem met reflexen is dat ze het verstand negeren. Kosten besparen is prima mits duidelijk is welke opbrengsten daarmee vervallen. Op dezelfde manier kan een solide businesscase vernieuwing rechtvaardigen. Slim snijden en slim investeren dus.

Om dat mogelijk te maken moet de IT-organisatie het bedrijfsmanagement voorzien van heldere feiten. Liefst uitgedrukt in die universele taal: geld. Dit is veel gevraagd van de gemiddelde IT-organisatie, maar in crisistijd moet men nu eenmaal snel volwassen worden. Daarom: zes tactieken voor goed IT-crisismanagement.

 

1. Geldstromen in kaart, budgetten op nul 

Organisaties weten vaak verrassend slecht waar IT-uitgaven aan opgaan. Nieuwe budgetten worden vastgesteld op basis van hun voorgangers: vorig jaar plus een beetje. Of als het crisis is: vorig jaar min een beetje. Geld wordt uit gewoonte uitgegeven, niet om waarde te creëren. Een radicaal uitgangspunt om dit patroon te doorbreken is: zero-based budgeting. Alle posten gaan op nul. Wie geld wil hebben, mag uitleggen waarom. Alle verzoeken worden beoordeeld op hun toegevoegde waarde. Wat gebeurt er als we iets niet doen? Zijn er goedkopere alternatieven om dezelfde doelen te bereiken?

2. Rekenen aan IT

IT-projecten komen te makkelijk weg met vage beloften als ‘flexibele bedrijfsvoering’ of ‘toekomstvaste infrastructuur’. Dit soort resultaten is best te kwantificeren. Door verwachte kosten en baten uit te zetten in de tijd kan een netto-contante-waardeberekening worden gemaakt. Natuurlijk zitten daar aannames en schattingen achter. Maar juist door die aannames in geld uit te drukken, ontstaat inzicht in de mogelijke bandbreedte van de echte waarde die projecten gaan opleveren. Nog beter is om ook de risico’s op te nemen die de baten kunnen blokkeren. De kosten van eventuele tegenmaatregelen completeren het beeld.

3. Inzicht in status-quo

Het heeft geen zin om te gaan rennen als je niet weet waar je staat. Weinig organisaties hebben echt inzicht in hun bestaande IT-landschap. Of in alle plannen, projecten en IT-leveranciers die daar op de een of andere manier bij betrokken zijn. Nog minder organisaties gebruiken de kennis die ze wel hebben om slimme besluiten te nemen. Het is dan onduidelijk wat bedrijfsbeslissingen voor IT-voorzieningen betekenen. En wat is de impact van een IT-wijziging op de bedrijfsvoering? Goed in kaart brengen wat er staat te draaien en zoemen aan systemen en applicaties – en hoe dit landschap de bedrijfsvoering ondersteunt – is geen luxe maar een noodzaak. En begrijpelijk voor de beslissers, graag (zie ‘ICT-landschapsfoto onmisbaar voor besluitvorming’, Automatisering Gids 32/33, 10 augustus 2007). Hetzelfde geldt voor de portfolio aan projecten en leveranciers. Andersom moeten beslissers recht doen aan het belang van IT voor hun bedrijf en zich er nu eens echt in verdiepen.

4. Status-quo als veranderingsstrategie

De negatieve lading van het begrip ‘legacy’ is een typische IT-rariteit. Er zit juist ontzettend veel waarde in die stoffige erfenis. Er is veel in geïnvesteerd, er is veel waardevolle kennis in vervat en het is juist deze IT die bedrijven draaiende houdt. Laat het bestaande IT-landschap dan ook het uitgangspunt zijn bij het realiseren van nieuwe wensen. Vaak is er meer dan men denkt en wellicht is het – met wat aanpassingen – zelfs wel genoeg.

5. Klein is fijn

Grote projecten kennen grote risico’s. Ze zijn niet te plannen, ze zijn duur, ze zijn moeilijk te managen en dus mislukken ze vaak. Bovendien duurt het lang voordat een groot project resultaat en dus geld oplevert. Kleine projecten zijn vaker succesvol en als ze falen kost dat minder. De truc is om waar mogelijk grote projecten in kleinere stappen op te splitsen. Iedere tussenstap die een waardevol resultaat oplevert, zorgt ervoor dat al een deel van de baten verzilverd wordt.

6. Interne kennis en kunde op orde 

De neiging om te geloven dat alles van buiten ook beter is, heeft geleid tot excessen. Als internen al hun tijd stoppen in het aansturen van hun externe collega’s of leveranciers, komen zij aan het opbouwen van eigen expertise nauwelijks toe. Door de crisis wordt het aantal externen rap kleiner. Op zich goed, maar met die externen verdwijnt een schat aan ervaring. Een risicoanalyse maakt duidelijk welke kennis onmisbaar is voor de organisatie en in welke hoofden die kennis zit. Een scala aan instrumenten is beschikbaar om de kennis vervolgens over te dragen aan de organisatie. In sommige gevallen zal het beter zijn om iemand toch binnenboord te houden.

Deze zes tactieken zijn niet nieuw en niet ingewikkeld. Toch zijn ze zeker geen gemeengoed in de besturing van IT. Organisaties zijn jarenlang gegijzeld door de blinde ambities en ivoren torens in hun IT-afdelingen. Andersom kijken bedrijven te vaak door een kortetermijnbril naar hun IT. Maar in tijden van crisis veranderen de spelregels en slimme spelers maken daar optimaal gebruik van.

Dit kan de zegen van de kredietcrisis zijn: dat de schaarste aan geld een trendbreuk afdwingt, zodat IT-management versneld volwassen wordt en eindelijk gaat aantonen wat het waard is. Maar dat kan alleen als IT en bedrijfsmanagement nauw samenwerken en elkaar willen begrijpen. En samen zoeken naar relevante activiteiten die waarde toevoegen en een opdrachtgever in de business hebben.

De onderbouwde balans tussen slim snijden en slim investeren die daaruit kan volgen, levert meer op dan overleven alleen. Organisaties die het hoofd koel houden en hun snij-of-vlucht-reflex in de hand weten te houden, kunnen de besturing van hun IT aanzienlijk verbeteren. Die organisaties kunnen sterker en lichter – en dus gezonder – uit de crisis tevoorschijn komen.