Thomas Gagné, teknisk chef hos Instream Financial som levererar program- och finanstjänster, tycker att många företag skapar en komplicerad byråkrati kring något som är överflödigt 90 procent av tiden:
- Varför skulle vi byta ut teknik och se till att våra anställdas kunskaper blir föråldrade innan vi hunnit räkna ut vilka fördelar den tidigare, nu förmodat inaktuella tekniken ger?

Det är en svår fråga du som CIO måste ställa dig innan du kan börja förnya verksamheten med SOA. Här kommer åtta andra, som är åtminstone något enklare att svara på.

SOA är en teknikarkitektur. Hur lägger man fram förslaget om en ny teknikarkitektur för verksamheten?

Det gör man inte!
– Prata aldrig med verksamhetssidan om SOA, de bryr sig inte, säger Randy Heffner, analytiker hos Forrester Research. Verksamhetens intresse för SOA är begränsat till om det ger minskade programkostnader eller snabbare system. Att bara skriva om koden till tjänster ger inte den typen av fördelar. För att det ska vara någon idé måste det finnas många överflödiga IT-tillämpningar som kan slås ihop till en enda tjänst. När du ska prata med verksamhetssidan kan det hjälpa att kvantifiera överskotten.

– Jag vet att samma information hanteras av åtminstone 26 olika program i vår IT-miljö, alla för olika syften. Vi tar fram informationen och lagrar den på flera ställen. Bara att bli av med supportkostnaderna för dem vore ett stort framsteg. säger Jeff Gleason, chef för IT-strategi hos försäkringsbolaget Transamerica Life Insurances pensionsavdelning.

Men finns det inte en inbyggd flexibilitet i SOA som kan ge mervärde om det används i verksamhetskritiska processer?
Jo. Blomsterföretaget proflowers.com, exempelvis, har inga överflödiga tillämpningar eller olika avdelningar som skriker efter tjänster. Men genom att dela upp beställningsprocessen i flera tjänster kan varje del isoleras och snabbt förändras vid behov.
– Till exempel för att hantera topparna i blombeställningar som infaller vid storhelger, säger Proflowers CIO Kevin Hall.

När Proflowers bara hade en enda tillämpning för alla beställningar så innebar minsta förändring av processen, eller en ökad transaktionsvolym (som vid Alla hjärtans dag) att man fick ta isär systemet och bygga om det. Nu hanterar en serverfarm topparna i varje del av beställningsprocessen genom att överföra lagringskapacitet till den tjänst som behöver den mest. Systemet är mer förutsägbart och har inte legat nere sedan den tjänsteorienterade processen lanserades 2002.
– Eftersom vi både kan skala horisontellt (fler servrar) och vertikalt (dela upp tjänsterna) behöver jag inte köpa in hårdvara som kan hantera varje tjänst under toppkapacitet. Vi är inte tvungna att svälja hela elefanten i en tugga längre, säger Kevin Hall.

När är SOA ingen bra idé över huvud taget?

Komplexitet är det främsta kravet om man vill införa SOA. Små företag med en enda infrastruktur, exempelvis den från Microsoft, som inte har krav på avancerad integration av tillämpningar är inga bra kandidater. Och stora företag med programinfrastruktur från i stort sett en enda leverantör (60 procent eller mer) bör också tänka sig noga för.
Om man inte behöver kunna göra snabba förändringar i processerna är det ingen mening med att göra om dem så att det blir möjligt.
Hos Owens Corning kommer 75 procent av mjukvaran från SAP. Eftersom företagets produkter tillverkas och säljs på liknande sätt i hela världen har CIO David Johns satsat på att integrera affärsprocesserna i SAP:s system.
– SAP är integrationsstrategin, säger han.

David Johns mål är att alla företagets avdelningar världen över ska ha samma version av SAP på en enda databas. Han övervakar också SAP:s tjänstestrategi, som gör att systemen kan skapa egna SOA för företagets kunder.

Whirlpool har också satsat hårt på SAP och global processintegration. Enligt Ezat Sezer, vice vd och CIO, är det vettigare än att integ­rera tillämpningar:
– Jag behöver inte bry mig om det längre, eftersom jag har lagt ut det på SAP. Jag ser fram emot att se SAP hantera de integrationskrav som jag tidigare fick ta hand om själv.

Att skapa en tjänst innebär mer planering och design än traditionell programutveckling och integration. Hur mycket mer kostar det?

Randy Heffner på Forrester uppskattar att merarbetet med tjänsteorienterad utveckling kan kosta mellan 30 och 100 procent mer på designstadiet, vilket utgör tio procent eller mindre av den totala kostnaden för ett programprojekt. Den extra arbetsinsatsen är nödvändig för att tjänsten ska kunna användas inom många områden på företaget, alla med sina egna speciella behov.

Jeff Gleason på Transamerica säger att tjänster som hanterar försäkringsinbetalningar från kunder behöver kunna levereras på flera sätt – via webbsajt, överföring till bank eller supportcenter – beroende vilka processer de olika affärsenheterna använder. Att förstå hur varje enhet vill använda tjänsten är en del av designarbetet, och viktigt för att få alla att gå med på att använda samma tjänst.

Men är inte folk på verksamhetssidan ofta medvetna om vilket merarbete tjänster innebär? De kanske inte vill betala?

Jeff Gleason har hört ekonomiansvariga säga det minst hundra gånger.
– De menar att om de måste betala för att
ta fram tjänsten så äter det upp de kostnads­mässiga fördelarna. Samtidigt vill de att vi ska hårdkoda integrationen, eftersom de behöver funktionen, säger han.

Gleason påpekar att hans jobb är att hjälpa verksamhetscheferna att inse att tjänster inte är specifika verktyg för specifika projekt, utan verktyg för hela verksamhetens arkitektur.
– Vi skapar en bit infrastruktur som kan återanvändas och förändras. När folk till slut förstår kraven för att göra det slutar de bry sig om de ökade initialkostnaderna, säger han.

Hur mycket återanvändning kan man förvänta sig? Och vad innebär det i reda pengar?

Återanvändningen av tjänster kan vari­era, och beror på hur rigid designen är. Vilket i sin tur beror på kompetens och erfarenhet hos utvecklare och projektledare, menar Randy Heffner. Vilken nivå av arkitekturplanering som ingått i en tjänst spelar också in. Till exempel har en tjänst större kapacitet för återanvändning om den har utvecklats som en del av en större SOA-strategi, med gemensamma utvecklingsmetoder, en central personalgrupp för arkitekturplanering och affärsana­lytiker som kan granska de processer som används och inkorporera de olika affärsenheternas behov i designen av tjänsten.
– Om en tjänst inte är utformad med kunskap om hur alla delar av företaget kan tänkas vilja använda den så det osannolikt att de kommer att vilja ha den, säger Jeff Gleason.

Ännu värre är det att tvingas designa en enstaka tjänst, som kanske innebär att arbetet måste göras om längre fram.
– Då kan man behöva skapa en andra tjänst som komplement till den första eftersom man inte har tid att modifiera den första. Eller bli tvungen att bygga om alltihop eftersom det inte uppfyller kraven längre, säger Gleason.

Om man inte tittar på tjänster ur ett arkitekturperspektiv finns det inget hopp om framtida integration av affärsprocesser eller hantering av affärsprocesser.

Men om en tjänst bara kan återanvändas en enda gång kan det ha en fördelaktig effekt på besparingarna, enligt Heffner. Även om tjänster kräver mer arbete under designfasen innebär återanvändning att det inte blir några kostnader alls för design, kodning och tester nästa gång. Tillsammans utgör dessa steg cirka 40 procent av ett programutvecklingsprojekt.

De som varit med ett tag varnar dock för att det är svårt att förutsäga hur återanvändbara tjänster kommer att bli. Att se till att en tjänst är lagom stor – inte försöker göra för mycket eller gör för lite – är en sann konst.
– Det är en utmaning för oss, säger Howie Miller, vice vd för integrationsarkitektur hos IBM:s internationella IT-grupp.
– Jag skulle säga att 30 procent av våra tillgångar står för 90 procent av vinsten eftersom de har rätt storlek.

  Jag måste kunna påvisa värdet för verksamheten av allt jag gör. Hur balan­serar jag arkitekturplaneringen med behovet av att snabbt ge mervärde?

Arkitekturplanering är tidskrävande. Med tjänsteorienterad utveckling, som förlitar sig på välkända programmeringsprinciper och tillgängliga tekniska standarder (soap, http och så vidare) kan det gå snabbare. Men båda två måste ske parallellt, anser Kurt Wissner, verkställande direktör för företagsarki­tektur och utveckling hos American Electric Power, AEP.
– Folk måste inse fördelarna med SOA ganska snabbt. Det är därför jag gillar att lägga upp det som ett projekt. Annars har man inte något gripbart att visa upp och förklara med.

Även om det hjälper att ha arkitekturpla­nering och kartläggning av processer på plats innan man börjar bygga tjänster (för att öka återanvändningsmöjligheterna) så ger det inga vinster på kort sikt. Det kan vara en nackdel.
– Jag gapade över för mycket på ett företag där jag jobbade tidigare, och misslyckades, säger Wissner.
– Vi gjorde en stor arkitekturplanering som kostade många miljoner dollar och som bara var en beskrivning av vad vi redan hade. Den gav inte mycket mer mervärde än en traditionell integrering, och vi hade inget alls att visa upp. Om man börjar med hela företaget finns det för många risker att misslyckas.

Genom att dela upp företagsplaneringen i mindre delar hos AEP kan Wissner lättare hämta sig efter motgångar.
– Vi har haft en del missar, men har snabbt kunnat rätta till dem eftersom det inte gällde så stora saker. Om man delar upp det i mindre bitar är det lättare att smälta, säger han.

– Affärsprocesser ändras hela tiden, säger Praveen Sharabu, chef för företagsarkitektur hos transportföretaget Con-Way.
– Ingen kan vänta i två år på att man ska
dokumentera allt, då är det redan inaktuellt när man är klar.

Vi har inte råd att bygga en miljon tjänster. Hur vet vi vilka vi ska satsa på, vilka som kommer att ge bäst utdelning på våra investeringar?

Den som är osäker kan börja med de processer som involverar kunder, påverkar vinsten direkt och hanterar problem i verksamheten. En undersökning från Business Performance Management Institute 2006 upptäckte att kundernas växande behov och preferenser är den största drivkraften när man ändrar på verksamhetsprocesser eller för in av nya tillämpningar. På andra plats kommer konkurrensfördelar och på tredje potentiella vinster. Besparingar visade sig ligga långt efter, på fjärde plats.
– Tillämpningar som vänder sig utåt ger det största mervärdet för verksamheten, och det dyker ofta upp krav på att de ska förändras, säger Gartners Daniel Sholler.
– Om man kan förbättra de tillämpningarna med tio procent är det bättre än att förbättra tillämpningar på lägre nivå med 50 procent.

Sholler slår fast att SOA självklart inte behöver innebära ett större mervärde än exempelvis ett bra programpaket.
– Men om det ändå är något man måste bygga själv, då bör man göra det tjänstorienterat.

 Hur kommer SOA att påverka IT-avdelningen?

I ett decentraliserat företag bör IT-avdelningen förbereda sig på strid. SOA driver på centralisering. Det är faktiskt ett krav.
– Man måste ha någon som leder arbetet och en person eller en liten grupp som hanterar arkitekturen och kontrollerar att utvecklarna håller sig till tjänsteutvecklingsmetoderna, säger Eric Falls, systemutvecklare hos Fastenal, som levererar material till byggbranschen.
– Om varje grupp lämnas åt sitt öde kanske de kommer fram till olika sätt att bygga på.

När tjänsteportföljen växer kan utvecklingsprocessen börja likna ett löpande band. Arbetet passerar genom projektgrupper som kan växa eller krympas efter behov. Men när SOA-fabriken väl är i full gång kommer det att krävas fler projektledare, affärsanalytiker och arkitekter så fort utvecklarnas produktivitet ökar.
– Två utvecklare kan göra sex utvecklares jobb. Det innebär att arkitekter och projekt­ledare får springa för att hinna med. Vi får förmodligen 50 procent mer gjort idag än för tre år sedan, säger Randy Hall på Proflowers.

---

Konkurrenskraft, ökad flexibilitet och sänkta kostnader är mål som hägrar. SOA kan ge allt det och mycket mer. Men inte just nu.

SOA är långt från någon beprövad metod. De företag som har lyckats bäst hittills är de som alltid lyckas med tekniska implementationer – stora företag med stora IT-budge­tar som arbetar med teknikbaserad verksamhet (tänk telekomföretag och finansbolag). De brukar också ha gott stöd från ledningen som i sig har bra grepp om tekniken.

Ett bolag som saknar dessa för­delar har det betydligt svårare.
För det första kräver SOA större investeringar och ett mer långsiktigt strategiskt åtagande än CIO kanske tror. Taktikdelen – tjänsteorienterad utveckling – är en teknisk utmaning som går att lösa. Men den strategiska delen – att skapa en arkitektur baserad på en uppsättning tjänster – innebär att CIO måste bygga upp hållbara argument för en gemensam företagsarkitektur, gemensamma utvecklingsmetoder och en centraliserad personalgrupp med projektledare, arkitekter och utvecklare.

För det andra måste vd och företagsledningen bana väg för IT, ända in i företagets viktigaste verksamhetsprocesser. Kunskap om hur dessa processer fungerar, och att få vara en del av arbetet med dem, är ju den stora vinsten med SOA-baserade verksamhetsförändringar.

För företag som inte arbetar med teknik, har stora budgetar eller verksamhetschefer som är välvilligt inställda till CIO och IT, är SOA ingen garanterad väg till förändring av verksam­heten, och ibland inte ens en önskvärd väg.
För små företag, företag som satsat stort på integrerade tillämpningar och företag som redan har stabila strategier för integration av tillämpningar kan man inte prata om ”när” man ska införa SOA, utan bara ”om”.

Svårt att mäta effekten

Som CIO måste du gå försiktigt fram med din SOA-strategi, eftersom de delar som innebär tjänsteutveckling och arkitekturplanering är helt olika men inte oberoende av varandra. De måste övervägas noggrant och utföras parallellt. Tjänster som byggs upp separat, utan hänsyn till företagets arkitektur och affärsmässiga mål, har liten återanvändningspotential (en av de största fördelarna med SOA), och kan även misslyckas direkt. Stora arkitekturplaner kan dra ut på tiden utan att egentligen tillföra något till verksamheten.

Och den flexibilitet man strävar efter är när det kommer till kritan svår att mäta.
–Vi kan inte säga att man ska införa SOA eftersom det kommer att ge mer flexibla system, säger Daniel Sholler, biträdande undersökningschef hos Gartner.
– Det finns inga mått som säger att om man blir mer flexibel så kan man spara x procent. Den två största problemen med SOA är brist på generell kunskap och svårigheten att räkna ut ROI, vad man tjänar på investeringen.

David Johns, CIO hos Owens Corning som tillverkar byggmaterial, håller med.
– Det finns ingen garanterad ROI i teknikstrategier, säger han.
Han menar också att målet aldrig kan vara att utveckla en tjänsteorienterad arkitektur i sig. Målet måste istället vara att öka produk­tiviteten och effektivisera produktionskedjan.
– Vi tittar på tekniska lösningar ur den aspekten, hellre än på vad branschen säger är den nya stora lösningen, säger han.
Thomas Gagné, teknisk chef hos Instream Financial som levererar program- och finanstjänster, tycker att många företag skapar en komplicerad byråkrati kring något som är överflödigt 90 procent av tiden.
– Varför skulle vi byta ut teknik och se till att våra anställdas kunskaper blir föråldrade innan vi hunnit räkna ut vilka fördelar den tidigare, nu förmodat inaktuella tekniken ger?

Det är en svår fråga du som CIO måste ställa dig innan du kan börja förnya verksamheten med SOA.

Ur CIO 4/2007