Evolutie Rabobank Architecturen Op weg naar Model Driven Design
Dr. Adrie Rozendaal Enterprise Business Modeling Rozendaal EBM B.V.
Overzicht
• • • • • • •
2
De Rabobank Architecturen: Office Paradigma Procesarchitectuur 3.x Planologie & Architectuur Enterprise Architecture Metamodel Iets over aanpak
De Rabobank Een profiel
3
De Rabobank in Nederland
Lokaal • Bankieren in 145 zelfstandige Rabobanken • 1000 vestigingen • Totaal 28.000 fte • 7,5 mln klanten Centraal • Rabobank Nederland: Coöperatieve Centrale RaiffeisenBoerenleenbank BA • Vestigingen Utrecht, Eindhoven, Tilburg • Computercentra Zeist, Best en Boxtel • Verwant met Interpolis, Robeco en DLL • 6.200 fte, waarvan ca. 3.000 in ICT
4
Het ICT-Bedrijf
•
Historie − Automatisering van administraties − Automatisering van geldstromen
•
Ambitie − Automatisering van processen 5
• • • •
3.000 medewerkers 700 applicaties 7x24 operatie Continuïteit:Twin Centra
Terugblik op Architecturen 3.x Leren van het verleden
6
Procesarchitectuur 3.0: Hoofdplaat Rabobank Procesmodel 3.0
Observaties:
0 Sturen organisatie 0.1 Ontwikkelen strategie
-Vermenging concepten bedrijfsfuncties en processen
0.4 Meten &
0.3 Doorvertalen jaarplandoelen
rapporteren
0.5 Analyseren &
bijsturen
1 Ontwikkelen & beheren formule 1.1 Onderzoeken markt
-Scope over verschillende bedrijven
-Beperkt tot „Planologie‟
0.2 Opstellen jaarplan
1.2 Ontwerpen & Ontwikkelen formule
2 Genereren & afhandelen verkoop 2.1 Bewerken markt
2.2 Plannen verkoop
2.3 Realiseren verkoop
2.4 Afhandelen verkoop
1.3 Bouwen & testen formule
1.4 Implementeren formule
3 Uitvoeren service & transacties 3.2 Aanpassen klantgegevens
3.1 Aanpassen overeenkomst
3.5 Beheren klantrisico
3.3 Uitvoeren transacties
3.6 Factureren
3.4 Behandelen vragen & klachten
3.7 Verstrekken verantwoordingsinformatie
4 Ondersteunen organisatie 4.1 Managen coöperatie
7
4.2 Managen financiële middelen
4.3 Managen fysieke middelen
4.4 Managen Human Resources
4.5 Managen externe relaties
4.6 Managen in- & externe communicatie
4.7 Managen ICT
4.8 Managen bedrijfsrisico
8
Architectuur en werkelijkheid: Applicaties
9
Infomatie Architectuur: vanuit IFW
10
11
Gegevens architectuur (uitwerking, voorbeeld)
12
„Koppeling‟ Kernobjecten en Applicatie Architectuur
13
Terugkijken in 7 schoten
14
Conclusies
Architectuur 3.x heeft ons geleerd.. .. dat ontwerp volgens architectuur bestaat .. dat bruikbaarheid en toegevoegde waarde voor de eindgebruiker essentieel is .. dat sturing op architectuur een noodzakelijke voorwaarde is .. dat integratie van verschillende aspect architecturen een issue is
15
Planologie en Architectuur In Bouw en Processen
16
Planologie Architectuur
17
Procesplanologie: Lokale Bank Klantgroep: breed Kanaal: multichannel
18
Private Banking
Retail particulier
Kantoor
Product: All-Finanz
Betalen
Procestypologie
Marketing
Retail bedrijf
Zakelijke Relatie
Telefoon
Sparen Afsluiten
Financieren Wijzigen
Internet
Beleggen
Beëindigen
Transactie
Verzekeren Service
Van planologie naar architectuur Gebaseerd op requirements
19
Eens een bank altijd een bank
20
Consequenties en requirements Klantgroep: breed Kanaal: multichannel
•
Private Banking
Retail particulier
Kantoor
Product: All-Finanz
Betalen
Procestypologie
Marketing
Retail bedrijf
Zakelijke Relatie
Telefoon Sparen
Afsluiten
Financieren Wijzigen
Internet Beleggen
Beëindigen
Transactie
Aantal processen, in beginsel: − Klantgroepen x Kanalen x Producten x Procestypologie x Varianten
•
Uniformiteit − Herkenbaarheid voor klant (zelfbediening) − Eenvoud voor de medewerker − Herbruikbare bouwstenen
•
Eisen vanuit de klant − Snelheid, voorspelbaarheid en in 1 keer goed
•
Eisen vanuit de bank − Marktaandeel, risicobeheersing en kosten
21
Verzekeren Service
Herontwerp primair proces
•
Observatie − Medewerker in het land leest geen schema‟s − Heeft „t liefst een lijstje met taken − Geen info die niet nodig is bij de uitvoering
•
Architectuureisen − − − −
22
Strakke hiërarchie (grof naar fijn) Uniform toepasbaar Toegankelijk op basis van schema én lijstjes Rigide structuur voor additionele procesinformatie
Architectuur voor primair proces
Wilsovereenstemming
Clean Order Moment
Adviseren klant
Genereren klantcontact
Aannemen klantvraag
Aannemen opdracht
Informeren klant
Toegankelijkheid
23
Helpen kiezen
Beheren afspraak
Verwerken opdracht
Incasseren vordering
Uitkeren tegoed
Afspraken nakomen
Referentiemodel Klantbedieningsprocessen Wilsovereenstemming
Clean Order Moment
Adviseren klant
Genereren klantcontact
Aannemen klantvraag
Aannemen opdracht
Informeren klant
Toegankelijkheid
Strikte hiërarchie 24
Helpen kiezen
Beheren afspraak
Verwerken opdracht
Incasseren vordering
Uitkeren tegoed
Afspraken nakomen
Referentie en werkelijkheid
25
Bouwstenen architectuur
Bouwstenen werkelijke wereld
Interactie Bankhal
2
2
Mobiele apparatuur
2 Vaste apparatuur
1
Massa medium2
Ketens
Externe partij2
Referentiemodel voor Applicaties Klantvraag
2 Authenticatie en autorisatie
Advies
2
2
Klantcontact
2
Reclames
2
Klantafrekening2 en informatie
Businessdomein Financieren
Geld Nodig Bedrijven
1
Ontvangen en betalen
1
1
Opdracht
2
Afspraak
Propositie (shared bedrijfsfuncties distributie en productie) Relatie
1
1
2
Distributie Klantcontact 2
Geld Nodig Particulieren
2
1
Klant (krediet) risico
Geld over (sparen)1
Samengesteld2 product en overeenkomst (Master)
2
Paymentengine2 Geld over (Beleggen)
Productie
1
1
2 Productadministra tie
Afdekken risico 1 (Particulieren)
Basis product2
Afdekken risico 1 (Bedrijven) Business function - level 1
Betalen
1
Sparen
1
Financieren 1 (productfabriek)
1
Beleggen
1
derden
Organisatie Financial Accounting
2
2
Management Accounting
26
Project Accounting
2
Centrale Marketing
2
2 Bedrijfsmanagem ent
1
1
HR
2
Staven en diensten
2
1
Enterprise Architecture Koppeling aspect architecturen
27
Definities
•
Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm‟s operating model. MIT Center for Information Systems Research
•
Enterprise Architecture describes enterprise applications and systems with their relationships to enterprise business goals. Wikipedia.org
•
Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks. IFEAD (Institute for Enterprise Architecture Developments)
Scope van Enterprise Architecture
Businessarchitectuur
* Alle aspecten worden gevoed vanuit de bedrijfsdoelen en – strategie
* Processen vormen de verbindende schakel tussen alle aspecten
Cluster
Business Rules
Informatiearchitectuur
D attribute
D attribute
Principle
Wet & Regelgeving en Beleid
Procesarchitectuur
Applicatiearchitectuur
Objective
Network type
Risico's en Beheersmaatregelen
…
IT-Infrastructuur
Waarom Enterprise Architecture
•
Enabler voor ondersteuning van processen die onderdelen van Enterprise Architecture nodig hebben: − − − −
Business Process Management Business Continuity Management Risk Management Voortbrengingsprocessen − product, formule én ICT − verandering én continuïteit
• • •
Versneller voor de korte time-to-market en hogere efficiency van processen Controller voor het inzichtelijk maken en aantonen van de compliance van processen Bestuurder van de inrichting en uitvoering van de processen, incl. eigenaarschap en werkverdeling
Inhoudelijke samenvatting Business Business
P roces sen Processen
Applicati Applicaties
• Huidige situatie − Elke deelarchitectuur is vanuit een autonome invalshoek ontwikkeld − In de loop van het voortbrengingsproces zijn alle tussenresultaten vastgelegd in aparte documenten. − De „transformaties‟ tussen deze documenten zijn nauwelijks traceerbaar. De werkmethode laat toe dat in de loop van het ontwikkeltraject steeds verder wordt afgeweken van het oorspronkelijke ontwerp op architectuurniveau en de ontwerpen daarna.
Technologie
Informatie
De procesarchitectuur is het ankerpunt voor onze integrale architectuur
Integratieprincipe: een proces volgt op een klantvraag (markt), heeft gegevens als input/output,
wordt ondersteund door een applicatie, die draait op een infrastructuur
Evolutie in de samenhang van Business en ICT •Sturen organisatie
•Formule management
•Adviseren klant
•Product management
•Aannemen opdracht
•Beheren overeenkomst
•Informeren klant
Klant
•Verwerken opdracht
•Incasseren vordering
•Uitkeren tegoed
•HRM
•Facilitair
•ICT
•Communicatie
•Coöperatie
•Inkoop
•Financiën
•Externe relaties
Business Procesfamilie xyz
Processen
Opdracht verstrekt
Uitvoeren opdracht
Opdracht uitgevoer d
Bevestigen uitvoering
‘Ding’, ICTbegrip
Verlenen nazorg
Product Incasso opdracht verstrekt
‘Ding’, Bancair Lexicon begrip
Processtap abc ..
Gegevens
..
Handeling Risico ‘Applicatie-Ding’ AutorisatieUser Access Presentation
Infrastructure Applications
User Devices
Infrastructure Services
Identity Access Management
Portals
Integration Services
Personal Communication
Content Services
Application Middleware
Applicaties
Core Infrastructure Printing Networks Locations
Storage
Server Platforms Security
Infrastructuur
Standard Applications
Operations
•Genereren klantcontact
•Risico management
..
•Routeren klantvraag
Gekoppelde objecten
34
(handelingenniveau )
Primaire eis: één set standaards om deze verandering te kunnen bewerkstelligen
• •
•
•
Archimate: Marktstandaard voor het ontwerp van Business en ICT, vanuit een geïntegreerde architectuurbenadering: ARIS Platform: Marktstandaard voor het vastleggen van onze „wereld‟ conform Archimate in een object-relatie geörienteerde omgeving: Rabo-Metamodel en –Conventies: Interne Rabo-standaard voor de manier waarop we deze twee standaards in onze organisatie toepassen: Referentie architecturen: − Processen: Procesarchitectuur 4.0 (Rabobank) en ITIL versie 3 (marktstandaard) − Gegevens: IFW (IBM) − Applicaties: Applicatiearchitectuur 4.0 (Rabobank)
Rabobank Metamodel Conventies voor Enterprise Architecture
36
Archimate – Metamodel (Summary)
Businesslayer
Applicationlayer
Technologylayer
Business laag
• • • • • •
Producten/diensten Klanten Organisatie Bedrijfsfuncties Processen Bedrijfsobjecten
•
GEEN APPLICATIES
Businesslaag in Archimate
Businesslaag Rabo-Metamodel
Business service (klantvraag) Soft goal Wet of Regel WR
Business objective
Hard goal
Principe P
Business requirement
3
Business function - level 3 Risk
Applicatielaag in Archimate (incl. aansluiting Business)
Applicatielaag in Archimate (incl. aansluiting Technologie)
Applicatielaag Rabo-Metamodel
Business requirement
Risk
User requirement
Application component - level 1 Application component - level 2
1 2
Application Application service service
33 Application component Application component - - level 3 level 3 Application authorization group
Data object
Application authorization function
Application interface
Application user interface
Technologielaag in Archimate
Technologielaag Rabo-Metamodel Business requirement
User requirement
Application component - level 1
1
Application component - level 2
2
33 Application component Application component - level 3 level 3
System requirement System software Application interface
Infrastructure Infrastructure service service
Node
Device
Artifact (executable)
Application user interface
Praktijk Casus
•
Model voor ICT-unit − Continuïteitsbedrijf − Veranderbedrijf
Business Process Excellence Verankering in Architecturen
47
De Halsband van de IT Architectuur Adviseren klant
Genereren klantcontact
Aannemen klantvraag
Ordeningsprincipe •
Proces: delivery chain
48
Aannemen opdracht
Verwerken opdracht
Incasseren vordering
De Halsband van de IT Architectuur Adviseren klant
Genereren klantcontact
Marketing System
Aannemen klantvraag
CRM System
Ordeningsprincipe • •
Proces: delivery chain ICT: bedrijfsfuncties
49
Aannemen opdracht
Advisory System
Risk Mgt System
Verwerken opdracht
Order System
Incasseren vordering
Product System
…… System
Invoice System
Financial System
De Halsband van de IT Architectuur Adviseren klant
Genereren klantcontact
Marketing System
Aannemen klantvraag
CRM System
Ordeningsprincipe • •
Aannemen opdracht
Advisory System
Risk Mgt System
Proces: delivery chain ICT: bedrijfsfuncties
Verbonden door medewerkers 50
Verwerken opdracht
Order System
Incasseren vordering
Product System
…… System
Invoice System
Financial System
De Halsband van de IT Architectuur Adviseren klant
Genereren klantcontact
Marketing System
Aannemen klantvraag
CRM System
Improve
Ordeningsprincipe • •
Aannemen opdracht
Advisory System
Order System
Product System
New Risk Mgt System
Incasseren vordering
Verwerken opdracht
Invoice System
New …… System
Financial System
Proces: delivery chain ICT: bedrijfsfuncties
Verbonden door medewerkers Huidige ICT-strategie: vernieuwen en verbeteren 51
De Halsband van de IT Architectuur Adviseren klant
Genereren klantcontact
Aannemen klantvraag
Aannemen opdracht
Verwerken opdracht
Incasseren vordering
Business Rules – Workflow Engine – Enterprise Service Bus – Virtual Employee
Marketing System
CRM System
Ordeningsprincipe • •
Advisory System
Risk Mgt System
Order System
Product System
…… System
Invoice System
Financial System
Proces: delivery chain ICT: bedrijfsfuncties
Verbonden door systemen Alternatieve strategie: procesoptimalisatie door inkapselen legacy 52
Iets over de implementatie Veranderen….
53
De scope - aspecten
• • • • • •
•
Requirements voor de beoogde verandering in het doelgebied Processen die herzien worden Gegevens die vereist zijn en gegevens die ontstaan of gewijzigd worden Bedrijfsfuncties die verbonden zijn met de gegevens en applicaties Applicatie onderdelen en interfaces naar andere systemen of services die nodig zijn in het proces Infrastructuur componenten, zodat CMS/BoM en de daarmee verbonden ICT-processen up-to-date blijft Specificatie van systemen nog te bezien
De scope – producten in het ontwikkeltraject •
• • • • •
•
BIP: formele vastlegging. Daarnaast kunnen communicatiedocumenten in andere formaten gemaakt (en weer vernietigd) worden Domein architectuur: is geïntegreerd in een BIP Programma architectuur en Project Start Architectuur: zijn scoping documenten Business analyse: detaillering van requirements, proces, gegevens en applicatie (high-level design en BoC) Engineering: applicatie ontwerp Exploitatie: transformatie van ontwerp naar implementatie en synchronisatie met CMS/BoM Specificatie van systemen: nog niet bekeken, staat nog ter overweging
Beeldvorming ten aanzien van de implementatie De omslag in de manier van denken, van office-producten naar objectgeörienteerd werken, is groot. Karikatuur van deze paradigma verschuiving: Office-World
MDD-World
Ik werk aan mijn opdracht, mijn document. Ik structureer dat op mijn manier. Ik neem dingen over, maar verander ze in overleg met de opdrachtgever. Wat er met de voorgaande documenten gebeurt is niet mijn probleem. Mijn werk zit beter in elkaar dan wat die architect destijds had bedacht.
Ik werk de modellen en objecten die door de architect gedefiniëerd zijn verder uit. Ik kijk wie er nog meer gebruik maakt van de objecten waaraan ik dingen verander. Ik neem in zo’n geval even contact op met de ander. Als ik een probleem in de oorspronkelijke structuur ondervind, neem ik contact op met de architect en kijk samen met hem hoe we dat oplossen.
De projectmanager bepaalt meer mijn manier van werken dan de architect. Tijd is minstens zo belangrijk als kwaliteit. Tijd is belangrijker dan conventies.
De projectmanager is er voor de planning en organisatie. De architect gaat over de inhoud, daar gaat de projectmanager niet over. De conventies en kwaliteitsnormen staan hoog in het vaandel.
Ik kan lezen en schrijven met Office. Dat schiet op. Ik wordt amper lastig gevallen met de relaties tussen mijn werk en dat van mijn collega’s. Dingen die niet zo belangrijk zijn laat je toch gewoon weg!
In eerste instantie heb ik er alleen maar last van, dat ARISgedoe. Het duurt langer, is meer arbeidsintensief. Toegevoegde waarde van consistentie, volledigheid, transparantie of hergebruik zie ik (nog) niet.
Ik ken het VBP: zo werken wij. Als het anders moet, dan ga ik daar ‘ns over nadenken en vind mijn weg wel weer.
Voor de manier van werken hebben we conventies. Als ik het even niet weet, duik ik daarin, vraag het na of doe ik een verbetervoorstel.
Denkwijze voor het implementatie ontwerp • •
Eén van de grootste risico‟s van deze verandering is het creëren van een ongeordende warboel van modellen en objecten in de repository Mogelijke consequenties: − Fouten in ontwerp of specificaties door het linken van verkeerde varianten/versies − Fikse reparatie inspanning op een later tijdstip
•
Oorzaken, gebaseerd op ervaring met de procesmodellering in 2009 en 2010 − Onervarenheid van medewerkers, onvoldoende tijd om het vak te leren − Het niet naleven van afspraken (conventies). Dit kan het gevolg zijn van „ik weet het beter‟ of „eigenlijk begrijp ik het niet, maar dat zeg ik niet‟.
•
Maatregelen (wordt verderop per item toegelicht) − Goede basistraining geven en zorgdragen voor (referentie)documentatie − Coaching-on-the-Job in de eerste maanden van het gebruik door een expert, geleidelijk afnemend. Vraagbaak beschikbaar daarna. − Onderlinge feedback in peer-groepen formeel organiseren, begeleid door expert − Referentiemodellen ontwikkelen, onderhouden en de toepassing er van uitleggen − Conventies onderhouden en uitdragen − Regelmatig „de thermometer‟ steken in hetgeen medewerkers maken/gemaakt hebben
Tot slot: waar gaat het om…
… Visie en strategie: business, proces of ICT? … Paradigma verschuiving … Verandermanagement
Met dank aan: collegae Rabobank, Sopra Group en Software AG
