Rabobank: Service Architectuur in de Praktijk

Transcriptie

1 abobank: Service Architectuur in de Praktijk Bert Bastenhof, Pieter Fortuin Computable, 21 september 2006

2 Inleiding 1. abobank omgeving 2. Architectuur binnen de abobank 3. Waarom Service Architectuur? 4. Structuur en Afspraken 5. Trends en Aanbod vanuit de Markt 6. Ervaringen met de ealisatie 7. Lessons learned en ichting 8. Conclusies

3 1.1 Merken van de abobank

4 1.2 Introductie abobank w Aangesloten banken: w Kantoren Nederland: w w w w 1300 Geldautomaten: Kantoren Buitenland: Medewerkers: Credit rating: Triple A w Klanten: w Landen: 9 miljoen 37 w Marktaandeel sparen: 38% w Marktaandeel hypotheken: 25%

5 1.3. Technische indicatoren w 18 z/os lpars 27 Non-stop systems (HP) 400 unix systems/lpars 2300 Windows servers Veel MQ koppelingen (meer dan queues) Veel C:D koppelingen Veel applicaties (>500)

6 2.1 Belang van ICT en Architectuur w Informatie is essentieel voor Financiële Dienstverlening Ÿ circa 20% van operationele kosten betreft ICT Ÿ honderden toepassingen per merk Ÿ meer dat 4000 ICT medewerkers w Architectuur is noodzakelijk voor de abobank Groep w Architectuur baseren op Ÿ kennis van de business en van oplossingen

7 2.2 Architectuur abobank Interactie Fysieke Vestiging Klant bezoek Extranet Telefoon Internet Automaat Post ALEX DistributieAndere distributie- kanalen derden kanalen v.d. abo Groep Pakkettering Producten derden Beleggen wholesale Shared wholesale services Verzekeren Leasing Beleggen Leasen retail Finan cieren Product Sparen Multi-label Betaalinfrastructuur Organisatiefuncties per eenheid Organisatie DATA Besturing Financiële administratie en Consolidatie Aspecten Bedrijfsvoering (Personeel, inkoop, Juridisch, etc) Externe Interfaces.. abobank International Bedrijfszorg Interpolis Direct Pensioenen Distributie obeco Direct ABB Betalen Infrastructuur Multi-channel

8 3.1 Drivers voor Service Architectuur w Procesondersteuning Ÿ integratie verleggen van gebruiker naar systeem w Multichannel Ÿ klanten, medewerkers, leveranciers in één proces w Multilabel Ÿ meerdere afnemers voor productadministraties w Kanteling van product naar klant w Hergebruik/Integratie Ÿ verschillende platformen Ÿ verschillende talen Ÿ verschillende eenheden

9 3.2 Definitie Servicearchitectuur w De abobank Servicearchitectuur is een set van modellen en principes voor het realiseren van gedistribueerde functionaliteit. w Er wordt uitgegaan van een benadering waarbij deze functionaliteit wordt gerealiseerd door een samenwerking van onafhankelijke componenten die via berichtuitwisseling services aan elkaar leveren.

10 4.1 Scheiden van Functies Interactie Proces Integratie Communicatie infrastructuur Applicatie

11 4.2 Intra en Inter Domeinverkeer Domein b Interactie Proces Pakket Integratie Domein communicatie infrastructuur Adapter Domein a Applicatie Centrale communicatie infrastructuur Adapter Pakket Transport Service registratie Protocol Beveiliging ServicebeschrijvingBeheer Domein d Interactie Proces Integratie Adapter Communicatie infrastructuur Domein c Adapter Applicatie Adapter Pakket Adapter Domein communicatie infrastructuur Adapter Pakket Adapter Pakket Adapter Pakket

12 4.3 De gemaakte Afspraken w Communicatie op basis van MQ en Http w Berichtstructuur op basis van SOAP/XML w Gebruik van de SOAP-header Ÿ eigen header voor beheer en sturing (circa 10 elementen) Ÿ beveiliging (circa 5 elementen) Ÿ migratie naar marktstandaard header w Webservices Ÿ nog verder in te richten Ÿ meer aandacht bereiken voor beheer Ÿ meer aandacht bereiken voor semantiek

13 4.4 Integratieniveaus 5Optimaliserend (Feedback uit de operatie / BPM maximaal) CM levels 4 Proces (inclusief multichannel / BPM nog niet optimaal) 3 Operationele besturing (terugkoppeling resultaat) 2 Cockpit (link) 1 Huidig (losse toepassingen)

14 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

15 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

16 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

17 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

18 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

19 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

20 5.1 Trends in de Markt Van Built to last Waterval methoden Naar Built to change Incrementele bouw en invoering Applicatie silo s Georkestreerde oplossingen Tightly coupled Loosely coupled Object oriëntatie Bericht oriëntatie

21 5.2 Leveranciers met ecosystemen Verticals Specifiek - bijv. bancaire productsystemen Microsoft CM, EP Oracl e SAP Financiële administratie, H Office, mail, content Ontwikkelingomgeving Algemeen Middleware - applicatie server portal BPM, EAI messaging Microsoft IBM Oracl e SAP Open Sourc e Database Platform - operating system Beheeromgeving HP

22 5.3 Uitgangspunten ecosystemen w Een ecosysteem is het geheel dat geleverd wordt door multi-layer leverancier Ÿ dus niet elke leverancier van een pakket levert ecosysteem w Integratie binnen een ecosysteem is een leveranciers issue w Integratie tussen ecosystemen op basis van standaarden Ÿ webservices (SOAP, XML, WS-Security, WSDL) w Bepaalde leveranciers van ecosystemen werken samen Ÿ bijvoorbeeld in het definiëren van standaarden w Advies: beperk het aantal ecosystemen

23 5.4.1 ecosystemen en ESB Verticals Specifiek - bijv. bancaire productsystemen Microsoft CM, EP Oracl e SAP Financiële administratie, H Office, mail, content Ontwikkelingomgeving Algemeen Middleware - applicatie server portal BPM, EAI messaging Microsoft IBM Oracl esb e SAP Open Sourc e Database Platform - operating system Beheeromgeving HP

24 5.4.2 ecosystemen en ESB Verticals Specifiek - bijv. bancaire productsystemen Microsoft CM, EP Oracl e SAP Financiële administratie, H Office, mail, content Ontwikkelingomgeving Algemeen Oracl e SAP esb IBM esb Microsoft esb applicatie server portal BPM, EAI messaging esb - esb Middleware Open Sourc e Database Platform - operating system Beheeromgeving HP

25 5.4.3 ecosystemen en ESB Verticals Specifiek - bijv. bancaire productsystemen Microsoft CM, EP Oracl e SAP Financiële administratie, H Office, mail, content Ontwikkelingomgeving Algemeen IBM Oracl e SAP esb esb esb Microsoft esb applicatie server portal BPM, EAI messaging esb - esb Middleware Open Sourc e Database Platform - operating system Beheeromgeving HP

26 6.1 Voorbeelden abobank Voorbeel Jaartal d 1995 w Fiatteren Betalen Techniek Ervaringe n Propriety NonStop -obuust, maar 1999 Propriety http 1999 MQ 2000 MQ w Klantservices 2004 SOAP over MQ w Sparen 2004 w aboweb Beveiliging w BK-toets (wrapping) w GIM (Verzekeren) geen scheiding met kanaal -Problemen met hergebruik -obuust -Uitgebreid, intensief gebruik, Webservices granulariteit - semantiek All Finance - UL+ schermen (level 3)-obuust -Positieve pilot, integratie is issue

27 6.2 Ervaringen in de Praktijk w Servicearchitectuur gestart in 1999 Ÿ standaarden en voorschriften zijn gegroeid à verschillende implementaties (versies) in omloop w Invoering in het begin lokaal Ÿ niet overal direct of volledig overgenomen à zekere wildgroei (aantal queues), ontbreken van de bekendheid w Weerstand in het begin Ÿ propriety versus standaard à discussies over propriety oplossingen w Aandacht en besef voor het beheer is gegroeid Ÿ aandacht voor ketenmanagement

28 6.2 Knelpunten w Ontbreken van eigenaar w Verantwoordelijkheden niet toegewezen w Ontbreken van Compliance w Geen centrale service repository Soms lokaal aanwezig w Te snelle invoering van technische componenten w Toegankelijkheid richtlijnen w Gebruik MQ

29 6.3. Invoering nieuwe technologie Stap 2: Begeleiden Eerste toepassing vernieuwing Showcase 1 Showcase 2 Showcase 3 Ondersteuning showcases Stap 3 Invoering in Organisatie BEHEE Stap 1: Onderzoek POC s; Vaststellen consequenties Project matig QA Kennis man.

30 7.1 Lessons Learned w Standaards Ÿ welke standaarden zijn rijp? Ÿ het lijkt mooier dan het is w Bouwen: wat is een goede service? Ÿ bij ontwerp uitgaan van processen Ÿ opstellen handvatten/ best practices Ÿ aandacht voor kosten/performance/beheer w Testen Ÿ gevaar voor lange testtrajecten Ÿ ketentesten t.o.v. point-to-point testen w Beheren Ÿ veel partijen, versies (nieuw naast oud), explosie van queues

31 7.2 ichting w Volgen van standaards w Beperken van het aantal ecosystemen w Afspraken over semantiek Ÿ branchestandaard per domein Ÿ abo eferentietaal bij interdomeinverkeer (gebaseerd op standaard) w Centrale repository Ÿ gedistribueerd gebruik (op basis van WSDL) w Beperken aantal toegangspoorten per domein Ÿ terugdringen aantal queues (vergroten beheersbaarheid) w Ontsluiten legacy systemen op basis van SOAP w Invoeren ketenmanagement; beveiligen op berichtniveau w Aandacht voor Businessrules engines

32 7.3. SOA governance w Het proces dat er voor zorgt dat de juiste dingen op de juiste wijze door de juiste personen worden uitgevoerd. Ÿ Ÿ Ÿ Ÿ best practices architectuur principes regelgeving vertrouwen w Drie stappen Ÿ Definieer SOA policies Ÿ icht een SOA infrastructuur in die het afdwingen van deze policies ondersteunt; Ÿ egel een aantal processen en procedures in voor het toezien op het nakomen van deze policies (compliance)

33 7.4 SOA Governance Bron: Systinet

34 8. Conclusies w Service Architectuur is meer dan techniek w Geef aandacht aan SOA governance w Service Architectuur biedt een technische ontkoppeling w Service Architectuur nodig om de complexiteit te beheersen w Aansluiten bij marktstandaarden en bij ecosystemen w Service Architectuur vergt lange adem w Invoering vereist een centrale sturing w Extra aandacht voor Beveiliging en voor Beheer is nodig