Forretningen skal understøtte SOA

Så lad os dog få slået salgsfrasen 'SOA understøtter din forretning' ihjel. SOA understøtter ikke forretningen i højere grad end nogen som helst anden brug af IT.

Det SOA gør, er at give muligheden for, at skabe en arkitektur der bedre understøtter forretningen. Pointen er, at SOA ikke giver noget som helst gratis. For at høste gevinsten af SOA kræver det, ud over at man kender sit mål, både tid og penge. Og netop her er den største barriere, som for alle andre IT-initiativer; PENGE. SOA tilføjer endda yderligere til denne kompleksitet, da ofte ikke er den der skal betale der høster gevinsten.

Dette er dog set ud fra et IT perspektiv, hvor det enkelte projekt ofte vil blive pålagt en ekstra udgift, hvor det er en anden part der høster gevinsten. Så kan man have nok så fine EA-principper, men hvis disse ikke er understøttet af forretningsmæssige begrundelser, er de meget svære at implementere i de enkelte projekter.

For at dette kan lade sig gøre skal 'forretningen understøtte SOA'. Har forretningen f.eks. en målsætning om at integrere sin suply chain IT-infrastruktur med X antal partnere, for derved at opnå Y og Z der giver virksomheden en ROI på X antal kroner, har man der kan konkretiseres i IT-strategien.

Så for at SOA kan understøtte forretningen, skal forretningen altså understøtte SOA. Et dejligt paradoks der konstant giver problemer når projekter under SOA-fanen skal implementeres. Problemet er, at den intet arkitekturparadigme kan opfylde forretningens krav, hvis ikke forretningen sikre at det er muligt at arbejde på tværs af de enkelte projekter.

Gevinsten af SOA kommer (som alle andre paradigmer der fokusere på genbrug) ikke i de første projekter. Det er op til forretningen at sikre at projekterne kan 'leve' videre over de enkelte projekter således som det altid har været målet med Enterprise Architecture (EA).

Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

"Dette er dog set ud fra et IT perspektiv, hvor det enkelte projekt ofte vil blive pålagt en ekstra udgift, hvor det er en anden part der høster gevinsten. Så kan man have nok så fine EA-principper, men hvis disse ikke er understøttet af forretningsmæssige begrundelser, er de meget svære at implementere i de enkelte projekter"

Enig. Og heri ligger måske den største udfordring for arkitekterne. Dels at sikre at forretningen forstår de overordnede principper og fordele ved SOA-investeringen generelt, og dels sikre at realiseringen af de delelementer der pålægges det enkelte projekt, også har en synlig fordel for dette (på kort eller længere sigt).

Kan der slet ikke kommunikeres nogle meningsfyldte synergier imellem de to, kan det være meget vanskeligt at opnå den helt store opbakning.

"Gevinsten af SOA kommer (som alle andre paradigmer der fokusere på genbrug) ikke i de første projekter. Det er op til forretningen at sikre at projekterne kan "leve" videre over de enkelte projekter således som det altid har været målet med Enterprise Architecture (EA)."

Ja, og derfor skal EA og herunder SOA, håndteres som et strategisk anliggende, som hvert eneste IT-projekt holdes op imod, for at sikre realisering af de langsigtede mål.

Forudsætning for den nødvendige ledelsesopbakning er, at det tydeligt kan anskueliggøres hvorfor og hvordan SOA bidrager til opfyldelse af forretningens mål. Og lige præcis her kan det være overordentlig vanskelig at understøtte argumentationen med konkrete tal, idet det som artikelforfatteren indleder med, "Det SOA gør, er at give muligheden for, at skabe en arkitektur der bedre understøtter forretningen", er igennem evnen til at udnytte arkitekturen, at gevinsterne høstes. Derfor er så vigtigt, at IT og forretning ser udfordringen som et fælles anliggende.

Mvh Holger Sørensen, funktionschef i PEN-SAM

  • 0
  • 0
Log ind eller Opret konto for at kommentere