torsdag, oktober 06, 2005

Att införa SOA

Är ni i startgroparna för att dra igång en SOA-satsning? Funderar ni på i vilken ände ni ska börja för att bygga en SOA? Kanske undrar ni om man ska börja med att kartlägga processerna i verksamheten, eller en inventering av nuvarande applikationsmiljö, eller kanske hitta produkter som kan förverkliga en SOA? Är sådant fallet, så är ni helt rätt ute. Alla tre aktiviterna krävs för att planera ett införande av en SOA. Men innan ni börjar införa en SOA så är det viktigt att ni är klara över vilka fördelarna är och vad ni ska tjäna på en SOA.

Fördelarna
En SOA kan sammanfattas i att skapa en IT-miljö som ligger i linje med en föränderlig omvärld eller en verksamhet. En SOA ska kunna svara direkt mot alla förändringar i den verksamhet som den implementerar. Den ska även kunna signalera tillbaka nödvändiga förändringar till verksamhetens processer.

1. Processerna
SOA handlar om att lära känna sina processer. Kännedomen om processerna är grundläggande inom SOA. Utifrån processerna byggs tjänstenätverket upp. Alla behov av tjänster utgår ifrån processerna. Underordnade tjänster till processerna är först och främst andra processer, men även datatjänster, interaktiva tjänster (som kräver mänsklig dialog) samt en grupp av beräkningstjänster. Kartläggningen innefattar processerna och dess beroenden till data och interaktivitet.

2. Applikationsmiljön
Nästa steg är att inventera den nuvarande applikationsmiljön för att veta var man står. Troligtvis finner man ett antal applikationer. Applikationer är silos som äger information och ansvarar för dess korrekthet så länge man går via applikationens gränssnitt. Applikationer abstraherar och döljer ingående processer, data och dialog med användarna. I en SOA existerar däremot inte applikationsbegreppet. I en SOA är istället processerna, datat och beräkningarna fria tjänster som är möjliga att återanvända för att bygga upp tjänstenätverket med.

3. Produkterna
Förr i tiden då man skapade datacentriska arkitekturer nyttjades teknologi och metodik som exempelvis Domain Driven Design, objektorientering och EJB. SOA kräver också sina produkter för att underlätta designen. I det här fallet ska det underlätta för processdriven design. Det finns olika åsikter om vem som har den bästa plattformen för SOA. Några kommer att satsa på en leverantör av hela plattformen (en superplattform), andra kommer välja det bästa av det mesta (best of breed). Det viktiga är att i en SOA ha kolla på var alla produkter kommer in i bilden och hur de hänger samman. Plattformen består bland annat av stöd för kommunikation, interaktivitet, processer, integration, säkerhet, datahantering och övervakning.

4. Införandet
När processerna är kartlagda, applikationsmiljön inventerad och man är konfortabel med en plattform så kan man planerar sitt införande av SOA. En fullständig SOA är inte ett troligt resultat av införandet. Man kommer alltid ha ett antal applikationer kvar från den gamla miljön som måste integreras. Så även om en SOA bygger på att alla applikationer ska ersättas med ett tjänstenätverk så bör man istället jobba uppifrån och ned. Börja med de övergripande processerna och integrera in applikationerna i tjänstenätverket. SOA handlar inte om att bygga om och kasta ut. Det handlar om att ha en strategi för att skapa en arkitektur som är lika föränderlig som din verksamhet kräver.

Go SOA!

Inga kommentarer: