Sund & Bælt – BroBizz og SOA

Præsentationer af emnet: "Sund & Bælt – BroBizz og SOA"— Præsentationens transcript:

1 Sund & Bælt – BroBizz og SOA
8. april 2008 Peter H. Christensen IT-chef

2

3 Forskellige betalingsformer. Forskellige valuta
Trafikken i Norden Kendetegnet ved: Stigning i trafikken Flere betalingsveje. Forskellige betalingsformer. Forskellige valuta En fremtid som ville bringe flere udstedere og operatører af On Board Units (OBU) (BroBizz, autoPASS) Forvirring hos kunder om : Hvor kan jeg bruge min BroBizz? Hvor kan jeg få rabat? Hvor mange valutaer skal jeg have med på ferie?

4 Projektet som ledte til EasyGo
Indledende undersøgelser til EasyGo startede i 2004 Endte med etablering af EasyGo samarbejdet som skulle implementere et samlet betalingsmiddel for Nordiske operatører af betalingsveje. Samarbejde mellem: Vägverket, Norge Statens Vegvesen, Sverige Sund & Bælt Holding A/S, Danmark Øresundsbro Konsortiet, Danmark/Sverige

5 Udfordringer i EasyGo løsningen
Lovmæssige problematikker: Forskellige love i forskellige lande Afregningssystemer og moms. 3 forskellige valutaer Systemet baserer sig på klassifikation ud fra blacklister Komplekse lokale prispolitiker

6 EasyGo tjenesten Udstedere Operatører 310.000 Storebælt BroBizz
Øresund BroBizz AutoPASS OBU i alt Operatører 25 bompengeanlæg og 1 færge i Norge Storebæltsbroen Øresundsbroen Mols-linjen HH-ferries Scandlines

7 Krav til løsning (BPM) Ingen forudgående erfaring på området. Ønske om afprøvet teknologi. Ingen standarder for struktur af informationer. Ønske om service som kunne skabe struktur standarder. Forskellige arbejdsgange i forskellige selskaber. Ønske om proces som understøtter forskellige arbejdsgange i forskellige selskaber. Usikkerhed om hvilken strategi fremtiden ville bringe. Ønske om fleksibilitet i løsningen, således at denne kunne tilpasses fremtidige ønsker/ændringer. Skalerbarhed

8 EasyGo løsningen

9 EasyGo løsningen

10 EasyGo løsningen

11 EasyGo løsningen

12 EasyGo løsningen

13 BizTalk i EasyGo løsningen
Grundlæggende udnyttelse af BizTalk Overvågning af mappeindhold og filprocessering. Validering af filer.

14 BizTalk i EasyGo løsningen
Processen i BizTalk Filer opsplittes efter modtager ID. Eksempel: Fil modtages fra NCFC, indeholdende lister til 2 udstedere Filen opsplittes nu i 2 seperate filer – 1 til hver udsteder. Filer samles efter modtager ID. Filer modtages fra 3 operatører til 1 udsteder. Filer samles til 1 fil til udstederen. Filer valideres: Filstruktur (header, body, footer), modtager, afsender. Dato, Filnavne (forrige fil, etc.) Filtyper (TIF, TIC, HGV, HGC, NAT, NAC m.fl. )

15

16 At bygge Service orienteret arkitektur kræver den rigtige organisering
Microsoft SOA Seminar At bygge Service orienteret arkitektur kræver den rigtige organisering København, 8. april 2008

17 Historisk organisering: fra decentralt - via central flaskehals - til decentralt igen
1. generation integration Ad-hoc integration uden strømligning 2. generation integration Strømligning på proprietær EAI 3. generation integration SOA – standardisering og nem tilgang Hver udviklingsteam vælger egen integrationsmekanisme og kæmper med at få disse at fungere Der introduceres en strømlignet integrationsplatform i virksomheden – men udviklingsteams har typisk ikke kompetence i denne og centraliseringen skaber flaskehalse i udvikling Der introduceres en SOA platform – med en Enterprise Service Bus – som er baseret på standarder og hvor alle udviklingsteams kan udvikle og udbyde sine egne services Review – arkitektur team Udv. Team 1 Udv. Team 1 Udv. Team 1 Database integration EAI integration Udv. Team 2 Corba integration Udv. Team 2 Integrations team Udv. Team 2 SOA - ESB

18 Samarbejde og koordinering mellem projekter
Ofte opstår de største udfordringer i forbindelse med portal- og integrationsprojekter I forbindelse med samarbejdet og koordineringen med andre projekter i IT programmet. Dette er velkendt for Netcompany – og vi er glade for at kunne deltage konstruktivt i et IT program hvor vi bidrager til at den samlede løsning er sammenhængende og kommer i mål til tiden. Det er Netcompany’s erfaring at man ved hjælp af en struktureret tilgang og med et fast fokus på at kortlægge og følge afhængigheder mellem projekterne kan få succes med et større IT program. Følgende områder skal være på plads IT program struktur med en masterplan kombineret med en aktiv involvering og koordinering af projekter Arkitektur styringsgruppe med aktiv deltagelse af projekter Fokus på slutprodukter for at sikre fremdrift og konkrete aftaler imellem partnerne. Netcompany arbejder med en konkret teknisk aftalestruktur for grænsesnit og afhængigheder (vedlagt på næste slides) Fleksibilitet i forhold til at kunne løse problemer / udfordringer imellem de deltagende projekter/parter

19 Samarbejde og koordinering mellem projekter
Fokus på slutprodukter og konkrete tekniske aftaler for at sikre fremdrift og præcision I samarbejdet MOSS Project 1 MOSS Project 1 Netcompany projekt Drift Andre projekter Program Kontor funktion som har styr på program milepæle, issues, og risici. Deltagelse af projektledere i ugentlige programmøder Arkitektur kontor for at sikre fokus på tekniske issues, konsistente guidelines og at implementering strømlines ligeså vedligehold og drift Deltagelse af projekt / IT arkitekter i ugentlige arkitektur møder

20 Netcompanys model til styring af afhængigheder mellem flere projekter
I et systemlandskab baseret på en service-orienteret arkitektur vil der være en række afhængigheder mellem projekterne/leverandørerne, som udvikler til arkitekturen Tydelig synliggørelse af afhængighederne er nødvendige for stram styring i programkontoret Nøglen til styringen er sikring gennem fokus på data kontrakter Data kontrakterne defineres for alle services, som identificeres under et design En data kontrakt defineres typisk som et XSD-skema eller en WSDL, hvis der er tale om en web-service. Skemaet definere dataformatet og hvilke data som udveksles i servicekaldet Når skema-definitionerne er afklaret, vil de enkelte projekter kunne udvikle deres interne applikationslogik uden afhængigheder til de øvrige projekter – førend integrationerne selvfølgelig skal kobles sammen og testes

21 Netcompanys model til styring af afhængigheder mellem flere projekter: eksempel
Nødvendige data kontrakter for services er markeret med rød i diagrammet til venstre Selvbetjeningsportalen starter en process, som kræver involvering af både applikation A og B Processen skal implementeres i BPM-systemet, som udstiller en service til at starte processen. En data kontrakt for servicen defineres, så selvbetjeningsportalen kender de krævede data for at starte processen Processen kræver involvering af både applikation A, B og Selvbetjeningsportalen hvor der skal defineres data kontrakter for services til dataudvekslingen Data kontrakterne sikrer, at leverandøerne af applikation A og B, Selvbetjeningsportalen og BPM-systemet kan udvikle deres applikationer uafhængigt af hinanden, da de hver især har aftalt kontrakterne til dataudvekslingen på forhånd Det er typisk portaldesignet som stiller krav til processen og derfor designer denne, mens applikationsleverandørerne bygger de nødvendige services til applikationerne, som processen anvender

22 Vi tror på en samarbejdsmodel som bygger på løbende forankring af resultater…
Ekstern kommunikation og koordinering Styregruppe Projektledelse NC Projektleder Forretning Projektleder IT Team A NC Teamleder Team … Skal sikre at der er tilstrækkelig ejerskab og forankring til at projektet ikke forstyrres eller forsinkes af eksterne afhængigheder eller problemstillinger. Dette implementeres ved forankring af ideer og løsninger i styregruppen kombineret med løbende koordinering af opgaver mod forretningen og IT organisationen. Succeskriterier for effektiv ekstern kommunikation og koordinering... Faste styregruppemøder til gennemgang af projektets fremdrift, samt godkendelse af slutprodukter og milepæle Korrekt sammensætning af styregruppe og/eller udvidet interessentforum så alle væsentlige interessenter løbende holdes orienteret Leveranceansvaret placeres hos én erfaren Netcompany projektleder som arbejder tæt sammen med kundens projektleder(e) Koordinering og afklaring mod forretningen og IT organisationen varetages af henholdvis Forretnings-projektlederen og IT-projektlederen. Begge personer har den nødvendige gennemslagskraft og placering i organisationen til at varetage projektets interesser

23 …samt åben og effektiv kommunikation af fremdrift på alle niveauer
Intern kommunikation og koordinering Styregruppe Projektledelse NC Projektleder Forretning Projektleder IT Team A NC Teamleder Team … Skal sikre at projektet effektivt samarbejder om at levere kvalitet i henhold til aftalt tidsplan og budget, samtidig med at IT projektdeltagerne opnår solid teknisk kompetence på den valgte platform. Dette implementeres gennem effektiv projektstyring, velgennemtænkt ressourceallokering, tæt teamarbejde og åben kommunikation indenfor projektet. Succeskriterier for effektiv intern kommunikation og koordinering... Solide teknikker og værktøjer til opfølgning og kommunikation Veldefinerede ansvarsområder, opgaver og deadlines for alle projektdeltagere både NC og kunde Åben kommunikation af fremdrift og issues: Ugentlige team statusmøder Ugentlige teamleder statusmøde med projektlederne Ugentlige kommunikationsmøder for hele projektet Teamledere med solid metodemæssig og praktisk erfaring med systemimplementering er ansvarlig for at teamet leverer kvalitet til tiden Erfarne og mindre erfarne ressourcer, samarbejder i små teams, om løsningen af ensartede opgaver af forskellig sværhedsgrad – herved sikres ”hands-on” oplæring med kontinuert tilgang til støtte