Maand: februari 2017

Even voldoende architectuur

Een goede visualisatie van het applicatielandschap maakt inzichtelijk welke systemen een organisatie heeft en hoe die met elkaar samenhangen. Dat is vaak ook meteen even voldoende architectuur.

Het heeft geen zin meer architectuurproducten op te stellen als intussen iedereen willekeurige projecten kan opstarten. Als een organisatie al niet gewend is om naar het applicatielandschap als geheel te kijken, dan helpen toekomstgerichte architectuurproducten zoals principes niet. Na een eerste architectuurstap is dus niet een tweede architectuurstap nodig, maar een stap in de organisatie van de besluitvorming.

Op eenzelfde manier heeft teveel investeren in besluitvorming ook weinig nut. Waarom veel werk maken van bijvoorbeeld business cases, als de inhoud van projecten niet meegewogen wordt bij besluiten? Als bij projectportfoliomanagement vooral gekeken wordt of het juiste documenttemplate is gebruikt, in plaats van of de voorgestelde verandering goed is voor het applicatielandschap als geheel? Na een eerste stap in de besluitvorming is dus niet een tweede stap nodig, maar iets anders.

Want zonder borging van kwaliteit in lopende projecten zijn investeringen in zowel architectuur als besluitvorming zinloos. Waarom architectuurkaders opstellen en zorgvuldig besluiten nemen als projecten vervolgens hun goddelijke gang mogen gaan? Projecten maken hun eigen ontwerpkeuzes onder druk van veranderende eisen en omstandigheden. Architectuur noch besluitvorming zorgen ervoor dat projecten dan binnen de lijntjes blijven kleuren.

Architectuur, besluitvorming én borging in projecten moeten in samenhang worden ingericht. Op alle vlakken moeten stappen worden gezet en zijn concrete maatregelen nodig om de dwarsverbanden te leggen. Pas dan komt de organisatie als geheel vooruit.

Zeven uitgangspunten voor effectieve ICT-architectuur

ICT-architectuur kan wel degelijk helpen bij het begrijpen en veranderen van de informatievoorziening. Als architecten daarbij de volgende zeven uitgangspunten hanteren, dan worden ze effectiever en hun architecturen succesvoller:

  • Relevant – Architectuur moet een reëel doel dienen: het oplossen van een knelpunt, het bereiken van een nieuw geformuleerde organisatieambitie of het aansluiten bij een veranderende omgeving. Alleen wat bijdraagt aan zo’n doel, hoort in een architectuur.
  • Eigen – Architectuur moet het specifieke van de organisatie en de bijbehorende informatievoorziening erkennen en adresseren. In het herkennen en erkennen van verschillen tussen ogenschijnlijk vergelijkbare organisaties en situaties zitten de echte problemen – én de kansen.
  • Werkelijk – Architectuur moet vooral gaan over échte dingen, dingen die bestaan in de IT-werkelijkheid. Dus wel over applicaties, gegevens of netwerken, maar minder over ‘infrastructuurservices’ of ‘logische applicatiefuncties’. Theoretische abstracties maken architecturen complex, suggereren vaak samenhang die er in werkelijkheid niet is en gaan voorbij aan beperkingen die in die werkelijkheid juist wel bestaan.
  • Begrijpelijk – Om een architectuur te laten werken moeten mensen de architectuur kunnen begrijpen. Architecten moeten architectuur vastleggen in een toegankelijke, op het publiek afgestemde vorm en mensen aanspreken in hun eigen taal. Het vraagt inspanning – van de architect, wel te verstaan – om complexe problemen en oplossingen zonder neerbuigende oversimplificatie uit te dragen.
  • Samenhang – Een architectuur moet de relevante perspectieven (zoals organisatie, informatie, techniek, beheer, beveiliging of realisatie) in samenhang omvatten. De architectuur geeft een integraal beeld dat meer is dan een opsomming van een aantal invalshoeken.
  • Haalbaar – Bij een architectuur hoort een realistisch pad van het nu naar de toekomst. Realisme is gebaseerd op een goed zicht op de huidige informatievoorziening en de mate waarin die informatievoorziening al dan niet in voldoende mate past bij de wensen en ambities van de organisatie. En op een reëel beeld van de implementatie- en veranderkracht van de organisatie.
  • Gedragen – Architectuur is in zichzelf niets; het is een idee in een hoofd of een visie op papier. Pas als informatievoorziening op basis van die ideeën en papieren wordt ingericht of aangepast, krijgt architectuur vaste vorm. Architectuur wordt dus pas effectief als de mensen in de organisatie – van bestuur tot werkvloer – er iets mee kunnen en willen.

Geen reden om heel ingewikkeld te doen

Over werken met architectuur kun je dikke boeken vol schrijven en dat is dan ook vaak gedaan. Toch is de essentie van het architectuurproces te vangen in enkele simpele vragen. Wat is er nu en wat willen we veranderen of oplossen? Welke nieuwe situatie past bij onze ambities en ontwikkelingen? Hoe gaan we dat bereiken? Veel ingewikkelder moet werken met architectuur niet zijn.

Een pragmatisch architectuurproces start als er iets moet veranderen in de werkelijke wereld. De informatievoorziening functioneert niet, het moet efficiënter of beter aansluiten op de toekomst. Om te kunnen bewegen is een samenhangend en begrijpelijk overzicht van en inzicht in hoe het nu is nodig. Hoe zit het echt met de applicaties, gegevens en infrastructuur? Hoe lopen de processen? Hoe zit het met beveiliging en andere relevante aspecten? Het startpunt is een eerlijke blik op het nu.

Vervolgens kan je van die werkelijke wereld iets vinden. Waar zit de pijn? Waar kraakt de informatievoorziening in haar voegen? Waar zijn aanpassingen nodig om ontwikkelingen te kunnen volgen of ambities te ondersteunen? Die analyse moet het specifieke karakter van de organisatie respecteren.

Wat is er nu en wat moet er anders: dat vormt de basis voor een schets van waar het naar toe moet. Dat toekomstbeeld moet realistisch zijn en haalbaar voor de organisatie. Ook het toekomstbeeld brengt meerdere perspectieven samen en is begrijpelijk voor iedereen die betrokken is.

Dan komt het daadwerkelijk bewegen, het daadwerkelijk iets veranderen in de echte wereld, bijvoorbeeld door projecten of andere vormen van wijzigingen. Om die veranderingen te kunnen richten naar het toekomstbeeld is draagvlak nodig – tot aan het hoogste niveau van besluitvorming. Niet iedere verandering zal een stap in de gekozen richting zijn; er zullen altijd redenen zijn om van de koers af te wijken, of om het toekomstbeeld aan te passen. Al doende leren we. Bovendien wacht de wereld niet netjes tot we uitveranderd zijn om zelf te veranderen. Het is dus zaak de cyclus tijdig te sluiten en te kijken naar de nieuw ontstane werkelijke wereld.

De architect begint in de modder, beziet de modderpoel van boven, bepaalt een richting en ploetert die nieuwe, iets drogere kant uit. Dat het ploeteren zelf zo moeizaam gaat, is nog geen reden om heel ingewikkeld over het proces te doen.

De onweerstaanbare verleiding van een generieke oplossing

Architecten vallen vaak in de valkuil van genericiteit: er zijn vergelijkbare toepassingen nodig dus pakken we het efficiënt aan en beginnen met een generieke, herbruikbare basis.

Het is een verleidelijke redenering die projecten in grote problemen brengt. De veronderstelling is dat je vooraf, op papier, kunt bepalen wat generiek gemaakt moet worden, zo precies zelfs dat je er software voor kunt maken. “No one is that smart,” stelden Don Roberts en Ralph Johnson al in 1996. En de miljoenen verslindende doch gefaalde pogingen om een multi-wetsysteem of een multi-regelingensysteem te maken tonen dat aan.

Beginnen met het generieke leidt tot lange discussies over abstracte concepten. De oplossing wordt mooier en ambitieuzer, omdat er altijd iets te vinden is dat misschien óók nodig is. En ingewikkelder, omdat met allerlei uitzonderingssituaties rekening moet worden gehouden. Als er dan ontwikkeld wordt, blijkt altijd dat er alsnog dingen zijn waar niet aan gedacht was, zelfs rond fundamentele aannames.

De aloude rule of three stelt dat je ervaring nodig hebt om een generieke toepassing of een raamwerk te maken. Voordat je aan generalisatie begint, moet je tenminste drie concrete toepassingen hebben gemaakt. En zelfs dan is generiek altijd moeilijker. Er ontstaan meerdere niveaus van programmeren, configureren of zelfs genereren. Met elk niveau wordt de ondersteuning door ontwikkel- en testtools lastiger en kunnen minder ontwikkelaars de complexiteit aan. Eindgebruikers zien vooral de beperkingen van een oplossing die net niet goed past of ze raken teleurgesteld omdat veel inspanning nodig is om het generieke stuk “af” te maken.

Generiek klinkt efficiënt, maar het is complex.

Referentie: Don Roberts, Ralph Johnson: Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks. In: Proceedings of the Third Conference on Pattern Languages and Programming. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.8767&rep=rep1&type=pdf

Het landschap is één systeem

In veel organisaties is het IT-landschap net een eilandengroep: een stel losse applicaties en gegevensverzamelingen die apart beheerd worden. Ook het eigenaarschap en de regie worden afzonderlijk geregeld met investeringen in geïsoleerde oplossingen en te weinig aandacht voor samenhang als gevolg. Koppelingen zijn de lelijke stiefkinderen waar niemand voor wil zorgen en waarover ruzie ontstaat. Veranderingen in het landschap resulteren in een hagelbui aan projectjes, soms samengebald in programma’s, die elkaar in de weg zitten en tegenwerken.

Maar informatie laat zich niet isoleren, die stroomt door de gehele organisatie. In een landschap hebben lokale veranderingen altijd gevolgen elders. Wanneer een onderwijsinstelling de studentenadministratie vervangt, moeten ook werkprocessen worden vernieuwd. De digitale leeromgeving, het ouderportaal, roosterprogramma’s en andere applicaties moeten worden aangepast en autorisaties opnieuw ingesteld.

Door het landschap te beschouwen als één, samenhangend systeem, kan op het geheel worden gestuurd en ontstaat grip op veranderingen. Daarvoor is overzicht en inzicht cruciaal: wat is er in huis aan functionaliteit, data en infrastructuur? Hoe hangt alles samen? Hoe lopen processen en waar wordt informatie gecreëerd, gedeeld en gebruikt?  Een architect zet IT-landschapsfoto’s in om dat overzicht te creëren en gedeelde belangen te tonen.

Om richting te kunnen geven moet ook het eigenaarschap die samenhang tonen. Als er niet één eigenaar kan zijn, een CIO bijvoorbeeld, dan is een constructief beraad van eigenaren nodig. Dat er af en toe een grensconflict wordt beslecht, is normaal. Maar eilandjes die elk in splendid isolation proberen te bestaan, dat is een achterhaald idee.

Getallen doen ertoe

Kiezen is moeilijk, zeker als je niet zeker weet hoe de toekomst eruit ziet. Grote lijnen zijn makkelijk te tekenen, maar goede keuzes vergen inzicht in de werkelijke situatie, de echte wereld. In die wereld doen details ertoe, althans, sómmige details. En daarbij gaat het vaak om aantallen, om getallen.

Als je niet naar de getallen kijkt koop je als productiebedrijf zomaar een hoog-beschikbare, fault-tolerant business-to-business oplossing met speciale tooling waar per dag maar honderd orders doorheen blijken te gaan. En dat zullen er ook nooit meer worden omdat de hoeveelheid ketenpartners inherent klein is.

Getallen helpen om richting te geven aan de architectuur: waar zitten echte problemen, waar lopen we risico, waar kunnen we impact hebben en waar doet het er niet echt toe. Als we een systeem in de lucht moeten houden voor de administratie van tien oud-klanten, dan zetten we het uit. Als het realistisch is dat er tweeëneenhalf miljoen gebruikers gaan stemmen, moeten we uitkijken.

Architecten vergeten soms te kijken naar de getallen. De droom van een mooi doel kan het zicht op de werkelijkheid doen verbleken. Zorg er daarom voor dat de relevante getallen inzichtelijk worden voor alle partijen – bijvoorbeeld in landschapsfoto’s. Doe inspiratie op uit atlassen – daar staan ook relevante getallen in die ons helpen de wereld te duiden. Soms in de vorm van een legenda, soms in de vorm van themakaarten die, bijvoorbeeld met kleuren, getallen relateren aan een bekend wereldbeeld.

Eerst de patronen herkennen

Wellicht herkenbaar: het IT-team van zorginstelling De Zonnehoed is behulpzaam en altijd bereikbaar. Omdat iedereen in de organisatie hen weet te vinden, zijn ze continu in de weer. Tijd voor proactief beheer hebben ze niet en dus ontstaan er steeds nieuwe incidenten die direct opgelost moeten worden.

Allerlei krachten oefenen invloed uit op zulk gedrag in organisaties: hoe macht en invloed verdeeld is, hoe geld stroomt, leiderschapsstijlen en beloningssystemen. Onder druk van zulke krachten ontstaan gedragspatronen die steeds dieper inslijten totdat ze onderdeel zijn geworden van de organisatiecultuur: ‘zo werken wij hier nou eenmaal.’

Soms zijn de bijeffecten van een gedragspatroon schadelijker dan de problemen die ermee worden opgelost. Deze antipatronen bieden slechts tijdelijk soelaas waarna het probleem verergerd terugkeert, of ze verplaatsen de pijn naar een ander deel van de organisatie zonder de werkelijke oorzaak weg te nemen.

Het brandjes blussen in De Zonnehoed houdt zichzelf onder meer in stand omdat het verslavend werkt: onder hoogspanning problemen oplossen geeft een kick. Als er weer eens een ramp is afgewend, krijgt de held in kwestie high fives van zijn collega’s en een schouderklopje van de baas. Het blussen zelf wordt als waardevoller ervaren dan het onzichtbare preventiewerk dat nieuwe branden voorkomt.

Zulke patronen bepalen mede wat een organisatie aan architectuur nodig heeft en aankan. Voor architecten is het dus belangrijk om ze te herkennen en erop in te spelen. De Zonnehoed heeft voorlopig geen behoefte aan een lange termijnvisie op het beheerlandschap. Eerst moet er worden afgekickt van de pyromanie. Pas dan kan preventie belangrijk worden gevonden en op termijn een nieuw gedragspatroon vormen.