Inledning
Innan vi börjar fundera på orsakerna till misslyckade SOA-insatser, låt oss definiera vad SOA är.
SOA (service-oriented architecture) är i grunden en samling tjänster som kommunicerar med varandra. Kommunikationen kan antingen handla om enkel datapassage eller om att två eller flera tjänster samordnar någon aktivitet. Samtidigt behövs något sätt att ansluta tjänsterna till varandra. I de flesta fall är anslutningstekniken för SOA den som används för Web Services. SOA kan också definieras som en löst kopplad arkitektur som är utformad för att tillgodose organisationens affärsbehov.
En av nycklarna till SOA-arkitekturen är att interaktioner sker med löst kopplade tjänster som fungerar oberoende av varandra. SOA-arkitekturen möjliggör återanvändning av tjänster, vilket gör det onödigt att börja om från början när uppgraderingar och andra modifieringar behövs. Detta är en fördel för företag som söker sätt att spara tid och pengar.
Vad är det då som gör att de flesta SOA-misslyckanden oftare beror på mänskliga problem än på tekniska problem?
Människor tenderar att misslyckas med att förklara SOA:s affärsvärde
SOA måste lösa verkliga affärsproblem, men väldigt ofta närmar sig IT-folk SOA enbart ur ett tekniskt perspektiv. De lägger ner mycket tid och kraft på arkitektur, styrning och leverantörsbedömningar, men glömmer vilka problem SOA ska lösa. Mycket tid och pengar går åt till att bygga upp arkitekturen, men när den väl är klar är det ingen i verksamheten som förstår fördelarna eller är intresserad av tekniken.
Det här är precis vad vi på EvergoPartners har stött på flera gånger i arbetet med våra företagskunder – för mycket kraft läggs på att fokusera på specifik teknik, istället för att förstå vilket värde det skulle generera för verksamheten. Vi rekommenderar därför att man börjar med att visa verksamheten hur SOA skulle lösa ett visst affärsproblem och sedan går vidare till att ta itu med teknikfrågor.
Effekterna av organisatoriska förändringar underskattas
Som med alla förändringsinitiativ är motstånd mot förändring en projektdödare. SOA medför enorma mängder förändringar för en organisation. Rädslan för det okända är den största orsaken till förändringsmotstånd. Människor måste förstå varför det är bra för både dem och företaget att förändra sitt sätt att arbeta. Utmaningen är att människor på olika nivåer inom organisationen påverkas på olika sätt. Varje nivå i verksamheten har problem som måste hanteras och lösas på individuell basis.
En av lösningarna på en sådan utmaning kan vara att anlita en extern expert på förändringshantering för att hjälpa ledningsgruppen för SOA-initiativet att hantera förändringar.
Människor försöker göra SOA ”budgetmässigt”, utan att ha den kompetens som krävs för att leverera det
Det skulle vara mycket svårt att implementera SOA med begränsade budgetar. Förutom all middleware som krävs finns det enorma investeringar i styrverktyg, utbildning, konsulttjänster, infrastruktur och säkerhet.
Att hantera SOA i en produktionsmiljö är en utmaning på grund av dess distribuerade och löst kopplade natur. Vissa företag försöker ta sig an SOA-projekt utan någon extern hjälp för att spara in på de höga konsultkostnaderna. Det krävs många specialiserade roller och kompetensuppsättningar som förmodligen inte finns inom organisationen. Du behöver SOA-arkitekter, modellerare av affärsprocesser, administratörer av verktygen, dataarkitekter och många andra kompetenser. Dessa positioner är inte billiga. Om du inte har många personer med erfarenhet av SOA kan det vara ett recept på katastrof att försöka göra detta utan hjälp utifrån för att spara pengar.
För att få de pengar som behövs måste du skapa en finansiell motivering för hela SOA-initiativet och visa de viktigaste finansiella indikatorerna för företaget. Visa en vision av de långsiktiga fördelar som SOA kommer att ge företaget. Om du bygger ett tillräckligt bra business case bör det finnas tillräckligt med pengar för att finansiera initiativet. För att minska de totala kostnaderna för din SOA-implementering finns det också flera bra open source-produkter tillgängliga.
Avsaknad av en sund SOA-styrning
SOA utlovar obegränsad smidighet och organisatorisk flexibilitet. För att uppnå dessa fördelar krävs dock att man kan hantera SOA-miljön på ett effektivt sätt inom hela företaget.
SOA-styrning ger möjlighet att mäta avkastning och formulera det pågående värdet av SOA på alla nivåer inom organisationen för att uppmuntra adoption och inköp. Det gör att du kan se vilka tjänster som används, genomdriva policyer och SLA:er, felsöka, analysera prestanda och hantera alla tillgångar. När SOA-användningen ökar kan SOA-tillgångarna dessutom bli ohanterliga utan styrning, och återanvändningen av tjänster minskar till förmån för anpassad utveckling. Ännu värre är att ändringar kommer att göras i dina befintliga tjänster som bryter mot andra affärsprocesser.
För att mildra ovanstående bör du behandla SOA-styrningen som ett initiativ som löper parallellt med din SOA-implementering. Det bör finnas ett särskilt team inom Enterprise Architecture med en egen färdplan och en långsiktig vision. Det kommer att ta tid att nå en hög mognadsgrad. I takt med att styrningen mognar, mognar också din SOA.
Inlåsning av leverantörer
SOA handlar om vad din organisation behöver – inte vad en leverantör säger att du behöver. Att förlita sig för mycket på leverantörer kan vara en katastrof. Leverantörernas mål är att sälja så mycket som möjligt till dig. Ditt mål är att implementera SOA framgångsrikt och att ge ditt företag maximala fördelar till minimal kostnad. Glöm inte att dina behov inte bara är en lista över system som måste fungera tillsammans – din lösning måste också göra saker enklare för dina utvecklare och användare.
Det är vår (EvergoPartners) erfarenhet att vissa av våra företagskunder fortfarande använder sina fullt fungerande äldre system på ett framgångsrikt sätt. Att ersätta dem med bara en ”rätt” lösning och att binda sig till bara en leverantör kan vara ett stort misstag som kan leda till onödiga kostnader på kort och lång sikt.
