Flexibiliteit en historie in administratieve systemen Hugo Brand

Presentatie over: "Flexibiliteit en historie in administratieve systemen Hugo Brand"— Transcript van de presentatie:

1 Flexibiliteit en historie in administratieve systemen Hugo Brand
Back to the Future Flexibiliteit en historie in administratieve systemen Hugo Brand

2 www.utopics.nl Introductie Klein, jong bedrijf Onderdeel van Ordina
Innovatieve oplossingen Projecten die anderen als utopisch beschouwen Strategische positie bij klanten (in de financiële sector) Ordina: 4000 medewerkers, Utopics: 90 medewerkers. Allemaal academici (en afstudeerders, stagiaires), dus jong, inhoudelijk en innovatief Projectbedrijf: samen met de klant verantwoordelijk voor projectresultaat Strategische positie: systemen die samenhangen met het primaire proces bij de klantorganisaties (utopisch)

3 Agenda Inleiding Toekomst en historie in administratieve systemen
Pauze Flexibiliteit in administratieve systemen

4 Multi-channeling in perspectief
Call centra werden toegevoegd Presentie op internet vereist Eerste self-service kanaal nieuw soort koppeling met fulfilment Klantgerichte MC – architecturen, CRM / CMS, integratie kanalen in processen Geen hype: serieuze doelen, serieuze uitdaging En nu? Media volgen elkaar snel op, internet lijkt niet de kip met gouden eieren… Media kwamen en gingen: vele jaren weinig verandering (telefoon is van 1876 oid), telex, telegram, telefoon, fax, maar zo heel veel veranderde er niet: iemand kreeg een aparaat erbij op zijn bureau, maar dingen werden nog steeds door dezelfde mensen op dezelfde manier afgehandeld worden. Bespreken op basis van doelen. Als we als voorbeeld de financiele sector pakken, elke sector is weer anders (voor de goede orde) Nieuw kanaal toegevoegd door call centra op te zetten. Presentie op internet, al snel duidelijk dat je meer moest bieden dan de mogelijkheid om een tje te sturen als je wilde concurreren met de single-channel bedrijven – koppeling naar fulfilment belangrijke uitdaging. Call centra kon je nog uitrusten met 6 verschillende schermen van systemen. Toen kwam men erachter dat je met minimaal 3 kanalen veel redundantie kreeg in de IT, veel effeciency kon behalen door in ieder geval de ICT-architectuur anders in te richten. In de financiele sector is men druk doende de blauwdrukken die in de laatste paar jaar gemaakt zijn te implementeren, uit ervaring weten we dat dat een bloedserieuse klus is met veel uitdagingen. CRM is de spin in het web van multichanneling, Campagne Management Systems, Het hyperige aan multichanneling komt van internet en de snel elkaar opvolgende nieuwe media. Multichanneling is voor de meeste organisaties een bloedserieuse en moeilijke taak met concrete doelen en problemen. Die moet de klant de mogelijkheid bieden om zonder wachttijd (zero-latency) en (schijnbaar) zonder menselijke tussenkomst zaken te doen. Dit betekent voor een organisatie een hele omslag, met name in de koppeling naar de fulfilment toe. Dit geldt nu voor alle zogenaamde digitale of directe kanalen, zoals internet maar ook IVR, WAP, en soms SMS. Grote keuze aan aspecten die te bespreken zijn MC Organisatie: niet zozeer een org die via meerdere kanalen en/of media communiceert en zaken doet, maar een organisatie die zonder structurele wijzigingen informatie kan uitwisselen en/of diensten kan aanbieden via een nieuw medium of kanaal. Correlary: in het kader van core-business: uitbesteden logistiek en techniek (zoiets als zelf de post rondbrengen) (dit is een beetje kort door de bocht) Dus sterke behoefte aan content-uitwisselings mechanisme: XML als zee-container van de informatielogistiek.

5 Multi-channel uitdagingen
Organisatie inrichting Kanaal procesinrichting en invulling Business performance measurement Architectuur, invulling en legacy ontsluiting Organisatie inrichting Architectuur, invulling en legacy ontsluiting Migratiepad Kanaal procesinrichting en invulling Beveiliging ICT kennis: Nieuwe concepten en techniek Content scheiden van vorm/media Business performance measurement ICT kennis: Nieuwe concepten en technieken

6 Inriching adminstratieve systemen
Tweetal issues spelen generiek bij de inrichting van adm. Sys.: hoe om te gaan met historische en toekomstige data flexibiliteit t.a.v. van proces en data.

7 Inrichting administratiesysteem
Doel: vastleggen van gegevens van administratieve objecten en hun verloop. Mutatie vs. data georienteerde administratie Tijdsdimensies: Valid time - Wanneer gebeurd het Transaction time - Wanneer kenbaar gemaakt Observation time - Wanneer waargenomen De valid time legt vast in welke periode in de werkelijkheid feiten of gebeurtenissen van toepassing zijn of geldig zijn. Feiten kunnen zowel in het verleden, in het heden of in de toekomst geldig zijn. Ook zijn combinaties van deze drie punten mogelijk. Voor ieder feit moet zowel een begin- als een eindtijd worden vastgelegd waarbinnen het feit geldig is. Zijn van een feit geen begin- en / of einddatum bekend, dan betekent dit dat het feit altijd al geldig was en / of altijd geldig zal blijven. Feiten mogen op ieder moment zowel gecreëerd, gewijzigd als gelezen worden. Kortom de valid time is geheel onafhankelijk van de huidige tijd (het heden) en zal daarom door de gebruiker moeten worden ingegeven. De transaction time duidt het tijdstip aan waarop de gegevens in het informatiesysteem zijn vastgelegd. Gegevens worden door het systeem vastgelegd op het moment van vastlegging (in het heden). Een toekomstige transaction time bestaat niet (kristallenbol), terwijl een transaction time in het verleden alleen gelezen mag worden. De observation time is het tijdstip dat een bepaalde gebruiker(sgroep) een verandering in het systeem waarneemt. Volgens Veldwijk is de huidige technologie niet in staat om dit op deze tijdsdimensie betrouwbaar te genereren. Mocht dit wel het geval zijn dan zou de observation time dezelfde eigenschappen bezitten als de transaction time.

8 Vastleggen tijdsdimensies
Wordt alleen de valid time vastgelegd, dan is het mogelijk om de veranderingen van feiten in de werkelijkheid te reconstrueren zoals daar in het heden over wordt gedacht. Het is echter niet mogelijk om (met zekerheid) te bepalen hoe een maand geleden over dit verloop werd gedacht. Gemaakte fouten die op een later tijdstip zijn verbeterd, zullen na verbetering niet meer zichtbaar zijn. Het systeem is een weergave van zoals in de huidige situatie (het heden) tegen heden, verleden en toekomst wordt aangekeken. In geval alleen de transaction time wordt opgeslagen, zijn alleen wijzigingen in het heden toegestaan en niet in het verleden of in de toekomst. De valid time wordt in principe gelijk gesteld aan de transaction time, omdat alles wordt vastgelegd op het moment dat het werkelijk plaatsvindt. Voorbeeld is het betalen met een PIN-pas. Bedragen worden gelijk afgeboekt, niet in de toekomst en niet in het verleden. Het systeem is een weergave van zoals in de huidige of een voorbij situatie (heden of verleden) tegen de situatie op dat moment en haar geschiedenis wordt aangekeken. Alle wijzigingen zijn zichtbaar, zoals op de bankafschriften een foute boeking en de bijbehorende tegenboeking altijd zichtbaar zullen blijven. Als zowel de valid als de transaction time wordt bijgehouden, is niet alleen te volgen wanneer een feit heeft plaatsgevonden. Maar ook welke kennis het systeem heeft over dit feit op een willekeurig moment in heden of verleden. Het systeem is een weergave van zoals op enig tijdstip (heden, verleden en toekomst) tegen heden, verleden en toekomst wordt aangekeken.

9 Mutatie vs. data georienteerde administratie
In de tijd kunnen de volgende gegevens bijgehouden worden: mutatiegegevens standgegevens beiden Registratie van mutaties biedt inzicht in het proces: welke acties hebben wanneer plaatsgevonden. Om de situatie op een gegeven moment te reconstrueren, moeten de betreffende mutaties in ogenschouw worden genomen. Het registreren van historie in data biedt een eenvoudiger inzicht in de situatie op een gegeven moment. Om mutaties te achterhalen dienen opeenvolgende situaties te wordenvergeleken. Een spaarrekening is een goed voorbeeld van iets waarbij het voor de hand ligt om mutatiehistorie op bij te houden. Wanneer er geld op de rekening wordt gestort, wordt niet eenvoudigweg het nieuwe saldo (met de mutatiedatum) opgeslagen, maar zal de mutatie “storting” worden geregistreerd. Voor de NAW gegevens van een relatie ligt het meer voor de hand om historie op de data zelf bij te houden. Wanneer de relatie verhuist zal een nieuwe versie van de relatie ontstaan met het nieuwe adres. Samenvattend kan gesteld worden dat het registreren van mutaties eenvoudiger inzicht biedt in het proces: welke acties hebben plaatsgevonden. Om de situatie op een gegeven moment te reconstrueren, moeten de betreffende mutaties in ogenschouw worden genomen. Het registreren van historie in data biedt een eenvoudiger inzicht in de situatie op een gegeven moment. Om mutaties te achterhalen dienen opeenvolgende situaties te worden vergeleken.

10 Datumvelden - alleen ingangsdatum
Vastleggen ingangsdatum SELECT * FROM contract c1 WHERE NOT EXISTS ( SELECT 1 FROM contract c2 WHERE c2.ingangsdatum > c1.ingangsdatum )

11 Datum velden - ingangs- en einddatum
Vastleggen ingangs- en einddatum SELECT * FROM contract c1 WHERE einddatum IS NULL

12 Datum in sleutel + Ondersteuning RDBMS - Mutatie werkt ver door
- Redundantie - Performance bij muteren Historie kan worden opgeslagen door datumvelden op te nemen in de primary key (pk) van de entiteit en tevens deze datumvelden op te nemen in foreign keys naar de betreffende entiteit. Dit alternatief kent de volgende voordelen: Relatie contract – polis wordt volledig door RDBMS onderhouden. Dit alternatief kent de volgende nadelen: Elke mutatie in contract werkt door in alle polissen. Dit betekent dus meteen dat contract besef moet hebben van alle foreign keys naar zichzelf toe; Veel redundantie; Slechtere performance bij muteren.

13 Alternatieve oplossingen
Stapelen - historie in de tabel van de entiteit zelf Schaduwen - historie in een aparte tabel Hybride - deel van de gegevens in aparte historie tabel(len)

14 Stapelen + Eenvoudige vastlegging - Redundatie
- Volledig verlies consistentiecontrole Historie kan worden opgeslagen door datumvelden op te nemen in de primary key (pk) van de entiteit, doch niet te werken met ‘echte’ foreign keys. Dit alternatief kent de volgende voordelen: Eenvoudige vastlegging. Dit alternatief kent de volgende nadelen: Veel redundantie; Volledig verlies consistentie controle door RDBMS (geen technische foreign key polis – contract).

15 Schaduwen + Actuele situatie relationeel
+ Actuele situatie snel te benaderen - Redundantie - Extra activiteiten bij muteren Historie kan worden vastgelegd door aparte tabellen te gebruiken voor de actuele en historische situatie. Dit alternatief kent de volgende voordelen: Actuele situatie volledig relationeel; Actuele situatie snel te benaderen. Dit alternatief kent de volgende nadelen: Veel redundantie; Extra activiteiten bij een mutatie.

16 Hybride + Actuele situatie relationeel
+ Actuele situatie snel te benaderen + Weinig redundantie - Extra activiteiten bij muteren - Ophalen historie Een meer intelligente variant van het schaduwen is het niet opslaan van een volledige entiteit in een historische tabel, maar een onderverdeling te maken naar de attributen. Attributen die vaak wijzigen worden samengenomen in één tabel, attributen die weinig wijzigen komen in een andere tabel. Ook zouden attributen die veel opslagcapaciteit vragen in een aparte tabel kunnen. Dit alternatief kent de volgende voordelen: Actuele situatie volledig relationeel; Actuele situatie snel te benaderen; Minder redundantie. Dit alternatief kent de volgende nadelen: Extra activiteiten bij een mutatie; Historische gegevens ophalen kost meer moeite dan bij schaduwen

17 De toekomst? Geen actuele situatie (views) Versies van objecten

18 Vergelijking alternatieven
Toelichting op de cijfers Benodigde ruimte. Als de datum in de sleutel zit, is err de meeste redundante opslag. Bij stapelen en schaduwen wordt dit al beter. De hybride opslag heeft de minste ruimte nodig. Performance actuele situatie. Alleen een op schaduwen gebaseerde oplossing biedt een snelle ingang op de historische situatie. Performance historische situatie. Alleen de hybride oplossing zal mogelijk iets minder performen, omdat meerdere tabellen benaderd moeten worden, al wordt dit weer gecompenseerd doordat de totale hoeveelheid data weer kleiner zal zijn Performance mutatie. Als de data in de sleutel zit, moet na een mutatie het meeste worden aangepast, niet alleen het eigen object, maar ook gerelateerde objecten. Bij schaduwen en stapelen blijven aanpassingen beperkt binnen het eigen object en bij een hybride oplossing zelfs tot een deel van het object. Faciliteiten RDBMS. Stapelen gebruikt geen faciliteiten van het RDBMS, stapelen een deel van de faciliteiten en als de datum in de sleutel zit worden alle faciliteiten gebruikt.

19 Flexibiliteit in administratieve systemen
Flexibiliteit in data opslag

20 Business Analysis dynamic individual Front Mid Back static mass
customised product standard

21 Architectuur en dynamiek
Distributiekanalen Klant processen Commerciele Services Produkt Systemen Processturing Dynamisch Stabiel

22 Dataflexibiliteit Traditioneel Vaste structuur met extra attributen
Streaming Hybride: vast + streaming Streaming met zoekcriteria Gedenormaliseerd Hybride: vast + gedenormaliseerd Bij deze opdeling kan generatie van het database schema gecombineerd met een geautomatiseerde conversie gezien worden als een variant op traditioneel.

23 Traditioneel + Begrijpbaarheid + Standaard - Wijzigingen

24 Vaste structuur met extra attributen
+ Goed te begrijpen - Beperkt flexibel - Overhead in ruimte

25 Streaming (puur) + Eenvoudige implementatie + Maximale flexibiliteit
+ Performance - Moeilijk te onsluiten met traditionele tools - Zoeken

26 Streaming (deels vast)
+ Flexibel + Redelijke ondersteuning standaard tools - Zoeken op flexibele kenmerken

27 Streaming (met zoekcriteria)
+ Flexibel + Redelijke ondersteuning standaard tools + Zoeken op vooraf onderkende flexibele kenmerken

28 Gedenormaliseerd Al dan niet met eigen tabel per datatype + Flexibel
+ Redelijk doorzichtig model - I/O - Database ruimte

29 Gedenormaliseerd (deels vast)
+ Flexibel + Redelijk doorzichtig model + I/O + Database ruimte

30 Vergelijking van alternatieven
Runtime performance. Pure streaming biedt de maximale performance. Met één IO operatie kan het volledige record worden gelezen of gemuteerd. Worden losse zoekcriteria opgeslagen, is iets meer IO nodig. Een traditionele structuur vereist iets meer IO dan pure streaming, maar kan ook gedeeltelijk worden gelezen of gemuteerd, wat de IO in bepaalde gevallen weer vermindert. Extra attributen opnemen geeft iets overhead. Denormalisatie geeft de slechtste performance, omdat er veel IO moet plaatsvinden om het volledige object te lezen. Een gedeeltelijke vaste structuur lost dit probleem weer deels op. Runtime performance vast zoeken. Een traditionele structuur biedt maximale performance, omdat zo nodig indexen kunnen worden ingezet en er een minimale hoeveelheid data moet worden doorzocht. Bij pure streaming moet in strings worden gezocht, wat lastig is. Worden de criteria los opgeslagen, dan vervalt dit probleem. Omdat alle criteria in één tabel zitten, zal dit iets minder performen dan de traditionele structuur. Er vanuit gaande dat een aantal zoekcriteria in het vaste deel zitten, zal streaming met een vast deel voor die attributen beter performen dan pure streaming. Runtime performance vrij zoeken. De oplossingen ontlopen elkaar niet zoveel. Bij op traditionele structuren gebaseerde oplossingen wordt het zoekgebied beperkt, omdat verschillende objecten in verschillende tabellen zitten. Op denormalisatie gebaseerde oplossingen hebben als voordeel dat er altijd gebruik kan worden gemaakt van indexen, maar hebben als nadeel dat de tabellen erg groot kunnen zijn. Bij streaming moeten altijd alle records worden gelezen, maar zijn complexe zoekcriteria weer in één keer te analyseren. Flexibiliteit. De traditionele structuur heeft een hoge flexibiliteit, omdat het uitgangspunt is dat deze erin gegenereerd wordt. Op het moment dat de flexibiliteit in extra attributen zit, is de flexibiliteit juist erg laag. De oplossingen met een vast deel scoren iets minder, omdat er in dit vaste deel geen flexibiliteit zit. Doorlooptijd modelwijziging. De traditionele structuur scoort hier laag, omdat elke wijziging een database wijziging tot gevolg heeft. De oplossingen met een deels vaste structuur scoren iets minder, omdat een wijziging in het vast veronderstelde deel impact op zowel de de database als de back office heeft. Toegankelijkheid. Een traditionele structuur is maximaal toegankelijk, de andere oplossingen scoren hierin een stuk minder. Het toevoegen van een vast deel aan streaming en denormalisatie maakt dit vaste deel wel goed toegankelijk. Opslagruimte. Een traditionele structuur en streaming geven geen opslag overhead. Het toevoegen van zoekcriteria aan streaming kost ruimte, het reserveren van extra attributen bij de traditionele oplossing kost nog meer. Volledige denormalisatie heeft de meeste opslagruimte nodig, wat gedeeltelijk teniet wordt gedaan door een vast deel toe te voegen.

31 Proces flexibiliteit

32 Eigenschappen flexibiliteit
Trade off tussen mate van flexibiliteit, performance en stabiliteit flexibiliteit heeft negatieve invloed op de performance van een systeem flexibiliteit heeft negatieve invloed op de stabiliteit van een systeem Onderscheid naar flexibiliteit in: data business rules proces Flexibiliteit in business rules: parameteriseren interpreteren genereren Flexibiliteit in proces: straight through processing: workflow tooling

33 Toelichting op de cijfers
Runtime performance. Genereren biedt de hoogste mogelijke performance, omdat op executietijd alles bekend is. Alles interpreteren zal te slecht performen, een gedeelte interpreteren performt al beter. Parameter sturing zal iets beter performen dan gedeeltelijk interpreteren, omdat er slechts een minimaal deel flexibel is. Flexibiliteit. Volledig interpreteren of genereren biedt een maximale flexibiliteit. Bij het gedeeltelijk interpreteren of genereren gaat al een deel verloren en bij parameter sturing is er de minste flexibiliteit. Doorlooptijd modelwijziging. Alle oplossingen die op de meta base gebaseerd zijn kennen een lage doorlooptijd: enkel de inhoud van de meta base moet geladen worden. Voor genereren geldt: hoe meer er gegenereerd wordt, hoe langer de doorlooptijd. Complexiteit oplossing. Parameter sturing zal het eenvoudigste te implementeren zijn, met een minimale complexiteit in zowel de modellen als in de uiteindelijke applicatie. Voor het gedeeltelijk genereren kunnen de bestaande generatoren grotendeels worden hergebruikt, zolang er maar geen extra functionaliteiten (zoals batchprocessen) nodig zijn. Bij interpreter oplossingen moet er uiteraard een interpreter worden gerealiseerd, terwijl bij volledige interpreteren of genereren de modellen minimaal uitgebreid moeten worden met batch functionaliteiten. Hoe meer geinterpreteerd of gegenereerd wordt, hoe complexer het wordt om nog een goed performende applicatie te krijgen. Dit geldt met name voor batches. Stabiliteit back office. Oplossingen die voor hun flexibiliteit gebruik maken van de product meta base zijn helemaal vast, een modelwijziging zal geen wijzigingen in de executable tot gevolg hebben. Voor het genereren geldt uiteraard dat hoe minder er gegenereerd wordt, hoe vaster de back office.

34 Domeinspecifieke talen
Indeling: Wat zijn domeinspecifieke talen? Waarom domeinspecifieke talen ? Toepassingen binnen Utopics Voorbeelden Vragen & Discussie

35 Wat zijn domein specifieke talen ?
Talen: middel t.b.v. modelleren van een systeem ( formeel, semi-formeel ) Domein specifiek: uitgerust met constructies toegesneden op een specifieke klasse probleemdomeinen Er is dus sprake van bewuste versmalling van het toepassingsdomein.

36 Waarom domein specifieke talen ?
Efficiënter in het gebruik door : toepassen semantisch rijkere constructies afdwingen van wetmatigheden van het betreffende domein ondersteuning van hergebruik van specificaties Lagere leercurve voor gebruiker van taal: taal staat dichter bij dagelijkse beleving gebruiker

37 Generator technology Uitleg plaatje:
Definition Business manager model Business modeler Generator Developer Uitleg plaatje: modelleur definieert in de definitiemanager (soort 4GL, zie straks), object-georiënteerd, de bedrijfsmodellen. Dit is de midoffice. Hij stelt commerciële producten samen op basis van basisproducten. Deze definities worden opgeslagen in het bedrijfsmodel. Vanuit het bedrijfsmodel kan via een generator een applicatie gegenereerd worden. De eindgebruikers gebruiken vervolgens deze applicatie. Voordeel: nieuw commercieel product-> modelleren, genereren: klaar! Front Office application User

38 Architectuur ontwikkelstraat

39 Workflow Process Model Workflow Manager generator User Interface Model Report Model Front Office Front Office generators Object Model Product Model Mid Office Metaoffice en generatortechnologie levert het volgende voorbeeld van een werkende praktijksituatie. Conclusie: Architectuur + generatortechnologie + financiële sector + Utopics = praktijkvoorbeeld. CCL module modules generator Overall architecture Fire Funeral ...

40 Wat te modelleren?  Generator
Productassortiment Processen Indeling user-interface Hoog-niveau applicatie-functionaliteit Koppelingen met (BO-)systemen. Productmodel Bedrijfsprocesmodel User-interfacemodel Objectmodel

41 Wat uit te programmeren?  Framework
o.a. Memorymanagement, persistentie Select en plaatsing schermcomponenten, resizing Workflowmanagement Versiemanagement producten Objectmodel-framework User-interfacemodel-framework Procesmodel-framework Productmodel- framework

42 Generatoroutput

43 Projectorganisatie Werkgroep “Front-office” Werkgroep “Modellering”
Produceert ontwikkelstraat Generieke oplossingen voor technisch complexe problemen Werkgroep “Modellering” Produceert de modellen Specifieke oplossingen voor gebruikerswensen

44 Voorbeeld object- en user-interfacemodel
klasse Persoon kenmerken naam : verplicht NaamStr gebdat : datum methoden Leeftijd():geheelgetal = retourneer gebdat.Jaren(vandaag); einde klasse dialoogscherm SelecteerLid (gevondenLid : Lid) titel “Selecteer Lid” schermcomponenten groep ZoekCriteria kenmerkveld Naam toont naam prompt “Naam” ... einde groep einde schermcomponenten einde dialoogscherm afgeleide klasse Lid isa Persoon kenmerken autos : verplicht LstAuto cascaderend einde afgeleide klasse

45 Voorbeeld Bedrijfsprocesmodel
proces AanvraagBehandelen eigenaar administrator activiteit VerwerkenInkomendePost met beschrijving “…” uitvoerende Postkamer gebruikt scherm Postregistratie subactiviteiten Registreren : gebruikt onderdeel Klantbeeld ... afsluitconditie tp <> leeg triggert alle Afd.Werkvoorb einde activiteit einde proces rol Afd(contract: Contract) verdeelt naar AfdelingA wanneer contract.tp.type = A AfdelingB wanneer ... anders naar proceseigenaar einde rol

46 Voorbeeld definitiemanager

47 Waarom domeinspecifieke modellen?  productmodel
Versiemanagement genereert één type versiebehoudend gedrag eenduidige aanpak ondersteuning bij definitie. MogelijkeProductelementen basisproduct AutoVerzekering productelementen wa: WettelijkeAanspr casco: CascoCompleet poi:PersoonOngInz … einde basisproduct levert op: lijst PEProductInfo generieke presentatie generieke Creeer-methode