Dré de Man

Grote softwareprojecten mislukken vaak, zegt IT-complexiteitsdeskundige Roger Sessions. Dat komt doordat de faalkans exponentieel stijgt met de complexiteit van een project. Dat kost alleen in de VS al meer dan een biljoen dollar per jaar. Sessions heeft zich jarenlang beziggehouden met de oorzaken en de gevolgen daarvan, en biedt oplossingen gebaseerd op een wiskundig model.

Je moet dingen zo eenvoudig mogelijk maken, maar niet eenvoudiger. Roger Sessions heeft deze uitspraak van Einstein niet alleen tot zijn lijfspreuk gemaakt, maar zelfs een (toegegeven, niet echt eenvoudige) methode ontwikkeld om IT-systemen precies zo eenvoudig te maken als nodig. Sessions zou het moeten weten; hij heeft bij IBM aan de wieg gestaan van een technologie om complexe systemen met elkaar te verbinden en heeft veel grote IT-systemen van nabij gezien. Nu verdient hij zijn brood met eenvoud; beter gezegd, hij leert bedrijven en architecten hoe ze IT-systemen minder complex kunnen maken. Volgens Sessions zijn er in Nederland besparingen van 58 miljard euro per jaar mee te behalen, zo veel dat alle bezuinigingen van een volgende kabinet er overbodig door worden.

Sessions ziet grote mogelijkheden wanneer IT-systemen vereenvoudigd zouden kunnen worden. Het is dan ook veel eenvoudiger ze op één lijn te brengen met eisen van de bedrijfsleiding (de business). Een doorsnee bedrijf zou 10-20 procent van de kosten – zowel directe als indirecte kosten – kunnen besparen door eenvoudiger software in te zetten. Je kunt er ook positief naar te kijken: welke mogelijkheden ontstaan er door eenvoudiger en beter werkende software?

Zo rooskleurig is de situatie echter niet. In de afgelopen decennia is de complexiteit en de daarmee verband houdende inefficiëntie van systemen alleen maar toegenomen. De gegevens met betrekking tot het falen van IT-systemen laten een duidelijke groei zien.

Sessions: ‘Als je een auto koopt van 100.000 euro mag je verwachten dat die ook veel beter en betrouwbaarder zou zijn dan eentje van 10.000 euro. In de IT is het zo dat naarmate je meer uitgeeft, het waarschijnlijker wordt dat het systeem je zal teleurstellen. Er is een hele reeks van studies die dat bevestigen. Als je een IT-systeem aanschaft van 500.000 pond, dan heb je een kans van 75 procent dat het succesvol is, in termen van het op tijd en binnen budget bereiken van de gestelde doelen. De kansen dat een project de gestelde doelen qua functionaliteit, budget en tijd haalt, zijn bij een project van vijf miljoen vrijwel nul. Complexiteit stijgt namelijk exponentieel met de grootte van een project.' [Met de macht 3.5, DdM.]

U beschrijft dat heel goed in uw boek, en geeft er zelfs formules voor, zowel vanuit het perspectief van de ontwikkelaar als voor de business analist. Toch vrees ik dat niet iedereen de consequenties ervan echt doorziet.

Sessions: 'Complexiteit wordt geregeerd door wat ik de wet van Glass noem. Glass stelt dat wanneer dat functionaliteit van een systeem toeneemt met 25 procent, de complexiteit met meer dan 100 procent toeneemt. De implicaties daarvan zijn enorm. Er wordt vaak gedacht dat je projecten alleen maar in stukjes hoeft te hakken om de complexiteit te doen afnemen, maar daardoor neemt het aantal verbindingen tussen de systemen weer toe. De complexiteit neemt echter even sterk toe als je het aantal verbindingen tussen systemen laat toenemen, dus je komt van de regen in de drup, wanneer je er niet op heel goed op let dat het aantal verbindingen beperkt blijft. Het is echt dansen op het slappe koord. Je hebt dus een methode nodig om tot zo simpel mogelijke oplossingen te komen.' 

Verwacht u iets van de nieuwe ontwikkelingen als SOA en cloud computing wanneer het gaat om het oplossen van de problemen rond complexiteit?

Sessions: ‘Cloud computing lost deze problemen niet op. Het is slechts een platform. Wanneer je een complex systeem naar de cloud brengt, neemt de complexiteit helemaal niet af. SOA’s laten de complexiteit in het algemeen al evenmin afnemen. Hoewel ze het vaak mogelijk maken kleinere systemen te bouwen, vergroten ze de complexiteit van de connecties dramatisch. SOA kan een deel van de oplossing zijn, maar er zijn veel complexe SOA’s en er zijn ook veel mislukkingen op dat gebied. Die ontstaan doordat men niet begrijpt hoe de complexiteit van de verbindingen de SOA beïnvloedt.' 

Verbindingen tussen applicaties kunnen in hoge mate bijdragen tot de complexiteit.

Sessions: ‘De sterkste connecties is synchroon, en introduceert een transactie tussen twee services. Zo’n transactie is echter erg complex. Je kunt hem simpeler maken door in de eerste plaats de transactie weg te nemen, en vervolgens de synchroniteitseis weg te nemen. Het is dus een zaak van het aantal verbindingen maar ook van de aard ervan. Wat je eigenlijk zou moeten doen, is een basisarchitectuur op businessniveau ontwerpen om vervolgens die architectuur door de data en technische architectuur te projecteren. Dat is echter niet eenvoudig. Het bouwen van complexe systemen is heel gemakkelijk. Het bouwen van eenvoudige systemen is heel moeilijk, maar uiteindelijk zijn het alleen de eenvoudige systemen die werken.’

Ook bij het aanpassen van bestaande systemen kan complexiteit goed aangepakt worden. Sessions ziet ook daar vooral brood in een goede opdeling van de functionaliteit in partities.

Sessions: 'Wanneer je een groot probleem hebt waarbij je niet goed begrijpt waar het zit, dan helpt een complexiteitsanalyse heel erg goed. Het werkt ook wanneer je erover denkt een groot systeem te kopen, zoals een ERP-systeem. Het is dan van groot belang om te kijken of de manier waarop functies zijn georganiseerd in het systeem past bij de organisatie van die functies binnen je organisatie. Wanneer die match er niet is, dan introduceer je een grote complexiteit en daarmee veel fouten. Dat is ook de reden waarom zo’n systeem bij de ene organisatie heel goed functioneert en bij een andere organisatie die op het eerst gezicht erop lijkt, helemaal niet. Je kunt dus de vraag of bijvoorbeeld SAP geschikt is voor je bedrijf niet beantwoorden door te kijken naar de functionaliteit. Veel belangrijker is de vraag: is het op dezelfde manier gepartitioneerd als mijn organisatie?'