När analyshuset Burton Group studerade SOA-implemen­ta­tioner hos 20 företag fann man att hela 50 procent var misslyckade. Och hos 30 procent var satsningen ”varken lyckad eller helt misslyckad”. Varför?

Enligt Burton Groups analyschef Anne Thomas Manes beror problemen främst på folk och processer, inte på teknik. För att lyckas krävs någon form av ”kulturskifte”.

Som arkitekturveteran håller jag med helt. Tekniken är det lättaste! Men om det nu är människornas fel att SOA inte funkar – vad gör vi för fel? Här ska vi gå igenom tio fallgropar. Inte för att skuldbelägga någon, utan för att du som CIO ska kunna göra upp en plan för att angripa ­varje punkt. Då kan du bättra på oddsen betydligt!

1. Lyckas inte förklara affärsvärdet
Ett vanligt misstag är att närma sig SOA från ett rent tekniskt håll. Man lägger för mycket tid och möda på arkitektur, governance och utvärdering av leverantörer (vilket förstås är bra), men glömmer att SOA måste lösa reella verksamhetsproblem (vilket är dåligt). Så massor av tid och pengar går åt till något som ingen är intresserad av.

Rekommendation: Utgå från verkliga verksamhetsproblem! Börja med att visa hur SOA kan lösa dem – sen tar du tekniken. Här är BPM, business process management, en ”killer app”. BPM låter verkamhetsfolk förbättra processer, skära bort dödkött och kapa kostnader utan inblandning av IT-sidan. Dra nytta av det!

2. Underskattar förändringen
Motstånd mot förändring och rädsla för det okända kan döda alla förändringsinitiativ, även SOA-projekt. SOA för med sig massor av förändring till en organisation, särskilt om det saknas en etablerad företagsarkitektur. Om du vill lyckas måste de anställda förstå vad företaget – och de själva – har att vinna på det nya. Utmaningen är att personal på olika nivåer påverkas på olika sätt och att varje behov och bekymmer måste bemötas separat.

Rekommendation: Ta fram en organisatorisk change mana­gement-plan (OCM) som klargör vad som behöver förändras och varför. Här ska framgå vilka steg som behöver tas för att driva ­igenom förändringen och varför den är nödvändig och fördelaktig för företaget och de anställda. Här är jag ett stort fan av Harvards ledarskapsguru John Kotters åttastegsmodell, som beskriver en process för att implementera förändring steg för steg på företaget.

3. Otillräckligt stöd från ledningen
Ditt SOA-initiativ lär knappast lyckas utan ledningens stöd. SOA är ett jätteprojekt som spänner över många avdelningar och system. Då krävs en stark projektledare med tydligt mandat – och tid att fokusera fullt ut på SOA.

Rekommendation: Den sponsrande ledaren ska helst vara en högt uppsatt affärsperson som har mycket att vinna på SOA. Låt affären äga och driva projektportföljen. Ledaren ska kunna flytta berg – och vara någon som tydligt bevisat sin ledarförmåga.

4. Snålheten bedrar visheten
Vissa företag försöker skapa SOA med begränsad budget. Det är en dålig idé. Förutom all ”mellanmjukvara” krävs jätteinvesteringar i governanceverktyg, utbildning, infrastruktur, säkerhet och konsulter. Snåla inte heller med livscykelverktygen, annars blir felsökning som att leta nålar i en höstack.

Rekommendation: Skapa en SOA-roadmap med en projektportfölj och en vision som visar de långsiktiga fördelarna för f­öretaget. Ta fram ett ekonomiskt existensberättigande för hela SOA-initiativet och visa på ROI eller andra viktiga nyckeltal. Så länge du har ett bra business case borde det finnas pengar att äska. För den som vill spara pengar finns flera bra open source-produkter: MuleSource, WSO2 och Red Hat har en hel verktygslåda för utveckling, livscykelhantering och integration. Push2Test har en för SOA-testning och CentraSite för registry och repository.

5. Brist på SOA-kompetens
För ett SOA-projekt behövs SOA-arkitekter, BPM-modellerare, administratörer för verktygen i stacken, dataarkitekter med mera. Och de är inte billiga.

Men att försöka implementera SOA utan SOA-erfaret folk är ett misstag modell större. SOA påverkar hela IT-avdelningen, inklusive testning, infrastruktur och säkerhet. Och verksamhetspersonalen måste utbildas i process­förbättring, och kanske även på BPM-verktygen.

Rekommendation:Ta fram en omfattande utbildnings- och resursplan, och ta med den från första början i penga­äskan och business case. Försök att äska så få gånger som möjligt, och få så mycket som möjligt från början. Annars kan ledningen börja se SOA som en pengasugare som ständigt vill ha mer.

6. Dålig projekthantering
I slutändan handlar allt om hur bra företaget hanterar projekt. Projektledarna måste hålla koll på omfattning och risker, få alla att hålla deadlines och kommunicera bra och relevant på alla nivåer i organisationen. Behovsinventering är en viktig bit, liksom kampen mot analysförlamning. Om ditt företag har svårt att leverera vanliga projekt är det dubbelt så svårt med SOA.

Rekommendation: Sätt dina bästa projektledare på SOA. Eller sök efter nya stjärnor. Få tag i folk som har riktigt stora, framgångsrika förändringsprojekt på CV:t. Och som också är tillräckligt tekniskt bevandrade för att begripa SOA på konceptnivå.

7. Tänker på SOA som ett projekt
Många företag är naiva och tror att SOA är som vilket projekt som helst. Men SOA är en arkitektur och når inte sin potential förrän företaget lever upp till grundprinciperna om tjänsteorientering. Det ställer i sin tur höga krav på sam­arbete. En ­affärstjänst kanske byggs av en SOA-arkitekt, en utvecklare, en dataarkitekt, en nätverksarkitekt och en säkerhetsspecialist. Dessutom finns specialisering inom stackens lager, på användargränssnitt, BPM, datatjänster, affärsregler, tjänstebussen, etcetera. Och alla de kanske jobbar på samma tjänst samtidigt.

Rekommendation: En IT-avdelning av standardsnitt är inte effektiv med SOA. En matrisorganisation i öppet kontorslandskap är att föredra, så att alla kan jobba smart ihop. Sätt upp whiteboards överallt. Och minimera antalet avstämningsmöten.

8. Underskattar komplexiteten
Som koncept är SOA inte svårt att förstå, men det är svårt att implementera. Det sköna är den enkelhet det kan erbjuda slutanvändarna, genom att integrera diverse ­system så att de ser ut som en enda tillämpning. Men det blir mycket mer komplext att bygga och hantera mjukvara. Det är ingen drag-drop-utveckling – SOA kräver att man följer standarder och best practice och förstår dess vision. Till det kommer säkerheten, som måste vägas in i arkitekturen från start. I efterhand är det svårt att fixa.

Rekommendation: Räkna med förhinder! Bygg i tid, för du kommer att få handskas med en hel del integrationsproblem, på grund av din kod och på grund av verktygen – produkterna är långt ifrån mogna. Håll förväntningarna på en realistisk nivå, och gapa inte över för mycket. Börja i liten skala, leverera värde ofta och bygg in säkerhet från början – inga efterkonstruktioner!

9. Misslyckad SOA-styrning
Styrning och governance är fula ord för många. Tala om SOA-hantering eller -ledning så kanske de ryser mindre! För att SOA ska kunna leverera sina fördelar (återanvändning, flexibilitet, agilititet) måste teamet följa de riktlinjer företaget sätter upp, låt oss kalla det ”designstyrning”. Utan den får du förmodligen ingen SOA utan bara ett gäng web services. I så fall kan du säga adjö till ROI, du kommer att få bygga allt från scratch hela tiden. Äkta SOA blir mer och mer lönsamt över tid. Till slut går utvecklingen över från att huvudsakligen bygga tjänster till att använda tjänster. Sedan har du ”runtime-styrning” – där du proaktivt ser över din SOA-miljö. Du håller koll på vilka tjänster som används, driver igenom policy och SLA:er, felsöker och gör prestandaanalyser. Tro inte att du är klar när du rullar ut. Att sköta en distribuerad miljö är ett försvarligt arbete.

Rekommendation: Behandla styrningen: som ett fullt finansierat projekt som löper parallellt med SOA-införandet. Du bör ha en grupp (vanligtvis inom EA) som jobbar särskilt med det här, med sin egen roadmap och långsiktiga vision. Försök inte införa styrning över en natt. Det är en lång resa – det tar flera år att nå verklig mognad. Men allt eftersom styrningen mognar, mognar också SOA. Investera i ett register och verktyg för repository och tjänstehantering. Du behöver också nya verktyg för att testa styrningen.

10. Låter leverantörer driva arkitekturen
Ron Schmelzer på Zapthink myntade uttrycket VDA för vendor-driven architecture, leverantörsdriven arkitektur – något som kan leda till katastrof. Leverantörernas mål är ju att sälja på dig så mycket som möjligt. Men ditt mål är en framgångsrik SOA-implementation, som levererar mesta möjliga till minsta möjliga kostnad. Alltid en intresse­konflikt.

Leverantörerna lovar perfekt integration om du köper alla verktyg från dem. Men tänk på att deras portföljer ofta är uppbyggda via uppköp. Därför kan de sällan leverera nämnvärt bättre integration än verktyg från olika företag.

Rekommendation: Var klar över vad du behöver innan du pratar med leverantörer. Och utvärdera dem noga. När det står mellan ett fåtal leverantörer, låt dem komma till dig och visa proof-of-concept där du står för kravbilden. Då kan de inte längre gömma sig bakom Powerpoint. Och läs på – läs vad folk skriver på nätet, prata med konsulter som jobbar med verktygen, med kolleger som infört SOA och med referenskunder. Ta inga genvägar här, för du får leva länge med de beslut du fattar. ]

Artikeln publicerad i CIO 3 2009
Översättning Johan Wikberg