{{{definitie}}}\n<<<\nApplication Service Providing is een vorm van dienstverlening waarbij de leverancier een geautomatiseerd systeem ter beschikking stelt aan de klant ter ondersteuning van haar businessprocessen.\n<<<\n\n

Naar aanleiding van het [[advies|Oriëntatie en advies]] worden één of meerdere aanvragen voor een offerte van een [[hypotheek|Hypotheek]] opgesteld en ingediend bij een [[geldgever|Geldgever]] naar keuze. Afhankelijk van het [[distributiekanaal|Distributiekanalen]] wordt de aanvraag door de consument zelf of door de adviseur opgesteld en ingediend. Indien gewenst kan bij deze aanvraag de [[bewijsstukken|Bewijsstuk]] die nodig zijn bij de acceptatie door de geldgever, worden meegestuurd.\nDe aanvraag kan vaak in elektronische vorm worden opgesteld en ingediend. De gegevens van de aanvraag worden dan elektronisch naar de geldgever of naar de serviceverlenende instelling, zoals Stater, verstuurd via het [[HDN]]-netwerk of via het Internet.\nDe aanvraag wordt behandeld in het proces [[Vastleggen aanvraag]] van het Mid-Office.\n

{{{definitie}}}\n<<<\nDe extra onderdelen die de consument met de [[geldgever|Geldgever]] afspreekt naast de algemene [[voorwaarden|Voorwaarden]] die van toepassing zijn op de [[hypotheek|Hypotheek]]. Voorbeelden hiervan zijn\n* aangepast rentepercentage\n* de periode waarin boetevrij afgelost kan worden.\n<<<

Om het bedrijf Stater beter te leren kennen, is op de volgende vragen een antwoord gegeven:\n* [[Wat is Stater?|Stater]]\n* [[Welke positie neemt Stater in?|Positionering]]\n* [[Welke diensten levert Stater?|Dienstverlening]] \n* [[Wat is het iSHS?|iSHS]] \n\n* [[Wat is een hypotheek?|Hypotheek]] \n* [[Welke hypotheekprocessen zijn er?|Hypotheekproces]]\n

De [[passering van de hypotheek|Passeren]] leidt tot het aanmaken van documenten door de notaris. Bepaalde documenten moet de [[geldgever|Geldgever]] in bezit hebben om [[het beheer van de hypotheek|Beheren leningen en verzekeringen]] correct te kunnen uitvoeren. Nadat de documenten zijn toegevoegd aan het dossier van de lening, worden de gegevens gecontroleerd. Bij onjuistheden wordt contact opgenomen met de betreffende notaris.

Uiteenlopende vragen van consumenten over hun huidige [[hypotheek|Hypotheek]] of over gewenste veranderingen van hun huidige hypotheek worden afgehandeld.

{{{definitie}}}\n<<<\nEen aflossingsnota is een brief, waarop de opbouw van het bedrag wordt gepresenteerd dat op de dag van gewenste aflossing van de lening moet worden betaald om de lening of een deel van de lening (één of meerdere leningsdelen) geheel af te lossen (terug te betalen).\nEen aflossingsnota wordt aangemaakt naar aanleiding van een verzoek van bijvoorbeeld een notaris.\n<<<

De ambitie van [[Stater]] is om nationaal en internationaal een toonaangevende hypotheekservicer te zijn. Dit komt tot uiting in de missie van Stater: \n|bgcolor(#FDEDDB):Het ondersteunen van onze klanten bij het realiseren van hun doelen door 'end-to-end' hypotheekdiensten te leveren voor de Europese hypotheekmarkt. Gebaseerd op een “shared service” concept en een onafhankelijke positie.|\n\nHieronder worden de belangrijkste elementen genoemd waarop deze missie is gebaseerd.\n* Toegevoegde waarde: Van toegevoegde waarde zijn voor onze klanten door meer mogelijk te maken en niet alleen een leverancier van diensten te zijn, maar een strategische partner.\n* Kosten efficiënte, internationaal georiënteerde, dienstverlener: Leverancier van een totaaloplossing met een concurrerende prijsstelling.\n* ~State-of-the-Art: Gebruik van innovatieve systemen en processen zodat onze klanten hun marktpositie kunnen behouden en uitbouwen.\n* “[[Shared service|Shared service center]]” concept: Gestandaardiseerde diensten en gecentraliseerde dienstverlening als basis voor een lage kostprijs. \n* Succesvolle internationale organisatie: Focus ligt op het ontwikkelen van een winstgevende internationale expansie, klanten krijgen hierdoor de mogelijkheid ook in andere landen toe te treden. \nIn 2004 heeft Stater geconcludeerd dat de [[huidige ICT-ondersteuning|iSHS]] onvoldoende in staat is deze missie te faciliteren. Vooral de toegenomen complexiteit van de [[omgeving|Omgevingsdimensies]] waarin Stater zich bevindt zijn hier de oorzaak van. Daarom is besloten een strategisch programma uit te voeren ter vervanging van het iSHS. Dit [[programma|€state]], €state genaamd, moet uiteindelijk leiden tot een compleet nieuwe ~ICT-oplossing (ook €state genoemd) gebaseerd op een nieuw te ontwikkelen [[architectuur|De oplossing]].\nUitgangspunten voor dit programma zijn geformuleerd als [[businessdrivers|Businessdrivers]]. Deze drivers maken de contouren van het nieuwe systeem duidelijk en dienen als input voor de nieuwe architectuur.\n

~ArchiMate is een modelleertaal. In deze modelleertaal worden drie lagen onderscheiden:\n[img[figuren/archimate.png]]\n__Businesslaag__: In de businesslaag worden producten en diensten (services) aangeboden aan externe klanten (in de omgeving). Deze producten en diensten worden gerealiseerd door het uitvoeren van business processen. \n__Applicatielaag__: De applicatielaag ondersteunt de businesslaag met applicatieve diensten. Deze diensten worden gerealiseerd door (software) applicatie componenten.\n__Infrastructuurlaag__: Deze laag biedt infrastructurele diensten die nodig zijn om applicaties te laten draaien. Deze diensten worden gerealiseerd door computers, communicatie apparatuur en systeem software. \n\nOp al deze lagen is een vorm van architectuur toepasbaar. ~ArchiMate heeft als doel om integratie tussen deze lagen mogelijk te maken. Op de [[website|http://www.archimate.nl]] van ~ArchiMate wordt meer informatie gegeven.

\n\n@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@\n \nTijdens de realisatie van het [[€state]]-programma zijn er afwijkingen in de realisatie van de architectuur ontstaan door project- en programmabeslissingen gebaseerd op andere belangen. Hierdoor ontstaat het gevaar dat de [[doelen|Doelen]] van €state niet allemaal (volledig) gehaald zullen worden. De architectuurafwijkingen zijn in kaart gebracht in een routekaart. De onderstaande figuur is een //voorbeeld// van zo'n routekaart. Van links naar rechts wordt de voortgang in de ontwikkeling van de ~ICT-oplossing uitgebeeld, van boven naar beneden de afwijkingen ten opzichte van de gekozen architectuur (de groene lijn). Het eindstation 'E1' geeft de plaats aan waarop de ~ICT-oplossing volledig volgens de architectuur gerealiseerd is. Pas op dat punt zullen alle [[doelen|Doelen]] van €state zijn bereikt. \n[img[figuren/roadmap.png]]\n\nHet is mogelijk om na een ontstane afwijking weer op de 'groene' lijn terug te keren. Er zullen dan echter wel extra investeringen gedaan moeten worden om dit te bereiken. Deze investeringen betreffen bijvoorbeeld het herschrijven of herstructureren van (onderdelen van) bepaalde componenten.\n

Uitgaande van de [[Stater strategie, de businessvisie|Businessdrivers]], [[omgeving|Omgevingsdimensies]] en [[businessrequirements|€state businessrequirements]] zijn architectuurprincipes afgeleid. Deze principes vormen de basis voor alle architectuurrelevante eisen die aan het [[€state]]-programma zijn gesteld. Hieronder volgt een opsomming van alle geïdentificeerde principes, gegroepeerd in een aantal hoofdgroepen:\n* Flexibiliteit op meerdere gebieden:\n** [[Procesmodulariteit]]: Processen zijn onderverdeeld in activiteiten die onderling onafhankelijk en ontkoppeld zijn; dit geldt zowel voor het primaire proces als ondersteunende activiteiten (controles, e.d.). Iedere activiteit kan zowel intern (bij Stater) als extern (bij de klant of elders) zijn belegd.\n** [[Productflexibiliteit]]: Er mogen geen technische redenen aanwezig zijn die een bepaalde combinatie van productkenmerken verhinderen. Legale combinaties van productkenmerken worden via instellingen/inregelingen gedefinieerd. De ~ICT-oplossing moet voorbereid zijn op het toevoegen van rekenregels zonder aanpassing van bestaande software. De flexibiliteit van de ~ICT-oplossing moet zodanig zijn dat niet-woninggebonden leningen ondersteund kunnen worden.\n** [[Flexibele tijdslijnen]]: De periodieke (administratieve) afsluiting kan per individuele financiële afspraak ingeregeld worden. Dagelijks vindt afsluiting van relevante afspraken plaats.\n** [[Billing]]: De ~ICT-oplossing maakt het mogelijk om op basis van een verzameling gebruiksgegevens verschillende vormen van tarifering aan te bieden.\n** [[Systeemmodulariteit]]: De ~ICT-oplossing is onderverdeeld in diensten/modules die onderling zijn ontkoppeld en in isolatie kunnen worden afgenomen.\n** [[Inregelbaarheid]]: De ~ICT-oplossing heeft meerdere niveaus van inregelbaarheid, waarbij de definities op generiekere niveaus overdraagbaar zijn naar specifiekere niveaus. Zo'n niveau wordt een [[aspectlevel|Aspectlevel]] genoemd. De basis voor dit model is onderscheid tussen generieke inregelingen, landspecifieke inregelingen, klantspecifieke inregelingen. \n* Integratie met klanten en de omgeving\n** [[Ketenintegratie]]: De choreografie van de activiteiten in het totale hypotheekproces is per klant inregelbaar en kan zowel intern als extern zijn belegd. \n** [[Straight Through Processing]]: De verwerking van aangeboden verzoeken (zoals aanvragen) dient door de ~ICT-oplossing automatisch uitgevoerd te kunnen worden.\n** [[Beschikbaarheid]]: De ~ICT-oplossing moet zodanig ingericht zijn dat er geen technische beperkingen zijn aan de beschikbaarheid ervan voor geautoriseerde gebruikers en processen.\n** [[Traceerbaarheid]]: Handelingen van gebruikers en services dienen controleerbaar te zijn en gelogd te worden. Fouten dienen geregistreerd te worden.\n** [[White-/private-labeling]]: Alle user-interfaces en alle brieven en rapportages van alle modules kunnen worden ingesteld naar het uiterlijk en de wensen van de klant. \n** [[Rapportage]]: De ~ICT-oplossing bevat geen ingebouwde kennis over rapportages. De rapportage functionaliteit is ontkoppeld van de geautomatiseerde ondersteuning van het primaire proces. Alle geautoriseerde partijen krijgen toegang tot hun rapportagedata, in de door hen gewenste vorm van doorsneden en aggregaties.\n** [[Koppelbaarheid]]: De ~ICT-oplossing moet eenvoudig kunnen worden gekoppeld aan andere systemen, softwarepakketten, databases en netwerken.\n** [[Multi-channeling]]: De modules van de ~ICT-oplossing kunnen via diverse (technische) [[kanalen|Kanalen]] worden gebruikt, en worden niet kanaalspecifiek geïmplementeerd. Deze modules kunnen zowel interactief (via een user-interface) als programmatisch worden gebruikt.\n** [[Autorisatie en Beveiliging]]: Toegang tot functies en gegevens van de ~ICT-oplossing dient op verschillende niveaus (gebruiker, geldgever, tussenpersoon, etc.) te worden geautoriseerd. Hierbij spelen zaken als single logon, beveiligde interacties tussen de partijen en 'Identity and access management'.\n* Internationalisatie\n** [[Meertaligheid]]: De ~ICT-oplossing biedt ondersteuning voor meerdere talen – zowel interactief, in rapportages als in ondersteuning (Help functies). De gekozen taal kan afhankelijk zijn van verschillende aspecten (gebruiker, klant, land, etc.).\n** [[Multi currency]]: De ~ICT-oplossing biedt ondersteuning voor meerdere valuta – zowel interactief, in rapportages als in ondersteuning (Help functies). Binnen één omgeving van een geldgever wordt met één valuta gewerkt.\n** [[Compliance]]: De ~ICT-oplossing conformeert zich aan nationale en internationale wet- en regelgeving (IAS/IFRS, BASEL II, WFD, SOXA, ~SAS70).\n* Kostenefficiëntie.\n** [[Schaalbaarheid]]: De ~ICT-oplossing is in staat meerdere miljoenen leningen te beheren zonder substantieel verlies van online- en batch-performance. Schaalbaarheid heeft ook betrekking op andere aspecten, waaronder aantal landen, aantal producten, aantal rapportages, aantal gebruikers, etc.\n** [[Onderhoudbaarheid]]: De structuur van de ~ICT-oplossing is zodanig opgezet dat wijzigingen beperkt blijven tot een minimaal aantal componenten en eenvoudig zijn door te voeren.\n** [[Beheerbaarheid]]: De kosten en benodigde inspanning voor het beheren van de ~ICT-oplossing dienen minimaal te zijn.

Het ontwikkelen van de architectuur in het kader van het [[€state]]-programma is met een eenmalig lineair proces gestart. Met [[het onderbrengen van de architectuurfunctie in de lijnorganisatie|Hoe heeft het architectuurdenken binnen Stater zich ontwikkeld]] is het bedrijven van architectuur een continu proces geworden. \n\n__Eenmalig proces__\nHet architectuurproces is begin 2004 begonnen met het inventariseren van zoveel mogelijk relevante informatie, onder andere [[visie, strategie|Businessdrivers]], [[omgeving|Omgevingsdimensies]] en [[requirements|€state businessrequirements]]. Hieruit zijn [[architectuurprincipes|Architectuurprincipes]] afgeleid. Deze principes vormen de basis voor alle architectuur relevante eisen die aan het [[€state]]-programma gesteld kunnen worden en zijn vervolgens gebruikt om een [[architectuurvisie|Ontstaan van de architectuurvisie]] te ontwikkelen. De kandidaat architecturen zijn uitgebreid gevalideerd en na [[evaluatie|Evaluatie]] is daarbij naar voren gekomen dat met de [[proces gecentreerde architectuur|Proces gecentreerde architectuur]] de business doelstelling het beste gediend is.\n\n__Continu veranderproces__\nIn het veranderproces wordt de architectuur aangescherpt, verdiept, verbeterd en geactualiseerd. De aanleiding voor deze veranderingen kan zowel intern als extern gedreven zijn. Interne triggers ontstaan door voortschrijdend inzicht, verdergaande kennisopbouw en discussies binnen de architectuurgroep. Externe triggers zijn veranderingen in de omgeving, nieuwe ontwikkelingen of nieuwe inzichten die zijn ontstaan bij het uitvoeren van [[projecten|Project Startarchitectuur]].\n\n[img[figuren/architectuurproces.png]]\n

Architectuur heeft de volgende producten opgeleverd. Er is een onderverdeling gemaakt naar omgeving, business en applicatie. \n\n* Omgeving\n** [[Omgevingsdimensies]]: Om inzicht te krijgen in de omgeving van [[Stater]] die complex is.\n** [[Klantbeelden]]: Om inzicht te krijgen in de omgevingsdimensies worden klantbeelden gebruikt. \n** [[Hypotheekproces]]: Om inzicht te krijgen in de procesgang van hypotheken en de daarbij betrokken partijen. \n* Business\n** [[Bedrijfsdomeinen]]: Beschrijving van de invulling van het algemene hypotheekproces door Stater.\n** [[Architectuurprincipes]]\n** [[Stater domeinmodel]]: Beschrijving van de functionele concepten.\n** [[Architectuurafwijkingen|Architectuurafwijkingen]]: Beschrijving van de afwijkingen op de doelarchitectuur. \n* ICT\n** [[Functionele Applicatiearchitectuur]]: Beschrijving van de invulling van de proces gecentreerde systeem architectuur. \n** [[Impact van de architectuur]]: Beschrijving van de impact van de architectuur op de ~ICT-organisatie.\n** [[Project Startarchitectuur]]\n** [[PACT|Meer informatie over de PACT]]: Beschrijving van de wijze waarop de architectuur gevalideerd wordt.

{{{definitie}}}\n<<<\nEen aspectlevel is een niveau binnen de architectuur van €state waarop inregeling of configuratie kan plaats vinden. (Zie [[Inregelbaarheid]].)\n<<<\n\nEnkele voorbeelden van aspectlevels: zakelijke relatie, geldgever, commercieel product en business partner.\nDit principe komt niet tot uiting in één component in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]], maar vormt de basis voor een aantal plekken waar configuratie mogelijk is, zoals bijvoorbeeld de product services of het [[Stater domeinmodel]]\nHet idee achter dit principe is dat configuratie op een abstracter niveau (bijv. 'land') wordt overerft op een concreter niveau (bijv. 'geldgever') waardoor de configuratie-items beter onderhoudbaar zijn.\n

{{{definitie}}}\n<<<\nToegang tot functies en gegevens van de ~ICT-oplossing dient op verschillende niveaus (gebruiker, geldgever, tussenpersoon, etc.) te worden geautoriseerd. Hierbij spelen zaken als single logon, beveiligde interacties tussen de partijen en 'Identity and access management'.\n<<<\n\nDit principe komt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] tot uiting door de keuze van de volgende componenten:\n* de access controller\n* authorization modeler\nWanneer er nauw met de klant wordt samengewerkt, moeten de autorisatiemodellen op elkaar worden afgestemd.\n

{{{definitie}}}\n<<<\nBPM staat voor Business Process Management. Bij BPM gaat het om het modelleren van de business processen binnen een softwaretool, die vervolgens in staat is om deze business processen daadwerkelijk uit te voeren. Hierdoor is de regie van een business proces geautomatiseerd.\n<<<

{{{definitie}}}\n<<<\nBusiness Process Outsourcing is een vorm van dienstverlening waarbij (delen van) het bedrijfproces van de klant wordt uitgevoerd door medewerkers van de leverancier, vaak ondersteund door een geautomatiseerd systeem van de leverancier. \n<<<\n

{{{definitie}}}\n<<<\nTot ~Back-Office-processen behoren de [[hypotheekprocessen|Hypotheekproces]] die zijn ingericht om de administratie van de verkochte [[hypotheek|Hypotheek]] uit te voeren. Daar hoort ook de periodieke verslaglegging bij.\n<<<

De bedrijfsvoering van Stater voor het leveren van [[hypotheekdiensten|Dienstverlening]] is onderverdeeld in domeinen, die qua doelstelling en activiteiten elk een afgebakend deel van de business representeren. \n\n@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@ \n

Bewaakt wordt dat bedragen, die voor de hypotheek betaald moeten worden door de consument, op tijd zijn betaald.\nBij te late betaling worden consumenten hieraan herinnerd. Bij toename en voortduring van de achterstand wordt contact opgenomen met de consument met als doel het betalingsprobleem op te lossen. Alle noodzakelijk acties in het kader van het belang van de geldgever worden uitgevoerd, zoals meldingen aan het [[BKR|Bureau Krediet Registratie]] en [[garanderende instellingen|Garanderende instellingen]]. Uiteindelijk kan dit zelfs leiden tot [[executoriale verkoop|Executoriale verkoop]] van het onderpand waarop de [[hypotheek|Hypotheek]] rust.\n

{{{definitie}}}\n<<<\nDe kosten en benodigde inspanning voor het beheren van de ~ICT-oplossing dienen minimaal te zijn. \n<<<\n\n* Vanuit technisch perspectief betekent dit één beheerlocatie, één installatie en uniforme standaardtechnologie.\n* Beheerbaarheid zal een stempel drukken op het aankoopbeleid van platformen en ontwikkel- en deployment-omgevingen \n* Beheerbaarheid zal een stempel drukken op het ontwerpen, bouwen en testen van software.\n* De verwachting is dat dit principe een positief effect heeft op de kosten. (verlaging van de TCO.)\n

Van hypotheken die worden verstrekt op een nog te bouwen of te verbouwen onderpand wordt het geld beheerd in een [[bouwdepot|Depot]]. Uitbetaling van geld uit het depot vindt plaats na indiening van een (bouw)nota. Afhankelijk van afspraken met de geldgever wordt periodiek rente vergoed over het bouwdepot. De consument ontvangt periodiek een overzicht met het verloop van het saldo in het bouwdepot. \n

Afhankelijk van de afspraken die zijn gemaakt in de offerte en zijn vastgelegd in de [[voorwaarden|Voorwaarden]] en de bepalingen wordt de lening en eventueel de bijbehorende verzekering beheerd. Het beheren omvat de volgende activiteiten:\n* Periodiek worden rente, aflossing en premies berekend en geboekt. \n* Indien noodzakelijk wordt het termijnbedrag herberekend en de consument geïnformeerd over het gewijzigde bedrag.\n* Jaarlijks ontvangt de consument een overzicht met het verloop van het saldo van de lening.\n

Op initiatief van geldgevers worden hypotheken verkocht en verhandeld op de zogenaamde [[secundaire markt|Secundaire markt]]. Van groepen hypotheken met dezelfde kenmerken, een [[pool|Pool]] genoemd, worden dan waardepapieren ([[securities|Security]]) uitgegeven, die kunnen worden gekocht en verhandeld door beleggers.\nDoor deze transacties worden de beleggers, gedurende de looptijd van de pool, de hypotheekhouder en ontvangen uit dien hoofde de rente en aflossing van de hypotheken in de pool.\n

{{{definitie}}}\n<<<\nDe ~ICT-oplossing moet zodanig ingericht zijn dat er geen technische beperkingen zijn aan de beschikbaarheid ervan voor geautoriseerde gebruikers en processen.\n<<<\n\n* Dit principe heeft een relatie met [[schaalbaarheid|Schaalbaarheid]].\n* De on-line beschikbaarheid van de ~ICT-oplossing mag niet be﮶loed worden door batchverwerkingen.\n* De beschikbaarheid van externe diensten beïnvloedt mogelijk de beschikbaarheid van eigen diensten.

De consument maakt, eventueel in overleg met de adviseur, op basis van de ontvangen offertes een definitieve keuze voor een [[geldgever|Geldgever]]. Indien gewenst kunnen nog andere offertes worden aangevraagd of bestaande offertes worden gewijzigd. De gekozen offerte wordt ondertekend en met de gevraagde [[bewijsstukken|Bewijsstuk]] geretourneerd naar de instelling (de geldgever zelf, of diens [[gevolmachtigde|Gevolmachtigde]]) die de getekende offerte verder afhandelt. \n

{{{definitie}}}\n<<<\nEen bewijsstuk is een document dat gebruikt wordt voor de verificatie van gegevens die bij de aanvraag zijn opgegeven. Een voorbeeld van een bewijs is een loonstrook. \n<<<\n

{{{definitie}}}\n<<<\nDe ~ICT-oplossing maakt het mogelijk om op basis van een verzameling gebruiksgegevens verschillende vormen van tarifering aan te bieden.\n<<<\n\nDe modules van de ~ICT-oplossing produceren voldoende fijnmazige gebruiksgegevens die flexibele billing mogelijk maken.

{{{definitie}}}\n<<<\nHet Bureau Krediet Registratie (BKR), gevestigd te Tiel, houdt van elke Nederlander met een krediet een dossier bij in het Centraal Krediet Informatiesysteem (CKI). Het gaat om onder andere leningen, creditcards en debet-standen op betaalrekeningen van ongeveer de helft van de bevolking. De bedoeling van deze administratie is de kredietwaardigheid te kunnen beoordelen van mensen die een lening aanvragen. Daartoe worden gegevens geadministreerd als alle lopende leningen en het aflosgedrag.\n<<<

Stater heeft de volgende uitgangspunten gedefinieerd waaraan het [[€state-programma|€state]] tegemoet moet komen. Deze business drivers zijn onder te verdelen in drie categorieën: strategisch, operationeel en technisch en geven weer op welke wijze Stater haar leidende positie in de markt wil uitbouwen. \n\n* Strategisch \n** Stater wil klanten flexibele oplossingen bieden met een kostenefficiënte [[dienstverlening|Dienstverlening]].\n** Stater wil nieuwe mogelijkheden creëren op het gebied van [[e-Servicing]] en [[ketenintegratie|Ketenintegratie]].\n** Stater wil de volledige automatische verwerking van [[businessprocessen|Bedrijfsdomeinen]] optimaliseren ([[Straight Through Processing]]).\n** Stater wil de ondersteuning van nieuwe klanten, nieuwe producten en nieuwe landen, evenals het doorvoeren van wijzigingen van bestaande ondersteuning, sneller kunnen realiseren.\n** Stater wil voorop blijven lopen met een ‘hard to copy’ ~ICT-oplossing waarmee de groeiende (inter)nationale concurrentie het hoofd geboden kan worden. \n** Stater richt zich op verdere vermindering van de ~ICT-kosten.\n*Operationeel\n** Nieuwe dienstverlening moet op een effectieve en kostenefficiënte wijze kunnen worden geïmplementeerd.\n** Het moet mogelijk zijn om, zonder grote impact, de functionele grenzen van de ~ICT-oplossing te verleggen om toekomstige ontwikkelingen te blijven ondersteunen.\n** Uitbreiding en aanpassing van functionaliteit mag geen impact hebben op de flexibiliteit van de ~ICT-oplossing en op de doorlooptijd van de realisatie hiervan.\n*Technisch \n** Stater streeft naar één gecentraliseerd Europees rekencentrum waarmee schaalvoordeel (lage kosten per lening) bereikt kan worden.\n** De technische performance van de ~ICT-oplossing moet blijvend acceptabel zijn ([[schaalbaarheid|Schaalbaarheid]]).\n** [[Microsoft, tenzij]] vanwege kostenminimalisatie.\nUiteindelijk moet het programma resulteren in een geautomatiseerde ondersteuning van de [[Stater]] [[dienstverlening|Dienstverlening]], waarmee de [[€state-doelen|Doelen]] gerealiseerd kunnen worden.\n

{{{definitie}}}\n<<<\nEen bedrijfsproces (of businessproces) is een aaneenschakeling van activiteiten en/of handelingen in een bedrijf met het doel om een product of dienst te leveren aan een klant. \nBij de overgang naar een volgende activiteit of handeling is overdracht van werk en bijbehorende informatie nodig, ofwel communicatie.\n<<<

Stater heeft gekozen voor een businessstrategie die geënt is op [[Operational Excellence]]. Dit geldt vooral voor de dienstverlening in de [[Back-Office]] waar Stater betrouwbare en efficiënte diensten wil leveren tegen concurrerende prijzen. Daarnaast wil Stater, voor de klanten die met het [[iSHS]] hun eigen [[Mid-Office]]-processen uitvoeren, een [[Customer Intimacy]] strategie nastreven. Hiermee komt Stater tegemoet aan wensen van de klant om onderscheidend in de markt te kunnen zijn. Beide strategieën leiden vervolgens tot een druk op Stater om haar producten en diensten op een hoog niveau te brengen ([[Product Leadership]]) zodat de klanten daarmee hun concurrentiepositie in de hypothecaire en financiële markt kunnen behouden of uitbouwen. Dit betekent dat Stater op alle drie de assen van deze concurrentiestrategieën optimaal moet presteren. Volgens de theorie van Treacy en Wiersema ([[1995; “The discipline of market leaders” ISBN 0-201-40468-9| http://www.managementboek.nl/boekeninfo.asp?CODE=inmqnrooqr&ReferrerID=1]]) kan een organisatie zich ontwikkelen tot een marktleider wanneer deze één van de drie concurrentiestrategieën (operational excellence, customer intimacy en product leadership) nastreeft. Volgens deze theorie is een organisatie niet gebaat bij het nastreven van alle drie de strategieën (zie het linker spanningsveld in onderstaande figuur).\n[img[figuren/dim_strategie.png]]\nStater, als een business proces insourcers en service provider, heeft klanten die (delen van) hun bedrijfsprocessen laten ondersteunen en/of uitvoeren door Stater. Deze klanten stellen eisen die slechts ingewilligd kunnen worden wanneer alle concurrentiestrategieën optimaal worden ondersteund. Omdat vaak belangrijke (soms zelfs core-) businessprocessen worden uitbesteed beschouwt men de servicer als een partner waarmee men nauwe relaties onderhoudt, maar waarvan men ook verwacht dat hij in belangrijke mate een rol speelt in productvernieuwing en –verbetering en niet in de laatste plaats de uitbestede businessprocessen efficiënt en optimaal uitvoert. Stater kan zich dus niet richten op één van deze concurrentiestrategieën maar zal ze alle drie moeten omarmen. \nMet deze ‘optimal partnership’-strategie, waarbij een optimale mix van de concurrentiestrategieën wordt nagestreefd en waarbij geen van de drie de boventoon kan voeren, kan Stater een sterke positie in de markt blijven houden (zie het rechterdeel van de figuur). Stater zal zich wel terdege bewust moeten zijn dat op alle drie de fronten de strijd gestreden moet worden.\n

Na uitbrengen van de offerte heeft de consument een bepaalde periode de tijd (vaak drie weken) om akkoord te gaan (ondertekenen) en de offerte met de gevraagde [[bewijsstukken|Bewijsstuk]] te retourneren naar de geldgever of diens [[gevolmachtigde|Gevolmachtigde]]. Deze periode wordt aangeduid met de geldigheid van de offerte. Vaak zal de geldgever of diens gevolmachtigde, naarmate de geldigheidstermijn verstrijkt, een herinnering naar de consument versturen.\nDe ontvangen getekende offerte en de bewijsstukken worden bij ontvangst gecontroleerd en als ontvangen geadministreerd. Indien de geldigheidstermijn verstrijkt zonder dat de offerte getekend retour is ontvangen, vervalt de offerte automatisch. \n

{{{definitie}}}\n<<<\nDe ~ICT-oplossing conformeert zich aan nationale en internationale wet- en regelgeving (IAS/IFRS, BASEL II, WFD, SOXA, ~SAS70)\n<<<\n\nDit betekent dat het systeem de door deze wetgeving geëiste informatie moet kunnen leveren. Zo stelt ~SAS70 bijvoorbeeld eisen aan de informatie die gelogd dient te worden gedurende het gebruik van het systeem.

Het composite pattern is een voorbeeld van een ontwerp pattern. Een ontwerp pattern is een algemene oplossing voor een veel voorkomend probleem tijdens het ontwerpen van software. Het composite pattern is toepasbaar op plekken waar bepaalde objecten kunnen worden gegroepeerd en waarbij bepaald gedrag zowel door een individueel object als door de groep moet kunnen worden vertoond. Zie de [[pagina op wikipedia (engels) over composite patterns|http://en.wikipedia.org/wiki/Composite_pattern]] voor aanvullende informatie.

Copyright 2006 Stater N.V.\nAlle rechten voorbehouden. Niets uit dit webdocument mag worden verveelvoudigd, opgeslagen,in een geautomatiseerd gegevensbestand of openbaar worden gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopie뮬 opnamen, of enige andere manier, zonder voorafgaande schriftelijke toestemming van Stater N.V. Het verbod betreft ook gehele of gedeeltelijke bewerking.\nStater N.V.\nHoofdkantoor: De Brand 40, 3823 LL Amersfoort, Nederland \nPostbus 2686, 3800 GE Amersfoort, Nederland\nIngeschreven in het Handelsregister ~KvK Gooi- en Eemland onder nummer 32073618 \nEmail: info@stater.com\n

{{{definitie}}}\n<<<\nEen bedrijfstrategie die erop gericht is klanten optimaal van dienst te zijn. De organisatie richt haar productenaanbod zeer nauwkeurig op een specifieke nichemarkt. De organisatie heeft een zeer gedetailleerde kennis van zijn klanten en kan zich snel aanpassen aan de behoeften van de klant. De organisatie richt zich op de customer's lifetime value, wat kan betekenen dat de dienstverlening in eerste instantie meer kost dan het oplevert, later wordt dit immers door de klantentrouw weer goedgemaakt. Albert Heijn en Robeco zijn hiervan een voorbeeld.\n<<<\n\n

Deze groep bevat informatie over de architectuur van Stater\n** [[Inleiding op architectuur]], waarin het begrip 'architectuur' wordt uitgelegd, en de scope van de architectuurbeschrijving in dit webdocument.\n** [[Architectuurproces|Architectuurproces]]. Deze groep bevat informatie over hoe het architectuurproces binnen Stater is vormgegeven. \n** [[Architectuurproducten]]. Deze groep bevat informatie over de architectuurproducten (zoals de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]]).\n

[[De uitdaging]] heeft geleid tot het formuleren van de [[architectuurprincipes|Architectuurprincipes]]. Op basis van deze principes is de [[architectuurvisie|Ontstaan van de architectuurvisie]] ontwikkeld. Deze visie is verder uitgewerkt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]]. Hieraan gerelateerde onderwerpen zijn:\n* [[Stater domeinmodel]]\n* [[Technische architectuur]] \n* [[Impact van de architectuur]] op de organisatie\n\n

De realisatie van [[€state]] is eind 2004 gestart. Het [[programmaoverzicht|Programmaoverzicht]] geeft een beeld van de afgeronde, lopende en te starten projecten. Om deze projecten voldoende 'architectuurbagage' mee te geven zijn er [[Project Startarchitecturen|Project Startarchitectuur]] geschreven om [[afwijkingen op de architectuur|Architectuurafwijkingen]] te voorkomen. \n\n

[[Stater]] heeft een uitdaging. Dit wordt uitgelegd in:\n* [[De ambitie|Ambitie]],\n* [[De businessdrivers|Businessdrivers]],\n* [[De omgeving|Omgevingsdimensies]]. \n[[€state]] is het antwoord op deze uitdaging.\n

[[Introductie]]

{{{defintie}}}\n<<<\nEr bestaan verschillende depots:\n* __bouwdepot__: Een bouwdepot is een depot (rekening) waaruit tijdens de bouw of verbouwing van de woning op verschillende momenten betalingen gedaan kunnen worden. Het geld in het bouwdepot wordt dus gebruikt om tijdens de (ver)bouw rekeningen van bijvoorbeeld de aannemer te betalen. Naarmate de bouw vordert, blijft er dus steeds minder geld in het bouwdepot over, totdat, aan het einde van de bouw, het bouwdepot leeg is. Het beschikbare geld is (deels) afkomstig uit de gerelateerde [[hypotheek|Hypotheek]].\n* __premiedepot__: Een premiedepot is een spaarrekening van waaruit gedurende een bepaalde periode de premies voor een levensverzekering voldaan kunnen worden. Het beschikbare geld kan (deels) afkomstig zijn uit de gerelateerde hypotheek.\n* __kredietdepot__: Een kredietdepot is een depot waaruit gedurende de looptijd van een hypotheek geld uit opgenomen kan worden. \n<<<

De dienstverlening van [[Stater]] is grofweg onder te verdelen in twee groepen\n* __Hypotheekdiensten__: Binnen het algemene [[hypotheekproces|Hypotheekproces]] biedt Stater de nodige [[diensten|Bedrijfsdomeinen]]. De diensten worden voor een groot deel ondersteunt door het [[iSHS]], de huidige ~ICT-oplossing van Stater. Bepaalde diensten worden door Stater in twee vormen aangeboden, [[BPO]] of [[ASP]]. Voor bepaalde klanten kan de totale dienstverlening bestaan uit een mengvorm van BPO en ASP ([[servicemodel|Servicedimensie]])\n* __Ondersteunende diensten__: Dit zijn diensten die de bovenstaande hypotheekdiensten ondersteunen of uitbreiden. Hierbij moet gedacht worden aan specifieke klantwensen. Dit kan variëren van het inregelen en inbouwen van nieuwe producten voor een klant tot het ontwikkelen van nieuwe applicaties voor een specifieke doelgroep, zoals [[e-Notaris]]. \nDe dienstverlening van Stater is ook beschreven op haar [[website|http://www.stater.nl/frames.asp?company_id=1&language=NL&menu_id=48]].

Elke klant van Stater richt zijn eigen distributieketen in waarin diverse partijen kunnen deelnemen, zoals [[tussenpersonen|Tussenpersoon]], [[tussenpersoon-organisaties|Tussenpersoon-organisatie]], [[inkoopcombinaties|Inkoopcombinatie]], [[packagers|Packager]] en [[geldgevers|Geldgever]]. Elke partij heeft zijn eigen rollen en verantwoordelijkheden in de keten en het [[hypotheekproces|Hypotheekproces]]. Stater ondersteunt en verbindt deze partijen in de distributieketens van haar klanten.\n \n[img[figuren/dim_distributie.png]]\nDoor de centrale positie heeft Stater de kans de distributieketens van haar klanten te stroomlijnen en efficiënt te maken. Hierdoor kunnen [[businessprocessen|Businessprocessen]] efficiënt en effectief worden uitgevoerd ([[Straight Through Processing]]).

{{{definitie}}}\n<<<\nHet medium waarlangs de [[geldgever|Geldgever]] de verkoop van [[hypotheken|Hypotheek]] distribueert. Er zijn verschillende vormen van kanalen:\n* __Direct__: Hierbij richt de geldgever zich direct tot de consument. Adviessites op internet zijn hier voorbeelden van, zoals bijvoorbeeld [[Moneyou|http://www.moneyou.nl]] of [[Bank of Scotland|http://www.bankofscotland.nl/]].\n* __Indirect__: Hierbij maakt de geldgever gebruik van onafhankelijke tussenpersonen of verkoopkantoren voor de verkoop van hypotheken.\n<<<

{{{definitie}}}\n<<<\nEen bepaalde toepassing van het [[distributienetwerk|Distributienetwerk]] voor een klant van Stater (geldgever).\n<<<

{{{definitie}}}\n<<<\nHet netwerk van partijen die een rol spelen in de distributie van hypotheken.\n<<<\nMet distributie wordt bedoeld de activiteiten die worden ondernomen om hypotheken aan consumenten te verkopen. \nVoorbeelden van partijen zijn [[tussenpersonen|Tussenpersoon]], [[tussenpersoon-organisaties|Tussenpersoon-organisatie]], [[inkoopcombinaties|Inkoopcombinatie]], [[packagers|Packager]] en [[geldgevers|Geldgever]]. Elke partij heeft zijn eigen rollen en verantwoordelijkheden in het netwerk en het [[hypotheekproces|Hypotheekproces]]. \n

Het [[€state-programma|€state]] moet uiteindelijk een ~ICT-oplossing opleveren waarmee de volgende hoofddoelstellingen gerealiseerd kunnen worden.\n* €state moet leiden tot een grotere klantenbinding doordat de klanttevredenheid verbetert.\n* Ondersteuning van nieuwe diensten, functionaliteit, productvormen, klanten en landen moet sneller dan nu gerealiseerd kunnen worden; inregelen in plaats van bouwen.\n* €state is een centraal ingerichte ~ICT-oplossing voor alle landen, gebaseerd op een internationaal georiënteerde architectuur.\n* Met een volledige inzet van €state moeten de totale ~ICT-kosten per lening substantieel lager zijn dan nu.\n* €state moet schaalbaar zijn, zodat een groei naar meerdere miljoenen te beheren leningen, zonder grote technische ingrepen, mogelijk is.\nDeze doelen maken het mogelijk dat Stater kan groeien naar een positie van Europees marktleider als hypotheekservicer met een kostenefficiënte [[dienstverlening|Dienstverlening]] en een daarop optimaal afgestemde ~ICT-oplossing. Bestaande klanten kunnen hierdoor worden behouden en steeds beter worden ondersteund. Daarnaast ontstaan er meer en betere mogelijkheden voor het verwerven van nieuwe (grote) klanten.\n

{{{Definitie}}}\n<<<\nEen domeinmodel beschrijft de concepten van een deel van “de werkelijkheid” vanuit een bepaald gezichtspunt. Het beschrijft welke elementen in “die werkelijkheid” een rol spelen en wat de verbanden tussen deze elementen zijn. Een domeinmodel heeft als doel om de belangrijkste concepten van een domein vast te leggen zodat dit gebruikt kan worden voor de realisatie van een systeem.\n<<<\nHet [[Stater domeinmodel]] is een [[object georiënteerd|Object georiënteerd]] domeinmodel waarbij gebruik gemaakt wordt van de [[UML]]-modelleertaal. In deze taal worden de [[concepten|Functionaliteit in het domeinmodel]] gedefiniëerd. Een voorbeeld van zo'n concept is definitie van de structuur waarin leningen en leningdelen worden gegroepeerd. Dit wordt door middel van een [[Composite pattern]] opgelost. \n[img[figuren/domeinmodel.png]]\nDit concept definieert een zeer flexibele structuur waarbij leningen en leningdelen in principe hetzelfde gedrag en attributen tot hun beschikking hebben. Deze generalisatie noemen we financiële afspraak.\nWanneer tijdens de realisatie van €state van dit concept afgeweken zal worden, wordt deze flexibiliteit (en daarmee de gewenste functionaliteit) niet bereikt.\n

In de dossier gecentreerde architectuur wordt de nadruk gelegd op het individuele geval. Iedere lening is in deze architectuur een apart dossier. Dat dossier bevat niet alleen alle gegevens van die lening, maar bevat ook de software voor de aansturing van de verwerking van die lening. Dit betekent dat elke lening een eigen verwerkingsproces heeft, waarmee maximale flexibiliteit is te verkrijgen in verwerking van de leningen. Kern van dit idee vormt een generator die op basis van flexibele configuraties in staat is om software voor iedere afzonderlijke lening te genereren.\n\nDeze kandidaat scoorde in de [[evaluatie|Evaluatie]] op de [[architectuurprincipes|Architectuurprincipes]] het hoogst. De haalbaarheid van de oplossing, als mede de verwachte doorlooptijd en kosten scoorden echter lager. Dit kwam onder andere door risico’s en onzekerheid rondom de realiseerbaarheid van de generator. \n\nDeze architectuurkandidaat is in de evaluatie afgevallen.\n

// ---------------------------------------------------------------------------------\n// Dutch Translated strings :: 20/5/2006 :: Lourens van Quadsk8.nl\n// 25/6/2006 minor changes\n// ---------------------------------------------------------------------------------\n\n// Messages\nmerge(config.messages,{\n customConfigError: "Fout in systemConfig tiddler '%1' - %0",\n savedSnapshotError: "Het lijkt erop of deze TiddlyWiki incorrect is opgeslagen. Bekijk http://www.tiddlywiki.com/#DownloadSoftware voor meer informatie",\n subtitleUnknown: "(onbekend)",\n undefinedTiddlerToolTip: "De tiddler '%0' bestaat nog niet",\n shadowedTiddlerToolTip: "De tiddler '%0' bestaat nog niet, maar heeft een vooringestelde schaduw waarde",\n tiddlerLinkTooltip: "%0 - %1, %2",\n externalLinkTooltip: "Externe link naar %0",\n noTags: "Er zijn geen tiddlers met tags",\n notFileUrlError: "Je zult deze TiddlyWiki eerst locaal (op eigen PC) moeten opslaan om de wijzigingen te kunnen bewaren",\n cantSaveError: "Het is helaas niet mogelijke de wijzigingen te bewaren. Dit komt mogelijk doordat de gebruikte browser bewaren niet ondersteund (Gebruik indien mogelijk FireFox), of omdat de padnaam naar je TiddlyWiki bestand niet toegestane karakters bevat",\n invalidFileError: "Het originele bestand '%0' lijkt geen geldige TiddlyWiki te zijn",\n backupSaved: "Backup bestand is opgeslagen",\n backupFailed: "Fout tijdens opslaan van het backup bestand",\n rssSaved: "RSS feed is opgeslagen",\n rssFailed: "Fout tijdens opslaan van het RSS feed betand",\n emptySaved: "Empty template opgeslagen",\n emptyFailed: "Fout tijdens opslaan van het lege (empty) template bestand",\n mainSaved: "TiddlyWiki basisbestand is opgeslagen",\n mainFailed: "Fout bij opslaan van het basis TiddlyWiki bestand. De gemaakte wijzigingen zijn niet opgeslagen",\n macroError: "Fout in macro <<%0>>",\n macroErrorDetails: "Fout bij uitvoeren van macro <<%0>>:\sn%1",\n missingMacro: "Die macro bestaat niet",\n overwriteWarning: "Een tiddler met de naam '%0' bestaat al. Kies OK om deze te overschrijven",\n unsavedChangesWarning: "WAARSCHUWING! Er zijn wijzigingen nog niet opgeslagen in TiddlyWiki\sn\snKies OK om te bewaren\snKies CANCEL om wijzigingen te negeren",\n confirmExit: "--------------------------------\sn\snEr zijn wijzigingen niet bewaard in TiddlyWiki. Indien je doorgaat zul je deze veranderingen verliezen\sn\sn--------------------------------",\n \n saveInstructions: "SaveChanges"});\n\nmerge(config.messages.messageClose,{\n text: "sluit",\n tooltip: "Sluit dit tekstblok"});\n\nconfig.messages.dates.months = ["januari", "februari", "maart", "april", "mei", "juni", "juli", "augustus", "september", "oktober", "november", "december"];\nconfig.messages.dates.days = ["zondag", "maandag","dinsdag", "woensdag", "donderdag", "vrijdag", "zaterdag"];\n\nmerge(config.views.wikified.tag,{\n labelNoTags: "",\n labelTags: "",\n openTag: "Open tag '%0'",\n tooltip: "Laat alle tiddlers zien met de tag: '%0'",\n openAllText: "Allen openen",\n openAllTooltip: "Open al deze tiddlers",\n popupNone: "Er zijn geen andere tiddlers met de tag: '%0'"});\n\nmerge(config.views.wikified,{\n defaultText: "De tiddler '%0' bestaat nog niet. Maak hier je tekst. Door dubbelklikken (of knop [edit]) wijzigt de editmodus.",\n defaultModifier: "(missing)",\n shadowModifier: "(shadow)"});\n\nmerge(config.views.editor,{\n tagPrompt: "Typ tags gescheiden door spaties, [[gebruik dubbele rechte haken]] indien nodig, of gebruik bestaande",\n defaultText: "Typ de tekst in voor '%0'"});\n\nmerge(config.views.editor.tagChooser,{\n text: "tags",\n tooltip: "Kies uit de bestaande tags om aan deze tiddler toe te voegen",\n popupNone: "Er zijn geen tags gedefineerd",\n tagTooltip: "Voeg toe de tag: '%0'"});\n\nmerge(config.macros.search,{\n label: "Zoek",\n prompt: "Zoek binnen deze TiddlyWiki",\n accessKey: "Z",\n successMsg: "%0 tiddlers gevonden die voldoen aan zoekterm: %1",\n failureMsg: "Geen tiddlers gevonden die voldoen aan: %0"});\n\nmerge(config.macros.tagging,{\n label: "taggend:",\n labelNotTag: "niet taggend",\n tooltip: "Lijst van tiddlers getagd met: '%0'"});\n\nmerge(config.macros.timeline,{\n dateFormat: "DD MMM YYYY"});\n\nmerge(config.macros.allTags,{\n tooltip: "Laat tiddlers zien met de tag: '%0'",\n noTags: "Er zijn geen tiddlers met tag"});\n\nconfig.macros.list.all.prompt = "";\nconfig.macros.list.missing.prompt = "Tiddlers met een verwijzing maar die nog gedefineerd moeten worden";\nconfig.macros.list.orphans.prompt = "Tiddlers zonder verwijzing vanuit andere tiddlers";\nconfig.macros.list.shadowed.prompt = "Tiddlers geschaduwd met standaard inhoud";\n\nconfig.commands.StyleSheet = "/***\snMaak op deze plaats je eigen aangepaste CSS \sn***/\sn/*{{{*/\sn\sn/*}}}*/\sn";\n\n\n\nmerge(config.macros.closeAll,{\n label: "Sluit alles",\n prompt: "Sluit alle tiddlers in de weergaven (behalve die worden aangepast)"});\n\nmerge(config.macros.permaview,{\n label: "Permaview",\n prompt: "Wijzigt de URI in de adresbalk zodat er een permanente verwijzing naar alle momenteel geopende tiddlers ontstaat"});\n\nmerge(config.macros.saveChanges,{\n label: "Bewaar wijzigingen",\n prompt: "Sla alle gewijzigde tiddlers op om een nieuwe TiddlyWiki te creëren",\n accessKey: "S"});\n\nmerge(config.macros.newTiddler,{\n label: "Nieuwe tiddler",\n prompt: "Maak een nieuwe tiddler",\n title: "NieuweTiddler",\n accessKey: "N"});\n\nmerge(config.macros.newJournal,{\n label: "nieuw log",\n prompt: "Maak een nieuwe tiddler met de datum en tijd van vandaag",\n accessKey: "L"});\n\nmerge(config.commands.closeTiddler,{\n text: "Sluit",\n tooltip: "Sluit deze tiddler"});\n\nmerge(config.commands.closeOthers,{\n text: "Sluit anderen",\n tooltip: "Sluit alle andere tiddlers"});\n\nmerge(config.commands.editTiddler,{\n text: "Bewerken",\n tooltip: "Maak wijzigingen in de tekst van deze tiddler",\n readOnlyText: "bekijk",\n readOnlyTooltip: "Bekijk de bron van deze tiddler"});\n\nmerge(config.commands.saveTiddler,{\n text: "bewaar",\n tooltip: "Sla de wijzigingen in de tekst van deze tiddler op"});\n\nmerge(config.commands.cancelTiddler,{\n text: "cancel",\n tooltip: "Negeer de gemaakte wijzigingen aan deze tiddler",\n warning: "Weet je zeker dat de veranderingen aan '%0' niet bewaard moeten worden?",\n readOnlyText: "klaar",\n readOnlyTooltip: "Bekijk deze tiddler weer in de normale weergave"});\n\nmerge(config.commands.deleteTiddler,{\n text: "verwijder",\n tooltip: "Verwijder deze tiddler",\n warning: "Weet je zeker dat je tiddler '%0' permanent wilt verwijderen?"});\n\nmerge(config.commands.permalink,{\n text: "Permalink",\n tooltip: "De permanente verwijzing naar deze tiddler"});\n\nmerge(config.commands.references,{\n text: "Referenties",\n tooltip: "Een lijst van tiddlers die naar deze verwijzen",\n popupNone: "Geen referenties"});\n\nmerge(config.commands.jump,{\n text: "Andere",\n tooltip: "Spring naar een andere open tiddler"});\n \n \nmerge(config.shadowTiddlers,{\n DefaultTiddlers: "GettingStarted",\n MainMenu: "GettingStarted",\n SiteTitle: "Mijn TiddlyWiki",\n SiteSubtitle: "een herbruikbaar non-lineair persoonlijk web notitieblok",\n SiteUrl: "http://www.tiddlywiki.com/",\n GettingStarted : "Om te beginnen met deze blanco TiddlyWiki, zul je eerst de volgende tiddlers moeten aanpassen:\sn* SiteTitle & SiteSubtitle: De naam en ondertitel van de site, zoals hierboven wordt weergegeven (na het bewaren, zullen ze ook in de titelbalk van de browser verschijnen)\sn* MainMenu: Het menu (gebruikelijk aan de linkerkant)\sn* DefaultTiddlers: Bevat alle namen van de tiddlers die je wilt laten verschijnen zodra deze TiddlyWiki wordt geopend.\snJe zult ook nog je gebruikersnaam voor ondertekenen van de wijzigingen moeten invullen: <<option txtUserName>>",\n SideBarOptions : "<<search>><<closeAll>><<permaview>><<newTiddler>><<newJournal 'DD MMM YYYY'>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel 'Instellingen »' 'Wijzig de geavanceerde TiddlyWiki opties'>>",\n OptionsPanel : "Deze InterfaceOptions zijn voor het instellen van TiddlyWiki en worden door de browser onthouden\sn\snGeef je gebruikersnaam op voor het signeren van de wijzigingen. Noteer het als een WikiWord (bijv. PietKlercks)\sn<<option txtUserName>>\sn<<option chkSaveBackups>> SaveBackups\sn<<option chkAutoSave>> AutoSave\sn<<option chkRegExpSearch>> RegExpSearch\sn<<option chkCaseSensitiveSearch>> CaseSensitiveSearch\sn<<option chkAnimate>> EnableAnimations\sn\snZie ook AdvancedOptions",\n AdvancedOptions : "<<option chkGenerateAnRssFeed>> GenerateAnRssFeed\sn<<option chkOpenInNewWindow>> OpenLinksInNewWindow\sn<<option chkSaveEmptyTemplate>> SaveEmptyTemplate\sn<<option chkToggleLinks>> Door op links van tiddlers dia al open zijn te klikken, zal deze laten sluiten\sn^^(override met Control of andere modificatie toets)^^\sn<<option chkHttpReadOnly>> HideEditingFeatures indien bekeken over HTTP\sn<<option chkForceMinorUpdate>> Beschouw edits als MinorChanges door de oorspronkelijke datum en tijd te handhaven\sn^^(override met Shift toets tijdens klikken op [klaar] of door Ctrl-Shift-Enter te drukken)^^\sn<<option chkConfirmDelete>> ConfirmBeforeDeleting\snMaximaal aantal regels in een tiddler edit vak: <<option txtMaxEditRows>>\snNaam voor map van de backup bestanden: <<option txtBackupFolder>>\sn",\n SideBarTabs : "<<tabs txtMainTab Datum Chronologisch TabTimeline Alle 'Alle tiddlers' TabAll Tags 'Alle tags' TabTags Meer 'Meer lijsten' TabMore>>",\n TabTimeline: "<<timeline>>",\n TabAll: "<<list all>>",\n TabTags: "<<allTags>>",\n TabMore : "<<tabs txtMoreTab Missend 'Missende tiddlers' TabMoreMissing Wezen 'tiddlers zonder ouders' TabMoreOrphans Schaduw 'Schaduw tiddlers' TabMoreShadowed>>",\n TabMoreMissing: "<<list missing>>",\n TabMoreOrphans: "<<list orphans>>",\n TabMoreShadowed: "<<list shadowed>>"});\n

€state is een strategisch programma van [[Stater]]. Het is gestart in 2004, met het doel een compleet nieuwe ~ICT-oplossing binnen Stater te implementeren.\n\nDe aanleidingen voor het starten van het €state-programma waren divers en de belangrijkste worden genoemd in de [[ambitie|Ambitie]] en [[businessdrivers|Businessdrivers]]. Concreet richt het €state-programma zich op de realisatie van een ~ICT-oplossing waarmee [[een aantal doelen|Doelen]] bereikt kunnen worden. Sleutelbegrippen zijn flexibiliteit, internationalisatie, schaalbaarheid, integratie met grote klanten en kostenefficiëntie.\n\nHet vervangen van een ~ICT-oplossing, als het [[iSHS]], is een ingrijpende operatie die een grote inspanning vergt van de medewerkers, een hoge impact heeft op de organisatie, veel geld kost en enkele jaren gaat duren. Naast de ontwikkeling van de nieuwe ~ICT-oplossing moet het iSHS gewoon blijven bestaan en worden onderhouden, totdat deze kan worden vervangen door de nieuwe oplossing.\n\nDe eerste fase in het €state-programma is uitgevoerd in 2004 en richtte zich op het beantwoorden van de volgende vragen:\n* Op welke wijze en hoe snel kunnen nieuwe [[requirements|€state businessrequirements]] ontwikkeld en beschikbaar worden gesteld aan de business?\n* Volgens welk scenario kan het [[iSHS]] het beste worden vervangen door de nieuwe ~ICT-oplossing? Uitgangspunt hierbij was, dat de bestaande oplossing voor de [[Mid-Office]] zo snel mogelijk moest worden vervangen.\n* Met [[welke architectuur|Ontstaan van de architectuurvisie]] kan de nieuwe ~ICT-oplossing het beste worden gerealiseerd om de doelstellingen van Stater te realiseren?\nIn oktober 2004 is de eerste fase van het €state-programma afgerond. Daarbij is het volgende besloten dan wel in gang gezet:\n* Vaststellen van [[de gekozen architectuurvisie|Functionele Applicatiearchitectuur]] en de [[leidende architectuurprincipes|Architectuurprincipes]].\n* [[Borging van het architectuurdenken|Hoe heeft het architectuurdenken binnen Stater zich ontwikkeld]] in de organisatie van Stater door medewerkers te benoemen met architectuur als aandachtsgebied.\n* Het ontwikkelen van een aantal nieuwe [[business requirements|€state businessrequirements]] in het iSHS.\n* [[Start van een realisatieprogramma|Programmaoverzicht]] voor de nieuwe ~ICT-oplossing, dit betekent:\n** Het zo snel mogelijk vervangen van de bestaande ~ICT-oplossing voor het ~Mid-Office door een nieuwe oplossing, die voor een deel kan worden ingekocht.\n** Het vervangen van de bestaande [[Stater Document Engine|SDE]] door een nieuwe oplossing. \n** Het realiseren van een [[Datawarehouse|Meer informatie over het DWH]] waarmee in de toenemende vraag naar rapportages kan worden voorzien. \n** De realisatie van een [[integration bus|Meer informatie over de integration bus]].\n

De [[architectuurkandidaten|Ontstaan van de architectuurvisie]] zijn geëvalueerd. Daarbij hebben we gekeken naar de haalbaarheid (waarbij zaken als kosten, doorlooptijd en risico's een rol spelen) en naar het voldoen aan de [[principes|Architectuurprincipes]]. Uit deze evaluatie is de proces gecentreerde architectuur als beste uit de bus gekomen. Deze is daarna verder uitgewerkt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]].\n\nIn onderstaand figuur wordt een overzicht gegeven van de scores van de kandidaten met betrekking tot haalbaarheid. De score is gebaseerd op 'verdienste' (schaal 1 - 3). Zo leveren een laag risico en goede uitbestedingsmogelijkheden een hoge score. Meer punten is dus beter.\n[img[figuren/evaluatie2.png]]\nIn het volgende figuur wordt een overzicht gegeven hoe goed de kandidaten scoren op de [[architectuurprincipes|Architectuurprincipes]]. Hierbij zijn alleen de principes meegenomen waaraan het grootste belang wordt gehecht. Ook hier geldt: meer punten is beter.\n[img[figuren/evaluatie1.png]]\n\nOp basis van de haalbaarheidsscore blijkt de functionaliteit gecentreerde architectuur de beste kandidaat te zijn, vanwege de ervaring die Stater heeft met het bouwen van systemen volgens deze architectuurbenadering. De dossier gecentreerde architectuur daarentegen scoort erg laag vanwege het hoge innovatieve karakter en de daarmee gepaard gaande onzekerheid.\n\nDe scoring op de architectuurprincipes laat een ander beeld zien: De functionaliteit gecentreerde architectuur scoort erg laag omdat er modules worden gerealiseerd waarin proces- en productafhandeling geïntegreerd met functionaliteit is ondergebracht. Hierdoor wordt niet voldaan aan de belangrijkste principes.\n\nConclusie: Uit het resultaat van beide analyses volgt dat de proces gecentreerde architectuur de beste totaalscore laat zien. Op basis van deze score heeft de €state-stuurgroep het besluit genomen om deze kandidaat architectuur als basis te nemen voor de verdere ontwikkeling van [[€state]].\n

{{{definitie}}}\n<<<\nDe executoriale verkoop is de openbare verkoop van een huis (onderpand) in opdracht van een geldgever. \nDe geldgever heeft het recht bij openbare verkoop van het huis zijn vordering (als de eigenaar in gebreke blijft met aflossing van de hypotheek) bij voorrang te verhalen op de opbrengst, dus voor de andere schuldeisers.\n<<<

{{{definitie}}}\n<<<\nDe factory is een component in de €state architectuur dat in staat is om voor de services in €state op een efficiënte manier de benodigde objecten in geheugen te creeëren, op basis van de [[€LF]].\nIn de [[PACT]] zal de factory daadwerkelijk worden geïmplementeerd en dus verder worden geconcretiseerd.\n<<<\n

De [[geldgever|Geldgever]] of diens [[gevolmachtigde|Gevolmachtigde]] beoordelen alle gevraagde [[bewijstukken|Bewijsstuk]] in relatie tot de oorspronkelijke aanvraag en de offerte. Na akkoord van alle stukken geeft de geldgever 'finaal akkoord'. Na 'finaal akkoord' zijn de geldgever en de consument gebonden aan de financiering. Aan annulering van de financiering door de consument zijn vaak kosten verbonden.\nDe consument en eventueel de adviseur worden middels een brief op de hoogte gesteld van het 'finaal akkoord'. De consument wordt gevraagd een afspraak te maken met de notaris voor het [[passeren|Passeren]] van de [[hypotheek|Hypotheek]]. Ook het passeren van de hypotheek moet binnen een, door de geldgever bepaalde, termijn plaats vinden. In overleg met de geldgever kan deze termijn worden verlengd. Soms zijn hieraan kosten verbonden.

{{{definitie}}}\n<<<\nDe periodieke (administratieve) afsluiting kan per individueel contract ingeregeld worden. Dagelijks vindt afsluiting van relevante contracten plaats.\n<<<\n\nAan de ene kant is dit een functionele eis. Daarom komt dit principe terug in de uitwerking van het [[Stater domeinmodel]]. Aan de andere kant stelt dit principe ook eisen aan de performance van het systeem. De uitwerking van dit principe mag geen negatieve invloed hebben op de [[beschikbaarheid|Beschikbaarheid]] van het systeem.

{{{definitie}}}\n<<<\nIn de ~Front-Office zijn alle [[hypotheekprocessen|Hypotheekproces]] ondergebracht die verband houden met het verkopen van een hypotheek aan een consument.\n<<<

Deze kandidaatarchitectuur is ontstaan uit een renovatiegedachte van het [[iSHS]]. Het idee was om subsystemen te onderkennen en deze stuk voor stuk te renoveren naar nieuwe technologie en zo als een aparte, functionele entiteit te laten voortbestaan. Deze modules communiceren middels een integrationbus met elkaar. Iedere functionele module wordt bovendien netjes ingedeeld in de bekende drielagenarchitectuur (user interface, businesslaag en datalaag). Deze renovatie is slechts een technische vernieuwing, en dient als startpunt voor de noodzakelijke functionele verbeteringen.\n\nUit de [[evaluatie|Evaluatie]] blijkt dat dit alternatief relatief gunstig scoort op vlakken als risico en kosten. Op het gebied van de [[architectuurprincipes|Architectuurprincipes]] was de score lager dan die van de andere kandidaten. Bovendien bleek het onmogelijk om een aantal belangrijke functionele tekortkomingen van het [[huidige systeem|iSHS]] op te lossen, omdat een gerenoveerd systeem feitelijk dezelfde functionele basis blijft behouden.\n\nDeze architectuurkandidaat is in de evaluatie afgevallen.\n

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@\n

De Functionele Applicatiearchitectuur beschrijft de invulling van de [[procesgecentreerde architectuur |Proces gecentreerde architectuur]] en is gemodelleerd [[volgens de ideeën|SOA volgens Stater]] die [[Stater]] heeft van een [[service oriented architecture|SOA]]. In deze architectuur zijn een aantal onconventionele ideeën opgenomen. Om onzekerheden rondom deze concepten weg te nemen, is een apart project gedefinieerd ter validatie van deze concepten. Dit project heet de [[PACT]], Proof of Architectural Concepts and Technology. ([[Meer informatie over de PACT]])\nOnderstaande figuur toont schematisch de componenten met hun onderlinge relaties waaruit de software architectuur is opgebouwd.\n [img[figuren/faa.png]]\n\nIn de figuur is een duidelijke scheiding aangebracht tussen productkennis en -intelligentie, proceskennis en -intelligentie en functionaliteit. \n\n__Product Services__\nAlle productkennis en -intelligentie is ondergebracht in de product services, waarin alle producten kunnen worden gemodelleerd (productmodel). Bovendien worden hier ook alle parameters bij de producten vastgelegd. Een product beschrijft een soort lening, bijvoorbeeld 'De Groeispaar hypotheek van Geldgever X'. Ook de prijs van het product (rentetarief) wordt hier geconfigureerd. Iedere aanvraag voor een hypotheek zal door de product services worden gevalideerd tegen het productmodel. Als deze validatie slaagt, zal de aanvraag worden voorzien van alle bijbehorende parameters, die de verdere verwerking sturen. Enorm belangrijk voor de product services is de eenvoud waarmee producten kunnen worden vastgelegd en de bijbehorende parameters. Een ander belangrijk punt voor de product services is de ondersteuning van de [[aspectlevels|Aspectlevel]]. Binnen de configuratie van producten is een gelaagdheid herkenbaar, zoals zakelijke relatie, geldgever, commercieel product etc. Parameters moeten kunnen worden verhuisd tussen de verschillende niveaus en het is mogelijk om parameters te erven en te overschrijven.\n([[Meer informatie over de product services]])\n\n__Process Engine__\nAlle proceskennis en -intelligentie is aanwezig in de process engine. In deze engine bevinden zich procesmodellen van alle processen die binnen het hypotheekdomein worden uitgevoerd. Zodra een trigger bij Stater binnenkomt (zoals een brief, een aflossingsverzoek, een [[HDN]]-bericht) wordt het bijbehorende procesmodel gevonden en wordt een proces gestart dat voor deze ene trigger het procesmodel gaat doorlopen, inclusief alle voorgedefinieerde acties in het procesmodel. De process engine heeft zo dus de regie in handen van alle processen. Met behulp van een Process Modeler is men in staat de procesmodellen te creëren en te beheren en het procesmodel te koppelen aan het juiste [[aspectlevel|Aspectlevel]] waarvoor deze uitgevoerd moet worden. Hiermee kan het hypothekenproces voor elke klant van Stater een eigen invulling krijgen.\n([[Meer informatie over de process engine]])\n\n__Services__\nDe acties die zijn gedefinieerd in de procesmodellen zullen vaak het uitvoeren van handelingen betreffen. Dit wordt gefaciliteerd door [[services|Service]] in de architectuur. Hier kennen we een viertal varianten van:\n* De functionele modules die de onderdelen in het proces afhandelen waar interactie met gebruikers nodig is.\n* De generieke services die functionaliteit verzorgen die in alle financiële instellingen voorkomen, zoals CRM, BKR functionaliteit enzovoort. De benodigde software is wellicht in te kopen.\n* De domein services verzorgen functies die horen bij het domein van Stater, zoals termijnberekening, controle aanvraag, aanmaken offerte, boeteberekening, inning, ...\n* De system services die algemene technische zaken regelen, zoals het ondersteunen van transacties, het verzorgen van logging.\n([[Meer informatie over de services]])\n\n__Functioneel Domeinmodel__\nVoor het realiseren van de services met elk hun eigen functionele verantwoordelijkheid is een domeinmodel gemaakt. Dit domeinmodel bevat een modellering van de belangrijkste concepten in het domein van Stater, inclusief hun onderlinge relaties. Het bevat feitelijk hoe Stater aankijkt tegen zijn domein en is de basis van iedere service die wordt gebouwd binnen Stater.\n([[Meer informatie over het domeinmodel |Stater domeinmodel]])\n\n__Integration Bus__\nEen ander belangrijk component in de architectuur is de integration bus. Deze component verzorgt de communicatie tussen alle onderdelen binnen €state. Enkele voorbeelden van zaken die worden verzorgd zijn protocoltransformatie, berichttransformatie en het bieden van een betrouwbare communicatie tussen verschillende partijen. Binnen de grenzen zal de uitwisseling van informatie tussen componenten zoveel mogelijk gebaseerd zijn op het gestandaardiseerde formaat [[€LF]]. Daarbuiten hangt het af van de afspraken tussen de verschillende partijen over welk formaat wordt gehanteerd. Deze €LF bevat alle gegevens van een individuele lening en is feitelijk de representatie van de lening. Bij aanroep van een service wordt deze €LF meegegeven, zodat de services in één keer beschikt over de benodigde gegevens. De service zal zijn respons ook weer onderbrengen in de €LF.\n(Meer informatie over de [[integration bus|Meer informatie over de integration bus]], [[de €LF|Meer informatie over de €LF]] en over [[de relatie tussen de product services, de €LF en services|Relatie tussen de product services, de €LF en services]])\n\n__Kanalen, Access Controler en VCE __\nInformatie kan via allerlei [[kanalen|Kanalen]] Stater bereiken. Voorbeelden zijn telefoon, fax, e-mail, post, ftp en internet. Na ontvangst door het kanaal wordt de informatie eerst opgeslagen in de kanaaldatabase en daarna aangeboden aan de access controller, die kijkt of de gevraagde actie wel mag worden uitgevoerd. Bovendien bepaalt deze access controller naar welke klantomgeving de aanvraag moet worden doorgezet. €state zal namelijk verscheidene virtuele klantomgevingen gaan bieden [[VCE]]'s (Virtual Customer Environment). Software gaat zorgen dat deze virtuele omgevingen zich volledig autonoom gedragen, zodat alle betrokkenen het idee hebben dat het een gescheiden systeem is. Hardwarematig kunnen deze omgevingen echter op één fysieke locatie worden uitgevoerd.\n([[Meer informatie over de VCE]])\n\n__Work Environment__\nDe work environment biedt de mogelijkheden aan de gebruiker om acties op te starten. Enerzijds is dat een menustructuur met daarin alle activiteiten uit alle klantomgevingen waarvoor de betreffende gebruiker is geautoriseerd. Anderzijds is dat een taaklijst met daarin alle activiteiten die open staan en die de gebruiker op basis van zijn of haar autorisaties mag uitvoeren. Deze beide ingangspunten zijn volledig aanpasbaar naar de huisstijl van de organisatie waar de gebruiker toe behoort.\n\n__Data Warehouse (DWH)__\nDe beschreven componenten vormen samen het OLTP systeem (~OnLine Transaction Processing) dat geoptimaliseerd is in het verwerken van transacties met betrekking tot het hypothekendomein. Gebruikers en klanten zullen daarnaast ook behoefte hebben aan allerlei rapportages en overzichten over de voortgang en de status. Daarbij zullen ze vaak meer geïnteresseerd zijn in informatie over groepen leningen dan in informatie over individuele leningen. Aangezien deze behoefte een heel andere organisatie van de gegevens verlangt dan een OLTP systeem, is een apart Data ~WareHouse (DWH) voorzien dat voorziet in die behoefte.\n([[Meer informatie over het DWH]])\n\n__Authorization Modeler__\nVoordat een service wordt aangeroepen is het belangrijk dat gecontroleerd wordt of de betreffende persoon of het betreffende systeem wel de service mag aanroepen. Daarvoor is de authorization-laag in het plaatje. Het configureren van de betreffende users, groepen en de bijbehorende autorisaties gebeurt door de Authorization Modeler. Dit is een generiek component dat niet alleen bruikbaar is binnen het ~Mid-Office project, maar generiek kan worden toegepast binnen €state.

{{{definitie}}}\n<<<\nGaranderende instellingen nemen (delen van) het risico van de geldgever op zich. \nEen bekend voorbeeld is de NHG. De Nationale Hypotheek Garantie (NHG) wordt verstrekt door de Stichting Waarborgfonds Eigen Woningen. Het is de naam van de garantie die verkregen kan worden als een lening wordt afgesloten voor het kopen of verbouwen van een woning. Hiermee staat het Waarborgfonds garant voor de terugbetaling van het hypotheekbedrag aan de geldverstrekker. \n<<<\n

De ~ICT-oplossing van [[Stater]] wordt gebruikt door verschillende groepen gebruikers. Naast de medewerkers van Stater maken de klanten van Stater gebruik van deze ~ICT-oplossing. Vaak hebben deze klanten de uitvoering van (delen van) hun [[businessprocessen|Businessprocessen]] uitbesteed aan andere partijen, zoals [[tussenpersoon-organisaties|Tussenpersoon-organisatie]] en [[packagers|Packager]]. Deze partijen werken dan namens de klant met de ~ICT-oplossing van Stater. Stater biedt ook directe toegang tot relevante informatie aan [[tussenpersonen|Tussenpersoon]] en notarissen (middels [[e-Servicing]]). Op termijn kan ook de consument in staat worden gesteld relevante informatie te raadplegen. \nOm een indruk te geven van het gebruik: \n* Aantal gebruikers [[iSHS]]: > 2500\n* Aantal gebruikers [[e-Intermediair]]: ± 4000\n* Aantal gebruikers [[e-Notaris]]: ± 2000\n[img[figuren/dim_gebruikers.png]]\nAlle gebruikers van deze partijen zullen met hun specifieke eisen en wensen optimaal ondersteund moet worden, bij voorkeur in de taal en huisstijl van de organisatie waarvoor Stater de diensten verleent ([[private labeling|White-/private-labeling]]). Daarnaast zal een gebruiker slechts voor zijn rol relevante gegevens en functies mogen benaderen. [[Authenticatie, autorisatie en beveiliging|Autorisatie en Beveiliging]] zijn hierbij sleutelbegrippen.

{{{definitie}}}\n<<<\nDe geldgever is de organisatie die de aankoop van bijvoorbeeld een huis financiert. \nBij een [[hypotheek|Hypotheek]] wordt het huis onderpand om de geldgever de zekerheid te geven dat hij het door hem geleende geld weer terug krijgt. De wet geeft de geldgever het recht bij openbare verkoop van het huis zijn vordering (als de eigenaar in gebreke blijft met aflossing van de hypotheek) bij voorrang te verhalen op de opbrengst, dus voor de andere schuldeisers.\n<<<

{{{definitie}}}\n<<<\nde gevolmachtigde is de instelling die namens de [[geldgever|Geldgever]] (een onderdeel van) het [[hypotheekproces|Hypotheekproces]] uitvoert. [[Stater]] kan optreden als zo'n gevolmachtigde.\n<<<

{{{definitie}}}\n<<<\nHDN (Hypotheken Data Netwerk) is een berichtenstandaard voor hypotheekaanvragen. Tevens wordt hiermee het netwerk aangeduid waarover berichten volgens deze standaard gedistribueerd worden. Ongeveer 5000 tussenpersonen maken gebruik van HDN. Jaarlijks worden ca. 350.000 berichten op een eenduidige manier uitgewisseld tussen het intermediair en de geldverstrekker. \n<<<

[[Leeswijzer]]\n[[Menubalk]]\n[[Tekstblokmenu]]\n[[Instellingen]]\n[[Copyright]]\n

Afhankelijk van de [[afspraken|Voorwaarden]] en de rentevastheidsperiode ontvangt de consument een bepaalde periode vóór het verstrijken van de einddatum van het rentepercentage van de lening een aanbod van een nieuwe rente. Indien na het verstrijken van de rente een nieuw product gewenst is, wordt deze wijziging vaak kosteloos doorgevoerd.

__Achtergrond__\nBij het ontwikkelen en het onderhouden van het [[iSHS]] is er geen structurele aandacht voor architectuur geweest. Slechts op ad-hoc basis werd door individuele medewerkers architectuurinitiatieven ontplooid. Dit heeft echter nooit geleid tot een brede acceptatie van architectuur. Na een aantal mislukte pogingen om het iSHS te vervangen heeft de directie van [[Stater]] in 2004 besloten om het [[€state]]-programma te starten, waarbij het ontwikkelen en beschrijven van een architectuur als een van de op te leveren producten werd vereist.\n\n__Architectuur als project binnen het €state-programma __\nHet architectuurproject binnen het [[programma|Programmaoverzicht]] is gestart met de inventarisatie van de [[visie, strategie|Businessdrivers]], en andere [[requirements|€state businessrequirements]] waaruit de [[architectuurprincipes|Architectuurprincipes]] zijn gedestilleerd. Met deze principes als uitgangspunt is een architectuurvisie ontwikkeld waarin een aantal [[architectuurkandidaten|Ontstaan van de architectuurvisie]] zijn ontworpen. Na de evaluatie van deze kandidaten is er gekozen voor de [[proces gecentreerde architectuur|Proces gecentreerde architectuur]]. Na deze beslissing is de keuze verder uitgewerkt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] om zo snel mogelijk aan de vervangingsvraag van het [[iSHS]] te kunnen voldoen. De urgentie van de vervanging bleek ook uit het feit dat parallel aan de ontwikkeling van deze architectuur een project werd opgestart om de [[Mid-Office]] applicatie met een ingekochte oplossing te vervangen. Het architectuurteam is betrokken geweest bij de leveranciersselectie en heeft de consequenties van de oplossingen in kaart gebracht. Na de keuze voor een leverancier en bijbehorende applicatie bleef het architectuurteam actief betrokken bij de ontwikkeling van de applicatie om zeker te stellen dat deze zoveel mogelijk in lijn met de beschreven architectuur ontworpen en gebouwd wordt. \n\n__Architectuur als lijnactiviteit binnen ~Stater-ICT __\nTot 2005 werd architectuur in €state binnen het project uitgevoerd. Project- en architectuurbelangen zijn lastig te verenigen in een project vanwege het verschil in focus. Architectuur richt zich op de beschrijving van de kaders waarbinnen de best passende oplossing kan worden gerealiseerd. Een project daarentegen richt zich op het zo snel mogelijk realiseren van het projectdoel en wordt daarbij vooral gedreven door tijd en geld. Het verschil in focus is vooral lange termijn versus korte termijn en beste oplossing versus compromisoplossing. \nDaarnaast werd geconstateerd dat architectuur een bredere scope heeft dan alleen het €state-programma. De architectuurfunctie werd een rol toebedeeld om een intermediair te zijn tussen ~ICT en de business met het doel de vragen van de business op een juiste wijze te vertalen naar ~ICT-oplossingen. \n\nDeze redenen hebben geleid tot de oprichting in 2005 van een aparte architectuurafdeling binnen ~ICT-organisatie van Stater. De activiteiten die deze afdeling uitvoerde waren:\n* Het verder uitwerken van de architectuur. Hierbij is een start gemaakt met het beschrijven van een business architectuur, het uitwerken van het [[Stater domeinmodel]] en voorbereiding gestart van de [[PACT]].\n* Het participeren in [[€state-projecten|Programmaoverzicht]]. Bij de start van een project wordt een [[Project Startarchitectuur|Project Startarchitectuur]] opgesteld waarna de betrokken architect het project waar nodig in de gewenste richting bijstuurt om [[afwijkingen van de gewenste doel-architectuur|Architectuurafwijkingen]] te voorkomen. Conflicten met projecten kunnen via een escalatiemechanisme los van het €state-programma opgelost worden. \n* Het afstemmen van de ~ICT-oplossingen op de vraag vanuit de business. Deze activiteit is niet echt van de grond gekomen.\n\n__Architectuur als lijnactiviteit binnen de business met een internationale focus__\nIn juli 2006 is met een reorganisatie besloten om de architectuurfunctie zoals deze binnen ICT was opgezet, over te hevelen naar Stater Nederland (de business). De reden die hieraan ten grondslag ligt is dat binnen Stater Nederland de behoefte aanwezig is meer grip te hebben op de ~ICT-processen. Met deze overheveling van de architectuurfunctie wordt beoogd de kloof tussen business en ICT te overbruggen. Daarnaast krijgt de architectuurfunctie de taak een internationaal businessprocesmodel te ontwikkelen, waarbij het Nederlandse model als uitgangspunt dient. Ook de verdere ontwikkeling van de Stater architectuur en de kaders waarbinnen de ~ICT-organisatie hun producten kan ontwikkelen, behoren tot het takenpakket.

{{{definitie}}}\n<<<\nDe koop van een huis staat of valt meestal met de financiering ervan. Voor de financiering doet de koper vaak een beroep op een bank, een verzekeringsmaatschappij of een pensioenfonds. Wie geld leent voor de aankoop van een huis, verleent hypotheek. Dat betekent dat het huis onderpand wordt om de financier de zekerheid te geven dat hij het door hem geleende geld weer terug krijgt. De wet geeft hem het recht bij openbare verkoop van het huis zijn vordering (als de eigenaar in gebreke blijft met aflossing van de hypotheek) bij voorrang te verhalen op de opbrengst, dus voor de andere schuldeisers. Dit recht van hypotheek wordt verleend door de eigenaar. Zodra het recht van hypotheek aan de financier is verleend, wordt deze hypotheekhouder. Het huis waarop de hypotheek rust is het onderpand. \n<<<

{{{definitie}}}\n<<<\nDe hypotheekakte is het officiële contract tussen u (de hypotheeknemer) en de hypotheekverstrekker.\nVolgens de wet dient een hypotheekakte ten overstaan van een notaris te worden gepasseerd. Daar wordt de hypotheekakte door beide partijen ondertekend, waarbij de geldverstrekker meestal via een volmacht zal tekenen. \n<<<

Gekeken met het blikveld van uitvoering van activiteiten en door wie, worden de processen in de [[waardeketen|Waardeketen]] van [[hypotheken|Hypotheek]] grofweg onderverdeeld in ~Front-Office, ~Mid-Office en ~Back-Office.\n\n[img[figuren/hypotheekproces.png]]\n\n* __Front-Office __ In de ~Front-Office zijn alle processen ondergebracht die verband houden met het verkopen van een [[hypotheek|Hypotheek]] aan een consument.\n** [[Oriëntatie en advies]]\n** [[Aanvragen offertes]]\n** [[Bespreken offertes en maken keuzes]]\n* __Mid-Office __ Tot de ~Mid-Office-processen worden alle processen gerekend die ten dienste staan van de afhandeling van de verkoop van een hypotheek. \n** [[Vastleggen aanvraag]]\n** [[Offreren]]\n** [[Completeren dossier]]\n** [[Finaal akkoord]]\n** [[Voorbereiden passeren (informeren notaris)]]\n** [[Uitbetalen gelden voor passeren]]\n** [[Passeren]]\n** [[Informeren voortgang]]\n* __Back-Office __ De processen van de ~Back-Office zijn ingericht om de administratie van de verkochte hypotheek uit te voeren. Daar hoort ook de periodieke verslaglegging bij.\n** [[Afhandelen notarisdocumenten]]\n** [[Ondersteuning distributie (bonus en provisie)]]\n** [[Beheren leningen en verzekeringen]]\n** [[Beheren bouwdepot]]\n** [[Herziening van rente]]\n** [[Wijzigen lening (omzetten)]]\n** [[Innen en bestemmen]]\n** [[Behandelen achterstanden]]\n** [[Afhandelen vragen consument]]\n** [[Verwerken algehele, gedeeltelijke en stille aflossingen]]\n** [[Royeren]]\n** [[Rapportage (financieel, operationeel, management)]]\n** [[Beheren pools (securitisatie)]]\n\n

De nieuwe [[architectuur|De oplossing]] zal impact hebben op de huidige werkwijze en procedures van diverse vakgebieden binnen [[Stater]] en zelfs buiten Stater.\nPer vakgebied (viewpoint) wordt aangegeven welke veranderingen er worden verwacht. Bij deze opsomming is geen volledigheid nagestreefd, want de impact kan namelijk pas na het uitvoeren van de [[PACT]] in kaart worden gebracht.\n\n__Klanten__\nMet de nieuwe architectuur wordt de klanten van Stater de mogelijkheid geboden om het [[hypotheekproces|Hypotheekproces]] [[op maat|Ketenintegratie]] in te richten, conform de wensen van de klant. Bepaalde delen van [[het proces|Businessprocessen]] kunnen op verzoek van de klant bij de klant of bij derden worden belegd, met gebruikmaking van €state of met een eigen systeem. Het afnemen van deze mogelijkheid stelt daarentegen ook eisen aan de klant of aan de organisatie waar de klant het deel van het proces wil onderbrengen.\nOm in- en outsourcen van businessprocessen soepel te laten verlopen is overdracht van werk en informatie noodzakelijk. Het juiste werk moet op het juiste moment aan de juiste persoon op de gewenste plek worden aangeboden en kunnen worden afgehandeld. Dit vraagt om een intensieve afstemming van de betrokken organisaties.\nBij overdracht van uitvoering van bussinessprocessen is het mogelijk dat van een ander informatiesysteem gebruik wordt gemaakt. Om het businessproces naadloos te laten aansluiten op het voorafgaande businessproces, zal overdracht van informatie moeten plaatsvinden tussen informatiesystemen. De informatiesystemen moeten hiervoor geschikt zijn en de regie moet eenduidig belegd zijn. \n\n__Gebruikers__\nGebruikers van €state zullen met [[userinterfaces|White-/private-labeling]] werken die volledig (kunnen) zijn ingericht volgens de eisen en wensen van de klant van Stater. Concreet zal de userinterface, wat betreft layout en uit te voeren stap in het hypotheekproces, op maat kunnen worden ingericht. Voorts zullen userinterfaces alleen gegevens communiceren, die voor het afhandelen van de betreffende uit te voeren handeling of processtap relevant zijn, volgens afspraak met de klant. Dit betekent dat (sommige) gebruikers geconfronteerd kunnen worden met verschillende uitingen van userinterfaces, die allen bedoeld zijn om één bepaalde handeling of processtap in het hypotheekproces uit te voeren.\n\n__Commercie__\nMet €state zal meer mogelijk worden dan met de huidige ~ICT-oplossing. De "time to market" (de tijd vanaf bedenken tot en met beschikbaarstellen van de oplossing aan de organisatie) van de implementatie van nieuwe gewenste functionaliteit zal korter worden, door: \n* inregelbare variabiliteit in uitvoering van [[processen|Procesmodulariteit]]\n* grote vrijheid in het inregelen van nieuwe [[producten en productcombinaties|Productflexibiliteit]].\nDit betekent kansen voor commercie, waarbij zeer helder moet zijn wat er wel en wat er niet met inregeling mogelijk is. Daarnaast biedt €state de potentie om de grenzen van Stater te verleggen en andere domeinen, dan het beheer van hypotheken, te betreden. Dit is mogelijk omdat door €state, ten opzichte van het huidige iSHS, belemmeringen weggenomen worden of minder groot zijn. Zo zal het mogelijk worden om:\n* zogenaamde consumptieve kredieten te beheren (leningen zonder een hypothecair onderpand)\n* andere hypotheken te beheren dan alleen hypotheken t.b.v. particulier woningbezit.\n\n__Functioneel Beheer__\nBij functioneel beheer is het [[inregelen en beheren|Inregelbaarheid]] van producten, productcombinaties en parameters belegd.\nDoor de invoering van de [[product services|Functionele Applicatiearchitectuur]] is veel functionaliteit te realiseren door configuratie van parameters. In het configureren van nieuwe functionaliteit zal het onderscheid bepaald moeten worden wat door functioneel beheer gedaan kan worden (relatief eenvoudig) en wat door ontwerpers en ontwikkelaars gedaan zal moeten worden.\n\n__Technisch beheer__\n* Er zal een visie moeten worden ontwikkeld rondom internationale ondersteuning. Bij aansluiten van meerdere klanten in verschillende landen op €state, zal bekeken moeten worden hoe dit vanuit één rekencentrum kan worden gefaciliteerd.\n* Op dit moment heeft technisch beheer te maken met een piekspanning in de maand, omdat het iSHS een maandafsluiting kent waarvoor maandspecifieke batchprocedures gedraaid moeten worden. €state kent geen maandritme, maar ondersteunt [[flexibele tijdslijnen|Flexibele tijdslijnen]], waardoor aantal en frequentie van kritieke processen zullen toenemen. Het toezicht op deze processen zal meer inspanning vragen.\n* Communicatie met externe partijen zal toenemen en complexer worden vanwege [[ketenintegratie|Ketenintegratie]] en [[Straight Through Processing]]. \n* Door nieuwe concepten en technologieën zal nagedacht moeten worden over handmatige of automatische loadverdeling ([[Schaalbaarheid]]).\n \n__Systeem ontwikkeling__\n* __Software Ontwikkeling__: Wijzigingen in de software mogen geen (beperkende) gevolgen hebben voor de werking van de [[architectuurprincipes|Architectuurprincipes]]. Voorbeelden van vraagstukken die hierbij spelen zijn:\n** Hoe te waarborgen dat nieuwe wijzigingen altijd op het [[aspectlevel|Aspectlevel]]-principe gebaseerd worden?\n** Hoe te waarborgen dat wijzigingen consistent over [[talen|Meertaligheid]] en [[kanalen|Distributiekanalen]] worden uitgevoerd?\n** Hoe te waarborgen dat nieuwe versies van services backwardscompatible zijn?\n* __Testen__: Bij het testen zal er een focus moeten zijn op de [[architectuurprincipes|Architectuurprincipes]]. Er zal moeten worden bepaald wat de verschillende principes betekenen voor de manier waarop er getest wordt. Zo zal waarschijnlijk niet de bestaande maar de //mogelijke// functionele situaties (vb: [[Flexibele tijdslijnen]], [[Productflexibiliteit]]) getest moeten worden. En zal er naast de bestaande producten ook potentiële (exotische) producten moeten worden getest. De principes wegen bij het testen niet allemaal even zwaar:\n** Bij de eerste opleveringen van €state zal er relatief veel aandacht gegeven moeten worden aan [[procesmodulariteit|Procesmodulariteit]], bij ‘normale’ ontwikkelingen is dit een ondergeschikte testactiviteit. \n** Vanwege [[ketenintegratie|Ketenintegratie]] krijgt het testen een bredere scope:\n*** Klanten, die systeemintegratie met Stater hebben, zullen hun systeem zelf moeten testen.\n*** Wanneer systemen van klanten getest worden, moet rekening gehouden worden met de beschikbaarheid van testversies en van [[OTAP-omgevingen|OTAP-omgeving]] van de andere partij.\n* __OTAP-omgeving __: Bij het inrichten van de [[OTAP-omgeving]] is [[ketenintegratie|Ketenintegratie]] een belangrijk principe waarmee rekening gehouden dient te worden. Zo zal er synchronisatie tussen interne en externe ontwikkel- en testprocessen moeten plaatsvinden. Vragen die hierbij spelen zijn: \n** Hoe wordt de inregeling van de ~OTAP-omgeving bij een geïntegreerde klantomgeving uitgevoerd?\n** Wanneer en op welke omgeving worden de verschillende schaalbaarheidsaspecten getest?\n* __Pakketselectie__: Bij selectie en aanschaf van (externe) softwareapplicaties, zal rekening gehouden moeten worden met de [[architectuurprincipes|Architectuurprincipes]]. Bij onvoldoende rekenschap kan de totale flexibiliteit van €state kan verminderen. Het nieuwe pakket mag geen functionaliteit bevatten, die al in andere modules van €state aanwezig is.

Betrokken partijen in het afhandelen van een aanvraag voor een [[hypotheek|Hypotheek]] willen graag op de hoogte worden gehouden van de voortgang van hun aanvraag in de "Mid-Office" processen. De eisen die worden gesteld aan snelheid en actualiteit nemen steeds meer toe.\n* Consumenten en adviseurs moeten kunnen raadplegen in welke fase de aanvraag in het proces verkeert en welke acties eventueel nog van hen worden verlangd. \n* Notarissen moeten voor hen bestemde passeringen kunnen opvragen. \n

{{{definitie}}}\n<<<\nEen inkoopcombinatie is een organisatie gericht op het overnemen en uitvoeren van de administratieve processen van de [[tussenpersonen|Tussenpersoon]]. Het bestaansrecht van inkoopcombinaties is gebaseerd op drie motieven: het overnemen van administratieve werkzaamheden, het bieden van interessante productarrangementen en provisieregelingen en de komst van de Wet Financiële Dienstverlening (WFD). Door de stringente eisen vanuit de WFD voelen steeds meer kleinere tussenpersonen zich genoodzaakt tot het aangaan van samenwerkingsverbanden of het aansluiten bij een inkoopcombinatie.\n<<<

Om u bekend te maken met architectuur, geven we een korte inleiding op dit onderwerp door de volgende vragen te beantwoorden:\n* [[Wat bedoelt Stater met 'architectuur']]\n* [[Hoe heeft het architectuurdenken binnen Stater zich ontwikkeld]]\n\n

Periodiek worden de te innen bedragen (rente, premies en aflossingen) geïnd conform de [[afspraken|Voorwaarden]] die hierover zijn gemaakt met de consument. Het is mogelijk dat bepaalde bedragen naar wens van de consument uit [[depots|Depot]] worden betaald. \nBedragen die spontaan door de consument worden overgemaakt, worden bestemd als extra storing op de hypotheekschuld.

{{{definitie}}}\n<<<\nDe ~ICT-oplossing heeft meerdere niveaus van inregelbaarheid, waarbij de definities op generiekere niveaus overdraagbaar zijn naar specifiekere niveaus. Zo'n niveau wordt een [[aspectlevel|Aspectlevel]] genoemd. De basis voor dit model is onderscheid tussen generieke inregelingen, landspecifieke inregelingen, klantspecifieke inregelingen. \n<<<\nDe inregelbaarheid betreft samenstelling van producten, de keuze en uitvoering van processen, de samenstelling van de distributieketen en de soort diensten. Inregeling vindt primair plaats in product services (zie [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]]).\n

Dit webdocument wordt het beste ondersteund door Internet Explorer 5.0 en hoger met een resolutie van 1024 x 768. \nBij gebruik door andere browsers of resolutie kan de informatie minder optimaal worden gepresenteerd. \nIn dit webdocument zijn externe links naar internetpagina’s opgenomen. Een toegang tot het internet is daarom aanbevolen maar is niet noodzakelijk.\nDit webdocument maakt gebruik van Javascript. De browser moet Javascripting toestaan, zonder deze ondersteuning zal de Architectuurbeschrijving niet leesbaar zijn.

[img[figuren/dim_internationaal.png]]\nDe afzonderlijke [[omgevingsdimensies|Omgevingsdimensies]] krijgen een bredere scope door de internationale [[ambitie|Ambitie]] van [[Stater]]. Dit vergroot de complexiteit:\n* Het klantbestand zal groeien met buitenlandse instellingen. Het omgaan met verschillende culturen zal een steeds belangrijkere rol krijgen. Stater en haar medewerkers moeten zich hier terdege van bewust zijn.\n* Andere landen hebben meestal een (van Nederland) afwijkend [[hypotheekproces|Hypotheekproces]], waarbij andersoortige [[diensten|Dienstverlening]] worden vereist. Stater zal deze processen en diensten moeten ondersteunen en leveren. \n* De aard en omvang van de marktontwikkelingen wordt door de internationale ambitie versterkt. Het scala aan product-, proces- en dienstverleningsvarianten wordt namelijk groter.\n* Net als het hypotheekproces, zal ook het distributienetwerk in andere landen afwijken, dus (mogelijk) andersoortige rollen en partijen die deze uitvoeren. Stater zal ook deze netwerken moeten kunnen ondersteunen. \n* Het belangrijkste effect op de gebruikersondersteuning is de noodzaak tot het ondersteunen van meerdere talen. Dit geldt zowel voor de gebruikersinterface als voor de output (brieven, rapporten, mail).\n* Voor de hand ligt dat Stater een grotere verscheidenheid aan juridische en fiscale regelgeving zal moeten ondersteunen. Hoewel de steeds voortschrijdende Europese eenwording tot meer uniformiteit op dit gebied zal leiden, is een harmonisatie op korte termijn niet te verwachten.\n* Internationalisatie zal de technologische diversiteit niet veel groter maken. Echter de ambitie om alle (inter)nationale klanten te bedienen vanuit een gecentraliseerd rekencentrum kan wel onder druk komen te staan, waardoor decentralisatie van systemen en infrastructuur voor de hand kan liggen.\n

[img[figuren/introductie.png]]\nDit webdocument bevat informatie over de architectuur van Stater. \nDe informatie is onderverdeeld in vier thema’s:\n* [[De achtergrond|Achtergrond informatie]]. Met informatie over [[Stater]], haar [[marktpositie|Positionering]] en het [[hypotheekproces|Hypotheekproces]]\n* [[De uitdaging]]. Met informatie over de [[ambitie|Ambitie]] van Stater en haar [[omgeving|Omgevingsdimensies]]\n* [[De oplossing]]. Met informatie over de gekozen architectuur\n* [[De stand van zaken]]. Met informatie over de realisatie van de architectuur.\nDe informatie wordt aangeboden in een ‘niet-lineaire beschrijving’. Hiermee wordt bedoeld dat de informatie is opgedeeld in losstaande tekstblokken, waarin sleutelwoorden (in vet) zijn opgenomen die verwijzen naar andere tekstblokken. \nDoor op deze verwijzingen te klikken stelt iedere lezer, afhankelijk van zijn eigen voorkeur, zijn verhaal samen. \n\nDoel van deze architectuurbeschrijving is om uitleg te geven over de Stater architectuur, de ontstaansgeschiedenis hiervan en de bijdrage die dit levert aan de realisatie van de doelstelling van Stater. De doelgroepen van deze architectuurbeschrijving zijn erg divers, van bestuurders en architecten tot administratieve medewerkers en computerbeheerders. Elke doelgroep heeft een eigen interesse en vakgebied en daardoor behoefte aan een specifieke beschrijving. Om niet meerdere beschrijvingen met verschillende invalshoeken te maken, is gekozen voor deze niet-lineaire beschrijving. Hiermee krijgt elke lezer de mogelijkheid een verhaal samen te stellen die tegemoet komt aan zijn behoefte. \n\nOm de lezer hierbij te ondersteunen, worden in de linker [[menubalk|Menubalk]] een aantal hulpmiddelen aangeboden, zoals een [[Help]] en [[Leeswijzer]], met tips om effectief dit webdocument te lezen.\n\n|bgcolor(#FDEDDB):Deze versie van de Stater Architectuurbeschrijving is de inzending voor het NK ICT Architectuur. Vanwege de openbaarmaking is deze versie geanonimiseerd en zijn tekstblokken met bedrijfsgevoelige informatie niet beschikbaar.|\n\nDit webdocument wordt het beste ondersteund door Internet Explorer 5.0 en hoger met een resolutie van 1024 x 768. Bij gebruik door andere browsers of resolutie kan de informatie minder optimaal worden gepresenteerd. \nIn dit webdocument zijn externe links naar internetpagina’s opgenomen. Een toegang tot het internet is daarom aanbevolen.\n\nDit webdocument is gebaseerd op het [[TiddlyWiki]]-concept.\n\n[[©Stater 2006|Copyright]]

[img[figuren/dim_wetgeving.png]]\nEr zijn steeds meer nationale en internationale regels waaraan Nederlandse financiële organisaties zich moeten houden, zoals de Wet Financiële Dienstverlening, ~Sarbanes-Oxley (SOXA), Basel II en ~SAS70. Wijzigingen in juridische en fiscale regels zijn moeilijk te voorspellen omdat ze gestuurd worden door politieke ontwikkelingen. Te denken valt aan de aftrekbaarheid van de hypotheekrente, het introduceren van starterssubsidies of recentelijk de aftrekbaarheid van de hypotheekschuld. \nDe juridische en fiscale regels hoeven niet altijd op dezelfde wijze toegepast te worden. Dit is afhankelijk van de [[soort klant|Klantdimensie]]. Bijvoorbeeld, alleen bedrijven met een notering op de Amerikaanse beurs zijn verplicht te voldoen aan de ~SOXA-regelgeving. De uitdaging voor Stater is om deze snel wijzigende wettelijke en belastingtechnische regelgeving voor alle klanten op een bevredigende wijze door te voeren.

{{{definitie}}}\n<<<\nKanalen bieden toegang tot €state faciliteiten. Dit kan direct, via elektronische toegang, maar ook via menselijke tussenkomt (bijvoorbeeld een call center)\nElektronische kanalen ontvangen normaalgesproken gestructureerde informatie, terwijl handmatige kanalen ongestructureerde informatie ontvangen waarbij menselijke interventie nodig is voor het bepalen van de routering.\n<<<

{{{definitie}}}\n<<<\nDe choreografie van de activiteiten in het totale hypotheekproces is per klant inregelbaar en kan zowel intern als extern zijn belegd. \n<<<\nDit principe is een uitbreiding op en een aanvulling van [[procesmodulariteit|Procesmodulariteit]] en [[systeemmodulariteit|Systeemmodulariteit]]. \nDe samenstelling van activiteiten in de keten kan variëren per klant; additionele activiteiten en dus modules zijn mogelijk. De configuratie en aansturing van de modules in een keten is gescheiden van de modules en instelbaar per keten. Informatie over de procesen en de bijbehorende gegevens moet uitwisselbaar zijn. Dit komt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] tot uiting in de proces engine waar de procesdefinities belegd zijn en de [[€LF]] waarmee informatieuitwisseling gefaciliteerd wordt.\n

Het volgende plaatje geeft een indruk van de wijzigingen die klanten vragen aan het huidige systeem van Stater ([[iSHS]]).\n\n[img[figuren/klantbeeld_wijzigingen.png]]\n\nWat opvalt is dat grote klanten in absolute aantallen meer wijzigingen vragen die ook groter in omvang zijn. In relatieve aantallen vragen een aantal kleine klanten juist veel wijzigingen ten opzichte van het aantal leningen dat ze hebben. Verder is er een toename in aantal wijzigingen en omvang van de wijzigingen in Duitsland te zien.\nVia dit soort klantbeelden wordt getracht om dergelijke trends waar te nemen en indien nodig voorbereidingen / aanpassingen voor te treffen.

Het [[iSHS]] lijkt één hypotheeksysteem dat door alle klanten wordt gebruikt. Dit is echter niet helemaal waar: Het systeem bestaat uit onderdelen waarvan de functionaliteit door de klanten verschillend of soms niet gebruikt wordt. Daarnaast bevat het iSHS ook klantspecifieke onderdelen en zijn er [[klantspecifieke interfaces|Technologische dimensie]] gebouwd. Met dit in het achterhoofd kan dus gesteld worden dat elke klant zijn eigen iSHS heeft, specifiek afgestemd op het [[service model|Servicedimensie]] van de klant. \n\nOm inzicht te krijgen in de verschillen van de (technische) ondersteuning die Stater aan haar klanten biedt zijn [[klantbeelden|Klantbeelden]] ontwikkeld. \nIn het onderstaande figuur worden twee klantbeelden getoond, waarin het service model, de gebruikers (medewerker van Stater en klanten, maar ook bijvoorbeeld tussenpersonen en notarissen), de systeemonderdelen en de doelgroep van de informatie zijn weergegeven. Met behulp van kleuren wordt in detail weergegeven hoe het service model is gerealiseerd, de varianten zijn:\n* Het proces wordt geheel door Stater uitgevoerd (systeem en medewerkers zijn van Stater) \n* Het proces wordt door de klant uitgevoerd met behulp van het systeem van Stater\n* Het proces wordt geheel door de klant uitgevoerd (systeem en medewerkers zijn van de klant). Hierbij zijn klantsystemen gekoppeld aan het iSHS.\n\n[img[figuren/klantbeelden.png]]\n\nDe klantbeelden in het bovenstaande voorbeeld vertonen verschillen. Twee van deze verschillende zijn er uit gelicht:\n# In het [[aanvraagproces|Vastleggen aanvraag]] maakt klant 2 gebruik van een webapplicatie om aanvragen in te dienen.\n# Het [[achterstandenproces|Behandelen achterstanden]] wordt door klant1 met eigen mederwerkers uitgevoerd op het systeem van Stater.

{{{definitie}}}\n<<<\nEen klantbeeld drukt de relatie uit die Stater met haar klanten heeft. De weergave van het klantbeeld is afhankelijk van de gekozen invalshoek, bijvoorbeeld van [[het aantal leningen|Klanten]], van [[welke onderdelen van het iSHS gebruikt worden|Klantbeeld van proces en systeemafname]], en van [[het aantal gewenste wijzigingen op het iSHS|Klantbeeld aantal wijzigingen]].\n<<<\nBinnen de architectuur worden de klantbeelden gebruikt om de [[omgeving|Omgevingsdimensies]] van Stater in kaart te brengen.

[img[figuren/dim_klant.png]]\nHet [[klantenbestand|Klanten]] van Stater bestaat uit verschillende soorten financiële instellingen met van elkaar afwijkende karakteristieken, zoals:\n* banken, verzekeraars en beleggers en hun business partners,\n* klanten met grote en kleine portefeuilles en productie,\n* klanten waarbij een [[hypotheek|Hypotheek]] een core product is en klanten waarbij dat een bijproduct is,\n* geldgevers en beleggers i.v.m. [[securitisaties|Securitisatie]] en funding.\nAl deze klanten, meer dan 35, hebben hun een eigen businessstrategie, marktbenadering en processen en hebben een eigen positie in de hypotheekmarkt en in de [[distributieketen|Distributie dimensie]]. Hierdoor heeft elke klant zijn eigen, unieke behoefte aan [[dienstverlening|Dienstverlening]] van Stater met bijbehorende afspraken, processen en systeemondersteuning. Dit levert dus raakvlakken op met de [[servicedimensie|Servicedimensie]] en de [[technologische dimensie|Technologische dimensie]].\n

Een overzicht van de klanten aan wie [[Stater]] haar [[diensten|Dienstverlening]] levert. \nDe hoogte van de cylinders representeert het aantal leningen.\n\n[img[figuren/klanten.png]]\n

{{{definitie}}}\n<<<\nDe mate waarin het systeem gekoppeld kan worden aan andere systemen, softwarepakketten, databases en netwerken.\n<<<\n\nDit principe is een technische implementatie van [[ketenintegratie|Ketenintegratie]] en [[procesmodulariteit|Procesmodulariteit]]. De ~ICT-oplossing biedt een infrastructuur om koppelingen met interne en externe systemen eenvoudig te kunnen realiseren (Broker met dataconversie). Alle modules communiceren met andere componenten via deze infrastructuur zodat de koppelingen eenvoudig kunnen worden verlegd (per keten/klant).\n

De informatie in dit webdocument is opgedeeld in losstaande tekstblokken, waarin sleutelwoorden (in vet) zijn opgenomen die verwijzen naar andere tekstblokken. Door te klikken op zo’n sleutelwoord wordt een nieuw tekstblok geopend en direct onder de actieve tekst geplaatst. Op deze wijze stelt de lezer een eigen verhaal samen.\nDeze methode kan al snel leiden tot een groot aantal geopende tekstblokken waarbij de lezer het overzicht verliest. Aanbevolen wordt een tekstblok direct te sluiten wanneer deze gelezen is. Hierdoor blijft het aantal geopende tekstblokken beperkt en houdt de lezer het overzicht.\n\nWanneer de lezer kiest voor een voorgedefinieerde invalshoek, wordt een aantal tekstblokken direct geopend in een nieuwe webbrowser en geeft zo een overzicht van die invalshoek. De lezer kan naar eigen inzicht nieuwe tekstblokken openen voor nieuwe of aanvullende informatie. Hierdoor kan echter de verhaallijn van de invalshoek verloren raken. Het advies is om eerst de invalshoek te lezen en pas daarna nieuwe tekstblokken te openen waarmee een verdieping van de invalshoek verkregen kan worden.\n\nWanneer het overzicht verloren dreigt te gaan, is het advies alle tekstblokken te sluiten (zie de [[menubalk|Menubalk]]) en vervolgens de [[introductie|Introductie]] weer op te roepen. Met enkele goed gekozen klikken kan het tekstblok gevonden worden om het verhaal verder te lezen.

©2006 [[Stater|http://www.stater.nl]]\n----\n''Algemeen''\n<html><a href="Stater Architectuurbeschrijving V1.1.html">Introductie</a></html>\n[[Leeswijzer]]\n[[Help]]\n\n''Thema's''\n[[De achtergrond|Achtergrond informatie]]\n[[De uitdaging]]\n[[De oplossing]]\n[[De stand van zaken]]\n\n''Invalshoeken''\n[[Management|Stater Architectuurbeschrijving V1.1.html#Stater%20Positionering%20Ambitie%20Businessdrivers%20Omgevingsdimensies%20Architectuurprincipes%20Estate%20%5B%5BDe%20stand%20van%20zaken%5D%5D]]\n[[Architectuur|Stater Architectuurbeschrijving V1.1.html#Stater%20Omgevingsdimensies%20iSHS%20Businessdrivers%20Architectuurprincipes%20%5B%5BFunctionele%20Applicatiearchitectuur%5D%5D]]\n[[Techniek|Stater Architectuurbeschrijving V1.1.html#Stater%20%5B%5BFunctionele%20Applicatiearchitectuur%5D%5D%20%5B%5BTechnische%20architectuur%5D%5D%20%5B%5BImpact%20van%20de%20architectuur%5D%5D%20Architectuurafwijkingen]]\n[[Gebruik|Stater Architectuurbeschrijving V1.1.html#Stater%20%5B%5BImpact%20van%20de%20architectuur%5D%5D%20%5B%5BFunctionaliteit%20in%20het%20domeinmodel%5D%5D]]\n[[Architectuurproces|Stater Architectuurbeschrijving V1.1.html#%5B%5BWat%20bedoelt%20Stater%20met%20'architectuur'%5D%5D%20%5B%5BHoe%20heeft%20het%20architectuurdenken%20binnen%20Stater%20zich%20ontwikkeld%5D%5D%20Architectuurproces%20Architectuurproducten]]\n----\n\n

[img[figuren/dim_markt.png]]\nDe hypotheekmarkt is sterk in beweging en de concurrentie neemt toe. Dit uit zich o.a. in de volgende ontwikkelingen:\n* Er zullen steeds sneller nieuwe, complexere hypotheekproducten (zoals de krediethypotheek) op de markt komen. \n* De grenzen tussen hypotheken en leningen vervagen. Dit leidt tot een verschuiving van hypothecaire leningen naar schulden zonder of met verschillende soorten zekerheden en tot ‘total finance’-oplossingen.\nOok [[de markt van dienstverleners|Positionering]] rond hypotheken is in ontwikkeling:\n* Nieuwe concurrenten betreden de markt van hypothekenserviceproviders, zoals ondernemende hypotheekbanken en ~ICT-dienstverleners.\n* Steeds meer nichespelers die slechts een (klein) deel van de [[waardeketen|Waardeketen]] bedienen, betreden de hypotheekmarkt.\n* Er is een groeiende vraag naar aanvullende diensten, zoals leveren van uitgebreide en geïntegreerde informatie, risicomanagement, zekerhedenbeheer en fundingmodellen.\nVoor Stater betekent dit een continue uitdaging om te veranderen op gebied van ondersteunde (hypotheek)producten, vormen van dienstverlening en het kunnen bedienen of spelen van rollen in de hypotheekketen.\n\n

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

@@Vanwege bedrijfsgevoelige informatie is de originele tekst uit dit tekstblok verwijderd.@@

{{{definitie}}}\n<<<\nDe ~ICT-oplossing biedt ondersteuning voor meerdere talen – zowel interactief, in rapportages als in ondersteuning (Help functies). De gekozen taal kan afhankelijk zijn van verschillende aspecten (gebruiker, klant, land, etc.)\n<<<\n\nMeertaligheid komt terug in de user-interfaces, brieven en rapportages. Aandachtspunt hierbij is dat er meerdere combinaties van talen binnen één omgeving aanwezig zijn. Bijvoorbeeld: Een Nederlandstalige consument koopt een huis in Frankrijk met een Nederlandse hypotheek te passeren bij een Franse notaris.\n\n\n\n\n

De linker menubalk biedt de volgende opties:\n* __Algemeen__: Hier kan worden gekozen voor het opnieuw opstarten van het webdocument en de [[introductie|Introductie]] weer op te roepen of de [[helpinformatie|Help]] te raadplegen.\n* __Thema’s__: Hier kan worden gekozen voor de belangrijkste thema’s. \n* __Invalshoeken__: Hier kan worden gekozen voor voorgedefinieerde invalshoeken. Wanneer de lezer hiervoor kiest, wordt een aantal tekstblokken direct geopend om zo een overzicht te geven van die invalshoek. De lezer kan naar eigen inzicht nieuwe tekstblokken openen voor nieuwe of aanvullende informatie. Het advies is om eerst een invalshoek te lezen en pas daarna nieuwe tekstblokken te openen waarmee een verdieping van de invalshoek verkregen kan worden. \n* __Zoek__: met zoeken worden alle tekstblokken getoond waarin het zoekwoord voorkomt.\n* __Sluit alles__: hiermee worden alle geopende tekstblokken gesloten.\n* __Permaview__: met deze optie kan de lezer zelf een invalshoek maken. Wanneer men hiervoor kiest, worden alle geopende tekstblokken in een link (URL) opgenomen. Deze URL kan net als elk webpagina-adres toegevoegd worden aan de favorieten in de internetbrowser. Op deze manier kan later deze ‘permanente view’ weer worden opgeroepen. \n* __Alle tekstblokken__: Deze tabel geeft een alfabetische opsomming van alle tekstblokken.\n

Stater heeft begin 2004 strategisch gekozen voor het "Microsoft, tenzij" beleid. Dit beleid houdt in dat als een product nodig is, er eerst wordt gekeken of Microsoft een product aanbiedt met ongeveer de gewenste functionaliteit. Als dit zo is, wordt dit Microsoft product geselecteerd. Pas als er een heel zwaarwegende reden is waarom het Microsoft product echt niet voldoet aan wat Stater wil, wordt er gekeken naar welke andere leveranciers een dergelijk product aanbieden. Voor deze selectie zal dan een RFI/RFP traject worden gestart.\n\nEr liggen een aantal redenen ten grondslag aan dit beleid, zoals:\n* Producten van één leverancier zorgen voor minder integratieproblemen en dus voor lagere kosten in beheer.\n* Meerdere producten betrekken van één leverancier kan veelal vanuit een raamcontract dat zorgt voor lagere licentiekosten.\n* Strategisch overleg met leveranciers over de toekomstige ontwikkeling van producten kost tijd en aandacht; vermindering van aantal leveranciers vermindert deze inspanningen.\n* Bij integratieproblemen kan beroep worden gedaan op één leverancier om het probleem op te lossen; de verschillende leveranciers kunnen niet naar elkaar wijzen.\nNatuurlijk zorgt het "Microsoft, tenzij" beleid voor een grote afhankelijkheid van de betreffende leverancier Microsoft. Afhankelijkheid van leveranciers is echter in ieder geval onvermijdelijk en Stater wil dan liever afhankelijk zijn van een wereldspeler als Microsoft. Voorbeelden van Microsoft producten die worden ingezet binnen Stater zijn:\n* Windows operating system\n* Office suite\n* .NET framework\n* Visual Studio als ontwikkeltool\n* ~BizTalk Server als [[integration bus|Meer informatie over de integration bus]] en [[process engine|Meer informatie over de process engine]]\n* SQL Server als database

{{{definitie}}}\n<<<\nTot de ~Mid-Office behoren de [[hypotheeekprocessen|Hypotheekproces]] die ten dienste staan van de afhandeling van de verkoop van een [[hypotheek|Hypotheek]]. \n<<<\n

{{{definitie}}}\n<<<\nDe ~ICT-oplossing biedt ondersteuning voor meerdere valuta – zowel interactief, in rapportages als in ondersteuning (Help functies). Binnen één omgeving ([[VCE]])van een geldgever wordt met één valuta gewerkt.\n<<<\n

{{{definitie}}}\n<<<\nDe modules van de ~ICT-oplossing kunnen via diverse (technische) [[kanalen|Kanalen]] worden gebruikt, en worden niet kanaalspecifiek geïmplementeerd. De modules kunnen zowel interactief (via een ~user-interface) als programmatisch worden gebruikt.\n<<<\n\nDit betekent dat elke modules zowel een service interface moet bieden als (voor zover relevant) een apart gescheiden user-interface. Uitgangspunt hierbij is dat er gebruik gemaakt wordt van internetstandaarden.

{{{definitie}}}\n<<<\nOTAP is de afkorting voor Ontwikkel, Test, Acceptatie en Productie. Het zijn systeemomgevingen waarin de verschillende fases van het software ontwikkelproces worden uitgevoerd. Deze omgevingen zijn strikt gescheiden om afhankelijkheden tussen de fases van het ontwikkelproces te voorkomen.\n<<<\n\n

{{{definitie}}}\n<<<\n"Objectoriëntatie of OO is de zienswijze die gebruikt wordt bij het objectgeoriënteerd programmeren. Bij deze benadering wordt programmatuur opgebouwd als een verzameling van interacterende objecten die elk behoren tot een soort of klasse. Objecten spelen de rol die variabelen spelen in klassieke programmatuur. De klassen daarentegen spelen de rol van de types."\n<<<\nDeze informatie is afkomstig van de [[OO pagina op Wikipedia|http://nl.wikipedia.org/wiki/Objectori%C3%ABntatie]].

Voordat een offerte uitgebracht kan worden wordt de aanvraag op kredietwaardigheid beoordeeld. Hierbij wordt primair gekeken naar:\n* de samenstelling van het inkomen en het betalingsgedrag van de aanvragers \n* de waarde van het onderpand, waarop de lening wordt verstrekt\n* eventuele ingebrachte aanvullende zekerheden. \nDe gegevens, die zijn vermeld op de aanvraag worden hierbij als vertrekpunt genomen. In een later stadium ([[Finaal akkoord]]) moeten aangeleverde [[bewijsstukken|Bewijsstuk]] aantonen dat deze gegevens correct zijn weergegeven op de aanvraag. Het beoordelen van een aanvraag kan aan de hand van een kredietbeoordelinginstrument (automatisch) uitgevoerd worden. Hierbij worden gegevens van externe instanties geraadpleegd, zoals het [[Bureau Krediet Registratie]]. Afhankelijk van de uitkomst van de beoordeling wordt een offerte aangemaakt of wordt de aanvraag (automatisch) voorgelegd aan een kredietbeoordelaar die handmatig de aanvraag toetst. \nWanneer een offerte aangemaakt wordt, wordt deze geretourneerd naar de indiener. De offerte bevat:\n* de gevraagde financieringsconstructie\n* de geoffreerde rentepercentages\n* de [[voorwaarden|Voorwaarden]] en [[aanvullende bepalingen|Aanvullende bepalingen]]\n* het overzicht met nog in te dienen bewijsstukken.\n

Als gevolg van [[de positie|Positionering]] en haar [[dienstverlening|Dienstverlening]] heeft [[Stater]] te maken met veel omgevingsfactoren. Deze factoren hebben betrekking op meerdere dimensies. Om op alle veranderingen in de omgevingsdimensies adequaat te kunnen inspelen is een flexibele ~ICT-oplossing noodzakelijk. Dit maakt het realiseren van de optimale dienstverlening en een geschikte ondersteunende ~ICT-oplossing complex. De behoefte aan flexibiliteit is een van de belangrijkste eigenschappen die door [[de nieuwe ICT-oplossing|€state]] gerealiseerd dient te worden en komt daarom terug in de [[architectuurprincipes|Architectuurprincipes]]. \nHieronder worden de belangrijkste omgevingsdimensies waar Stater mee te maken heeft toegelicht.\n[img[figuren/dimensies.png]]\n* [[Klantdimensie]]: Het [[klantenbestand|Klanten]] van Stater bestaat uit verschillende soorten klanten met elk hun eigen karakteristieken, eisen en wensen.\n* [[Businessstrategiedimensie]]: De businessstrategie van Stater is gericht op het bereiken van een optimale mix van operational excellence, customer intimacy en product leadership. Hierdoor is Stater in staat haar klanten maximaal te ondersteunen in het behouden en uitbouwen van hun concurrentiepositie in de hypotheekmarkt.\n* [[Servicedimensie]]: Stater ondersteunt verschillende servicemodellen met als uitersten een puur ~BPO- of een puur ~ASP-model. In de praktijk worden de klanten ondersteund met een gemengd model van zowel BPO als ASP.\n* [[Marktontwikkelingen]]: Stater ziet allerlei ontwikkelingen in de markt op het gebied van o.a. producten, dienstverlening, processen en funding.\n* [[Distributie dimensie]]: Stater vervult een centrale rol in het hypotheken distributienetwerk en is in staat de betrokken partijen te ondersteunen en te verbinden.\n* [[Gebruikersdimensie]]: Gebruikers van de ~ICT-oplossing van Stater zijn te verdelen in verschillende groepen (zoals medewerkers van Stater zelf, medewerkers van klanten van Stater, medewerkers van partijen in de distributieketen, tussenpersonen en notarissen).\n* [[Juridische en fiscale dimensie]]: De voortdurende wijzigingen in wettelijke en belastingtechnische regelgeving moeten voor alle klanten op een bevredigende wijze worden doorgevoerd. De klanten hebben overigens vaak behoefte aan een eigen interpretatie van deze regels. \n* [[Technologische dimensie]]: ICT speelt een sleutelrol in de bedrijfsvoering van Stater. Daarbij streeft Stater ernaar om processen zoveel mogelijk geautomatiseerd af te handelen. Dit heeft implicaties op het gebied van integratie en van bericht- en bestanduitwisseling met andere organisaties. \n* [[Internationale dimensie]]: De ambitie van Stater is om de leidende internationale servicer in de Europese hypotheekmarkt te zijn. Dit vereist kennis van de hypotheekmarkt, producten en processen in de landen waar Stater is gevestigd of wil toetreden. Dit versterkt de diversiteit van de eerder genoemde omgevingsdimensies.

{{{definitie}}}\n<<<\nDe structuur van de ~ICT-oplossing is zodanig opgezet dat wijzigingen beperkt blijven tot een minimaal aantal componenten en eenvoudig zijn door te voeren.\n<<<\nDit komt terug in de inrichting van de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] door de splitsing in aparte componenten en het onderscheiden van procesengine en product services.\n

De [[passering|Passeren]] van de [[hypotheek|Hypotheek]] is ,indien van toepassing, aanleiding om bonus en provisie te berekenen en uit te betalen aan de betrokken adviseur (of zijn organisatie). Afhankelijk van de [[geldgever|Geldgever]] en het [[distributiekanaal|Distributiekanalen]] worden verschillende bonus- en provisieregelingen beheerd en toegepast. \n

In de eerste fase van het [[€state]]-programma is een architectuurvisie ontwikkeld voor de toekomstige ~ICT-oplossing. Op basis van de input ([[visie, strategie|Businessdrivers]], [[omgeving|Omgevingsdimensies]] en [[€state businessrequirements]]) zijn de [[architectuurprincipes|Architectuurprincipes]] opgesteld. Hiermee zijn drie verschillende architectuurkandidaten ontworpen:\n* [[Functionaliteit gecentreerde architectuur]]\n* [[Dossier gecentreerde architectuur]]\n* [[Proces gecentreerde architectuur]]\nIn de [[evaluatie|Evaluatie]] zijn de kandidaten met elkaar vergeleken. Geschat is in welke mate ze voldoen aan de architectuurprincipes en zijn aspecten als haalbaarheid, doorlooptijd en verwachte kosten in ogenschouw genomen. \n|bgcolor(#FDEDDB): Op basis van deze evaluatie heeft de €state-stuurgroep gekozen voor de proces gecentreerde architectuur.|\nDeze is daarna verder gedetailleerd in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]].

{{{definitie}}}\n<<<\nEen bedrijfstrategie die erop gericht is de primaire businessprocessen zo effectief en efficiënt mogelijk te laten verlopen met als doel de concurrentiepositie in de markt te verstevigen. Klanten op een zeer betrouwbare wijze producten en diensten leveren tegen zeer competitieve prijzen. Dell Computers en ~EasyJet zijn hiervan een voorbeeld.\n<<<\n\n

De consument oriënteert zich op de financiering van een te kopen onderpand. Hierbij kan de consument gebruik maken van verschillende [[distributiekanalen|Distributiekanalen]]. Doel van het proces 'oriëntatie en advies' is om, op basis van de behoefte van de consument, niet alleen de best passende financieringsconstructie vast te stellen, maar ook om de consument inzicht te geven en eventueel te ondersteunen in het vervolg van het af te lopen traject. De consument ontvangt hierbij overzichten van hypotheekberekeningen en adviezen. \n

{{{definitie}}}\n<<<\nDe PACT is het project Proof of Architectural Concepts and Technology dat een concrete implementatie voor een aantal architectuur concepten verzorgt en neemt daarmee een aantal onzekerheden rondom architectuur concepten en technologieën weg.\nZie [[Meer informatie over de PACT]] voor de onderwerpen.\n<<<

{{{definitie}}}\n<<<\nEen packager is een organisatie alleen gericht op het overnemen en uitvoeren van de administratieve processen van de [[tussenperonen|Tussenpersoon]]. Dit in tegenstelling tot een [[inkoopcombinatie|Inkoopcombinatie]] die daarnaast productarrangementen en provisieregelingen aanbiedt.\n<<<\n\n

<!-- HEADER -->\n<div class='header' macro='gradient vert #7E62A4'>\n <div class='headerShadow'></div>\n <div class='headerForeground'></div>\n</div>\n\n<!-- MAIN MENU -->\n<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>\n\n<!-- SIDEBAR -->\n<div id='sidebar'>\n <div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>\n <div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>\n</div>\n\n<!-- DISPLAY -->\n<div id='displayArea'>\n <div id='messageArea'></div>\n <div id='tiddlerDisplay'></div>\n</div>\n\n<!-- EIGEN DIV's-->\n<div style="position: absolute; background-color: white; left: 0px; top: 0px; height: 66px; width: 211px; padding: 0;"><center><img border ="0" src="figuren/stater_logo.png"></center></div> \n\n<div style="position: absolute; background-color: transparant; left: 215px; top: 18px; height: 66px; width: 500px; padding: 0;"><font size="4" color="#ffffff"> </font></div> \n\n\n

Het feitelijk passeren van de [[hypotheek|Hypotheek]] vindt plaats bij de notaris. De kopende en de verkopende partij (of hun afgevaardigden) zijn daarbij aanwezig. Alle benodigde documenten worden ondertekend, zoals de [[transportakte|Transportakte]] en de [[hypotheekakte|Hypotheekakte]]. De notaris draagt zorg voor de afwikkeling van de gelden, de bijschrijving in de openbare registers en het melden van de passeerdatum aan de [[geldgever|Geldgever]]. De geldgever ontvangt van de notaris de definitieve passeerdatum en de documenten die nodig zijn voor het beheren van de hypotheek.\nDe passeerdatum is het moment waarop de hypotheek van kracht wordt en moet de consument zijn betalingsverplichtingen nakomen.\n

{{{definitie}}}\n<<<\nEen pool is een verzameling hypotheken met gelijkwaardige kenmerken en risicoklasse die door de oorspronkelijke geldgever zijn verkocht aan beleggers op de [[secundaire markt|Secundaire markt]]. De beleggers ontvangen de periodiek verschuldigde bedragen aan rente en aflossing van de hypotheken\n<<<

[[Stater]] is op hypothekengebied op dit moment koploper in het succesvol aanbieden van 'shared BPO' aan verschillende klanten in meerdere landen. Zo heeft Stater ongeveer 30% van de Nederlandse hypotheken in beheer.\n\nHet uitbesteden van business processen ([[BPO]]) ontwikkelt zich in de volgende fasen:\n* __Internal Sourcing__: De diensten in het [[hypotheekproces|Hypotheekproces]] zijn gecentraliseerd (in een [[shared service center|Shared service center]]) en worden gebruikt door de eigen organisatie. \n* __Single client BPO __: Spelers in dit model zijn veelal doorgegroeid vanuit een interne shared service center naar een zelfstandig bedrijf, waarbij de diensten worden afgenomen door één klant in één land. Ook de ~ICT-oplossing wordt ingezet voor één klant.\n* __Shared BPO __: BPO voor relatief kleine klanten. De dienstverlening wordt ingezet voor meerdere klanten. Dit geldt ook voor de ~ICT-oplossing om de gewenste schaalvoordelen te bereiken.\n* __Large Shared BPO __: 'Shared BPO' voor grote klanten. Hierbij stoten klanten hun eigen personeel af, waardoor het kunnen insourcen van personeel van vitaal belang is.\n* __Value chain unbundling __: Verdere opsplitsing van de [[hypotheekwaardeketen|Waardeketen]] waarbij spelers zich zullen specialiseren op een beperkt aantal activiteiten in de keten.\nBij elke faseovergang neemt de complexiteit toe. Een voorbeeld van toenemende complexiteit is de overgang van 'single client BPO' naar 'shared BPO': Bij deze overgang moeten meerdere klanten bediend worden met dezelfde ~ICT-oplossing. Dit betekent dat de ~ICT-oplossing hiervoor geschikt moet zijn of moet worden gemaakt. Om de toenemende complexiteit aan te kunnen moeten er dus investeringen gedaan worden. \nWanneer er weinig spelers (concurrentie) in een fase zijn, zijn de marges hoog. De marges zullen dalen zodra meerdere spelers de fases betreden. Het betreden van een volgende fase zorgt ervoor dat er weer hogere marges behaald kunnen worden. De complexiteit van de volgende fase moet dan wel eerst onderkent en bestreden zijn.\n\nIn het volgende figuur is aangegeven in welke fasen Stater en haar concurrentie zijn gepositioneerd. \n[img[figuren/positie.png]]\n\n\nDoor de toename van het aantal spelers zullen de tarieven van de ~BPO-diensten onder druk komen te staan en zullen er hogere eisen aan het niveau van de diensten gesteld worden. Hierdoor worden de spelers in dit marktsegment gedwongen een volgende stap te maken in het BPO groei model met als uiteindelijk doel 'Large shared BPO' of zelfs 'value chain unbundling'.

De proces gecentreerde architectuur ontstond uit een kleinschalige Proof of Concept, die in het verleden (voor [[€state]]) is uitgevoerd. Het idee is om productkennis en –intelligentie uit de programmatuur te halen en onder te brengen in een Product Configurator, die geoptimaliseerd is om productaanpassingen middels configuratie te ondersteunen. Op deze manier worden programmatuuraanpassingen geminimaliseerd. Op een zelfde manier wordt ook de proceskennis en –intelligentie uit de programmatuur gehaald en ondergebracht in een Process Engine, die is geoptimaliseerd om processen visueel te modeleren. Procesaanpassingen kunnen dan ook worden geconfigureerd in plaats van geprogrammeerd. De overgebleven functionaliteit wordt gerealiseerd in losse services, met elk een eigen functionele verantwoordelijkheid.\n\nUit de [[evaluatie|Evaluatie]] bleek dit alternatief de beste balans tussen realisatie van een systeem dat in hoge mate voldoet aan de gestelde [[principes|Architectuurprincipes]] en doelen enerzijds en risico, kosten en doorlooptijd anderzijds. \n\nDe €state-stuurgroep heeft voor dit alternatief gekozen en het is verder uitgewerkt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]].\n

{{{procesmodulariteit}}}\n<<<\nProcessen zijn onderverdeeld in activiteiten die onderling onafhankelijk en ontkoppeld zijn; dit geldt zowel voor het primaire proces als ondersteunende activiteiten (controles, e.d.). Iedere activiteit kan zowel intern (bij Stater) als extern (bij de klant of elders) zijn belegd.\n<<<\n\nDit principe komt tot uiting in de volgende elementen in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]]:\n* De keuze voor een [[process engine|Meer informatie over de process engine]], waarin de processen gemodelleerd kunnen worden door het samenstellen van een procesmodel uit losse, onafhankelijke diensten. De process engine is in staat het procesmodel uit te voeren en daarbij de regie over het proces te voeren.\n* De keuze voor de [[integration bus|Meer informatie over de integration bus]], waardoor het transparant wordt of interne dan wel externe services worden aangeroepen.\n* Het opdelen van de geautomatiseerde ondersteuning in herbruikbare, losse, onafhankelijke services.\n

{{{definitie}}}\n<<<\nEen bedrijfstrategie die gericht is op het zoveel mogelijk ontwikkelen van innovatieve producten en diensten. Het gaat hier om technologisch hoogstaande producten, creativiteit, snelle commercialisering en constante verbetering. Nike en Philips zijn hiervan een goed voorbeeld\n<<<\n\n

{{{definitie}}}\n<<<\nEr mogen geen technische redenen aanwezig zijn die een bepaalde combinatie van productkenmerken verhinderen. Legale combinaties van productkenmerken worden via instellingen/inregelingen gedefinieerd. De ~ICT-oplossing moet voorbereid zijn op het toevoegen van rekenregels zonder aanpassing van bestaande software. De flexibiliteit van de ~ICT-oplossing moet zodanig zijn dat niet-woninggebonden leningen ondersteund kunnen worden.\n<<<\n\nDit principe komt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] tot uiting in de volgende elementen:\n* Al het gedrag in de ~ICT-oplossing dat afhankelijk is van productparameters wordt daadwerkelijk gestuurd door inregelingen op één centrale plek: de product services.\n* De bouwstenen voor de functionele verwerking van producten en de daaraan gerelateerde inregelingen worden gedefinieerd in het [[Stater domeinmodel]].\n

[[€state]] wordt gerealiseerd door middel van het uitvoeren van meerdere projecten, die gelijktijdig aan elkaar en/of na elkaar worden uitgevoerd. Dit geheel van projecten wordt het programma €state genoemd.\nOp dit moment is nog geen volledig zicht op //alle// projecten die nodig zijn om het €state programma af te ronden.\nNa afronding van de voorbereidende studie van €state, waarin ook de gewenste architectuur van €state is vastgesteld, is in november 2004 op basis van criteria gekozen voor de uitvoering van de volgende projecten.\n\n[img[figuren/projectoverzicht.png]]\n\n__Project ~Mid-Office __\nDoel van het project is om alle functionaliteit met betrekking tot de afhandeling van hypotheken in het [[Mid-Office]] te realiseren.\n\n__Project Stater Document Engine 2.0__\nMet de Stater Document Engine (SDE) worden brieven aangemaakt en afgedrukt.\nProject SDE 2.0 heeft tot doel versie 2.0 van de SDE te realiseren waarmee de mogelijkheden voor het beheer en aanmaak van brieven wordt verbeterd.\n\n__Data Warehouse__\nDoor middel van een incrementele aanpak, waarbij tussentijds incrementen worden opgeleverd en in gebruik worden genomen, wordt het [[data warehouse|Meer informatie over het DWH]] gerealiseerd.\nHet data warehouse voorziet in de vraag naar rapportages over gegevens die door Stater worden beheerd.\n\n__Communication core__\nHet project communication core voorziet in de realisatie van de [[integration bus|Meer informatie over de integration bus]].\n\n__New hardware infrastructure__\nVoor €state is een volledige nieuwe hardware infrastructuur nodig, voor zowel ontwikkeling als productie.\nDit project voorziet in de nieuwe hardware infrastructuur. \n\n__PACT __\nDe [[PACT]] verzorgt een concrete implementatie voor een aantal architectuurconcepten.\n\n__Project ~Back-Office __\nDoel van het project is om alle functionaliteit met betrekking tot de afhandeling van hypotheken in het [[Back-Office]] te realiseren.\n

De projecten die binnen het €state-programma uitgevoerd worden, leveren elk een bijdrage aan de realisatie van de architectuur. Om het project voldoende 'architectuurbagage' mee te geven wordt een Project Startarchitectuur (PSA) beschreven. In dit document wordt geprobeerd zo goed mogelijke afweging te maken tussen het lange termijn architectuurbelang en het korte termijn projectbelang. \nEen PSA is een beschrijving waarin de architectuur wordt toegespitst op de specifieke situatie van een project. De architectuur wordt zo geformuleerd en verder verdiept dat het duidelijk is aan welke standaards en richtlijnen het project zich moet houden, om de juiste bijdrage aan de architectuur in bredere zin te leveren. De globale inhoud van een PSA ziet er als volgt uit: \n* Een beschrijving van de rol van het project in de realisatie van de €state doelarchitectuur. Hierbij wordt stil gestaan bij de standaards en richtlijnen die van toepassing zijn in het betreffende project. Er wordt per item globaal aangegeven wat het item inhoudt en vervolgens wat het concreet voor het betreffende project inhoudt. \n* Een beschrijving van de doelarchitectuur van het (deel)systeem dat binnen het project wordt opgeleverd. Hier zullen eveneens standaards en richtlijnen uitvloeien, die eveneens stuk voor stuk worden behandeld.\n* Het migratiepad om van de huidige naar de nieuwe situatie te komen. Vragen die hierbij aan bod komen zijn: Welke systemen kunnen in welke volgorde worden vervangen en wat is de beste manier om om te gaan met de tijdelijke situatie waarin oude systemen en nieuwe systemen worden gecombineerd. Ook hier wordt weer geprobeerd om zo goed mogelijk het korte termijn projectbelang en het lange termijn architectuurbelang af te wegen. \n* Concessies aan de architectuur, inclusief voorgestelde maatregelen ter vermindering van de concessies of voorstellen voor vervolgprojecten ter oplossing van de concessies.\n* Openstaande punten.\n \nHet doel van de PSA is het minimaliseren van [[architectuurafwijkingen|Architectuurafwijkingen]] en project helpen bij het leveren van een bijdrage aan de architectuur. Verder worden eventuele architectuurafwijkingen wel inzichtelijk gemaakt en wordt een voorstel gedefinieerd voor oplossing van de afwijking.\n

Bij het ontwikkelen van het [[Stater domeinmodel]] kwam de vraag naar voren of bepaalde oplossingen in het model ook wel konden werken in de werkelijkheid (in code). Om hiervoor gevoel te krijgen is een prototype ontwikkeld. In dit prototype zijn de belangrijkste [[functionaliteiten|Functionaliteit in het domeinmodel]] uit het domeinmodel verwerkt. Het doel van het prototype is dus vooral gericht op validatie van de realiseerbaarheid van het domeinmodel. Doordat het prototype de belangrijkste concepten uit het domeinmodel bevat, is het ook een hulpmiddel geworden om het domeinmodel uit te leggen. Onderstaand figuur is een schermafdruk van dit prototype. \n\n[img[figuren/prototype.png]]\n\n

{{{definitie}}}\n<<<\nDe ~ICT-oplossing bevat geen ingebouwde kennis over rapportages. De rapportage functionaliteit is ontkoppeld van de geautomatiseerde ondersteuning van het primaire proces. Alle geautoriseerde partijen krijgen toegang tot hun rapportagedata, in de door hen gewenste vorm van doorsneden en aggregaties.\n<<<\n\nIn de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] komt dit principe tot uiting in het [[data warehouse|Meer informatie over het DWH]] dat de primaire bron is voor de rapportages.\n

Er kunnen twee typen rapportages worden onderscheiden:\n* Intern: Rapportages om de bedrijfsvoering te sturen, te controleren en te verantwoorden. \n* Extern: Rapportages voorvloeiende uit juridische en fiscale regelgeving.\nWanneer er sprake is van [[BPO]] zal de servicer beide typen rapportages moeten verzorgen voor haar klanten.

In de [[product services|Meer informatie over de product services]] kunnen producten en hun bijbehorende parameters worden geconfigureerd. Een product beschrijft een soort lening, bijvoorbeeld 'De Groeispaar hypotheek van Geldgever X'. Een product wordt samengesteld uit relevante producteigenschappen en de mogelijke bijbehorende waardes. Een voorbeeld van een producteigenschap is de 'rentevastheidsperiode'. Deze periode geeft aan hoe lang de rente van een lening vast ligt (uitgedrukt in maanden). De mogelijke waardes van deze eigenschap zijn bijvoorbeeld 1, 6, 12, en 24. Een ander voorbeeld van een producteigenschap is bijvoorbeeld of boetes van toepassing zijn. Mogelijke waardes zijn dan de boetemethodieken die van kracht zijn.\n\nEen individuele lening wordt gerepresenteerd in een [[€LF|Meer informatie over de €LF]]. De definitie van de €LF bevat attributen en parameters die van toepassing zijn op de lening. Een waarde zoals het aantal maanden kan opgeslagen worden in een attribuut. Op basis van een waarde kunnen echter ook parameters aan de €LF toegevoegd worden, wanneer er bijvoorbeeld sprake is van een bepaalde boetemethode.\n\nWanneer producten wijzigen, kan dit leiden tot wijzigingen in de €LF en tot aanpassingen in de [[services|Meer informatie over de services]]:\n* Het samenstellen van een nieuw product uit bestaande producteigenschappen en waarden zal niet leiden tot wijzigingen in de €LF. Daarnaast is het niet waarschijnlijk dat er nieuwe functionaliteit nodig is die in de services gerealiseerd zal moeten te worden.\n* Wanneer een nieuw product wordt samengesteld uit een nieuwe combinatie van bestaande producteigenschappen met //nieuwe// waarden, zal dat ook niet leiden tot wijzigingen in de €LF. Waarschijnlijk zullen er wel beperkte wijzigingen nodig zijn in de services om om te kunnen gaan met deze nieuwe waarden.\n* Het samenstellen van een nieuw product uit een nieuwe combinatie van //nieuwe// producteigenschappen met //nieuwe// waarden zal wel leiden tot wijzigingen in de €LF (omdat deze eigenschappen ook geregistreerd dienen te worden bij de lening). Dit zorgt dus voor een structurele wijziging aan de €LF waar de services ook overweg mee moeten kunnen. Daardoor zullen deze services ook aangepast moeten worden.

Na algehele aflossing van de lening (voortijdig of bij einde looptijd) kan de notaris een verzoek tot volmacht van royement vragen. Heeft de consument aan alle betalingsverplichtingen voldaan, dit mede ter beoordeling van de geldgever, dan verstrekt Stater de volmacht. De notaris verzorgt de doorhaling van de inschrijving in het openbare register waarmee het recht van [[hypotheek|Hypotheek]] vervalt.

{{{definitie}}}\n<<<\nDe Stater Document Engine is een bestaande applicatie waarmee de brieven uit het [[iSHS]] volgens het [[private label|White-/private-labeling]]-concept worden vervaardigd en gedistribueerd.\n<<<\n

{{{definitie}}}\n<<<\n"In computing, the term service-oriented architecture expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation." \n<<<\nDeze definitie is afkomstig van de [[SOA pagina op wikipedia (Engels)|http://en.wikipedia.org/wiki/Service-oriented_architecture]], zie link voor meer informatie. Zie ook [[SOA volgens Stater]] voor de interpretatie van Stater van de term SOA.\n

De ontwikkelde €state architectuur is gebaseerd op het gedachtegoed van een [[SOA]]. Volgens Stater zijn dit de belangrijkste ingrediënten van een dergelijke architectuur en zullen in het €state programma worden verwezenlijkt:\n\n* Functionaliteit wordt opgedeeld in losse, onafhankelijke services, met elk hun eigen functionele verantwoordelijkheid (zie [[meer informatie over de services|Meer informatie over de services]]).\n* Single Point of Definition; elke functionaliteit is precies op één plek belegd en is herbruikbaar indien ergens anders noodzakelijk.\n* Business Processen worden samengesteld uit deze elementaire functies (services) en de regie van de processen wordt geautomatiseerd. De term hiervoor is Business Process Management ([[BPM]]).\n* Communicatie tussen partijen intern en extern wordt gefaciliteerd met een [[integration bus|Meer informatie over de integration bus]] zodat partijen worden ontkoppeld en technische obstakels worden weggenomen.\n* Gebruik van internationale open standaarden, hetgeen communicatie met externe partijen vereenvoudigt.\n* Mogelijkheid om services aan externe partijen aan te bieden en tevens de mogelijkheid om services van externe partijen te gebruiken in eigen processen.

{{{definitie}}}\n<<<\nDe ~ICT-oplossing is in staat meerdere miljoenen leningen te beheren zonder substantieel verlies van online- en batch-performance. Schaalbaarheid heeft ook betrekking op andere aspecten, waaronder aantal landen, aantal producten, aantal rapportages, aantal gebruikers, etc.\n<<<\n\nConcreet betekent dit dat services parallel uitgevoerd moeten kunnen worden waardoor dezelfde functionaliteit voor verschillende processen tegelijkertijd beschikbaar is. Dit wordt bereikt door het inzetten van extra hardware componenten.

{{{definitie}}}\n<<<\nDe schuldrest is de uitstaande schuld van een leningsdeel op een bepaald moment in de tijd.\nEen lening kan zijn samengesteld uit meerdere leningsdelen met elk een eigen schuldrest.\nDe schuldrest van de lening is dan de som van de schuldresten van de leningedelen.\n<<<

{{{definitie}}}\n<<<\nDe plaats waarop een [[pool|Pool]] hypotheken wordt aangeboden aan beleggers en verhandeld tussen beleggers.\n<<<

{{{definitie}}}\n<<<\nOm een [[pool|Pool]] hypotheken te verhandelen op de [[secundaire markt|Secundaire markt]], worden securities uitgegeven, die kunnen worden gekocht door beleggers. Een security vertegenwoordigt een bepaalde waarde van de pool hypotheken.\nHet opdelen van de pool in securities, het verhandelen van de securities en het afhandelen van de geldstroom richting de beleggers uit hoofde van de verkochte securities wordt geregeld door een organisatie die wordt aangeduid met de term Special Purpose Vehicle.\n<<<

{{{definitie}}}\n<<<\nEen service is een herbruikbare, losse, onafhankelijke brok functionaliteit met een eigen functionele verantwoordelijkheid.\n<<<\nZie [[Meer informatie over de services]] voor de karakteristieken van de services.

Met elke klant van [[Stater]] is afgesproken welke [[dienstverlening|Dienstverlening]] de klant afneemt. Dit resulteert in verschillende servicemodellen die in meerdere of mindere mate [[ASP]] en [[BPO]] dienstverlening omvat. Per klant wordt in detail afgesproken welke processen door Stater worden uitgevoerd en welke processen de klant zelf uitvoert, eventueel met gebruik van de systemen van Stater. Met een [[klantbeeld|Klantbeeld van proces en systeemafname]] wordt het servicemodel in relatie tot het huidige [[iSHS]] getoond. \n[img[figuren/dim_service.png]]\nDe ambitie is om nog verder te gaan in [[ketenintegratie|Ketenintegratie]], zodat (delen van) processtappen door de klant, door Stater of door een andere organisatie kan worden uitgevoerd, ondersteund door systemen van Stater, van deze partijen zelf of van anderen.

{{{definitie}}}\n<<<\nOrganisatie die voor meerdere, interne of externe, partijen overeenkomstige diensten uitvoert.\n<<<

<<search>><<closeAll>><<permaview>>

<<tabs txtMainTab 'Alle tekstblokken' 'Alle tekstblokken' TabAll>>

Een niet-lineaire architectuur beschrijving

Stater

Stater is een onafhankelijke leverancier van diensten aan [[hypotheekverstrekkers|Geldgever]] in verscheidene Europese landen, met een sterke [[positie|Positionering]] in Nederland. \n\nStater is in 1997 gestart met het beheer van [[hypotheken|Hypotheek]] als onafhankelijk opererende dochter van [[Bouwfonds|http://www.bouwfonds.nl]]. Door de uitbreiding van het dienstenpakket en de snelle internationale ontwikkeling, is Stater in 1 januari 2001 zelfstandig geworden. Inmiddels is zij uitgegroeid tot een internationale speler met meer dan 800 medewerkers. Het hoofdkantoor is gevestigd in Amersfoort, daarnaast zijn er vestigingen in Leusden, Bonn (Duitsland) en in Brussel (België). \n\nDe missie van Stater luidt:\n|bgcolor(#FDEDDB):Het ondersteunen van onze klanten bij het realiseren van hun doelen door 'end-to-end' hypotheekdiensten te leveren voor de Europese hypotheekmarkt. Gebaseerd op een “shared service” concept en een onafhankelijke positie.|\n\n__Klanten__\nTot de [[klanten|Klanten]] van Stater behoren onder andere (hypotheek)banken, verzekeraars, pensioenfondsen en andere geldgevers, voor wie het beheer van de hypothekenportefeuille vaak niet tot de core business behoort. \n\n__Diensten__\nDe [[dienstverlening|Dienstverlening]] bestaat uit het passeren van hypotheken en beheren van de hypothekenportefeuilles. Daarnaast adviseert en ondersteunt Stater haar klanten bij risicomanagement, het securitiseren van hypotheekportefeuilles en bij kredietrisicoanalyses en -beleid.\n\n__Onafhankelijk__\nStater streeft er naar om een professionele en goede businesspartner te zijn voor haar klanten en verkoopt zelf geen hypotheken. Zij verbindt [[partijen in de keten|Distributie dimensie]] en stimuleert en draagt bij aan innovatie van de hypotheekmarkt. Een voorbeeld van innovatie is [[e-Notaris]].\n\n__Werkwijze__\nStater werkt met haar klanten samen en is erop gericht om met hen tot afspraken en oplossingen te komen, die voor alle partijen [[de meest optimale situatie|Businessstrategiedimensie]] oplevert. Stater streeft ernaar om de werkwijze zoveel mogelijk te standaardiseren, vanwege de schaalvoordelen en kwaliteit die dit oplevert voor al haar klanten ([[Operational Excellence]]). Om toch te kunnen voldoen aan specifieke klantbehoeften ([[Customer Intimacy]]), zorgt zij voor een modulair opgezette dienstverlening, waarbij klanten de keuze hebben uit eenvoudige en goedkope diensten of uit hogere serviceniveaus tegen hogere kosten. \n\n__Ambitie__\nDe [[ambitie|Ambitie]] van Stater is om haar positie in de markt als onafhankelijke en toonaangevende partij in Nederland en het buitenland uit te breiden.

Naast functionaliteit van het [[iSHS]] zal [[€state]] ook nieuwe en/of toekomstig gewenste functionaliteit moeten gaan ondersteunen. Deze vernieuwingen zijn afgeleid van de [[architectuurprincipes|Architectuurprincipes]] en van [[businessrequirements|€state businessrequirements]]. \nIn het [[domeinmodel|Domeinmodel]] van [[Stater]] worden alle concepten gedefinieerd en beschreven waarop de ontwikkeling van deze [[functionaliteit|Functionaliteit in het domeinmodel]] dient te worden gebaseerd.\nDit betekent dat het domeinmodel de kaders schept waarbinnen de realisatie van [[€state]] zal moeten plaatsvinden. Op basis van het domeinmodel is een [[prototype|Prototype]] ontwikkeld om te valideren dat de concepten in het domeinmodel ook daadwerkelijk gerealiseerd kunnen worden.\n

{{{definitie}}}\n<<<\nDe verwerking van aangeboden verzoeken (zoals aanvragen) dient door de ~ICT-oplossing automatisch uitgevoerd te kunnen worden.\n<<<\n\nDit principe stelt vooral eisen aan de inrichting van processen waarvoor STP gewenst is. Processen zullen dan gebruik moeten maken van geautomatiseerde services. Foutsignalering (uitval door bijvoorbeeld incomplete gegevens), traceerbaarheid (waar is het fout gegaan?) en correctie/herstartmogelijkheden zijn hierbij belangrijke aandachtspunten. Deze aandachtspunten gelden voor de hele keten (en daarmee ook voor externe partijen).\n

/***\n!Stater Colors\n*@@bgcolor(#FDEDDB): #FDEDDB stater palet: zalm@@\n*@@bgcolor(#FAD2A5): #FAD2A5 stater palet: oranje@@\n*@@bgcolor(#FFC567): #FFC567 stater palet: oranje@@\n*@@bgcolor(#FF9900): #FF9900 stater palet: oranje*@@\n*@@bgcolor(#D5CCE2): #D5CCE2 stater palet: paars@@\n*@@bgcolor(#A18CBC): #A18CBC stater palet: paars*@@\n*@@bgcolor(#7E62A4): #7E62A4 stater palet: paars@@\n*@@bgcolor(#63088C): #63088C stater palet: paars@@\n*@@bgcolor(#660066): #660066 stater palet: paars*@@\n*@@bgcolor(#3C0555): #3C0555 stater palet: paars@@\n*@@bgcolor(#F0CC8E): #F0CC8E stater palet: mengkleur@@\n*@@bgcolor(#CAA592): #CAA592 stater palet: mengkleur@@\n!Colors Used\n*@@bgcolor(#FDEDDA): #FDEDDA - Background (headers) white@@\n*@@bgcolor(#18f): #18f - Top blue@@\n*@@bgcolor(#3C0556): #3C0556 - Mid blue@@\n*@@bgcolor(#014):color(#fff): #014 - Bottom blue@@\n*@@bgcolor(#FDEDDA): #FDEDDA - Bright yellow@@\n*@@bgcolor(#FAD2A4): #FAD2A4 - Highlight yellow@@\n*@@bgcolor(#D5CCE3): #D5CCE3 - Background yellow@@\n*@@bgcolor(#A28CBC): #A28CBC - Border yellow@@\n*@@bgcolor(#7E62A1): #7E62A1 - Title (headers) purple@@\n*@@bgcolor(#866): #866 - Subtitle grey@@\n!Generic Rules /%==============================================%/\n***/\n/*{{{*/\nbody {\n background: #fff;\n color: #000;\n}\n\na{\n color: #3C0556;\n}\n\na:hover{\n background: #7E62A4;\n color: #FDEDDB;\n}\n\na img{\n border: 0;\n}\n\nh1,h2,h3,h4,h5 {\n color: #7E62A1;\n background: #FDEDDA;\n}\n\n.button {\n color: #3C0555;\n border: 0px solid #fff;\n}\n\n.button:hover {\n color: #FDEDDB;\n background-color: #7E62A4;\n border-color: #D5CCE3;\n }\n\n.button:active {\n color: #fff;\n background: #D5CCE3;\n border: 1px solid #A28CBC;\n}\n\n/*}}}*/\n/***\n!Header /%==================================================%/\n***/\n/*{{{*/\n.header {\n background: #3C0556;\n}\n\n.headerShadow {\n color: #000;\n}\n\n.headerShadow a {\n font-weight: normal;\n color: #000;\n}\n\n.headerForeground {\n color: #fff;\n}\n\n.headerForeground a {\n font-weight: normal;\n color: #FDEDDA;\n}\n\n/*}}}*/\n/***\n!General tabs /%=================================================%/\n***/\n/*{{{*/\n\n.tabSelected{\n color: #3C0555;\n background: #D5CCE1;\n border-left: 1px solid #3C0555;\n border-top: 1px solid #3C0555;\n border-right: 1px solid #3C0555;\n}\n\n.tabUnselected {\n color: #fff;\n background: #7E62A4;\n}\n\n.tabContents {\n color: #3C0555;\n background: #D5CCE1;\n border: 1px solid #3C0555;\n}\n\n.tabContents .button {\n border: 0;}\n\n/*}}}*/\n/***\n!Sidebar options /%=================================================%/\n~TiddlyLinks and buttons are treated identically in the sidebar and slider panel\n***/\n/*{{{*/\n\n/*** EDIT! ***/\n#sidebar {\n background-color: #FAD2A5 ;\n}\n\n#sidebarOptions input {\n border: 1px solid #3C0556;\n}\n\n#sidebarOptions .sliderPanel {\n background: #FDEDDA;\n}\n\n#sidebarOptions .sliderPanel a {\n border: none;\n color: #3C0556;\n}\n\n#sidebarOptions .sliderPanel a:hover {\n color: #fff;\n background: #3C0556;\n}\n\n#sidebarOptions .sliderPanel a:active {\n color: #3C0556;\n background: #fff;\n}\n/*}}}*/\n/***\n!Message Area /%=================================================%/\n***/\n/*{{{*/\n#messageArea {\n border: 1px solid #A28CBC;\n background: #D5CCE3;\n color: #014;\n}\n\n#messageArea .button {\n padding: 0.2em 0.2em 0.2em 0.2em;\n color: #014;\n background: #fff;\n}\n\n/*}}}*/\n/***\n!Popup /%=================================================%/\n***/\n/*{{{*/\n.popup {\n background: #18f;\n border: 1px solid #3C0556;\n}\n\n.popup hr {\n color: #014;\n background: #014;\n border-bottom: 1px;\n}\n\n.popup li.disabled {\n color: #3C0556;\n}\n\n.popup li a, .popup li a:visited {\n color: #eee;\n border: none;\n}\n\n.popup li a:hover {\n background: #014;\n color: #fff;\n border: none;\n}\n/*}}}*/\n/***\n!Tiddler Display /%=================================================%/\n***/\n/*{{{*/\n.tiddler .defaultCommand {\n font-weight: bold;\n}\n\n.shadow .title {\n /*** #866 ***/ \n color: #866;\n}\n\n.title {\n color: #7E62A1;\n}\n\n.subtitle {\n color: #866;\n}\n\n.toolbar {\n color: #3C0556;\n}\n\n.tagging, .tagged {\n border: 1px solid #eee;\n background-color: #eee;\n}\n\n.selected .tagging, .selected .tagged {\n background-color: #ddd;\n border: 1px solid #bbb;\n}\n\n.tagging .listTitle, .tagged .listTitle {\n color: #014;\n}\n\n.tagging .button, .tagged .button {\n border: none;\n}\n\n.footer {\n color: #ddd;\n}\n\n.selected .footer {\n color: #888;\n}\n\n.sparkline {\n background: #FDEDDA;\n border: 0;\n}\n\n.sparktick {\n background: #014;\n}\n\n.errorButton {\n color: #ff0;\n background: #f00;\n}\n\n.cascade {\n background: #eef;\n color: #aac;\n border: 1px solid #aac;\n}\n\n.imageLink, #displayArea .imageLink {\n background: transparent;\n}\n\n/*}}}*/\n/***\n''The viewer is where the tiddler content is displayed'' /%------------------------------------------------%/\n***/\n/*{{{*/\n\n.viewer .listTitle {list-style-type: none; margin-left: -2em;}\n\n.viewer .button {\n border: 1px solid #D5CCE3;\n}\n\n.viewer blockquote {\n border-left: 3px solid #666;\n}\n\n.viewer table {\n border: 2px solid #333;\n}\n\n.viewer th, thead td {\n background: #D5CCE3;\n border: 1px solid #666;\n color: #fff;\n}\n\n.viewer td, .viewer tr {\n border: 1px solid #666;\n}\n\n.viewer pre {\n border: 1px solid #FAD2A4;\n background: #FDEDDA;\n}\n\n.viewer code {\n color: #7E62A1;\n}\n\n.viewer hr {\n border: 0;\n border-top: dashed 1px #666;\n color: #666;\n}\n\n.highlight, .marked {\n background: #FAD2A4;\n}\n/*}}}*/\n/***\n''The editor replaces the viewer in the tiddler'' /%------------------------------------------------%/\n***/\n/*{{{*/\n.editor input {\n border: 1px solid #3C0556;\n}\n\n.editor textarea {\n border: 1px solid #3C0556;\n background-color: #F7F7F1;\n width: 100%;\n}\n\n.editorFooter {\n color: #aaa;\n}\n\n/*}}}*/

/***\n!Sections in this Tiddler:\n*Generic rules\n**Links styles\n**Link Exceptions\n*Header\n*Main menu\n*Sidebar\n**Sidebar options\n**Sidebar tabs\n*Message area\n*Popup\n*Tabs\n*Tiddler display\n**Viewer\n**Editor\n*Misc. rules\n!Generic Rules /%==============================================%/\n***/\n/*{{{*/\nbody {\n font-size: 14px;\n font-family: arial,verdana;\n position: relative;\n margin: 0;\n padding: 0;\n}\n\nh1,h2,h3,h4,h5 {\n font-weight: bold;\n text-decoration: none;\n padding-left: 0.4em;\n}\n\nh1 {font-size: 1.35em;}\nh2 {font-size: 1.25em;}\nh3 {font-size: 1.1em;}\nh4 {font-size: 1em;}\nh5 {font-size: .9em;}\n\nhr {\n height: 1px;\n}\n\na{\n text-decoration: none;\n}\n\nol { list-style-type: decimal }\nol ol { list-style-type: lower-alpha }\nol ol ol { list-style-type: lower-roman }\nol ol ol ol { list-style-type: decimal }\nol ol ol ol ol { list-style-type: lower-alpha }\nol ol ol ol ol ol { list-style-type: lower-roman }\nol ol ol ol ol ol ol { list-style-type: decimal }\n/*}}}*/\n/***\n''General Link Styles'' /%-----------------------------------------------------------------------------%/\n***/\n/*{{{*/\n.externalLink {\n font-weight: bold;\n}\n\n.tiddlyLinkExisting {\n font-weight: bold;\n}\n\n.tiddlyLinkNonExisting {\n font-style: italic;\n}\n\n/* the 'a' is required for IE, otherwise it renders the whole tiddler a bold */\na.tiddlyLinkNonExisting.shadow {\n font-weight: bold;\n}\n/*}}}*/\n/***\n''Exceptions to common link styles'' /%------------------------------------------------------------------%/\n***/\n/*{{{*/\n\n#mainMenu .tiddlyLinkExisting, \n#mainMenu .tiddlyLinkNonExisting,\n#mainMenu .externalLink,\n#sidebarTabs .tiddlyLinkExisting,\n#sidebarTabs .tiddlyLinkNonExisting{\n font-weight: normal;\n font-style: normal;\n}\n\n/*}}}*/\n/***\n!Header /%==================================================%/\n***/\n/*{{{*/\n\n.header {\n position: relative;\n}\n\n.header a:hover {\n background: transparent;\n}\n\n.headerShadow {\n position: relative;\n padding: 66px 0px 0px 0px;\n left: -1px;\n top: -1px;\n}\n\n.headerForeground {\n position: absolute;\n padding: 10px 0px 0px 0px;\n left: 0px;\n top: 0px;\n}\n\n.siteTitle {\n font-size: 3em;\n color: #A18CBC;\n}\n\n.siteSubtitle {\n font-size: 1.4em;\n color: #A18CBC;\n}\n\n/*}}}*/\n/***\n!Main menu /%==================================================%/\n***/\n/*{{{*/\n#mainMenu {\n /*** EDIT!1 ***/\n background-color: #FFC567;\n position: absolute;\n left: 0;\n width: 204px;\n text-align: left;\n line-height: 21px;\n padding: 10px 0px 0px 7px;\n font-size: 12px;\n}\n\n\n/*}}}*/\n/***\n!Sidebar rules /%==================================================%/\n***/\n/*{{{*/\n\n/*** EDIT! ***/\n#sidebar {\n position: absolute;\n left: 0px;\n top: 475px;\n width: 211px;\n font-size: 13px;\n}\n/*}}}*/\n/***\n''Sidebar options'' /%----------------------------------------------------------------------------------%/\n***/\n/*{{{*/\n\n/*** EDIT! ***/\n#sidebarOptions {\n padding-top: 0.3em; \n left: 0px; \n}\n\n\n#sidebarOptions a {\n margin: 0em 0.2em;\n padding: 0.2em 0.3em;\n display: block;\n}\n\n#sidebarOptions input {\n margin: 0.4em 0.5em;\n}\n\n#sidebarOptions .sliderPanel {\n margin-left: 1em;\n padding: 0.5em;\n font-size: .85em;\n}\n\n#sidebarOptions .sliderPanel a {\n font-weight: bold;\n display: inline;\n padding: 0;\n}\n\n#sidebarOptions .sliderPanel input {\n margin: 0 0 .3em 0;\n}\n/*}}}*/\n/***\n''Sidebar tabs'' /%-------------------------------------------------------------------------------------%/\n***/\n/*{{{*/\n\n#sidebarTabs .tabContents {\n width: 15em;\n overflow: hidden;\n}\n\n/*}}}*/\n/***\n!Message area /%==================================================%/\n***/\n/*{{{*/\n#messageArea {\nposition:absolute; top:0; right:0; margin: 0.5em; padding: 0.5em;\n}\n\n*[id='messageArea'] {\nposition:fixed !important; z-index:99;}\n\n.messageToolbar {\ndisplay: block;\ntext-align: right;\n}\n\n#messageArea a{\n text-decoration: underline;\n}\n/*}}}*/\n/***\n!Popup /%==================================================%/\n***/\n/*{{{*/\n.popup {\n font-size: .9em;\n padding: 0.2em;\n list-style: none;\n margin: 0;\n}\n\n.popup hr {\n display: block;\n height: 1px;\n width: auto;\n padding: 0;\n margin: 0.2em 0em;\n}\n\n.popup li.disabled {\n padding: 0.2em;\n}\n\n.popup li a{\n display: block;\n padding: 0.2em;\n}\n/*}}}*/\n/***\n!Tabs /%==================================================%/\n***/\n/*{{{*/\n.tabset {\n padding: 1em 0em 0em 0.5em;\n}\n\n.tab {\n margin: 0em 0em 0em 0.25em;\n padding: 2px;\n}\n\n.tabContents {\n padding: 0.5em;\n}\n\n.tabContents ul, .tabContents ol {\n margin: 0;\n padding: 0;\n}\n\n.txtMainTab .tabContents li {\n list-style: none;\n}\n\n.tabContents li.listLink {\n margin-left: .75em;\n}\n/*}}}*/\n/***\n!Tiddler display rules /%==================================================%/\n***/\n/*{{{*/\n\n/*** EDIT! margin: 1em 17em 0em 14em; ***/\n#displayArea {\n margin: 1em 17em 0em 14em;\n position: absolute;\n left: 35;\n width: 75%;\n}\n\n\n.toolbar {\n text-align: right;\n font-size: .9em;\n visibility: hidden;\n}\n\n.selected .toolbar {\n visibility: visible;\n}\n\n.tiddler {\n padding: 1em 1em 0em 1em;\n}\n\n.missing .viewer,.missing .title {\n font-style: italic;\n}\n\n.title {\n font-size: 1.6em;\n font-weight: bold;\n}\n\n.missing .subtitle {\n display: none;\n}\n\n.subtitle {\n font-size: 1.1em;\n}\n\n/* I'm not a fan of how button looks in tiddlers... */\n.tiddler .button {\n padding: 0.2em 0.4em;\n}\n\n.tagging {\nmargin: 0.5em 0.5em 0.5em 0;\nfloat: left;\ndisplay: none;\n}\n\n.isTag .tagging {\ndisplay: block;\n}\n\n.tagged {\nmargin: 0.5em;\nfloat: right;\n}\n\n.tagging, .tagged {\nfont-size: 0.9em;\npadding: 0.25em;\n}\n\n.tagging ul, .tagged ul {\nlist-style: none;margin: 0.25em;\npadding: 0;\n}\n\n.tagClear {\nclear: both;\n}\n\n.footer {\n font-size: .9em;\n}\n\n.footer li {\ndisplay: inline;\n}\n/***\n''The viewer is where the tiddler content is displayed'' /%------------------------------------------------%/\n***/\n/*{{{*/\n* html .viewer pre {\n width: 99%;\n padding: 0 0 1em 0;\n}\n\n.viewer {\n line-height: 1.4em;\n padding-top: 0.5em;\n}\n\n.viewer .button {\n margin: 0em 0.25em;\n padding: 0em 0.25em;\n}\n\n.viewer blockquote {\n line-height: 1.5em;\n padding-left: 0.8em;\n margin-left: 2.5em;\n}\n\n.viewer ul, .viewer ol{\n margin-left: 0.5em;\n padding-left: 1.5em;\n}\n\n.viewer table {\n border-collapse: collapse;\n margin: 0.8em 1.0em;\n}\n\n.viewer th, .viewer td, .viewer tr,.viewer caption{\n padding: 3px;\n}\n\n.viewer pre {\n padding: 0.5em;\n margin-left: 0.5em;\n font-size: 1.2em;\n line-height: 1.4em;\n overflow: auto;\n}\n\n.viewer code {\n font-size: 1.2em;\n line-height: 1.4em;\n}\n/*}}}*/\n/***\n''The editor replaces the viewer in the tiddler'' /%------------------------------------------------%/\n***/\n/*{{{*/\n.editor {\nfont-size: 1.1em;\n}\n\n.editor input, .editor textarea {\n display: block;\n width: 100%;\n font: inherit;\n}\n\n.editorFooter {\n padding: 0.25em 0em;\n font-size: .9em;\n}\n\n.editorFooter .button {\npadding-top: 0px; padding-bottom: 0px;}\n\n.fieldsetFix {border: 0;\npadding: 0;\nmargin: 1px 0px 1px 0px;\n}\n/*}}}*/\n/***\n!Misc rules /%==================================================%/\n***/\n/*{{{*/\n.sparkline {\n line-height: 1em;\n}\n\n.sparktick {\n outline: 0;\n}\n\n.zoomer {\n font-size: 1.1em;\n position: absolute;\n padding: 1em;\n}\n\n.cascade {\n font-size: 1.1em;\n position: absolute;\n overflow: hidden;\n}\n/*}}}*/

{{{definitie}}}\n<<<\nDe ~ICT-oplossing is onderverdeeld in diensten/modules die onderling zijn ontkoppeld en in isolatie kunnen worden afgenomen.\n<<<\n\nDit geldt zowel voor primaire procesactiviteiten als afgeleide aspecten (bijvoorbeeld rapportage, consumenteninformatie en controles) en ondersteunende services (bijvoorbeeld documentmanagement). Elke module kan zowel intern (bij Stater) als extern zijn gerealiseerd, op basis van gestandaardiseerde interfaces. Modules maken geen aannames over onderling gemeenschappelijke toestand (stateless).

Het onderstaande figuur geeft een beeld van de technische invulling van de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]].\n[img[figuren/technische_architectuur.png]]\nVoor deze invulling wordt veel gebruik gemaakt van Microsoftproducten vanwege het [[Microsoft, tenzij]]-beleid. In de [[PACT]] worden de keuzes gevalideerd en verder gekeken naar de invulling van de technische architectuur.

[img[figuren/dim_technologisch.png]]\nElke klant van Stater heeft zijn eigen, unieke behoefte aan [[dienstverlening|Dienstverlening]] van Stater met bijbehorende afspraken, processen en systeemondersteuning. Stater streeft er daarbij naar om de [[businessprocessen|Businessprocessen]] maximaal te ondersteunen met geautomatiseerde oplossingen. Dit betekent dat de ~ICT-oplossing van Stater in staat moet zijn te communiceren met alle partijen in het distributienetwerk, zoals de klanten van Stater, [[BKR|Bureau Krediet Registratie]], [[NHG|Garanderende instellingen]], Kadaster en [[HDN]]. Al deze partijen hebben hun eigen ~ICT-oplossingen waarmee geïntegreerd moet worden. \nDe ambitie is om nog verder te gaan in [[ketenintegratie|Ketenintegratie]], zodat (delen van) processtappen door de klant, door Stater of door een andere organisatie kan worden uitgevoerd, ondersteund door systemen van Stater, van deze partijen zelf of van anderen. Dit vormt een verdergaande technologische uitdaging voor de ~ICT-oplossing. \n

Het tekstmenu biedt de volgende opties:\n* __Sluiten__: sluit het actieve tekstblok.\n* __Sluit anderen__: sluit alle tekstblokken behalve de actieve.\n* __Referenties__: toont alle tekstblokken die een verwijzing bevatten naar de actieve tekst. \n* __Andere__: geeft een overzicht van alle andere geopende tekstblokken in het webdocument.\n

{{{definitie}}}\n<<<\nEen tiddler is een tekstblok dat gebruikt wordt als een bouwsteen van een TiddlyWiki. De acties die op een tiddler uitgevoerd kunnen worden staan in het [[tiddlermenu|Tekstblokmenu]] dat geactiveerd wordt als de muis op de tiddler staat. \n<<<\n

{{{definitie}}}\n<<<\nEen [[TiddlyWiki|http://www.tiddlywiki.com]] is een gratis beschikbare [[wiki|Wiki]] die oorspronkelijk is gemaakt door [[Jeremy Ruston|http://www.osmosoft.com]]. Met een ~TiddlyWiki is het mogelijk om een wiki te maken die zelfstandig kan bestaan. Niet alleen op een webserver, maar ook in een mail, of op een usb-stick.\nIn een ~TiddlyWiki is de informatie is opgedeeld in losstaande tekstblokken: de [[tiddlers|Tiddler]], waarin verwijzingen zijn opgenomen naar andere tiddlers. Door telkens op deze verwijzigen te klikken, kan de lezer zijn eigen verhaal samenstellen.\n<<<\n

{{{definitie}}}\n<<<\nHandelingen van gebruikers en services dienen controleerbaar te zijn en gelogd te worden. Fouten dienen geregistreerd te worden.\n<<<\nDit principe komt in de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] tot uiting door de keuze van de volgende componenten:\n* de system service logging. \n* de integration bus.\nBelangrijk aandachtspunt hierbij is de traceerbaarheid in de keten.\n

{{{definitie}}}\n<<<\nDe transportakte is de akte die de overdracht van de woning regelt. De transportakte wordt bij de notaris opgemaakt en ondertekend.\nDe transportakte heet officieel de akte van levering.\n<<<

{{{definitie}}}\n<<<\nEen tussenpersoon is een persoon of een organisatie die namens een bepaalde branche, bijvoorbeeld hypotheken of verzekeringen, advies- en/of verkoopactiviteiten uitvoert met als doel om producten van bedrijven te verkopen aan consumenten.\nEen tussenpersoon, ook wel aangeduid als "intermediair", pretendeert onafhankelijk te zijn, waarmee wordt bedoeld dat de tussenpersoon niet gebonden is aan de verkoop van producten van een bepaald bedrijf (onderneming). \n<<<

{{{definitie}}}\n<<<\nTer versterking van de vertegenwoordiging in de bedrijfstak kunnen [[tussenpersonen|Tussenpersoon]] zich verenigen in organisaties met als doel de belangen van de consument beter te behartigen.\n<<<

{{{definitie}}}\n<<<\n"UML staat voor Unified Modeling Language. Dit is een modelmatige taal die door Grady Booch, James Rumbaugh en Ivar Jacobson is ontworpen om [[object-georiënteerde|Object georiënteerd]] analyses en ontwerpen voor een informatiesysteem te kunnen maken. Sinds 1997 bestaat er een standaard voor UML. Kenmerkend is dat de UML modellen een grafische weergave zijn van bepaalde aspecten van het informatiesysteem."\n<<<\nDeze tekst is afkomstig van de [[UML-pagina op Wikipedia|http://nl.wikipedia.org/wiki/UML]].

Tijdens het [[passeren|Passeren]] van de akte van eigendom van het onderpand en het passeren van de [[hypotheek|Hypotheek]] worden (meestal) de gelden overgemaakt van de kopende partij naar de verkopende partij. De afwikkeling van de geldstroom loopt via de notaris. Daags voor passeren vraagt de notaris de gelden op bij de [[geldgever|Geldgever]] die op zijn beurt het benodigde bedrag overmaakt en de definitieve gegevens voor het opmaken van de akte aanlevert. Dit laatste is nodig omdat de consument tussen het moment van het geven van [[Finaal akkoord]] en het moment van passeren vaak nog een wijziging in de financiering laat aanbrengen en omdat de notaris over de laatste actuele rentetarieven, die zijn verwerkt in de financiering, moet beschikken.

{{{definitie}}}\n<<<\nDe Virtual Customer Environment houdt in dat iedere component in de €state architectuur zich bewust is voor welke klant van Stater hij actief is en daarnaar acteert. Op deze manier zorgen alle componenten samen virtueel voor een klant specifiek systeem, dat de gebruiker het idee geeft dat het systeem volledig gescheiden is van de systemen voor andere klanten.\nZie [[Meer informatie over de VCE]] voor meer details.\n<<<\n

[[Aanvragen|Aanvragen offertes]] kunnen via verschillende [[kanalen|Distributiekanalen]] worden ingediend: op papier (fax of post) of elektronisch ([[HDN]] of Internet). Bij het vastleggen van een aanvraag worden de aangeleverde gegevens gecontroleerd op volledigheid en juistheid, voor zover het laatste mogelijk is. Voorbeelden van controles zijn:\n* Wie de aanvraag heeft ingediend? Is het kanaal toegestaan?\n* Van welke geldgever(s) wordt een offerte gevraagd?\n* Welk(e) product(en) worden aangevraagd?\nAlleen volledig ingevulde en correct bevonden aanvragen kunnen voor een offerte in [[behandeling|Offreren]] worden genomen. Bij onvolledige en/of incorrecte aanvragen wordt een bericht geretourneerd naar de indiener met het verzoek om de gegevens te corrigeren of aan te vullen.\n

Een [[hypotheek|Hypotheek]] kan voor het bereiken van het einde van de looptijd algeheel worden afgelost. Aan de algehele aflossing gaat een verzoek vooraf, meestal ingediend via de notaris. Naar aanleiding van het verzoek wordt een [[aflossingsnota|Aflossingsnota]] voor de consument en de notaris opgesteld, waarop precies het te betalen bedrag is weergegeven ter voldoening van de openstaande [[schuldrest|Schuldrest]] op de dag van de gewenste aflossing. \nBewaakt wordt dat op de dag van de algehele aflossing het noodzakelijke bedrag ook daadwerkelijk wordt betaald. Is dat het geval, dan wordt de algehele aflossing geëffectueerd.\nOok is het mogelijk dat consumenten voortijdig een deel van de lening wenst af te lossen of een vervroegde aflossing of een extra premiestorting wil uitvoeren.\nVan een stille aflossing is sprake als de schuldrest van de lening geheel is voldaan door betaling van de periodieke bedragen. Meestal gebeurt dit bij het verstrijken van de afgesproken looptijd. \n

De notaris, die bij het [[passeren|Passeren]] van de [[hypotheek|Hypotheek]] betrokken zal worden, wordt middels een brief hierover geïnformeerd en ontvangt de voorlopige instructies van de geldgever. Met deze informatie kan de notaris de voorbereidende werkzaamheden uitvoeren voor het passeren van de hypotheek, zoals het kadastrale onderzoek.\n

{{{definitie}}}\n<<<\nDe voorwaarden bevatten de algemene bepalingen van de [[geldgever|Geldgever]]. Voorbeelden van hypotheekvoorwaarden zijn\n* bepalingen over renteaanpassing\n* voorwaarden voor vervroegd aflossen\n* voorwaarden voor verkoop van de woning\n* regels voor het bepalen van de afkoopwaarde bij een leven- of spaarhypotheek\n* extra vereiste verzekeringen\n* verhuiscondities\n* boeteregelingen\n* achterstandsregelingen\n<<<

{{{definitie}}}\n<<<\nMet de waardeketen van een [[hypotheek|Hypotheek]] worden de activiteiten bedoeld die waarde toevoegen aan de hypotheek in de periode tussen het ontstaan en het weer beëindigen van een hypotheek (de levensloop).\n<<<

\nAls eerste een definitie van het begrip architectuur:\n<<<\nOnder architectuur verstaan we een consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichtingen, systemen en technische infrastructuur van de organisatie. De architectuur kan in zekere zin gezien worden als het geheel van afspraken dat ervoor zorgt dat individuele ontwikkelingen aansluiten op elkaar en op het overkoepelend bedrijfsbelang. (bron: "DYA: snelheid in samenhang in business- en ~ICT-architectuur", ISBN 90-72194-62-4)\n<<<\n\nVertaald naar de praktijk van Stater leidt deze definitie tot een implementatie van architectuur met drie verschillende gezichtspunten, namelijk business, geautomatiseerde ondersteuning en infrastructuur:\n* De architectuur vanuit een business oogpunt beschrijft de omgeving, de dienstverlening ten behoeve van die omgeving, en de businessprocessen die de dienstverlening realiseren.\n* De architectuur vanuit een automatiseringsoogpunt beschrijft de wijze waarop businessprocessen door systemen worden ondersteund en geeft de kaders aan waarbinnen deze systemen ontwikkeld moeten worden. \n* De infrastructuur architectuur beschrijft de kaders voor de noodzakelijke voorzieningen die nodig zijn om de geautomatiseerde ondersteuning mogelijk te maken. \n\nOm grip te krijgen op de betekenis en de onderlinge samenhang van bovengenoemde gezichtspunten is gekozen voor [[ArchiMate]] als referentiekader. Dit heeft geleid tot concrete onderverdeling van architectuur waarbij de servicegedachte leidend is. \nDe servicegedachte heeft als uitgangspunt dat diensten worden geleverd waarmee de afnemer zijn doelen kan realiseren: Stater levert aan haar omgeving hypothecaire diensten. Om deze diensten te kunnen leveren, voert Stater allerlei businessprocessen uit die op hun beurt weer gebruik maken van diensten die het hypotheeksysteem levert. Het hypotheeksysteem maakt gebruik van de diensten die worden aangeboden door het onderliggende platform. Het onderstaande figuur is een visuele weergave van deze servicegedachte.\n\n[img[figuren/architecturen.png]]\n\nDe architectuur die dit webdocument beschrijft, heeft vooral een focus op de applicatielaag. De oorzaak hiervoor is dat er vanuit het [[€state]]-programma een sterke behoefte lag voor een [[architectuur van een nieuwe geautomatiseerde ondersteuning|Functionele Applicatiearchitectuur]].\nOp dit moment maakt het denken over de invulling van het [[architectuurproces|Architectuurproces]] een [[ontwikkeling|Hoe heeft het architectuurdenken binnen Stater zich ontwikkeld]] door waarbij de andere aspecten aan bod komen.

{{{definitie}}}\n<<<\nAlle user-interfaces en alle brieven en rapportages van alle modules kunnen worden ingesteld naar het uiterlijk en de wensen van de klant. \n<<<\n\nIn de [[Functionele Applicatiearchitectuur|Functionele Applicatiearchitectuur]] heeft dit impact op de functionele modules, de rapportages, de brieven en het eventuele gebruik van communicatiekanalen (bijvoorbeeld email).\n\n

Op verzoek van de consument kan de lening worden gewijzigd. Indien gewenst wordt eerst een offerte gemaakt van de te wijzigen lening. Na akkoord van de consument wordt de wijziging doorgevoerd. \n

{{{definitie}}}\n<<<\nEen wiki is het beste te omschrijven als een webpagina waarbij iedereen de inhoud van die webpagina kan wijzigen. Op [[Wikipedia|http://en.wikipedia.org/wiki/Wiki]], zelf ook een wiki, kan meer informatie over wiki's gevonden worden (in het engels). \n<<<

{{{definitie}}}\n<<<\nEen webapplicatie die door Stater aan het intermediair (de [[tussenpersonen|Tussenpersoon]]) ter beschikking is gesteld. Hiermee zijn de tussenpersonen in staat de voortgang van afhandeling van de door hun ingediende aanvragen direct (real-time) te raadplegen. Hierdoor kan een adviseur zelf de processtap “[[informeren voortgang |Informeren voortgang]]” uitvoeren.\n<<<\n

{{{definitie}}}\n<<<\nEen webapplicatie die door Stater aan het notariaat ter beschikking is gesteld. Hiermee kunnen notarissen zelf bepaalde activiteiten van het [[hypotheekproces|Hypotheekproces]] direct uitvoeren, zoals [[voorbereiden passeren|Voorbereiden passeren (informeren notaris)]] en [[uitbetalen gelden|Uitbetalen gelden voor passeren]]. \n<<<\n

{{{definitie}}}\n<<<\nEen door Stater geïntroduceerde verzamelnaam waarmee de diensten worden aangeduid die door Stater via webtechnologie ter beschikking worden gesteld. Voorbeelden hiervan zijn [[e-Notaris]] en [[e-Intermediair]].\n<<<\n

Bij het uitvoeren van haar [[dienstverlening|Dienstverlening]] maakt Stater momenteel gebruik van het internationale Stater Hypotheek Systeem (iSHS). Dit systeem is door Stater zelf ontwikkeld en het is al jaren het leidende hypotheeksysteem in de Nederlandse markt. De kracht van dit systeem komt tot uiting in de volgende punten:\n* Het ondersteunt [['shared BPO'|Positionering]].\n* Het is een bewezen oplossing voor het afhandelen van [[de Mid-Office- en Back-Office-processen|Hypotheekproces]]\n* De processen worden ondersteund door workflow management.\n* Het systeem is toegankelijk via Internet ([[e-Servicing]]).\n* Het systeem maakt het mogelijk om papierloos te werken.\n* Aanvragen voor hypotheken kunnen automatisch worden geoffreerd ([[Straight Through Processing]]).\n* Brieven worden automatisch gegenereerd met de Stater Document Engine.\n* Ondersteuning van automatische kredietscoring.\n* Het ondersteunt [[private label servicing|White-/private-labeling]] waardoor klanten van Stater hun eigen identiteit aan de consument kunnen tonen.\nOndanks de grote kracht van het iSHS loopt Stater tegen de beperkingen van dit systeem aan. Door de toegenomen complexiteit van diensten, hypotheekproducten en klantwensen kunnen nieuwe [[requirements|€state businessrequirements]] niet meer effectief en efficiënt in het iSHS worden doorgevoerd. Dit is een van de redenen voor de start van de ontwikkeling van een [[nieuwe ICT-oplossing|€state]].

{{{definitie}}}\n<<<\nDe €LF (€state Loan File) is het gestandaardiseerde berichtformaat dat voor alle communicatie tussen componenten van €state wordt gebruikt. Het is een XML bestand dat alle informatie bevat van één enkele lening. Alle [[services|Service]] lezen de benodigde informatie uit de €LF en kunnen de inhoud van de €LF wijzigen of uitbreiden. De €LF is ''//de//'' representatie van een lening of [[hypotheek|Hypotheek]] binnen [[€state]]. \nZie [[Meer informatie over de €LF]] voor meer details.\n<<<

€state is een strategisch programma van [[Stater]]. Het is gestart in 2004, met het doel een compleet nieuwe ~ICT-oplossing binnen Stater te implementeren.\n\nDe aanleidingen voor het starten van het €state-programma waren divers en de belangrijkste worden genoemd in de [[ambitie|Ambitie]] en [[businessdrivers|Businessdrivers]]. Concreet richt het €state-programma zich op de realisatie van een ~ICT-oplossing waarmee [[een aantal doelen|Doelen]] bereikt kunnen worden. Sleutelbegrippen zijn flexibiliteit, internationalisatie, schaalbaarheid, integratie met grote klanten en kostenefficiëntie.\n\nHet vervangen van een ~ICT-oplossing, als het [[iSHS]], is een ingrijpende operatie die een grote inspanning vergt van de medewerkers, een hoge impact heeft op de organisatie, veel geld kost en enkele jaren gaat duren. Naast de ontwikkeling van de nieuwe ~ICT-oplossing moet het iSHS gewoon blijven bestaan en worden onderhouden, totdat deze kan worden vervangen door de nieuwe oplossing.\n\nDe eerste fase in het €state-programma is uitgevoerd in 2004 en richtte zich op het beantwoorden van de volgende vragen:\n* Op welke wijze en hoe snel kunnen nieuwe [[requirements|€state businessrequirements]] ontwikkeld en beschikbaar worden gesteld aan de business?\n* Volgens welk scenario kan het [[iSHS]] het beste worden vervangen door de nieuwe ~ICT-oplossing? Uitgangspunt hierbij was, dat de bestaande oplossing voor de [[Mid-Office]] zo snel mogelijk moest worden vervangen.\n* Met [[welke architectuur|Ontstaan van de architectuurvisie]] kan de nieuwe ~ICT-oplossing het beste worden gerealiseerd om de doelstellingen van Stater te realiseren?\nIn oktober 2004 is de eerste fase van het €state-programma afgerond. Daarbij is het volgende besloten dan wel in gang gezet:\n* Vaststellen van [[de gekozen architectuurvisie|Functionele Applicatiearchitectuur]] en de [[leidende architectuurprincipes|Architectuurprincipes]].\n* [[Borging van het architectuurdenken|Hoe heeft het architectuurdenken binnen Stater zich ontwikkeld]] in de organisatie van Stater door medewerkers te benoemen met architectuur als aandachtsgebied.\n* Het ontwikkelen van een aantal nieuwe [[business requirements|€state businessrequirements]] in het iSHS.\n* [[Start van een realisatieprogramma|Programmaoverzicht]] voor de nieuwe ~ICT-oplossing, dit betekent:\n** Het zo snel mogelijk vervangen van de bestaande ~ICT-oplossing voor het ~Mid-Office door een nieuwe oplossing, die voor een deel kan worden ingekocht.\n** Het vervangen van de bestaande [[Stater Document Engine|SDE]] door een nieuwe oplossing. \n** Het realiseren van een [[Data Warehouse|Meer informatie over het DWH]] waarmee in de toenemende vraag naar rapportages kan worden voorzien. \n** De realisatie van een [[integration bus|Meer informatie over de integration bus]].\n

{{{definitie}}}\n<<<\n€state businessrequirements zijn de functionele eisen en wensen die in het kader van het [[€state]]-programma zijn geïnventariseerd en gedefinieerd en die door €state ondersteund moeten worden. Daarnaast betreffen dit functionaliteiten waarvan men verwacht deze in de (nabije) toekomst nodig te hebben, zoals [[flexibele tijdslijnen|Flexibele tijdslijnen]] en ondersteuning van consumptieve kredieten.\n<<<\n