Auteur: Admin

In het oog is in het hart

Verrassend vaak zit de top van een bedrijf ook letterlijk in de top: de bovenste verdiepingen van een kantoor zijn veelal gereserveerd voor de hogere managementlagen. Dat ICT vaak in de kelder wordt geplaatst, zou je nog positief kunnen uitleggen als  “ICT vormt het fundament waarop moderne organisaties zijn gebouwd”. Op het moment dat de ICT-afdeling in een aftands bijgebouw op een aparte locatie zit, houdt dat denken echt op.

Dat afstanden in een organogram ook vertaald worden naar fysieke afstanden, heeft onbedoelde neveneffecten.

Uit onderzoek dat is gedaan op universiteitscampussen blijkt dat mensen die een kamer dichtbij een gedeelde keuken krijgen, meer vrienden maken en sneller een partner vinden. Meer persoonlijk contact leidt sneller tot wederzijdse sympathie: we vinden aardig wie we vaker zien. Dat geldt op het werk evengoed. We hoeven niet massaal verliefd te worden, maar wederzijdse sympathie bevordert de samenwerking.

Als ICT in de kelder zit en de directie op zolder, groeien de twee langzaam maar zeker uit elkaar – niet zo gek dat de kwaliteit van de besluitvorming rond ICT vaak te wensen over laat. Als ICT niet in de gebouwen zit waar het echt gebeurt (bijvoorbeeld in het ziekenhuis) wordt het nog erger. Hoe weet je dan nog wat er speelt op de werkvloer? Hoe krijg je dan nog passende oplossingen voor actuele problemen?

Voor architecten is een informeel netwerk dat door de hele organisatie loopt essentieel. Dat gaat niet vanzelf, dat moet je helpen ontstaan door de fysieke afstand te verkleinen. Kom uit de kelder, of zorg voor een werkplek in het hart van de organisatie. Een dag meelopen op een productieafdeling, een middag naast de koffieautomaat werken op de financiële afdeling, aanschuiven bij de heisessie van personeelsmanagement – aanwezigheid op de werkvloer en op de hoogste verdieping zorgt voor verbinding met de praktijk. En dat is een goede basis voor vertrouwen, samenwerken en invloed.

In de beperking toont zich de meester

Veel architectuurmethodes en referentiearchitecturen bevatten een of ander raamwerk. Een indeling in verschillende aandachtsgebieden bijvoorbeeld, vaak iets als bedrijf, informatie en techniek. Of een definitie van de verschillende soorten elementen waaruit een architectuur kan bestaan, zoals eisen, principes, processen, diensten, logische functies en gegevenselementen. Meestal een combinatie van beiden.

Zo’n raamwerk vergemakkelijkt het werk van een architect. Het helpt bijvoorbeeld discussies te structureren door telkens de nadruk te leggen op één duidelijk gedefinieerd perspectief. Een raamwerk helpt doelen, randvoorwaarden en oplossingen uit elkaar te halen. Mits goed gebruikt, kan een raamwerk helpen om de consistentie van het geheel te bewaken.

Raamwerken hebben ook een gevaar in zich. Het is moeilijk weerstand bieden aan de neiging om alle onderdelen in te vullen, om te beginnen linksboven in het raamwerk en pas te stoppen als je rechtsonder aangekomen bent en onderweg ieder vlakje volledig ingekleurd hebt. Dat is dan ook precies wat er in architectuurtrajecten te vaak gebeurt. Het raamwerk is een doel op zich geworden.

Dat is niet alleen verspilling van tijd, geld en intelligentie, het zorgt er ook voor dat veel belanghebbenden afhaken. Zij moeten input leveren over iets dat op dat moment helemaal geen issue is en geen waarde toevoegt, terwijl datgene waar ze naar op zoek zijn – een richtinggevend principe op een bepaald vlak, een keuze voor een bepaalde technologie – nog (lang) niet op de agenda staat.

Architectuur gaat altijd om essentie, zelden om compleetheid. Werk uit waaraan behoefte is, tot een niveau dat waarde toevoegt.

Ceci n’est pas…

ICT-trajecten hebben baat bij een gedeeld beeld tussen de betrokken partijen – figuurlijk, maar ook letterlijk. Een goede visualisatie drukt dat beeld uit in relevante concepten die alle betrokkenen begrijpen.

Die relevante concepten variëren per geval. Soms gaat het om processen, soms om systemen of servers. Soms gaat het om heel specifieke zaken, zoals de ‘brandweer- en ambulancekolom’ of ‘het risico op botsingen tussen treinen’. Zulke situatie-afhankelijke concepten zijn cruciaal voor een gedeeld beeld over het nu en de toekomst. In een visualisatie moet de weergave van zo’n concept dan ook voor zichzelf spreken. Als ‘boef’ een relevant concept is, dan moet er ook een boef op de plaat staan en niet een rechthoekje met een cilindersymbool en het woord ‘boef’ erin.

ICT-architecten gebruiken vaak architectuurtalen om zulke visualisaties te maken. Belanghebbenden moeten meegaan in de concepten, abstracties en verbanden die uit het conceptueel raamwerk en meta-model van zo’n taal volgen. De vraag lijkt niet langer: ‘Hoe ziet ons bedrijf eruit?’, maar: ‘Uit welke bedrijfsfuncties en bedrijfsobjecten is onze dienstverlening aan externe actoren opgebouwd?’.

Platen waarbij de methodiek de boventoon voert, ook in de weergave, missen hun doel. Bij een begrijpelijke plaat vraagt niemand zich af wat het achterliggende meta-model is en of dat wel consequent is gevolgd. Dat doen alleen architecten. Overigens: iedere goede plaat, juist óók een begrijpelijke, heeft wel degelijk een onderliggend meta-model dat consistent is toegepast. Het is alleen bijna nooit hetzelfde en beperkt zich zeker niet tot de traditionele blokken en pijltjes.

ICT-architecten mogen onderling best in architectentaal praten, als dat helpt. Maar niet met anderen. Dat wat essentieel is in de belevingswereld van de verschillende belanghebbenden vormt de basis voor een effectieve visualisatie. De vormgeving wordt daarbij zo goed mogelijk op die belevingswereld afgestemd. Een plaat heeft pas zin, als hij begrepen wordt.

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.