Ultraflexibiliteit – een model voor soepel evoluerende software Flexibiliteit van software is een populair thema. Zeker met het oog op de rigiditeit van vele legacy systemen is die belangstelling goed te begrijpen. Veel voorstellen om flexibiliteit van software te vergroten zijn op de keper beschouwd puntoplossingen. Ze maken het mogelijk om een specifiek aspect van een complex softwaresysteem flexibeler te maken. In dit artikel wordt betoogd dat dit in de praktijk per definitie de beoogde flexibiliteit beperkt. De echte oplossing moet gezocht worden in een architectuur die flexibele subsystemen op een flexibele manier verenigt – een ultraflexibele architectuur.
Productontwikkeling Als de voortekenen niet bedriegen, en auteurs zoals Chris Anderson [1] en Don Tapscott [2] gelijk krijgen, dan gaan we een tijd tegemoet waarin voorheen verwaarloosde economische niches een interessant jachtterrein worden voor slimme leveranciers. Denk maar aan een beleggingsfonds dat belegt volgens een speciale ethische code – bijvoorbeeld afgestemd op vegetariërs – of een TomTom speciaal voor natuurvorsers. Dat betekent wel dat die producten zodanig vorm moeten krijgen dat ze een specifieke doelgroep aanspreken. Er worden dus nieuwe productvarianten met specifieke producteigenschappen bedacht. Het soepel kunnen omgaan met de resultaten van zo’n creatief proces levert interessante uitdagingen op voor een toekomstvaste architectuur. Traditionele manieren van productontwikkeling worden idealiter gedreven door een grondig onderzoek van de doelgroep. Zo’n onderzoek moet antwoord geven op vragen als: wat vinden potentiële klanten belangrijk wat vinden ze mooi of lekker – of juist niet wat zijn ze bereid te betalen Die antwoorden moeten de keuzes die tijdens de productontwikkeling worden gemaakt op een objectiveerbare manier onderbouwen. Er zijn verschillende redenen waarom een dergelijke benadering voor niche-producten niet voldoet. Ten eerste is het lang niet altijd makkelijk om een representatieve vertegenwoordiging van een doelgroep in een klantenpanel bijeen te brengen. Ten tweede is het een tijdrovend proces – tijd die de concurrent kan gebruiken om de toch al niet al te omvangrijke markt als eerste te betreden. En ten derde is het een kostbaar proces. De ontwikkelingskosten voor doelgroepenproducten mogen natuurlijk niet al te zwaar op de kostprijs gaan drukken. Stuk voor stuk redenen waarom zulke producten tot voor kort maar mondjesmaat ontwikkeld werden. Tegenwoordig zoeken bedrijven manieren om zo snel en goedkoop mogelijk speciale doelgroepproducten op de markt te brengen, om vervolgens met de feed-back van de markt een proces van verbetering en verfijning in te gaan. Een soort eXtreme Productontwikkeling. En mocht een product onverhoopt totaal niet aanslaan, dan is er nog geen man overboord, want er hoeft maar een minimale investering afgeschreven te worden. In het verlengde hiervan is het van wezenlijk belang dat de informatiearchitectuur dit ontwikkelingsproces ondersteunt. Dat stelt nieuwe eisen aan de flexibiliteit van systemen. “Ze weten nog niet precies wat ze willen” is een realiteit waar architecten mee moeten leren omgaan. In dit artikel wordt een manier geschetst om dit met inachtneming van de principes van een service georiënteerde architectuur te realiseren. Hierin staat een “soepel product” centraal, waarmee wordt aangegeven dat het product zo is ontworpen dat het in principe kan evolueren in elke richting die de business vraagt.
Een praktijkvoorbeeld Dit is niet het eerste artikel waarin de zoektocht naar de heilige graal van flexibiliteit, wendbaarheid of toekomstbestendigheid van software wordt beschreven. In tegendeel. Er zijn al vele methoden en technieken voorhanden. Denk maar aan business process management systemen of aan business rule engines. Sterker nog, was “agility” niet het “unique selling point” van de Service Georiënteerde Architectuurstijl? Allemaal waar. Maar toch blijkt keer op keer weer in de praktijk dat de geboden flexibiliteit de nodige beperkingen heeft. Dat toch weer net datgene wat voor een nieuw product nodig is, er niet lekker in zit. Of dat er in elk geval niemand te vinden is die weet hoe je een nieuwe behoefte moet vertalen in regels en modellen om te bereiken wat er wordt gevraagd. Neem nou de wereld van verzekeringen Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 1
en pensioenen. Die is behoorlijk in ontwikkeling. Je ziet daar een opkomst van doelgroepproducten. Een zorgverzekering speciaal voor vegetariërs, een overlijdensrisicoverzekering speciaal voor patiënten met suikerziekte en een annuleringsverzekering die uitkeert als het Nederlands elftal de finale van het EK-voetbal haalt. En dat is nog maar het topje van de ijsberg. Laten we eens een praktijkvoorbeeld bij de kop pakken. Neem een (aanvullende) verzekering waarvan de premiehoogte afhangt van de body-mass index (BMI). Mensen met een gezond gewicht betalen een lagere premie dan mensen met overgewicht of ondergewicht. Bij extreem over- of ondergewicht valt iemand buiten de doelgroep en moet een aanvraag worden afgewezen. Het verzekeringsproduct omvat verder een kortingsregeling voor een cursus Sonja Bakker en een abonnement op een fitnesscentrum. Een relatief simpel product gericht op mensen die bereid zijn om te investeren in hun gezondheid. Verzekeraars zijn anno 2008 vaak wel in staat om een verzekeringsproduct op te bouwen uit herbruikbare productcomponenten. Een WA-dekking en een Casco-dekking vormen samen een AllRisk product – al of niet aangevuld met een dekking voor rechtshulp in het buitenland. De productcomponent voor WA-dekking wordt natuurlijk ook gebruik voor een WA-verzekering of een WA-plus verzekering. Toch vormen in ons voorbeeld de “oneigenlijke” productcomponenten niet zelden een probleem. Verzekeraars denken van origine in risico’s en dekkingen, en de gemiddelde administratie heeft een verzekeringsproduct ook op zo’n manier gemodelleerd. Het past lang niet altijd in het bestaande systeem dat er pure kostencomponenten als abonnementen en kortingen bij een verzekering meeverkocht worden. De BMI als premiebepalende factor en als acceptatiecriterium zou in moderne omgevingen eigenlijk geen probleem mogen zijn. Een business rule engine is bij uitstek in staat om de rekenregel te valideren die nodig is om vast te stellen of iemand met een bepaald gewicht en lengte binnen of buiten de range valt die een gezond gewicht veronderstelt. Maar ja, dan moet je wel eerst de lengte en het gewicht van een verzekerde persoon kennen. Dus je moet de schermen aanpassen, de B2Binterfaces – en misschien ook wel de interne interfaces – en je moet de productservice aanpassen om de extra attributen in de database op te kunnen slaan. Al met al is de flexibiliteit die een rules engine biedt nog niet genoeg om zo’n nieuw product zorgeloos te kunnen implementeren. Als je even over dit voorbeeld doordenkt, dan is de veranderingsdrempel in werkelijkheid nog een stukje hoger. Want bij de meeste mensen is het gewicht aan verandering onderhevig. Dat betekent dat de gegevens in de database in de loop van de tijd hun betrouwbaarheid verliezen. Dat betekent ook dat er een nieuw bedrijfsproces gedefinieerd moet worden om die gegevens regelmatig te actualiseren. En dat proces moet getriggerd worden door een nieuw businessevent – laten we zeggen op twee maanden voor de prolongatiedatum. Het genereren van zo’n nieuw event en het vastleggen van de complete flow om het event af te handelen – opbellen, emailen en/of brief versturen, zonodig herinneringen versturen, het antwoord verwerken en het uitblijven van een antwoord afhandelen – het hebben van een modelgedreven workflowsysteem helpt, maar is nog geen garantie voor instant succes.
Ervaringen uit het verleden Veel van de geschetste problematiek is door leveranciers al eerder opgelost. Er zijn standaard systeemcomponenten op de markt waarmee verzekeraars hun eigen producten kunnen definiëren, met productcomponenten die aan een risico gekoppeld zijn, en productcomponenten die een vaste inkoopprijs hebben. De schermen passen zich automatisch aan de door de verzekeraar zelf gedefinieerde productkenmerken aan en het staat de verzekeraar vrij om per product zijn eigen regelingen in te voeren. Dit zijn oplossingen die vandaag al een mate van flexibiliteit bieden die ook in de toekomst nodig blijft. Het zijn oplossingen waarin vele praktijklessen op het gebied van flexibiliteit al zijn ingebed. In de huidige moderniseringsgolf dreigen de lessen uit het verleden opnieuw geleerd te moeten worden. Onder het motto “met SOA wordt alles anders en beter” is het radicaal loskoppelen van presentatie-, bedrijfsproces- en informatieverwerkingslogica tot principe verheven. Met de inzet van business rule engines en/of business process management systemen wordt flexibiliteit ingebakken – althans in theorie. Maar het besef dat de inzet van deze technieken niet automatisch de gezochte flexibiliteit gaat realiseren, is nog lang niet overal doorgedrongen. Het wordt tegenwoordig algemeen erkend dat het goed is om een ingewikkeld systeem op te delen in eenvoudigere deelsystemen met elk een duidelijk afgebakende verantwoordelijkheid – in het jargon: gesepareerde concerns. Maar het inzicht dat het een illusie is om te denken dat een eigenschap zoals flexibiliteit iets is waarvoor je één subsysteem speciaal verantwoordelijk zou kunnen maken, is bepaald nog geen gemeengoed. Het begrip dat een flexibel systeem juist hele hoge eisen stelt aan een soepele samenwerking van de verschillende onderdelen, dringt ook nog maar langzaam door. Neem nou als voorbeeld het concept business rules. Dat is typisch zo’n subsysteem om flexibiliteit te bieden. Eén van de meest gezaghebbende auteurs op dit terrein is Barbara von Halle. In haar boek Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 2
“Business Rules Applied” legt ze uit dat “a system built according to business rules methodology should [be] based on a very stable data model” [3]. Data analyse is dan ook een van de hoekstenen van haar “business rules approach”. Als het datamodel stabiel is, dan mag de rest flexibel zijn, zo lijkt de gedachte. En toch blijkt het in de praktijk keer op keer enorm handig te zijn om nieuwe producten te kunnen baseren op nieuwe regels die gebruik maken van nieuwe productkenmerken – nieuwe feiten in het jargon van business rules. Denk maar aan ons voorbeeld van de BMI-kenmerken. Maar hoe moet dat dan in de praktijk, als daarvoor eerst een aanpassing van het datamodel nodig is? In de betere polissystemen kan zo’n nieuw productkenmerk al lang dynamisch gedefinieerd en meteen gebruikt worden. En die dateren nog van de tijd voordat SOA in zwang raakte. Het zou toch zonde zijn als zo’n verworvenheid dankzij technologische ontwikkelingen verloren zou gaan? Maar zou er geen synthese mogelijk zijn tussen de SOA architectuurprincipes en de best practices uit bestaande praktijk? Zijn ze fundamenteel onverenigbaar, of zouden ze elkaar juist kunnen versterken?
Ingrediëntenmix voor soepel evoluerende software Voor het ontwikkelen van een soepele productservice, een service dus die in staat is om met minimaal onderhoud aan de programmatuur de huidige en toekomstige producten te bedienen, moeten er allerlei verschillende functies gerealiseerd worden die op verschillende niveaus verschillende vormen van flexibiliteit bieden. Neem aan dat zo’n service geschikt moet zijn om een product langs meerdere kanalen aan te bieden, om er verschillende labels aan te koppelen en liefst ook nog om op meerdere gebruikersplatformen aangeboden kan worden – denk daarbij bijvoorbeeld aan de Windows desktop, de webbrowser en de iPhone. Laten we er om de gedachten te bepalen eens van uitgaan dat een soepel verzekeringsproduct slechts vijf verschillende services biedt (zie figuur 1). Transactionele services o Productselectie o Premieberekening o Acceptatiecheck Inrichtingsservices o Productdefinitie o Productfiattering Inrichtingsservices Product Definitie
Transactionele services Product Fiattering
Product Selectie
Premie Berekening
Acceptatie Check
Soepel Verzekerings Product
Figuur 1:: Service decompositie Deze services moeten naar de gebruiker toe de schermen, rapporten en correspondentie kunnen leveren die nodig is om het product gedurende de gehele levenscyclus te voeren. Uiteraard is er daarbij een functie nodig om label-, kanaal- en platformspecifieke opmaak te verzorgen. Voor het koppelen van externe systemen zal het daarnaast nodig zijn om sommige services te ontsluiten voor de buitenwereld. Daarbij dient rekening gehouden te worden met een veelheid aan berichtformaten en protocolstandaarden – reden om een transformatiefunctie te voorzien (zie figuur 2).
Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 3
Opmaak voor label, kanaal en platform Schermen
Rapporten
Inrichtingsservices Product Definitie
Transformatie
Correspondentie
B2B Functies
Transactionele services Product Fiattering
Product Selectie
Premie Berekening
Acceptatie Check
Soepel Verzekerings Product
Figuur 2:: De productservices productservices in hun interactie met de buitenwereld Om deze services te kunnen bieden moeten er verschillende basisfuncties worden gerealiseerd. Om te beginnen is er een kernproduct nodig. Dit bevat de kernfunctionaliteit die nodig is voor ieder of vrijwel ieder verzekeringsproduct – denk aan begrippen als verzekerd risico, dekking, clausule en dergelijke. Uiteraard is het wenselijk dat kernproduct de mogelijkheid heeft om een product flexibel op te bouwen uit productcomponenten – hetzij risicocomponenten, hetzij kostencomponenten. We hebben al gezien dat het vaak nuttig is om een kernproduct flexibel uit te kunnen breiden met additionele kenmerken om er een maatwerkproduct van te kunnen maken. Dit is geen triviale functie, want zulke kenmerken kunnen om te beginnen datatechnisch allerlei verschillende eigenschappen hebben (getal, string, keuzelijst). Maar om echt flexibel met zulke kenmerken om te kunnen gaan moeten ze niet alleen vastgelegd kunnen worden, maar ook onder de juiste condities en op de juiste manier gepresenteerd en gevalideerd kunnen worden én ze moeten getransformeerd kunnen worden uit inkomende en naar uitgaande berichten. We hebben al vastgesteld dat alleen flexibiliteit voor in/uitvoer en voor dataopslag niet voldoende is. Voor verschillende producten gelden verschillende acceptatieregels en de formule om een premie te berekenen is niet alleen voor ieder product verschillend, maar ook nog eens regelmatig aan verandering onderhevig. Dit is allemaal logica die heel goed op basis van flexibele bedrijfsregels op te lossen is. Uiteraard worden die regels gebaseerd op welgedefinieerde begrippen – regels worden immers gebouwd op feiten uit de data en termen uit de metadata. Het is daarom zinvol om de metadata die in regels wordt gebruikt in een aparte gegevenscatalogus vast te leggen. Tenslotte moeten we nog een functie benoemen die businessevents kan genereren. Op het eerste gezicht is die functionaliteit vergelijkbaar met die voor berekeningen en beslissingen – als een bepaald feit zich voordoet, dan moet er een event worden gegenereerd. Het verschil is echter dat regels passief zijn – ze worden pas uitgevoerd als ze worden aangeroepen – en businessevents moeten juist actief gegenereerd worden – ze initiëren immers een werkstroom (zie figuur 3). Soepel Verzekerings Product
Generieke bronsystemen Gegevens Catalogus
Metadata service
Specifieke bronsysteem Berekeningen & Beslissingen
Regeling service
Event Generatie
Event service
Extra Product Karakteristieken
Kern Product
Veredeld Product Service
Figuur 3:: De bronnen van een soepel verzekeringsproduct verzekeringsproduct We zijn nu dus flexibel in de interactie met de buitenwereld, in de gegevensverwerking, in de business logica en we kunnen zelfs op een flexibele manier businessprocessen starten. En toch zijn Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 4
we er nog niet. We missen nog een deel van het totale spectrum. We hebben nog geen functie onderkend voor het flexibel maken van de flow, de doorstroming. Er worden tegenwoordig op verschillende niveaus separate stromen onderkend. De werkstroom in een werkproces is een bekend concept. Hierin ligt de volgorde vast van de activiteiten die uitgevoerd moeten worden om een bepaald product of dienst aan een klant te leveren. Net zo goed als er een stroom van menselijke activiteiten is, is er ook een stroom te onderkennen in de taken die een softwaresysteem uitvoert – de processing flow – zoals de verwerkingsketen: 1. de aangeleverde gegevens valideren 2. de aangeleverde gegevens verrijken (het verzamelen van de relevante feiten) 3. met de gegevens een berekening of bewerking uitvoeren 4. het resultaat opslaan 5. het resultaat aanbieden De paginastroom is de laatste waarin voorzien moet worden. Bij slimme elektronische formulieren is er een – vaak contextafhankelijke – gefaseerde interactie tussen de gebruikers en het systeem. Dat is zo bij het elektronisch invullen van het belastingformulier, maar dat is natuurlijk net zo relevant bij een elektronische schademelding of bij het elektronisch aanvragen van een hypotheek of verzekering. En pas als het hele formulier correct is ingevuld, dan wordt het businessevent gegenereerd dat de werkstroom start (zie figuur 4).
Soepel Verzekerings Product
Pageflow Workflow Processing Flow
Figuur 4 : Flexibele doorstroming Nu is de synthese van bewezen flexibele oplossingen en service georiënteerde architectuurprincipes een feit. Het model voorziet hiermee en passant in alle aanpassingen die voor het introduceren van een BMI-productvariant nodig zouden zijn. Het is immers mogelijk gemaakt om voor het product nieuwe feiten te definiëren – zoals lengte en gewicht – in de gegevenscatalogus. De veredelde productservice zal deze nieuwe feiten als extra product karakteristieken in de database opslaan. En de slimme schermen kunnen deze extra product karakteristieken automatisch vertalen in additionele vragen op het vragenformulier. Desgewenst kan de pageflow aangepast worden aan de antwoorden die op de nieuwe vragen worden gegeven. In de regelingservice kunnen de bedrijfsregels gedefinieerd worden die voor het accepteren van de aanvraag en het berekenen van de premie uitgevoerd worden. Er kunnen ook transformatieregels opgevoerd worden voor de ondersteuning van B2B-koppelingen – uiteraard binnen de grenzen van wat de bestaande koppeling mogelijk maakt. Het is zelfs mogelijk om een wekker-event op te voeren dat op een gewenst moment een nieuw bedrijfsproces initieert om de BMI-gegevens te actualiseren. Uiteraard zal een business analist na moeten denken over de precieze inrichting van dit nieuwe proces, en de workflow moeten modelleren. Gegeven de ingebouwde flexibiliteit wordt het voor deze analist wel aantrekkelijk om voor dit proces in eerste instantie een lichtgewicht implementatie te kiezen en pas als het nieuwe product blijkt aan te slaan en er ervaring met het nieuwe proces is opgedaan een meer geavanceerde implementatie door te voeren. eXtreme Productontwikkeling hoeft geen utopie te blijven.
Conclusie Dit artikel beschrijft een modelarchitectuur om te voorzien in een typische, hedendaagse behoefte aan flexibiliteit van organisaties die informatie-intensieve producten leveren op een sterk competitieve markt. Het voorbeeld is toegespitst op een verzekeringsproduct, maar het is evenzeer toepasbaar op producten van banken, leasemaatschappijen en telecom service providers. En ook binnen verzekeraars zal deze architectuur niet alleen voor productmanagement, maar bijvoorbeeld ook voor claimsmanagement ingezet kunnen worden. Het is een architectuur die laat zien dat het netelige thema flexibiliteit wel degelijk conform de service georiënteerde architectuurprincipes vormgegeven kan worden. Het laat ook zien dat verschillende aspecten van flexibiliteit op verschillende plaatsen in de architectuur vorm moeten krijgen om echt soepel mee te kunnen bewegen met wijzigende wensen en behoeftes uit de business. Het flexibel koppelen van flexibele deelsystemen vereist in feite een ultraflexibele architectuur.
Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 5
Opmaak voor label, kanaal en platform Schermen
Rapporten
Inrichtingsservices Product Definitie
Transformatie
Correspondentie
B2B Functies
Transactionele services Product Fiattering
Product Selectie
Premie Berekening
Soepel Verzekerings Product
Generieke bronsystemen Gegevens Catalogus
Metadata service
Acceptatie Check
Pageflow Workflow Processing Flow
Specifieke bronsysteem Berekeningen & Beslissingen
Regeling service
Event Generatie
Event service
Extra Product Karakteristieken
Kern Product
Veredeld Product Service
Figuur 5:: het complete referentiemodel voor een ultraflexibele architectuur De vraag of je de flexibiliteit zodanig zou kunnen realiseren dat complexe producten zonder tussenkomst van IT-ers, door bijvoorbeeld productspecialisten zelf ingericht zouden kunnen worden, het self-service model, valt buiten het bestek van dit artikel. Echter, gegeven de inherente complexiteit die de wens van flexibiliteit met zich meebrengt, zou het geen verbazing mogen wekken als blijkt dat er bepaalde specialistische kennis en vaardigheden nodig blijven om ultraflexibele systemen slim in te richten. Hans Bot Hans Bot is Managing Architect bij Aquila: Achitect voor de verzekeringsketen en gastdocent enterprise architectuur bij DNV-CIBIT. Hij is actief in het Nederlands Architectuur Forum, supporter van het Landelijk Architectuur Congres en mede-oprichter van het Nederlands Kampioenschap ICT Architectuur. Met dank aan Mark Tuente voor zijn waardevolle feed-back. Noten [1] Chris Anderson: “The Long Tail: Why the Future of Business is Selling Less of More”; 2006. [2] Don Tapscott and Anthony D. Williams: “Wikinomics: How Mass Collaboration Changes Everything”; 2006. [3] Barbara Von Halle: “Business Rules Applied: Building Better Systems Using the Business Rules Approach”; 2001, p. 53.
Verschenen in LAC Jaarboek 2008: Architectuur maakt de toekomst mogelijk
Pagina 6
