SOA i verkligheten

Är Service Oriented Architecture (SOA) bara tomma ord? Eller finns det ett värde för din organisation i att sträva efter en tjänsteorienterad arkitektur?

Se våra utbildningar inom SOA

För att finna svaret på det måste man börja med att titta på vad SOA egentligen är och hur ens organisation kan tjäna på SOA. Dessutom - vad krävs för att skapa en framgångsrik tjänsteorienterad arkitektur?

Princip och inte teknik SOA beskrivs ofta ur ett tekniskt perspektiv. Många produktleverantörer har valt att utnyttja den uppmärksamhet konceptet fått på marknaden och presenterat "SOA-produkter". Men den här informationen har ofta varit snårig, vilket har gjort det svårare att förstå vad SOA är och hur det skulle kunna fungera i den egna organisationen.

Ett relevant perspektiv på SOA, är att se det som en strategi för att knyta samman teknik och affärsverksamhet. SOA är ett sätt att göra affärer, stimulera innovation samt att använda och återanvända existerande kunskaper, tillgångar och investeringar. Ur det här perspektivet är SOA en princip eller en arkitekturell filosofi som en organisation förbinder sig till, inte en viss teknik eller bestämd teknisk arkitektur.

SOA innebär en löst kopplad arkitektur, vars syfte är att möta organisationens och verksamhetens behov på det mest effektiva sättet. För att göra det krävs komponentifiering. Att dela in organisationens system i komponenter är inget nytt. Värdet med komponentifiering har traditionellt varit återanvändning, minskat underhåll och standardisering inom organisationen. Men SOA lovar mer än så. Inom SOA fokuserar man i betydligt större utsträckning på att möta organisationens och verksamhetens behov.

Traditionellt ser man IT som något isolerat och som bör struktureras efter den interna organisationen. SOA-perspektivet är att IT måste vara strukturerat efter hur verksamheten fungerar och hur organisationens processer används.

Ökad flexibilitet och aktualitet

SOA blir därför en fråga för hela verksamheten. Organisationen behöver vara eller bli mer processorienterad för att IT ska kunna stödja verksamhetens krav och förändringar mer effektivt. Ytterligare en drivkraft bakom SOA är det ständiga kravet på aktuell information. En tjänsteorienterad arkitektur ger möjlighet att gå från en schemastyrd hantering till en händelsestyrd hantering.

Det ger i sin tur möjlighet att på ett helt nytt sätt anpassa processerna för att automatiskt agera på händelser och information i realtid. Det är just de ständiga förändringarna och kraven på aktuell information för att effektivt kunna övervaka och styra sina processer som ökar behovet av SOA inom många organisationer idag.

Framgångsreceptet

För att lyckas med SOA måste de tekniska perspektiven alltid beskrivs i termer av vilket värde de skapar för verksamheten. Organisationen måste också ha rätt verktyg och arbetssätt för att övervaka och styra SOA-arbetet. Det finns ett antal mekanismer som alla bidrar till att hitta rätt i djungeln och komma igång på rätt sätt med en SOA Roadmap:

1. SOA-vision. Ta fram en verksamhetsorienterad SOA-vision som påvisar vad SOA innebär för organisationen och vilken nytta det kan bidra till.

2. SOA Entry points. Jobba aktivt för att hitta ett bra startprojekt som är lagom stort, kopplat till ett aktuellt verksamhetsbehov och som täcker in olika aspekter av en tjänsteorienterad arkitektur på lämplig nivå.

3. SOA Maturity Model. Vid sidan av vision och operativa projekt måste man säkerställa att organisationens förmåga avseende SOA utvecklas. Genom mognadsmodellen gör man kontinuerliga mätningar och får förslag på vad som behöver förbättras.

4. Verksamhetsarkitektur. Att ha en verksamhetsmodell som säkerställer en flexibel verksamhet på hög nivå är i de flesta fall ett måste. Denna modell ska upprättas mer som byggstenar än som detaljerade processer.

5. Referensmodell för SOA. Det räcker inte med vision, startprojekt, verktyg och arkitektur. Det finns fortfarande ingen garanti att lösningar utformas på rätt sätt. En referensmodell säkerställer att lösningar utformas enhetligt och på rätt sätt.

6. SOA Governance. Att ha en arkitektur räcker inte för att lyckas. Man måste också säkerställa att projekten och arkitekturen integreras, det vill säga att utvecklingsprocessen tillämpar arkitekturen. I detta sammanhang bör påpekas att modellen även måste täcka in förvaltningsprocessen.

Slutligen, kom ihåg att SOA i sig själv aldrig får vara ett mål. Det gäller att tidigt identifiera vad som är drivkrafterna och värdena med en SOA-implementation. Då kan SOA i din organisation bli en verklig framgång.

Richard Hallgren | Sogeti


 
Gold Partner
Novell Partner

Senaste besökta utbildningar