Diagnose, Ontwerp en Verandering

Simpele oplossingen?

Complexe oplossingen zijn besmet. Wij mensen willen de wereld begrijpen, problemen snappen en in de IT zijn we verliefd op oplossingen zonder complexiteit. Maar houden we onszelf door het verkopen van simpele oplossingen in voor complexe IT problemen niet continue voor de gek?

De afgelopen 20 jaar is het aantal mislukte IT projecten gestaag gegroeid. Sommige IT architecten vergelijken de IT graag met de bouwsector. Dit zou wel een volwassen sector zijn, zonder het type mislukkingen waar de IT sector nog altijd zo door wordt gekenmerkt. Voor het gemak vergeten we dan maar spoortunnels die maar niet willen lukken, afbrekende balkons en de vele constructie en ontwerpfouten bij de bouw van huizen en gebouwen de kleinschaligheid zelden het nieuws halen, maar wel een trauma geven voor de opdrachtgever.

SimpelEinstein2

Complexiteit is iets wat nooit onderschat mag worden. Simpele oplossingen voor complexe problemen zijn er niet of zelden. Grote complexe trajecten in de IT kenmerken zich vaak door een lineaire aanpak. De aanpak start vaak met het vaststellen van abstracte doelen en de aandacht is vooral gericht op verbeteren van de output van de organisatie, kostenreductie en het versimpelen van het daaraan gekoppelde informatieproces. Er is vaak erg weinig aandacht voor het versterken van het leervermogen in de organisatie. Niet zelden doordat grote IT projecten naast efficiëntie verbetering ook tot een reductie van dure menselijke resources moeten leiden. Soms nog met tussenstop via sourcing naar een ander werelddeel waar menskracht en kennis goedkoper is.

Daadwerkelijke participatie van experts vanuit de organisatie voor het probleemoplossingstraject is vaak problematisch omdat bewust afstand wordt genomen van bestaande werkwijzen. In de dominante ontwerpaanpak bij oplossen van problemen worden vooral machts-, dwang- en expert-strategieën gehanteerd. En de dure externe IT consultants moeten het toch wel beter weten?

In complexe systemen bestaan geen lineaire oorzaak-gevolg relaties. Er is sprake van causale kringen die een complexere samenhang laten zien. Het in veel organisaties lineaire oorzaak-gevolg denken bij IT problemen leidt tot een ernstige reductie van de werkelijkheid en het negeren van de vele dimensies van de complexiteit. Ook bij IT problemen. Veel interventies bij IT problemen die op simpele oorzaak gevolg relaties zijn gebaseerd slaan de plank dan ook bijna altijd mis.

swissarmknife

Complexiteit ontstaat vanuit relaties van elementen in een systeem, interacties en relaties vanuit een systeem met een ander systeem en relaties met de omgeving. Een IT oplossing dient altijd te werken in interactie met een omgeving. Een omgeving is zelden 100% onder controle. Het gedrag van mensen, de klanten, die gebruik moeten maken van internet kanalen en apps blijkt vaak lastig te voorspellen. Maar ook de enorme complexiteit van infrastructuur en applicatielagen is lastig te doorzien. Relaties en afhankelijkheden blijken vaak net anders te zijn dan aangenomen.

Het rationeel volgens een architectuurmethodiek ontwerpen van een groot complex IT systeem aan de hand van geanalyseerde requirements is vaak onmogelijk. Het aantal elementen, relaties en combinaties is daarvoor bij grote complexe systemen gewoon te groot. En omdat we toch steeds sneller, betere en complexe systemen op de markt willen zetten is architectuurbenadering, waarbij de complexiteit weer hanteerbaar wordt gemaakt, cruciaal. Gelukkig zijn voor complexe IT problemen vele systeembenaderingen mogelijk om sneller tot resultaat te komen. In de wat meer ‘traditionele’ IT architectuur methoden, zoals TOGAF, is helaas nog weinig ruimte gemaakt voor deze wetenschappelijke inzichten vanuit systeembenaderingen om complexiteit beter beheersbaar te maken.

easy