Hoe architectuurprincipes je kunnen onderscheiden van de concurrent

Benny Prij, vrijdag 04 september 2009

Toepassing van architectuurprincipes bij TKP Pensioen

Het is belangrijk om een duidelijke visie te hebben als organisatie om je te onderscheiden van je concurrenten. Door deze visie te vertalen in een aantal heel fundamentele principes zorg je dat je deze ook kunt omzetten in realiteit. Dit artikel beschrijft een aantal principes die TKP Pensioen heeft gekozen bij het inrichten van haar informatievoorziening, en de wijze waarop dit heeft bijgedragen in haar onderscheidend vermogen ten opzichte van andere pensioenuitvoerders.

Inleiding

TKP Pensioen is een algemeen pensioenuitvoerder voor enkele tientallen ondernemings-pensioenfondsen. Het bedrijf is op 1 januari 1989 ontstaan bij de privatisering vanuit de overheid van de Koninklijke PPT Nederland. In de eerste jaren werd alleen de pensioen-administratie voor de werknemers van KPN gevoerd. In 1998 werd KPN opgesplitst in KPN Telecom en TPG Post. Dit betekende dat er twee afzonderlijke pensioenfondsen (met eigen pensioenregelingen) ontstonden waarvoor de administratie moest worden uitgevoerd. Op 1 januari 2003 werd TKP overgenomen door Aegon Nederland waarna het bedrijf als algemeen pensioenuitvoerder ook diensten voor andere pensioenfondsen ging verrichten.

Nederland kent twee soorten pensioenfondsen namelijk Ondernemingspensioenfondsen (OPF-en) en Bedrijfstakpensioenfondsen (BPF-en). Een ondernemingspensioenfonds is specifiek voor de werknemers van één bedrijf (onderneming). Een bedrijfstakpensioenfonds moet de pensioenen voor de werknemers van alle bedrijven in een specifieke branche (bijv. vervoer, metaal, bakkersbedrijven,etc.) verzorgen. Nederland kent enkele honderden OPF-en en een zestigtal BPF-en.

Met het oog op de splitsing van KPN in 1998 is besloten een nieuw informatiesysteem te ontwikkelen om de uitvoering van meerdere pensioenregelingen te kunnen ondersteunen. Het op dat moment in gebruik zijnde systeem kon dat niet. Tevens moesten op dat moment nog niet bekende, maar wel verwachte, ontwikkelingen op pensioeninhoudelijk vlak door het te ontwikkelen systeem ondersteund kunnen worden. In de ontwerpfase van dit systeem, in 1996, zijn er daarom enkele principes vastgesteld welke het mogelijk moesten maken om bovenstaande eisen te realiseren. Tevens moesten de problemen in de bestaande administratieve processen (en systemen), zoals de verwerking van terugwerkende kracht mutaties (uitleg zie volgende paragraaf) opgelost worden.

Om verdere (versnelde) groei te kunnen realiseren heeft TKP in 2007 besloten om naast OPF-en ook de markt van de pensioenadministratie voor BPF-en op te gaan. Om deze klanten te kunnen bedienen moesten enkele bedrijfsprocessen (zoals gegevensinwinning en premieoplegging en –inning) op andere wijze ingericht worden. Om dit ontwikkeltraject te ondersteunen zijn de enterprise-architectuur en de referentie-architectuur in 2009 geactualiseerd, en gestructureerd beschreven. De hierbij geïnventariseerde architectuur-principes zijn (opnieuw) door het management onderschreven. In de volgende paragraaf worden de architectuurprincipes verder toegelicht.

De principes

TKP was er bij het ontwerp van het informatiesysteem van overtuigd dat de door hen vastgestelde architectuurprincipes essentieel waren voor het realiseren van de bedrijfsdoelstellingen. In de loop der jaren is men meer en meer overtuigd geraakt van het feit dat juist de realisatie en handhaving van deze principes voorwaardelijk zijn geweest voor het behalen van haar successen in de pensioenmarkt. Wel is gebleken dat bij grotere bedrijfsmatige ontwikkeltrajecten de vertaling van de bedrijfseisen naar te realiseren systeemfunctionaliteit de architectuurprincipes vaak opnieuw uitgelegd (en verdedigd) moesten worden. Mede daarom is besloten om bij de ontwikkeling van de benodigde extra systeemfunctionaliteit voor de uitvoering van BPF administraties, de enterprise-architectuur en de daarin opgenomen de architectuurprincipes op gestructureerde manier te beschrijven en deze (opnieuw) door het management te laten vaststellen. In de uitvoering hiervan werd gekozen voor de door ArchiXL beschreven aanpak [Greefhorst, 2009].Twee principes, zoals ze in de enterprise-architectuur van TKP zijn opgenomen zullen hier nader worden toegelicht.

Het eerste principe betreft het scheiden van applicatiefunctionaliteit en specifieke businessfunctionaliteit. Anders gezegd, pensioeninhoudelijke aspecten van te administreren regelingen zijn niet (hard) gecodeerd in applicatiefunctionaliteiten. Dit principe is ontstaan vanuit de oorspronkelijke ontwerpopdracht om goed om te kunnen gaan met nog niet gespecificeerde veranderingen in pensioenregelgeving. In de loop der jaren is dit ook een sterk principe gebleken waar het het opnemen van nieuwe klanten (pensioenregelingen) in het systeem betrof.

Het principe is gerealiseerd door alle pensioentechnische bedrijfsregels (het “wat”), op basis van een productstructuur, uit te voeren met behulp van een rule-engine. “Hoe” deze bedrijfsregels voor klanten uitgevoerd moeten worden is, op basis van voorgedefinieerde standaardprocessen in een case managementtool, klantspecifiek ingeregeld. Door dit principe op deze wijze toe te passen krijgt elke klant (elk pensioenfonds) toch maatwerk geleverd. Dit blijkt, op grond van periodiek uitgevoerd onderzoek, te resulteren in een hoge klant-tevredenheid.

Verder wordt dit principe gerealiseerd door het datamodel generiek (bijna object georiëntieerd) te modelleren. Hierdoor heeft uitbreiding van vast te leggen variabelen (parameters) geen verandering in het model op zich tot gevolg. Het datamodel is sinds het ontwerp van het systeem dan ook nog nooit gewijzigd ondanks het feit dat het aantal geadministreerde pensioenregelingen is gegroeid van 4, bij in productie gaan van het systeem in 2000, naar 21 in 2009. In figuur 1 is weergegeven hoe dit principe is beschreven in de enterprise-architectuur.

Het tweede principe schrijft voor dat er niet wordt gewerkt op basis van afgeleide gegevens. Dit houdt in dat uitkomsten altijd moeten worden bepaald op het moment dat ze nodig zijn. Deze worden altijd gebaseerd op de in de database aanwezige feiten (basisgegevens).

Dit principe is in feite ontstaan vanuit de problematische (complexe) manier waarop systemen tot op dat moment met de zogenaamde terugwerkende kracht mutaties (TWK-s) omgingen. Een TWK is een wijziging van een pensioenbepalend gegeven met een ingangsdatum welke in de tijd gezien ligt vóór al eerder geregistreerde pensioenbepalende gegevens. In systemen werden “standen” vastgelegd welke de opgebouwde pensioenrechten weer moesten geven. In geval van TWK-s moeten dan nieuwe standen worden bepaald en al eerder vastgelegde standen “ongeldig” worden gemaakt.

Het is bij TKP gebleken dat 80% van het databeslag in het bestaande systeem werd gevormd door deze standgegevens. Verder bleek ook ongeveer 80% procent van de applicatie-functionaliteit betrekking te hebben op het vervaardigen en onderhouden van standgegevens. Figuur 2 is de weergave van dit principe in de enterprise-architectuur van TKP.

Vooral het tweede principe heeft vanaf dag één tot veel discussie geleid. Ingehuurde ontwerpers welke gewend waren traditionele “waterval” systemen te ontwikkelen waren bang voor onoplosbare performanceproblemen. Later in contacten met andere pensioenuitvoerders kwamen regelmatig hiermee verwante vragen op tafel. Ook werd vaak gezegd dat bepaalde pensioenregelingen zo complex zouden zijn dat deze zich niet zouden lenen voor toepassing van de hier beschreven principes. In de praktijk is daar bij TKP (21 pensioenregelingen van uiteenlopende aard in 2009) echter nog niets van gebleken.

Applicaties zijn onafhankelijk van specifieke regelingen en klanten

Motivatie

  • Applicaties hoeven niet te worden aangepast bij nieuwe of gewijzigde regelgeving waardoor hierop snel kan worden ingesprongen

  • Nieuwe klanten moeten snel kunnen worden ondersteund

Implicaties

  • In het case management systeem worden master processen geïnstantieerd voor specifieke regelingen

  • Het gegevensmodel van applicaties is generiek gedefinieerd en kent geen regelingspecifieke tabellen

  • Applicaties zijn maximaal regelgestuurd, waarbij regels snel aanpasbaar zijn zonder de programmacode aan te passen

Figuur 1 Eerste principe

Er worden geen afgeleide gegevens opgeslagen

Motivatie

  • Hierdoor zijn uitkomsten altijd actueel en problemen met terugwerkende-kracht mutaties worden voorkomen

Implicaties

  • Gegevens worden bepaald op het moment dat ze noodzakelijk zijn

  • Uitkomsten van eerdere pensioenberekeningen worden niet hergebruikt daar waar exactheid vereist is

  • Alleen in het geval performanceproblemen zullen optreden kan hiervan worden afgewerken (b.v. uitkomstendatabase voor indicatieve productberekeningen)

  • Gegevens worden uit de bron opgehaald

Figuur 2 Tweede principe

Het proces

De beschreven principes zijn niet zonder slag of stoot tot stand gekomen. Nadat TKP tot het ontwerp van een nieuw informatiesysteem had besloten werd een tweetal externe partijen uitgenodigd een systeemconcept te presenteren welke aan de businessdoelstellingen van TKP zou kunnen voldoen. Beide partijen kwamen met een systeemconcept dat niet wezenlijk afweek van het al in gebruik zijnde systeem. TKP zag hierin niet de oplossing waar zij naar op zoek was. Hierop werd besloten om enkele eigen TKP medewerkers een aantal dagen “de hei op te sturen” om te onderzoeken of er toch niet een beter aan de doelstellingen voldoend concept bedacht kon worden. Dit heeft het succesvol gebleken systeemconcept opgeleverd waarvan de hier beschreven principes de basis vormen.

De ideeën voor het systeemconcept zijn ontstaan doordat de hierbij betrokken medewerkers beschikten over de juiste mix van vaardigheden. Deze bestonden onder meer uit een ruime praktijkervaring met het bestaande systeem, een helder beeld van de bedrijfsdoelstellingen en goede analytische vaardigheden (abstractievermogen). Hierdoor kon een helder beeld worden gegeven van een generieke opzet voor een informatieverwerkend bedrijf welke actief is op de pensioenmarkt. Vooral de inbreng van de praktijkervaring bleek hierbij belangrijk te zijn. Hierdoor konden de “problemen” die er waren met het op dat moment operationele systeem meegenomen worden in het systeemconcept.

In de afgelopen jaren is gebleken dat de logica van het systeemconcept duidelijk uit te leggen is maar dat de correcte vertaling ervan in praktische oplossingen in sommige gevallen toch een stuk lastiger blijkt te zijn. In het TKP concept moet elk probleem na analyse worden vertaald in een oplossingsvoorstel welke voldoet aan de generieke eigenschappen van het systeem-concept. Omdat probleem en oplossing hierdoor niet meer altijd 1 op 1 met elkaar verbonden lijken te zijn, ontstaan soms discussies over de voorgestelde oplossing.

Op commercieel gebied is het systeemconcept een belangrijk verkoopargument gebleken. Op basis hiervan konden alle vragen van potentiële klanten, m.b.t. de uitvoering van hun pensioenadministratie, door TKP worden beantwoord. Ook heeft de toepassing van de principes de opname van nieuwe klanten in de pensioenadministratie beter uitvoerbaar en voorspelbaar gemaakt.

De stormachtige groei van het bedrijf vereist wel dat steeds meer mensen het concept, en de principes ervan, moeten begrijpen. Omdat er geen eenduidige (overzichtelijke) beschrijving van bestond en handhaving impliciet bij een aantal (IT-)medewerkers was belegd, is besloten tot een expliciete vastlegging ervan.

Het proces van beschrijving heeft zijn diensten meteen bewezen tijdens de ontwikkeling van IT functionaliteit voor BPF administratie. Hiermee werd de toegevoegde waarde van het hebben van een gestructureerde architectuurbeschrijving ook meteen duidelijk voor de organisatie. In het traject van de ontwikkeling van de architectuurproducten (enterprise-architectuur, referentie-architectuur en oplossingsarchitecturen) werd het management betrokken om tot eenduidige vaststelling van de architecturen en de daarin opgenomen principes te komen.

Conclusies

In dit artikel is beschreven dat het bedenken van principes niet zo ingewikkeld hoeft te zijn, maar dat het kiezen van de juiste principes wel erg essentieel is. Zo essentieel dat het zelfs een belangrijke onderscheidende factor voor de organisatie kan worden en een verkoop-argument richting klanten. Het lastige deel van de principes is vooral om ze, ook onder druk, staande te houden. Doordat het hele fundamentele keuzes zijn waar niet iedereen bij betrokken is geweest kan er er discussie ontstaan. Uiteindelijk is vasthoudendheid de sleutel geweest om het systeemconcept clean te houden.

Referenties

[Greefhorst, 2009] D. Greefhorst et. al: Een pragmatische aanpak voor enterprise-architectuur, Via Nova Architectura, mei 2009.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

17-04: GIA sessie over data-driven multi-channel marketing meer...

26-04: KNVI sessie over Architecture Mining meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden