Hoe architectuurprincipes je kunnen onderscheiden van de concurrent
Benny Prij
Friday, 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.
Er is momenteel geen open standaard voor de vastlegging van architectuurprincipes. TOGAF 9 beschrijft een sjabloon voor vastlegging van individuele principes, maar biedt geen structuur voor het vastleggen van een verzameling principes in relatie tot elkaar en in relatie tot andere architectuurproducten. ArchiMate kent, als taal voor het vastleggen van architectuurproducten, momenteel geen architectuurprincipes in haar metamodel. Dit artikel beschrijft een manier om architectuurprincipes gestructureerd vast te leggen. Deze structuur kan in architectuurrepository’s gebruikt worden als aanvulling op het TOGAF Architecture Content Model of het ArchiMate metamodel.
Richard Lugtigheid is inhoudelijk verantwoordelijk voor de architectuur bij PGGM. Hij geeft leiding aan een team van businessconsultants en architecten, dat er voor zorgt dat PGGM de ICT- en procesoplossingen krijgt die de bedrijfsstrategie van PGGM actief ondersteunen. Het bewaken van de samenhang tussen de diverse proces- en systeemcomponenten, het voldoen aan wettelijke kaders en andere compliancy-aangelegenheden is daarbij cruciaal. Architectuur is daardoor een van de belangrijke stuurinstrumenten om de PGGM-strategie, en het daarvan afgeleide informatiebeleid, te realiseren.
Marjo Smulders is hoofd van de afdeling ‘ICT-beleid en architectuur’ van Rabobank. Deze afdeling die ongeveer 50 medewerkers telt, wordt in de vakliteratuur ook wel aangeduid met CIO Office en werkt zowel voor Rabobank Groep als voor Rabobank Nederland.
Voor Rabobank Groep worden de ICT-strategie, de architectuur en het daarbij behorende afsprakenkader opgesteld. Daarbinnen behoren bijvoorbeeld ook het informatiebeveiligingsbeleid en het opsporen van synergiemogelijkheden over de groepsonderdelen tot de taken van haar afdeling.
Voor Rabobank Nederland gaat de rol van haar afdeling nog wat verder. Daar wordt ook daadwerkelijk invulling gegeven aan de ICT-strategie, -beleid en de architectuur.
Met behulp van de principegenerator kun je in enkele minuten gevoel ontwikkelen voor de werking van principes en – niet onbelangrijk – je hebt direct een handjevol principes die te gebruiken zijn als vertrekpunt voor een dialoog over principes binnen de eigen organisatie. In dit artikel wordt kort ingegaan op het idee achter de principegenerator en wordt de werking beschreven.
Corné den Ouden is enterprise architect bij Achmea en tevens voorzitter van het Enterprise Architectuur Team (EA-team). Dat EA-team - bestaande uit elf leden en een secretaris - bestrijkt alle aspecten van architectuur, van business tot en met technologie infrastructuur en de security. Het EA-team is verantwoordelijk voor de enterprise architectuur van Achmea en daarmee voor de kaders en richtlijnen waarbinnen de onderdelen van Achmea mogen bewegen. Om te borgen dat die kaders en richtlijnen ook daadwerkelijk worden gerespecteerd, heeft het EA-team mandaat om te controleren en om te sturen op programma’s, projecten en de architectuurinrichting van de onderdelen.
Henk Dado geeft momenteel leiding aan het Concern Informatiemanagement bij de Algemene Pensioen Groep (APG). Daarmee is hij verantwoordelijk voor ontwerp, realisatie en implementatie van het ICT-beleid, waaronder de ICT-architectuur, inclusief de infrastructuur. Zijn verantwoordelijkheid omvat tevens consultancy, beveiliging en methoden, technieken en hulpmiddelen voor systeemontwikkeling. De totale groep is, inclusief ondersteuning op methoden en tools, ongeveer 50 FTE. Overigens zal hij deze rol binnenkort verruilen voor een andere managementpositie binnen APG.
Op 6 juli 2009 heeft er een NAF Insight (mini-seminar) plaatsgevonden op het gebied van architectuurprincipes. Doel van dit seminar was vooral om kennis en ervaringen uit te wisselen op het gebied van architectuurprincipes en input te krijgen voor het boek dat wordt geschreven vanuit de werkgroep architectuurprincipes. In dat kader hebben zowel dienstverleners als gebruikersorganisaties hun visie en ervaringen gedeeld en heeft er een discussie plaatsgevonden.
Op dit moment herbergt de Verzekeringsmaatschappij Nationale-Nederlanden diverse Lines of Business (LoB’s), die van oudsher zeer product-georiënteerd zijn en met ieder zijn eigen specifieke IT. Momenteel vindt binnen het bedrijf een beweging plaats, waarbij de businessdomeinen binnen en tussen de LoB’s beter worden ingepast binnen de totale informatiestroom. Architectuur speelt bij deze slag, die volgens CIO Ton van der Linden bij heel veel financiële instellingen gemaakt wordt, een belangrijke rol.
Wouter Schmitz geeft leiding aan een groep van 17 business- en enterprisearchitecten. Deze groep vormt het ‘Center of Expertise’ voor architectuur bij het gedeelte van ABN AMRO dat in handen is van de Nederlandse staat. Wouter is met zijn team eigenaar van de architectuurmethode en tooling. Tevens supervideert hij de totale architectuurcommunity van alle architecten binnen ABN AMRO. Wouter is verantwoordelijk voor het uitvoeren van de architectuurgovernance binnen de ABN AMRO. Voorts ligt bij hem het beheer van de architectuurkennis en de Current State Architecture, een diepgaand systeemoverzicht van de ABN AMRO organisatie.
Henk Grevelman is naast CIO van pensioenverzekeraar Zwitserleven tevens de bedenker van een volwassenheidsmodel voor IT-organisaties. De architect kan wat hem betreft worden meegenomen in het ontwikkelpad, dat in vijf stappen van ‘stabiliteit’ naar ‘uitdagendheid’ moet leiden. Communicatie, inlevingsvermogen en verwachtingenmanagement zijn volgens de CIO de aandachtspunten.
Digitale architectuur staat volgens John Froger heel dicht bij diens fysieke evenknie. Het is dus geen toeval dat de voormalige-CIO van ABP tijdens de terugblik op zijn tien jaar bij het pensioenfonds regelmatig gebruik maakt van analogieën uit de echte wereld. Ook visualiseren is volgens hem erg belangrijk. Bij de Sociale Verzekeringsbank, waar hij vóór zijn periode bij ABP werkte, liet hij de directievoorzitter de pijnpunten in de bedrijfsprocessen en architectuur zelfs letterlijk voelen door hem stapsgewijze fysiek het hele bedrijfsproces te doen doorlopen.
Voor Achmea-Group Information Officer (GIO) Eric Sluis strekt het digitale architectuurdenken zich uit over het totale speelveld van het bedrijf: producten, diensten, processen, informatie, systemen, de technische infrastructuur en zelfs de structuur van de organisatie. “Wat ik wil is een integrale visie op ons bedrijf, nu en straks, en op de transformatie die we doormaken. En daar zitten dus al die verschillende aspecten aan.”
Naast architectuurvisualisaties zijn architectuurprincipes het centrale thema in de digitale architectuur. Er bestaan echter nog grote meningsverschillen over wat architectuurprincipes precies zijn. In de praktijk zie ik naast serieuze verzamelingen van architectuurprincipes nog te vaak vage lijstjes die meer lijken op een wensenlijst voor Sinterklaas dan een serieuze opsomming van architectuurprincipes die daadwerkelijk en aantoonbaar de ontwerpruimte inperken.
Voor iedereen staat vandaag in de automatiseringsgids een goed verhaal te lezen over architectuurprincipes; de column van Daan Rijsenbrij. Een paar punten uit die column wil ik nu graag aanstippen en verder uitwerken. Een enkel punt dat niet in de column aan bod komt wil ook even behandelen, zoals de CIO die hoeder moet zijn van de architectuurprincipes voor de organisatie. In mijn dagelijkse praktijk als enterprise architect kom ik vaak onduidelijkheid en onmacht tegen in relatie tot architectuurprincipes. Het wordt echt tijd dat enterprise architecten samen met de CIO werk maken van dit instrument waar veel kracht en macht van uit kan gaan.
Wim Walter, oud-CIO PGGM en tegenwoordig Chief Marketing Officer bij de uitvoeringsorganisatie PGGM1 kijkt tevreden terug op een zeer omvangrijke migratie naar Microsoft dot.Net. Tijdens deze zeer omvangrijke consolidatieslag is hem een aantal dingen duidelijk geworden: je moet keuzes durven maken, hier vervolgens aan vasthouden en als IT-organisatie altijd samen optrekken met de business. Bovendien heeft Walter de grote waarde van architectuur leren inzien.
De overheid koopt Fortis. ABN Amro is het grootste onderdeel, dus wellicht gaat die combinatie volgens Wellink ABN heten. Maar hoe zit dat dan nu met eigenaarschap en innovatie in de nieuwe duo-organisatie?
Dit is een vraagstuk want 1) de huidige noodzakelijke veranderingen moeten in goed tempo blijven doorlopen bij de organisaties en 2) nieuwe noodzakelijke verandering moeten in goed tempo kunnen worden opgestart en 3) de nieuwe 'tijdelijke' duo-organisatie zorgt voor een aardverschuiving van de businesscase voor de huidige en nieuwe veranderingen.
Ik was laatst zeer geboeid door een schilderij van Johannes Vermeer dat ik zag. Ik bleef er naar kijken. In verschillende boeken heb ik gelezen over het fenomeen asymmetrische balans en de schilderijen van Vermeer. Vermeer heeft, zo schrijft men, de grenzen van spiegelsymmetrie opgezocht. Hij heeft eigenlijk spiegelasymmetrie toegepast. In deze blog ga ik verder in op het principe van het fenomeen dat ik ‘spiegelasymmetrie’ noem.
The concepts of architectural principleand business rule are currently ill-defined. As a consequence, there is a lot of misunderstanding and confusion. Only by putting these concepts in an appropriate and theoretically sound conceptual framework can they become well-defined. Only well-defined concepts are useful, both in science and in practice.
Het gebied van architectuurprincipes is nog relatief ontgonnen. Er is nog geen overeenstemming over wat architectuurprincipes precies zijn, wat voor soorten architectuurprincipes worden onderkend, hoe je architectuurprincipes beschrijft en hoe je precies tot architectuurprincipes komt. Op het Landelijk Architectuur Congres 2007 is er daarom een workshop over dit onderwerp georganiseerd. Dit artikel is een verslag van die workshop.
Well considered business architecture can support an organization in becoming a place where Innovation thrives. Organizations will need to promote an environment of interaction to facilitate cross-pollination and the free flow of information. This supports the promotion of creativity and the development of ideas when seeking to exploit the full potential of innovative powers.
De prescriptieve architectuurbenadering heeft als uitgangspunt dat vrijheidsgraden van architecten en ontwerpers moeten worden beperkt door het stellen van kaders in de vorm van architectuurprincipes en richtlijnen. Er rijzen in de praktijk nog veel vragen bij het opstellen van dit soort principes en richtlijnen. Dit artikel geeft daarom een op de praktijk gebaseerd beeld en gaat in op een praktijksituatie bij een grote verzekeraar.
Voor het onderzoek is een onderzoeksplan opgesteld dat is opgenomen in het eerste hoofdstuk. Hier is gekeken wat de aanleiding van het onderzoek is en welk probleem- en doelstelling hierbij komt kijken. Een onderzoeksvraag is opgesteld met deelvragen om het onderzoek concreet te maken. Vervolgens is het onderzoek verdeeld in een aantal activiteiten en is gekeken naar het toekomstige studentinformatiesysteem van de Radboud Universiteit. ...
Guido Chorus , Yves Janse, Chris Nellen, Stijn Hoppenbrouwers, Erik Proper
Tuesday, 24 July 2007
This technical report is the result of two experiments conducted as part of an ongoing research effort to formalize architecture principles. The experiment involves a first, and modest, evaluation of the use of ORM and ORC as a means to formalize and ground architecture principles. The experiments involve the evaluation of the use of ORM and ORC to formalize the example principles provided by the TOGAF (The Open Group Architecture Framework) and principles taken from industrial practice.
In deze scriptie wordt een begin gemaakt met de theorievorming voor een prescriptieve architectuurmodelleertaal. Er wordt betoogd dat de prescriptieve modelleertaal architect- en methodeonafhankelijk ontworpen dient te worden.
Door het toepassen van digitale architectuur1 zijn ondernemingen en instellingen beter en sneller in staat om zich aan te passen bij wat medewerkers in een organisatie doen en veranderingen in het ecosysteem. Binnen de Radboud Universiteit (RU) ontbreekt het aan systematisch inzicht in de wisselwerking tussen het bedrijfsgebeuren en de informatiesystemen. In het bijzonder is er behoefte aan modellen, blauwdrukken, toekomstvisies en principes. Dit onderzoek [RVN] heeft zich beperkt tot het opstellen van principes, ook wel richtinggevende uitspraken, ten behoeve van het maken van keuzes over het studentinformatiesysteem.
In 2004 heeft Univé Verzekeringen haar vernieuwde visie op de inrichting van haar informatievoorziening gedefinieerd. Een omslag in denken. Een visie die ook binnen de muren van Univé de service-georiënteerde architectuur introduceert. Geen verkokerde systeemarchitectuur maar een samenspel van componenten die de benodigde functionaliteit oplevert. De vraag is natuurlijk: “Is dit meegaan met de hype of een logisch gevolg van hetgeen de bedrijfsvoering wenst/eist?”1. Een technologie push of business alignment? In dit artikel wordt deze vraag beantwoord.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-) Architectuurraamwerk beschreven. In dit eerste artikel wordt gedetailleerd ingegaan op de essentie van het ontwerpproces.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-)Architectuurraamwerk beschreven. In dit tweede artikel wordt het Metamodel xAF beschreven en zal nader worden ingegaan op de Architectuur-principes.
Dit artikel beschrijft het onderzoek dat is verricht aan de Radboud Universiteit naar het opstellen van principes, ten behoeve van het maken van keuzes over het studentinformatiesysteem.
