Development

Governance
Kerntaak

Terug naar de kern van architectuur

Architecten moeten op een andere manier denken, communiceren en bewegen

© CC BY-SA 2.0,  Christopher Bowns op Flickr
21 juni 2017

Architecten moeten op een andere manier denken, communiceren en bewegen

ICT-architectuur is vaak kostbare flauwekul. Architecten sluiten onvoldoende aan bij de praktijk, ze maken architectuurproducten die niemand begrijpt en hun denkbeelden worden niet gedragen. Veel organisaties zouden nauwelijks minder af zijn zonder hun architecten en de architecturen die ze maken. Dat is jammer, want een ICT-architectuur kan cruciaal zijn bij het begrijpen en veranderen van de informatievoorziening.

Gedurende de afgelopen twintig jaar is het vakgebied van ICT-architecturen steeds verder ontwikkeld. De discussies, veelal tussen architecten onderling, hebben geleid tot allerlei (meta)methoden, modelleertalen en raamwerken, waar we inzichten over het nu en uitgangspunten en principes voor de toekomst mee moeten beschrijven. En tot talloze referentiemodellen die een sjabloon willen geven voor de informatiehuishouding van schijnbaar gelijksoortige organisaties binnen een bepaald domein.

Het vakgebied is daarmee steeds verder van de praktijk afgedwaald. De uitgebreide methoden en formele architectuurmodellen die onder architecten zo populair zijn, staan hen juist vaak in de weg. Ze leiden af van waar architecten zich veel meer mee bezig zouden moeten houden: overzicht geven, helpen richting te geven en draagvlak voor veranderingen creëren. Kortom, grip krijgen op de informatievoorziening en hoe die zich moet ontwikkelen.

Essentie is eenvoudig samen te vatten

Architecten hebben een andere manier van denken, van communiceren en van bewegen nodig om écht iets te kunnen betekenen voor hun organisaties. Effectievere architecten en succesvollere architecturen vragen slechts een simpel proces en, vooral, een pragmatische houding [zie kader]. Het is tijd om terug te gaan naar de kern.

Over werken met architectuur kun je boeken vol schrijven en dat is dan ook vaak gedaan. Toch is de essentie van architectuur eenvoudig samen te vatten: grip krijgen op en richting geven aan complexe ICT. De kern van het architectuurproces is simpel. Wat is er nu en wat willen we veranderen? Welke nieuwe situatie past bij onze ambities en ontwikkelingen? Hoe gaan we dat bereiken? Veel ingewikkelder moet werken met architectuur niet zijn.

Overzicht

Een pragmatisch architectuurproces start als er iets moet veranderen in de werkelijke wereld. De informatievoorziening functioneert niet, moet efficiënter of beter aansluiten op de toekomst. Misschien gaan we fuseren of stoten we taken en onderdelen af. Als er geen concrete aanleiding is moet de architect geen grootse of meeslepende plannen maken en die proberen door te drukken. Hij kan zich beter voorbereiden op de toekomst en dat begint bij het heden: weten hoe het nu zit in de organisatie en welke ontwikkelingen er gaande zijn.

Het vakgebied is steeds verder van de praktijk afgedwaald

Als er eenmaal een echte aanleiding is, en we dus moeten bewegen, is inzicht in het nu hard nodig. Hoe zit het echt met de relevante applicaties, gegevens en infrastructuur? Hoe lopen de betrokken processen? Hoe zit het met beveiliging en beheer? En vooral: hoe zit het met die aspecten die specifiek voor onze organisatie belangrijk zijn? Voor een ziekenhuis zijn dat bijvoorbeeld de patiëntveiligheid of medicatieverstrekking. Voor ProRail kunnen het de veiligheidsrisico’s op het spoor zijn. Wie alleen van een standaardmodel uitgaat, doet vaak veel te veel en mist dan alsnog vaak juist die aspecten die relevant zijn in een specifieke situatie.

Om overzicht en inzicht te bieden, visualiseert de architect het nu op een manier die mensen op de werkvloer én in het bestuur kunnen begrijpen. Wind er geen doekjes om. De blik op het nu moet realistisch zijn en tonen hoe de situatie in werkelijkheid is.

Draagvlak

Vervolgens kunnen we van die werkelijke informatievoorziening iets vinden. Zit er ergens pijn? Wat voldoet prima? Waar zijn aanpassingen nodig om ontwikkelingen te kunnen volgen of (beter) invulling te kunnen geven aan de ambities van de organisatie? Ook deze analyse moet het daadwerkelijke karakter van de organisatie respecteren. Wat zijn de echte ambities, bijvoorbeeld rond samenwerking in de keten? Wat zijn de wettelijke verplichtingen? Denk aan het bewaken van de privacy van klanten of het ontsluiten van medische gegevens aan patiënten.

Het inzicht in wat er nu is en wat er anders moet, vormt de basis voor een schets van waar het naartoe moet. Dit toekomstbeeld brengt meerdere perspectieven samen en moet begrijpelijk zijn voor iedereen die betrokken is. Ook moet het passend en haalbaar zijn voor de organisatie. Dat betekent dat in het beeld het eigen karakter van de organisatie herkenbaar is. Dus niet a priori een generiek multi-wetsysteem bedenken, maar een oplossing die rekening houdt met de verschillende uitvoeringskenmerken van die wetten. En niet het allerbeste, researchgerichte zorginformatiesysteem selecteren voor een kleine kliniek die dat niet nodig heeft en nauwelijks kan gebruiken.

Wie van een standaardmodel uitgaat, doet vaak veel te veel

Dan komt de beweging zelf, het daadwerkelijk veranderen van tastbare componenten uit de informatievoorziening. Meestal gebeurt dat in de vorm van projecten en programma’s. Om die veranderingen te kunnen richten naar het toekomstbeeld is draagvlak nodig – van de werkvloer tot aan het hoogste niveau van besluitvorming. Niet iedere verandering zal overigens altijd direct 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 immers. Bovendien wacht de wereld niet netjes met veranderen tot wij uitveranderd zijn. Het is dus zaak om continu te kijken naar de nieuw ontstane werkelijke wereld.

Luisteren

Om de veranderingen te kunnen richten is een mooie en gedragen toekomstvisie alleen onvoldoende. De architect moet monitoren welke ideeën er opkomen en hoe die passen in de visie. Besluitvorming over de voorgestelde veranderingen moet geregeld worden – en (hoog) belegd worden. De verandering zelf moet op de werkvloer plaatsvinden en de architect speelt een rol om mensen mee te krijgen. Door te helpen de schets praktisch uit te werken, door onzekerheden weg te nemen en vooral door te luisteren: tijdens de implementatie valt er voor architecten veel te leren. Een architectuur op zichzelf is niets: pas als een architect erin slaagt de informatievoorziening op basis van de papieren ideeën aan te passen, krijgt architectuur vaste vorm.

Geen reden om ingewikkeld te doen

Kortom, de architect begint in de modder, beziet de modderpoel van boven, bepaalt een richting en probeert met alle mogelijke middelen een drogere kant te bereiken. Dat het allemaal zo moeizaam gaat, is nog geen reden om heel ingewikkeld over het proces te doen.

Checklist voor effectieve architecten

Niet te ingewikkeld doen over het architectuurproces is één aspect dat kan bijdragen aan effectievere architecten en succesvollere architecturen. Een pragmatische houding van architecten is zo mogelijk echter nog belangrijker. Nu zal geen architect van zichzelf vinden te theoretisch bezig te zijn, maar het kan geen kwaad dat af en toe eens kritisch te onderzoeken. Een ICT-architect moet zich bezighouden met de dingen die er toe doen.

Dat kan aan de hand van de volgende controlevragen:

• Is het 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.

• Is het 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.

• Gaat het over werkelijke zaken?

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 samenhang die er in werkelijkheid niet is en gaan voorbij aan praktische beperkingen.

• Is het begrijpelijk genoeg?

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.

• Biedt het 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.

• Is het 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.

• Wordt de architectuur gedragen?

Een architectuur op zichzelf is 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.

 

Site auteurs

Gert Florijn, Matthijs Maat en Eelco Rommes zijn de initiatiefnemers van architectuurmeteenhoofdletterp.nl, een site met korte observaties, ervaringen en overdenkingen die gaan over effectievere architectuur.

Lees meer over Development OP AG Intelligence
3
Reacties
Anoniem 21 juni 2017 15:19

Goed artikel, is een aanzet om architectuur weer de functie te geven waar het voor bedoeld was. Eén relevant / begrijpelijk beeld geven van ..... in dit geval een ICT oplossing, zowel naar de gebruikende organisatie (klant) als naar de bouwer / beheerder.

Een beeld dat de communicatie tussen partijen over eigenschappen, rsico's, mogelijkheden en dergelijke op een relevante manier ondersteund. Niet te verwarren met een blauwdruk = de detail engineering = alle bouten en moeren en de samenhang daar van.

Anoniem 21 juni 2017 15:19

Goed artikel, is een aanzet om architectuur weer de functie te geven waar het voor bedoeld was. Eén relevant / begrijpelijk beeld geven van ..... in dit geval een ICT oplossing, zowel naar de gebruikende organisatie (klant) als naar de bouwer / beheerder.

Een beeld dat de communicatie tussen partijen over eigenschappen, rsico's, mogelijkheden en dergelijke op een relevante manier ondersteund. Niet te verwarren met een blauwdruk = de detail engineering = alle bouten en moeren en de samenhang daar van.

Anoniem 21 juni 2017 12:56

Goed verhaal. Wel maak ik onderscheid tussen ICT-Architectuur en Enterprise-Architectuur. ICT-Architectuur (of Enterprise ICT-Architectuur) gaat over de samenhang van alle aspecten binnen ICT. Enterprise-Architectuur (en daar zijn de meningen over verdeeld) gaat over de samenhang van alle aspecten binnen een organisatie. Beiden zijn relevant en hebben relaties met elkaar. Juist draagvlak vinden is het meest belangrijke voor een architect. Laat nu juist dat een beroep doen op vaardigheden die van nature bij de "meer traditionele" architect minder zijn ontwikkeld.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.