SOA - serviceorienteret arkitektur - medfører, at systemudviklerne i højere grad skal tænke på den samlede helhed, som deres moduler skal indgå i. Hos DSB har satsningen på SOA gjort det hurtigere at udvikle nye moduler til systemintegration.
Efter et par år med en serviceorienteret arkitektur har DSB Informatik gjort en klar erfaring: Kulturen udgør en større udfordring end teknologien.
Det skyldes, at udviklerne i en serviceorienteret arkitektur udvikler små moduler, der kommunikerer på kryds og tværs med andre moduler.
Dermed mister den enkelte udvikler kontrollen med det, han tidligere har opfattet som “sit” system.
– Det sværeste er at overbevise folk om, at det er en god ide. Det er en stor kulturforandring, når udviklerne bliver nødt til at give slip på noget, og det er ikke sjovt for dem, fortæller udviklingschef Niels Feldthus fra DSB Informatik.
Kommunikerer indbyrdes
DSB’s it-systemer består af en lang række applikationer, der kommunikerer indbyrdes.
Nogle funktioner er implementeret i flere systemer, andre er dannet ved at koble systemerne tæt sammen. Det gør det svært at udvikle noget nyt, fordi en ændring ikke kun får betydning for det system, der ændres, men også for alle de systemer, der er afhængige af det.
Den afhængighed skal SOA-projektet hjælpe med at fjerne.
Nu oprettes der webservices, som stiller integrationstjenester til rådighed for de applikationer, der har brug for dem.
Til at udvikle disse webservices har DSB Informatik oprettet et kompetencecenter for integrationsløsninger.
– Når en forretningsenhed ønsker at få gennemført en integration, henvender den sig til centret. Her sikrer man sig, at alle de relevante spørgsmål bliver stillet. Tidligere var integration ofte et spørgsmål om at forbinde et punkt med et andet, men i SOA kommunikerer mange med mange, siger it-arkitekturchef Erik Haahr, DSB Informatik.
Ny måde at tænke på
Det kræver en ny måde at tænke på hos udviklerne. Som eksempel nævner han en integration med det centrale ERP-system fra SAP.
– Der har SAP-udviklerne skrevet en tjeneste, hvor de stiller nogle data til rådighed. De bruger SAP-funktioner til at filtrere i dataene, så der kun kommer dem, et enkelt system har brug for. Men hvis de nu i stedet stillede alle data til rådighed, kunne mange flere webservices trække på dem – så kunne filtreringen foregå på webservice-laget i stedet for i SAP, forklarer han.
Den bærende teknologi i DSB’s SOA-system er programmeringssproget BPEL (Business Process Execution Language).
Det er et højniveausprog, der fokuserer på forretningsprocesser. Det meste af udviklingen foregår i et grafisk udviklingsværktøj, hvor udviklerne definerer applikationens sammenhænge og forløb. BPEL-koden afvikles af Oracles middlewaresystem Fusion.
Varmer op under forretningen
– Udviklerne bruger BPEL til at udvikle integrationspunkter. Men vi er ved at varme op under forretningen for at få den til at tegne forretningsprocesser i BPML (Business Process Modeling Language, red.). Så er der værktøjer, der direkte kan generere BPEL-kode ud fra tegningerne, siger Erik Haahr.
Foreløbig er kun en enkelt webservice i drift hos DSB.
Den bruges af de systemer, der sender billetter ud til kunderne i breve. Men i løbet af i år venter DSB Informatik, at godt 100 webservices går i drift.
– Vi er stort set tilfredse med at være gået SOA-vejen. Men vi kan godt føle os lidt alene i verden nogle gange – der er ikke mange, der er gået samme vej endnu. Derfor er det også vigtigt for os, at vi har et stærkt partnerskab med vores leverandør. Vi finder mange fejl i denne nye teknologi, for der er ikke så mange andre til at finde dem, siger Niels Feldthus.
Læs mere om SOA i fredagens trykte udgave af Computerworld/CTO.
