Video: SOA giver Danske Bank penge på bankbogen

Karsten Fogh Ho-Lanng, Teknologidirektør i NNIT A/S

Nemlig, lige efter bogen! Hold fokus på forretningen, og hav en overordnet strategi så det langsigtede billede også er etableret. SOA handler om evnen til at anvende IT til at have de rigtige processer og de rigtige varer på hylderne. Intet mindre, for det er alfa omega at udgangspunktet er forretningen, ikke en ide om at skabe en fleksibel platform for platformens skyld.

Men samtidig understreger strategen Peter Schleidt jo også, at den overordnede vision skal være i orden, og at det er et langt sejt træk at komme igennem. Det kræver mange års målrettet arbejde at nå dertil. Banker har i europæisk perspektiv ry for at være lidt (for ikke at sige temmelig) konservative, men fremsynet i Danske Bank er eksempel til efterfølgelse i den samlede europæiske banksektor.

Danske Bank minder os om, at det er med SOA som med mange andre IT-projekter: Det kan godt være, at mulighederne nærmest er uendelige, men det virker altså kun hvis man "gør det rigtigt".

Anders Quitzau, innovationschef hos IBM Danmark.

Peter Schleidts interview viser, at der klart er noget at hente på bundlinien, når man har implementeret en SOA strategi. Men er SOA noget alle bør overveje? Ja, overveje, men ikke nødvendigvis implementere. Jeg mener, der er en række spørgsmål, man skal kunne nikke til, når investeringen skal vurderes:

- har virksomheden mange samhandelspartnere eller skiftes de ofte ud?
- har man mange special udviklede applikation og integrationsflader?
- Er der stor dynamik i virksomhedens produkt- og serviceportefølje?
- Ændrer virksomheden ofte forretningsgange?
- Konkurrerer virksomheden på 'first-mover' parameteren og er en væsentlig støtte til denne konkurrence parameter?

Er en eller flere af disse kriterier opfyldt - og er de forretningsmæssigt kritiske, så kan en SOA-strategi meget sandsynligt være den rigtige.

I dag er SOA nok først og fremmest noget for de større virksomheder, men efterhånden som både de tekniske og brancheorienterede datastandarder falder på plads, vil SOA bevæge sig ned i markedet.

Efter min mening vil SOA derfor ændre det konkurrencemæssige landskab. Hvor velkonsoliderede organisationer kunne differentiere sig gennem store IT-investeringer, vil SOA betyde, at 'first-mover' fordelen i fremtiden vil blive væsentligt kortere. IT har været og er i nogle brancher en konkurrence 'buffer', men nu flyttes konkurrencen længere ud i værdikæden, hvor det er innovation af forretningsmodel, produkter og services, der skal fokuseres på - og den kendte undskyldning 'det kan ikke lade sig gøre pga. vores IT-systemer' vil blive endnu dårligere.

Der er nogen, som mener at SOA vil få samme markedsmæssige betydning som internettet i sin tid. Det glæder jeg mig til, for så går vi en meget spændende tid i møde.

Jan Horsager, redaktør på Computerworld.

Tankegangen om service orienteret arkitektur (SOA) rummer hele essensen i den vision om digital virksomhed, som vi dyrker her på Computerworld.

Løst koblede softwarekomponenter er byggeklodserne til at skabe en hvilken som helst digital proces og dermed digital virksomhed. De tre bogstaver rummer løftet om håndtering af både den uendelige kompleksitet i moderne databehandling og den fuldt integrerede og intuitive brugergrænseflade.

Derfor er også risiko for varm luft i store mængder. Både hos leverandører og i store projekter risikerer SOA-begrebet at blive det gulvtæppe, som manglende fokus og svar kan fejes ind under.

Derfor er det vigtigt hele tiden at fokusere på og kommunikere, hvad formålet med den service orienterede arkitektur er - i Danske Bank at kunne håndtere kundens samlede engagement - og hvor udfordringerne ligger - for eksempel risikoen for høje CPU-omkostninger og lange svartider, hvis komponentene ikke udnyttes effektivt, som Peter Schleidt taler om.

Henrik Hansen, administrerende direktør i i-Seven.

At indføre SOA som applikationsarkitektur er ikke ukompliceret. For en virksomhed af Danske Banks størrelse, som har den rette økonomi og de nødvendige ressourcer, er der ingen tvivl om at anvendelsen af SOA giver nogle store konkurrencemæssige fordele - ikke mindst i forhold til en evt. opkøbs- og fusionsstrategi.

Men for den mindre virksomhed, med begrænset økonomi og ressourcer, kan det være svært at komme i gang med SOA. For rent umiddelbart er det svært at få øje på fordelene set fra brugernes side. Løst koblede systemer og abstraktion af data og logik giver ikke umiddelbart nogle fordele for slutbrugeren. Der hvor den virkelige fordel kommer til udtryk er når vi anvender SOA til at integrere de forskellige systemer og understøtte forretningsprocesserne. I stedet for at diskutere om man skal vælge Microsoft, IBM, Open Source eller noget helt andet, så lad os tage udgangspunkt i de systemer, som allerede findes i virksomheden. Lad os anvende det økonomisystem, der passer bedst, den CRM løsning der løser sælgernes behov, det HR-system de bedst kan leve med i Personaleafdelingen osv. Lad os i stedet for fokusere på at understøtte de processer, som findes i virksomheden optimalt og få systemerne til at spille sammen på en bedre og mere fleksibel måde.

Det er her SOA med fordel kan anvendes - også i mindre virksomheder. Med SOA er det nu engang heller ikke sådan at det er enten eller. Man kan anvende SOA i de situationer hvor det giver mening og fortsætte med at integrere systemerne på traditionel vis i andre sammenhænge - det ene udelukker ikke det andet. Men moralen er:

Start småt - tænk stort.

Jeg synes også det er værd at minde om SOA kan gøre virksomheden mere løst koblet til service providers, f.eks. når software as a service (SaS) vinder mere indpas. Det vil primært være services der ligger udenfor virksomhedens kernekompetencer der er relevante her.

Som eksempel kan nævnes muligheden for at knytte sin udbyder af web/video konferencer til sig via SOA og på den måde integrere disse funktioner i forretningsprocesserne.

Det giver mulighed for at skifte udbyder relativt nemt, samt at integrere de bedste funktioner fra flere udbydere.

Så skal vi måske også lige huske det altoverskyggende nøgleord når det gælder SOA: Governance!

Der er talrige eksempler på SOA "gone bad" pga. manglende eller mangelfuld governance. Uden stram styring bliver SOA en omkostning og en hæmsko, bl.a. fordi man risikerer ikke at realisere det indforståede genbrugspotentiale.

Nye SOA "brugere" kan med fordel starte med at kigge på SOA med Event Driven Architecture (EDA), som er en mere aktiv og dynamisk arkitektur, som dog kræver endnu større overblik og endnu skrappere governance. Det giver en mere "intelligent" SOA, som man ligeså godt kan starte med.

Når det er sagt så... Viva SOA!

Jeg er enig i mange af de betragtningerne, herunder fordele og farer, i Peters og de øvrige indlægsholder femhæver.

SOA er for mig først og fremmest en platform til at sikre og gøre forretningsintegration nemmere, herunder såvel både integrationen mellem interne systemer (skabt af forskellige lokale behov og/eller opkøb af nye selskaber mv.) og integrationen til eksterne forretninspartners systemer (leverandører og kunder). Kort sagt skabe værdi i "hele værdikæden".

Grundlæggende er det en metode til styring af nutidens markeds- og konkurrencevilkår, som ER højere hastighed og større kompleksistet. Eller mere populært sagt at gøre det nemmere for "forretningsbrugerne" at skabe værdi fra IT, som ofte er fanget i en gordisk knude, fordi påtrods af kompleksisteten stigere, så er der også et rimeligt krav og behov for at gøre anvendelsen af IT mere tilgængelig og intuitiv - "making it simple and effective".

Og det var nemmere i "gamle dage" med mainframes, som Peter omtaler, hvor alt nærmest "by design" var integreret (i det mindste internt), fordi vi alle var koblet til den samme hub. Men de tider er også, som Peter siger, forbi. Og en af SOA vigtigste opgaver er netop at kompensere for "gamle tider" og gøre kompleksisteten "under overfladen" usynlig for lægmand.

Kort sagt skal alle kunne "køre IT systemerne" uden også at skulle være "mekaniker-uddannet", som det har været nødvendigt med den stigende kompleksistet op igennem 90-erne med krav om omfattende forandringsledelse og IT-superbrugere osv. - "højstdannet" medarbejdere, som kunne overskue og forstå (ville have skrevet "forklaret" til menig mand, men det ses sjældner succesfuldt) forretningsprocesserne/-systemer fra væg-til-væg, herunder meget afgørende at kunne forudse konsekvenser og effekter, fordi det kan koste meget dyrt i ekstra omkostninger og/eller tabt omsætning (kunder og muligheder).

Veldefineret services med "tilpasset og gennemsigtige forretningsprocesser" gør dette muligt at undgå dette - og det er nødvendigt og har stor værdi. Ikke kun i private virksomheder, men også indenfor den offentlige i forhold til alle borgerne som det vil være helt umuligt at træne og give forandringsstyring i "tunge underliggende systemer" - så "self service" er kommet for at blive.

SOA hjælper også til at gøre "nødvendige forandringer" i den underliggende kompleksistet nemmere at håndtere (udskifte), fordi det blivet en beskyttende lag. Fordi tidligere, og især de sidste 10 år med med mange udskiftninger af ERP-systemer, var det også "vejen frem" at udskifte alle de underliggende systemer på een gang, fordi andet nogle gange ikke var muligt. Hvilket gav store indirekte omkostninger til uddannelse og forandringsledelse, som kan undgås eller stærkt reduceres med SOA. Når de underliggende systemer blive "usynglige" er det nemmere at udskifte dem enkeltvis.

Og mange af de "store revolutioner" af IT i virksomhederne er ikke altid værd at skrive hjem om. De mest succesfulde forandringer/forbedringer er dem, som sker enkelt og igennem evolution. Kort sagt: Til at overskue og håndtere.

Så udover at skabe adgang til en masse forretningsmuligheder (opportunity costs) er SOA er godt et eksempel på, hvordan "costs in IT can take cost out of doing business" fordi især de indirekte omkostninger reduceret mærkbart.

Her på falderabet inden og "I køber SOA" vil jeg fremhæve den største og mest hyppige risiko, som jeg ser; fordi "SOA kan ikke købes - det skal bygges". Og ordentlig håndværk tager (lidt) tid. Jeg har set mange eksempler på, at en hurtig prototype er blevet skabt, og senere blevet solgt til topledelsen (i en iver på at imponere) som den "færdige løsning".

Prototyper er utrolige vigtige til at påvise/synliggøre en effekt og give nyttig viden og (konkret) input til en business case. Men mange "piloter" får lov at flyve videre i "produktion", og de, især hvis der kommer mange af dem, ender med at blive en stor byrde med et højt behov for brandslukning samt vedligeholdelsesomkostninger, der skaber en barriere for nye (nødvendige) investeringer og udvikling.

Piloter skal give læring og indsigt, hvorefter de skal "rives ned igen" for at give plads til at bygge den rigtige løsning. SÅ gå ikke igang uden, at der også er plads til (tid og penge) og forståelse for at bygger en langtrækkende og bæredygtig platform. Lidt ligesom sidst i 90'erne, hvor "vi alle have travlt med ombord på det sidste Internet-tog inden det forlod parronen". Mange af de virksomheder, som klarer sig bedst idag og er mest agile, er de virksomhederne, som valgte eller var tvunget til at "blive tilbage" for at "lægge skinnerne til fremtidens togdrift", f.eks. ved at istedet at bruge tiden på at bygge et vellykket ERP system.

Danske Bank kunne være et godt eksempel dette, men jeg kender også andre eksempler, som jeg har været heldige at have været i kontakt med, som beviser at "rettidig omhu" virker. Også uden for Mærsk, selvom det måske er smuttet lidt for dem den seneste tid (ifølge skriverierne i pressen

God fornøjelse med at "træde de rigtige skridt med SOA" - simpel IT (forretningsunderstøttelse) bliver lige så nødvendigt som strøm - og uanset hvad nogle lærde tror: IT - and now SOA - DO MATTER

med al respekt, jeg er lidt forvirret omkring fordelene ved koncernstrategien en "en fælles platform" og de fordele der ligger i den konkrete IT-arkitektur.
Den besparelse Peter omtaler i forbindelse med Sampo bank - følger den at SOA eller af koncernstrategien? Den potentielle besparelse der ligger i komponentgenbrug i SOA, er vel ikke direkte den samme som de stordrift fordele der kan opnås ved at kører flere banker på samme system.
Og hvordan kan "en platform" referere til integrationsarkitekturen når den gjorde at strategien "en platform" kunne bibeholdes?