De duivelsdriehoek

Deze maand geen aflevering in de reeks don’t believe the model, don’t ignore the model, maar een bijdrage waartoe ik geïnspireerd ben door mijn bezoek aan het ‘Gartner Spring Symposium’, afgelopen april in Florence. In dit artikel wordt ingegaan op enkele onderwerpen op het terrein van de systeemontwikkeling die sterk in de belangstelling stonden.

Peter Søndergaard, directeur Gartner Research in Europa, nam de openingspresentatie van het congres voor zijn rekening. Hij begon met de uitspraak dat business alignment, de afstemming van IT op de business, niet langer een probleem is. De reden daarvoor is simpel: IT is nu de business. Hij stelde dat de samensmelting van traditionele en op internet gebaseerde ondernemingsmodellen een voorwaarde zal blijken voor succes: 95 tot 98 procent van de pure dotcoms zal de komende twee jaar niet overleven: ‘Share beats profits? Get real! When the music stops, only profitable business models survive.’

Maar ook traditionele ondernemingen bevinden zich in een bedreigde positie. Om succesvol te blijven moeten ze hybride ondernemingen worden. In de woorden van Søndergaard: van ‘brick and mortar’ naar ‘brick and click’. Ook werd gewaarschuwd voor de complexiteit van de problematiek: driekwart van de ondernemingen budgetteert hiervoor maar de helft of minder van wat nodig is. Applicatie-integratie is de kritieke succesfactor voor de transformatie van een traditionele naar hybride onderneming. Jonge web-wizards zullen moeten samenwerken met de oude garde, die alles weet van de back-ends: de ‘green hair — gray hair challenge’.

Opportunistische en systematische projecten…

Een bekende duivelsdriehoek in de systeemontwikkeling is die van kwaliteit (in ruime zin, dus inclusief functionaliteit), tijd en geld. Aan een van de hoeken iets veranderen, betekent onvermijdelijk iets voor de andere hoeken: meer kwaliteit betekent dat het project langer gaat duren en/of meer gaat kosten. Moet het voor minder geld, dan gaat dat ten koste van de kwaliteit en/of de doorlooptijd. Het ter discussie stellen van de kwaliteit ligt in de taboesfeer: dat doet een serieuze systeemontwikkelaar niet… toch?
Discussies over dit onderwerp zijn er genoeg: de eisen die gesteld worden aan de time-to-market, en dus aan de doorlooptijd van de systeemontwikkeling, zijn terecht hoog. Het onderscheid in opportunistische en systematische projecten kan misschien helpen dit onderwerp uit de taboesfeer te halen en de discussies te rationaliseren.

Systematische projecten zijn gerelateerd aan de langetermijnstrategie van de onderneming. De resulterende systemen kenmerken zich door hoge kwaliteitseisen in termen van beschikbaarheid, integriteit, schaalbaarheid, beheersbaarheid en efficiency. Maar een onderneming kent ook urgente behoeften. Systemen die, als ze te laat worden opgeleverd, helemaal niet meer nodig zijn. Het zijn projecten die bedoeld zijn om kansen (opportunities) te grijpen, vandaar de naam ‘opportunistische projecten’. Voor dergelijke projecten gelden lagere kwaliteitseisen, het mag wat kosten — effectiviteit gaat hier vóór efficiency — maar er worden zeer hoge eisen gesteld aan de doorlooptijd; het moet snel!¹

… en mislukte projecten

Het verschil tussen systematische en opportunistische projecten is geïllustreerd door een duivelsdriehoek (figuur 1). Deze duivelsdriehoek kent als hoeken complexiteit, urgentie en kans op succes. Er zijn twee vormen met een hoge kans op succes: het opportunistische project met een lage complexiteit en een hoge urgentie, en het systematische project met een hoge complexiteit en een lage urgentie. De boodschap hierachter is dat ondernemingen veeleisende back-endsystemen nodig hebben; systemen die je realiseert met systematische projecten. Ondernemingen moeten daarnaast ook kansen grijpen om ‘in business’ te blijven. En daarvoor zijn opportunistische projecten nodig. IT-afdelingen kunnen dus niet kiezen voor óf een opportunistische óf een systematische aanpak. In plaats daarvan moeten ze vaststellen voor welke projecten de systematische en voor welke de opportunistische aanpak gekozen moet worden. Beide typen projecten (en systemen) zullen naast elkaar voorkomen. Dat is lastig, maar beter dan mislukte projecten.

Figuur 1: Opportunistische, systematische en mislukte projecten (Bron: GartnerGroup)

Applicatienormalisatie

Lang geleden brak het besef door dat gegevens voor een onderneming een grote waarde vertegenwoordigen. Normalisatie van gegevens en vastlegging ervan in centrale databases maakten hergebruik van die gegevens mogelijk: zo ga je om met zaken van waarde! Op vergelijkbare wijze werd tijdens een van de presentaties op het congres applicatienormalisatie² geschetst als een aanpak die recht doet aan de waarde die code, ‘business logic’, voor een onderneming vertegenwoordigt. In traditionele monolithische applicaties is deze business logic niet toegankelijk, omdat presentatiefuncties, business logic en gegevensbenadering zijn verweven; ze vormen een bijna onlosmakelijk geheel. De oplossing voor nieuw te bouwen applicaties is het opzetten daarvan volgens een ‘service oriented architecture’, waarin programma’s (servers) aan andere programma’s de mogelijkheid bieden de business logic (service) wél afzonderlijk te benaderen. Op deze manier is een servicegeoriënteerde architectuur vooral een middel om hergebruik van de business logic mogelijk te maken. Het is echter meer: het is ook een oplossing voor het probleem van de verschillende systemen en de verschillende platformen. Herbruikbare business logic is, dankzij de servicegeoriënteerde architectuur, niet systeem- of platformgebonden. De oplossing die de servicegeoriënteerde architectuur is, brengt wel nieuwe problemen met zich mee, omdat intensieve communicatie nodig is tussen de verschillende programma’s (die vaak ook nog op verschillende systemen of op verschillende platformen draaien.) Om maar eens één probleemgebied te noemen: end-to-end transactie-integriteit. Hoeveel servers zitten er in de volgende keten: van de gebruiker die via zijn telefoon een order doorgeeft tot en met de terugmelding aan diezelfde gebruiker over de uitvoering van de order via diezelfde telefoon of via een ander door die gebruiker gekozen kanaal? Hoe communiceren deze met elkaar, synchroon of asynchroon? Hoe garandeer je voldoende beschikbaarheid en, als er beschikbaarheid is, performance — en wie garandeert dit aan wie? Wie is verantwoordelijk voor de verschillende beveiligingsaspecten authenticatie, autorisatie, ‘non-repudiation’, encryptie — en wie is precies waarvoor aansprakelijk? Niet alleen technische problemen dus; ook commerciële en juridische aspecten spelen een rol.

Figuur 2:
Interfaces tussen onderdelen zonder integration broker

Figuur 3:
Interfaces tussen onderdelen met integration broker

Middleware

De oplossing voor dit nieuwe probleem is middleware, software die een probleemloze communicatie tussen verschillende programma’s mogelijk maakt — op hetzelfde of op verschillende platformen. ‘Middleware is geen doel op zich, het is een middel. Het doel zijn effectieve gedistribueerde applicaties’. Peter Søndergaard gaf al aan dat applicatie-integratie een kritieke succesfactor is voor de transformatie van een traditionele naar hybride onderneming. Het is dus niet verwonderlijk dat op het congres verschillende presentaties werden gegeven waarin middleware centraal stond. Sleutelzinnen uit die presentaties zijn: ‘integratie blijft een probleem, het gaat niet vanzelf over — loop er dus niet voor weg’, ‘middleware is belangrijk en wordt nog veel belangrijker — verdiep je er dus in en maak weldoordachte keuzen’ en ‘middleware is ingewikkeld — onderschat het niet’.³ Vooral integration brokers kregen veel aandacht. Veel servers gebruiken betekent veel relaties tussen die servers (zie figuur 2). Naarmate het aantal servers groeit, groeit ook het aantal relaties — maar dan harder. De complexiteit hiervan kan gemakkelijk te groot worden om nog van een beheersbaar geheel te spreken. Dit kan al gebeuren in een situatie met monolithische systemen, waarbij er grotere, maar veel minder eenheden zijn. In een servicegeoriënteerde architectuur worden de relaties gedefinieerd in de vorm van services; elke service heeft zijn eigen interface. In die situatie is het aantal elementen groter, en het aantal relaties véél groter. Integration brokers vervullen een rol in het reduceren van deze complexiteit (figuur 3). Routing en vertaling van boodschappen behoren tot de standaardfunctionaliteit van een broker, additionele functies zijn denkbaar, zoals een message warehouse, een tijdelijke bewaarplaats voor berichten die (nog) niet afgeleverd konden worden. Integration brokers ontwikkelen zich uit producten die in de afgelopen tien jaar ontstaan zijn en bekend zijn onder namen als message broker, data broker, integration hub of enterprise work manager.

Goede antwoorden, goede vragen

Een goed symposium geeft antwoord op een aantal vragen. Zoals: Ja, XML gaat een rol van betekenis vervullen in de integratie- en middlewareproblematiek. Ja, de positie van Java is en wordt verder verstevigd, maar ook: Microsoft zal een eigen koers varen — sommige organisaties moeten dus kiezen, andere moeten beide doen. Nee, het mainframe is definitief niet op zijn retour, als enterprise-server staat het sterker dan ooit. Ja, beveiliging en beschikbaarheid zullen veel aandacht, tijd en geld kosten. Ja, dat geldt ook voor testen, vooral voor het end-to-end testen van nieuwe consumer facing applications (hoeveel verschillende protocollen en door serviceproviders veroorzaakte verschillen verwacht u voor internet via de mobiele telefoon?) Nee, er zijn geen tools die de integratieproblematiek end-to-end afdekken. Ja, het lijkt erop dat je als werkgever solliciteert bij een werknemer in plaats van andersom — en dat blijft nog wel even zo.
Een goed symposium stuurt bezoekers naar huis met een aantal goede, nieuwe of opnieuw geformuleerde vragen. Voor mij liggen die vooral op het terrein van hergebruik, component based development en servicegeoriënteerde architecturen. Genoeg materiaal dus voor de komende tijd…

Noten

1. ‘Het mag wat kosten’ verdient een nuance: lage toetredingskosten zijn ook van belang voor opportunistische projecten. Daarom wordt vaak gekozen voor hard- en software waarvan de aanschafkosten laag zijn. De relatief hoge kosten van gebruik en beheer zijn van minder belang omdat de verwachte levensduur van het systeem kort is.
2. Het begrip applicatienormalisatie is misleidend: Gegevensnormalisatie is een vergaand ondubbelzinnige activiteit door de wiskundige formulering van de verschillende normaalvormen. Applicatienormalisatie is dat niet; de bekende ontwerpvraagstukken generiek versus specifiek en aggregeren versus partitioneren zullen zich steeds opnieuw aandienen en principes als maximale samenhang en minimale koppelingen zullen bepalend zijn voor de keuzen die in dit ‘normalisatieproces’ worden gemaakt.
3. Quotes van Massimo Pezzini, vice-president bij Gartner.

Referentie

http://gartner12.gartnerweb.com/symposium/static/00/s_eu/home.html [Deze server bestaat niet langer, en www.gartner.com biedt geen informatie meer over dit symposium, WL, 21 maart 2010.]

oorspronkelijke publicatie: Wil Leeuwis, in: informatie, mei 2000, p. 60-62. © 2000, informatie.