2
Agenda
• PFA Pension
•Governance kontra organisationsstruktur i PFA
• Alignment af BPM og forretningsprocesser
• Resultater
• Udfordringer
• Fremtiden
• Hvem er jeg?
• Lars Rosenberg Nielsen,
• Teknisk Arkitektur, IT Innovation og Service, PFA Pension
3.
3
Hvem er PFAPension
• Vi blev grundlagt i 1917 af
arbejdsmarkedets parter
• Vi er ejet af kunderne
• Over 1 mio. danskere har valgt et af vores
produkter
• Største leverandør af firmapension i
Danmark
• Mere end 13 mia. kroner i omsætning
• Vi har 220 mia. kroner i pengetanken
• Vækst – 2004 +2,5%, 2005 +8%, 2006
+12%
• 1.100 medarbejdere – heraf 900 i Marina
Park og resten er fordelt på
afdelingskontorer i Herlev, Århus, Aalborg
og Kolding
4.
4
Baggrund
• PFA strategiproces2002 satte mål for en markant udvikling og
transformation af PFA Pension:
• Svært realiserbare på eksisterende Siemens mainframe platform
• IT-drevet forretningstransformation, med udskiftning af
størstedelen af applikationsplatformen og udfasning af mainframe
platformen.
• CSC valgt som systemintegrator i december 2002
• Programstart for Teknologiprogrammet i januar 2003
Kundefokus Produktudvikling Effektive processer
5.
5
Baggrund - Teknologiprogrammet
20032004 2005 2006 2008 20102007 2009
Unit Link Prototype
DitValg Konvertering
Kundeportaler
Rådgiver-
portal
SAP
Nye produkterIR 1.0
IR 1.1, 1.2, 1.3 …
SeeBeyond eGate -> Service Infrastruktur -> ALSB
6.
6
PFA Pension
Forretningsområde 2
Forretningsudvikling
FU,Stab
UFO
IT Innovation & Service
TAO, Stab
TSO
Drift
Kerneprocesser
Leverancer&
Økonomi
Sikkerhed
Støtteprocesser
TekniskArkitektur
Organisering
• Udviklingsforum (UFO) varetager
forretningsprojekterne
• Technical Architecture Office (TAO)
har ansvaret for arkitekturretningen
• Technical Sign-off Office (TSO)
har det endelige ledelsesmæssige
ansvar for strategiske og taktiske
it beslutninger
7.
7
Teknisk Arkitekturs projektansvar
•Ejer af Teknologi strømmen i projektmodellen
• TAO skal sikre at projekternes valg vedrørende
teknisk arkitektur passer med PFAs retning for IT
9
SOA i Forsikringsleverancen(IR)
- udvikling af ny forretningsmodel
1. Alt analysearbejdet tager udgangspunkt i de udvalgte forretningsprocesser
2. Proces teamet analyserer og nedbryder forretningsprocesser ift.
applikationsområder (svømmebaner)
3. Grænsesnit beskrives via forretningstermer og -data
4. Service Infrastruktur projektet medvirker til at omsætte til service
arkitektur og veldefinerede XML definitioner og skema
5. SI projektet implementerer adaptorer og transformationer
6. Applikations projekterne udvikler service interfacet ift. egen applikation
Forretnings-
arkitektur
Proces
Analyse
Service
Analyse
Service
Implemen-
tering
Service ReviewData ReviewService Registry
Primære
Processer
Støtte
Processer/
værktøj
10.
10
Arbejdsredskaber
• Beskrivelser afservices og serviceintegrationer virker som en
offentlig kontrakt
• Domænemodel og kanonisk model er udgangspunktet for alt
datamodellering
<element
Scheme>
…
</element>
<element
Contract>
…
</element>
<element
Benefit>
…
</element>
Globale regler
Kundeaftale
0-n
1
1-n
1-nProdukt-
rammeaftale
1
1
Opsparer-
aftale
0-n
0-n
Virksomhed
(juridisk enhed)
1
0-n
0-n
1
0-n
Opsparer-
kontrakt
1-n
1
Ydelse
Konto
1-n
0-nRisikooverskuds
gruppe
0-nPrm. beregn.
gruppe
0-n
Pool
0-1
• Obligatoriske
tværgående regler
• AMP
• Brancheaftaler
0-n1-n
1
1
0-n
Kunde delaftale
PFA's regelskema
• SK 3
• AMB sats
• Invalide
maks.
• 10%
reglen til
livrenter
• Ratetjek
• Anvendel-
se af AMB
• Basis
• Anvendel-
se af
admin.
• Præmie-
skala
Koncern
Tværgående aftaler
0-n Skade
registrering
1
Konto
1-n
Skadefolder
0-n
0-n
1
1
0-n
Person
1
Skive
1-n
1
0-n
1
Produkt-
platform
1-n
Forhold ml.
ydelser
Tilvalg
Ydelser
1-n
1-n
1-n
Globale regler
Kundeaftale
0-n
1
Kundeaftale
0-n
1
1-n
1-nProdukt-
rammeaftale
1
1-n
1-nProdukt-
rammeaftale
1
1
Opsparer-
aftale
0-n
0-n
1
Opsparer-
aftale
0-n
0-n
Virksomhed
(juridisk enhed)
1
0-n
Virksomhed
(juridisk enhed)
1
0-n
0-n
1
0-n
Opsparer-
kontrakt
0-n
1
0-n
Opsparer-
kontrakt
1-n
1
Ydelse
1-n
1
Ydelse
Konto
1-n
Konto
1-n
0-nRisikooverskuds
gruppe
0-nRisikooverskuds
gruppe
0-nPrm. beregn.
gruppe
0-nPrm. beregn.
gruppe
0-n
Pool
0-n
Pool
0-1
• Obligatoriske
tværgående regler
• AMP
• Brancheaftaler
0-1
• Obligatoriske
tværgående regler
• AMP
• Brancheaftaler
0-n1-n
1
1
0-n
Kunde delaftale
0-n1-n
1
1
0-n
Kunde delaftale
PFA's regelskema
• SK 3
• AMB sats
• Invalide
maks.
• 10%
reglen til
livrenter
• Ratetjek
• Anvendel-
se af AMB
• Basis
• Anvendel-
se af
admin.
• Præmie-
skala
Koncern
Tværgående aftaler
0-n Skade
registrering
1
0-n Skade
registrering
1
Konto
1-n
Konto
1-n
Skadefolder
0-n
0-n
1
Skadefolder
0-n
0-n
1
1
0-n
Person
1
1
0-n
Person
1
Skive
1-n
1
0-n
Skive
1-n
1
0-n
1
Produkt-
platform
1-n
Forhold ml.
ydelser
Tilvalg
Ydelser
1-n
1-n
1-n
11.
11
SOA er enkommunikationsform
• Fælles forståelsesramme
Forretnings-
arkitekter
Forretning
Forretningsanalytikere
Udviklere
Testere
IT Ledelse
HR
Tekniske Arkitekter
Configuration Management
12.
12
Teknisk modning –fra punkt-til-punkt til BPM
Punkt-til-punkt
Forretningsservices og
simpel aggregering
Forretningsprocesser –
services og processer
smelter sammen
14
Case: Opret Opsparer– swimlane diagram
Start fra portal
Start fra
indbetaling
Opret/hent stamdata på
person i alle systemer fra
2. fase
Opdatering af skattekoder
til service enabled
mainframe (fase 1)
Hent
engangementsoversigt i
alle policebærende
systemer (fase 2)
Ved firmaskift skal
personen behandles
manuelt
Opret police i
policebærende systemer
Automatisk firmaskift
implementeres i Q4 2007
hvor forretningsbehov er
Hele processen
bundet sammen
af BPM
16
Case: Opret Opsparer– skærmbilleder fra
processen
Opret Opsparer fra portal
Person oplysninger i
stamdata systemet
Kontrakt oprettet i
forsikringssystem
17.
17
Resultater - arkitektur
•Centraliseret Teknisk Arkitektur
stabsfunktion (TAO) og Service
Infrastruktur Projekt med
ansvaret for governance af SOA
artefakter
• Sammenspil mellem TAO som ejer
Teknologi strømmen i
projektmodellen og de tekniske
arkitekter på Service Infrastruktur
projektet. Implementeret ved at
TAO ressourcer deltager som
tekniske arkitekter på de
forskellige projekter
• Arkitektur principper og
projektmodel skaber rammen for
den taktiske udførelse.
• Hvad virker/virker ikke på et
operationelt plan giver feedback
på arkitekturprincipper
• Service genbrug og
sammensmeltning mellem
processer, BPM og services er
sikret
• Viden er blevet skabt, delt og
forbedret relativt hurtigt
Tilgang Resultater
Udførelse
18.
18
Resultater - udvikling
•Centraliseret Service Infrastruktur
Projekt med ansvaret for udvikling
af service integrationer og
governance af SOA artefakter
• Formel review proces af service
beskrivelser, service kald
beskrivelser og data modellering.
Teknisk Analyse af
forretningsprocesser.
Deltagelse i Impact Analyser
• Service genbrug
• Sammensmeltning mellem
processer, BPM og services
• Design af services er sket ud fra
en fællesskabstanke
• Servicekontrakter offentliggjort i
service repository
• Ændringer som ikke tilfredsstiller
SOA principperne bliver ikke
godkendt
Resultater
Udførelse
Tilgang
19.
19
Resultater - operationel
•Centraliseret Service Infrastruktur
Projekt med ansvaret for udvikling
af service integrationer og
governance af SOA artefakter
• Servicekontrakter og beskrivelser
af kald af services reviewes for
elementer som oppetid,
forventninger til volumen,
frekvens, krav til responstid, m.m.
• Giver i dag input til design af
service integrationer og capacity
management
• Fremtiden vil inkludere teknisk
understøttelse af runtime
governance. Vil sandsynligvis ske
via BEA AquaLogic SOA
Management (Amberpoint)
Resultater
Udførelse
Tilgang
20.
20
Resultater - andet
•I starten af et projekts analysefase tildeles en Teknisk Arkitekt fra
TAO med SOA erfaring. Det skubber hurtigt projektet i den rigtige
SOA retning
• Overblik over processer og services igennem Sharepoint og et
Access baseret Service Repository muliggør et hurtigt estimat på
budget og ressourceallokering
• PFA benytter i dag sin egen Enterprise Service Bus af historiske
årsager. Ved at have fokuseret på processerne ved udviklingen af
services er vi i stand til at skifte teknisk platform til BEA AquaLogic
Service Bus uden ændringer til service integrationer.
21.
21
Udfordringer under vejs
•Kulturel modning i organisationen/kommunikation
• Governance dur ikke hvis bevæggrundene ikke er blevet
forklaret godt nok
• Ikke tilstrækkelig uddannelse af teknisk analyse team har gjort at
der er blevet fundet en del afvigelser i reviews
• Projekternes ressourceallokering har været med til at skabe
udfordringer i håndhævelsen af governance processerne
22.
22
Fremtiden
• SOA Governancei en ITIL proces
• Højere grad af automatisering i governance proces
• Runtime governance til sikring af kontrakt mellem udbyder og
brugere af services
• SLA monitorering via BEA AquaLogic Service Bus
• Facilitering af mere kommunikation mellem forretning og IT – en
socialiseringsproces
#5 Kundefokus : Produkter der er nemmere at forstå og mere gennemskuelige
Bedre og mere forståelig
Produktudvikling: Effektiv udvikling, marketing og administration af nye produkter baseret på markedsinteresse
Effektive processer: Løbende udskifte utidssvarende teknologi, for at sikre muligheden for i fremtiden at tilpasse sig kunde- og markedsbehov
#16 &lt;number&gt;
WebLogic Integration/JPD-Java Process Definition: Venstre side: Proces-flow, næsten genkendeligt i forretningsdiagram. Højre side, ren java-klasse. Samme proces. Softwaren får de to ender til at mødes.