Who´s afraid of the Big, Bad SOA?

Who´s afraid of the Big, Bad SOA?

Alle er enige om at det ikke finnes konkurrerende strategier på markedet. SOA er veien og lyset. Samtidig er usikkerheten tilsvarende stor. SOA er så ny at folk er redde for å brenne seg.

Denne kommentaren handler ikke om hva SOA - på langspråk Tjenesteorientert Integrasjonsarkitektur - er. Hundre artikler har forsøkt å avgrense og forklare de bærende konseptene, blant annet modularisering, tjenester som lar seg dele og løse koblinger. Nei, temaet her er usikkerheten: SOA ble ikke født i går, konseptet har fire-fem år på baken. Hvorfor er folk likevel redde?

Svaret er at SOA ikke (bare) er et teknisk konsept. Ved første øyekast ser det ut som en it-greie, men i virkeligheten er utfordringene av organisasjonsmessig og forretningsmessig karakter.

For det første må vi kvitte oss med puristene, de som liker å dele verden i to – SOA eller ikke-SOA. SOA er et kontinuum fordi det inneholder gammelt og nytt. Dette er et hovedpoeng. Større bedrifter kan ikke skifte ut alle sine applikasjoner med nye, det lar seg bare ikke gjøre. Det er her SOAs store styrke ligger – å fornye gradvis. Evolusjon, ikke revolusjon. Å soafisere et applikasjonslandskap tar mange år.

Likevel, det kreves en betydelig investering i programvare og kompetanse for å komme i gang. Sånn er det bestandig, det er ikke noe som heter gratis lunsj. Det må anskaffes og bygges et SOA-fundament. Det er ikke noe du kan kjøpe i butikken, hver SOA-installasjon er kundetilpasset og dermed forskjellig.

Flaggbærere

Det forutsetter dessuten at noen går foran og bærer flagget. Ingen andre enn sterke it-ledere vil ta på seg denne rollen. Det forutsetter også at investeringen blir godkjent av toppledelsen eller styret. SOA lukter av "grand plan", en ny begynnelse og store ambisjoner. Mange ledere er immune for sånt. Investeringer i arkitektur pleier å bli omfattet med skepsis. Ledere er opptatt av ny funksjonalitet som de tror vil tiltrekke kunder, ikke av fundamentering.

Her ligger usikkerheten på lur: Får vi lov? Hvem tør stikke ut nakken og fremme forslaget? Hvem får blemmen hvis det går galt?

Ett av de bærende konseptene bak SOA er gjenbruk. Tjenester og komponenter lages eller kjøpes for å bli brukt i flere sammenhenger. Det skaper synergi og reduserer kostnadene. Baksiden av denne medaljen er sentralisert styring. Skal gjenbruk kunne praktiseres, må det finnes en felles enhet, ofte kalt en arkitekturgruppe, som skal tenke ut hvilke tjenester det er hensiktsmessig å bruke hvor. Det vil øke it-avdelingens makt å arbeide ut fra denne opphøyede posisjonen. Forretningsenhetene er ofte bare måtelig begeistret for tanken, det smaker av å innordne seg, å gi slipp på en del av selvbestemmelsen. Sameie er notorisk konfliktskapende. Det forutsetter at folk er villige til å gå i takt. Forretningsenhetene liker bedre å ha sine egne applikasjoner som de slipper å dele med andre.

Sterk vilje

Skal SOA lykkes, må det derfor finnes en sterk vilje som sier at selvstendighet er vel og bra, men automatiserte prosesser og kostnadsdeling er bedre. Avdelingene i en bedrift er aldri selvstendige, de henger sammen både her og der i tverrgående prosesser. De må levere data til hverandre. Data av høy kvalitet, ellers blir mottageren nødt til å spandere mye manuell "vaskeinnsats". En forutsetning for SOA er at denne sterke viljen finnes og at den blir respektert. Jo bedre avdelingene samarbeider desto lettere er det for SOA-tanken å slå rot. Det er derfor SOA en organisasjonsmessig, ikke (bare) en teknisk utfordring.

Et tredje usikkerhetsmoment dreier seg om "granularitet". Hvor store skal tjenestene være? Er tjeneste bare et nytt navn på applikasjon? Da blir mulighetene til gjenbruk kraftig beskåret. Eller skal helheten stykkes opp i hundrevis og tusenvis av biter? Da blir gjenbruk mye lettere, men da må man holde orden på et komponentbibliotek av dimensjoner. Og ha håndverkere som er i stand til å velge rett komponent. Uten et betydelig innslag av pragmatisme kan man snuble allerede her.

Sterk vilje til samordning. Få forretningsenhetene med på å bruke penger på arkitektur istedenfor funksjonalitet. Ha en pragmatisk holdning til virkemidlene. Tre krevende forutsetninger. Og da har jeg ennå ikke begynt å snakke om å velge.

hidas@online.no

Les om:

Enterprise