SOA-kartläggning

För ett tag sedan skrev Tamina Vahidy en artikel om resultatet av en undersökning som gick ut på att kartlägga vilka komponenter som användes mest för att uppnå en SOA.

• 71% Web Services
• 61% Portalramverk
• 46% Applikationsserver
• 43% Integrationsramverk
• 36% Säkerhetsramverk
• 18% Analysramverk
• 18% Datacentralisering
• 14% ESB
• 14% BPM

Tamina konstaterar "- That's an excellent illustration not just of how companies are building SOA, but of SOA's complexity". Hon säger att SOA är inte en applikation, utan en paradigm. SOA är allt ovan, från portalramverk till datacentralisering. Det är det som gör det komplext!

Sedan kan man ju konstatera att prioriteringarna (av siffrorna ovan att dömma) är något förskjutna mot EAI och inte de delar som implementerar det unika med en SOA, nämligen BPM och ESB. Det är bara att konstatera att vi kommer få se negativa erfarenheter av SOA så länge man inte uppnår målen med SOA. Ronan Bradly beskyller produktleverantörerna för att paketera sina gamla EAI-produkter som ESB:er, vilket jag skriver under på.

SOA och DSL

Det har alltid funnits ett stort gap mellan problembeskrivaren och problemlösaren när det kommer till programutveckling. Det gapet har med tiden försökts att överbryggas på alla tänkbara sätt. Problem beskrivs av personer som har kunskaper inom problemdomänen, medan lösningen skapas av personer som har kunskap i verktygen som används för att konstruera lösningen.

En väg att minska gapet och som fått alldeles för stort genomslag är CASE-verktygen, som exempelvis Rational. I ett CASE-verktyg enas problembeskrivaren och problemlösaren i ett gemensamt språk och metodik som ex. UML/RUP. Det finns generellt sätt mängder av problem med den här typen av modeller, men i synnerhet ett som har förpassat UML & Co till 90-talet. UML kan nämligen inte exekveras!

Att UML inte kan exekveras har man försökt att åtgärda med hjälp av kodgenerering. Det blev aldrig, av förståliga skäl, någon hit eftersom den genererade koden inte fick några fans bland utvecklarna som hela tiden låg steget före med ny teknik. UML är även ett problem med tanke på underhåll eftersom man blev tvungen att underhålla både kodbasen och modellen. UML nådde heller inte fram till roten av problemet, att minska gapet, utan skapade istället två nya raviner. Det första mellan problembeskrivaren och modellen, men även mellan modellen och problemlösaren. Den fylldes med nya roller som titulerade sig analytiker, kravhanterare och andra former av "fördyrande mellanhänder".

DSL (Domain Specific Languages) är ett annat sätt att minska gapet. Det går ut på att skapa språk som kan exekveras samtidigt som det närmar sig problembeskrivaren genom att "prata" samma språk som honom. Det viktiga med DSL är just att det, precis som UML, ska ge möjligheten att modellera inom problemdomänen samtidigt som det ger ett resultat som kan exekveras.

Ett enda språk kan inte lösa alla problem. Därför måste det finnas en mängd språk som på olika nivåer skapar lösningen. Vissa språk är nära problembeskrivaren och andra är närmare tekniken. Det är lite som idén med .NET (även om MS väljer att ersätta alla andra programspråk med C#) där flera språk enas runt en exekveringsmodell, tillskillnad från Java där alla kodare enas runt ett språk som ska passa alla problem.

En SOA är ett nätverk av komponenter av DSL:er som samspelar med det gemensamma i Web Services. Web Services ger även möjligheten att konstruera arkitekturer av komponenter utvecklade för olika exekveringsplattformar, vilket betyder att man kan uppnå fördelarna med .NET utan att för den delen vara fullt beroende av en exkeveringsmodell.

Skikten av språk som används, nära problembeskrivarens domäner ned till tekniken skiljer sig mellan en traditionel arkitektur och en SOA. I en klassisk skiktad arkitektur så finns en hierarki där ju närmare problemet man kommer desto mer finns behovet av DSL:er. Att knyta samman alla språken i ett gemensamt meta-språk kommer säkert ge de stora leverantörerna något nytt att bråka om framöver (se SCA och SDM).

Oavsett vem som bygger det ultimata meta-meta-meta-...-språket så är en SOA ett klockrent exempel på hur olika DSL:er samspelar i en arkitektur. Där finns det nämligen ingen hierarki som avgör vem som orkestrerar vem. En SOA är ett nätverk och inte en skiktad arkitektur.

WS-Management

WS-Management (eller MS-Management) har publicerats här.

Läs mer om WS-Management här.

Enligt denna källa kommer WCF i.o.m. R2 supporteras av WS-Management.

Tjänsteorientering IV - Första steget

Att uppnå en SOA är ingen enkel omställning. Att gå från en applikationsorienterad IT-miljö till en tjänsteorienterad kräver stora förändringar inom IT.

Applikationer har karaktäriserats som en paketering av tjänster, där just paketering har ingivit en positiv trygghetskänsla. Trygghet både för den som använder applikationen, men även för den som erbjuder tjänsterna. Det negativa med applikationen är att den är som en svart låda som säger "jag erbjuder allt eller inget" i form av tjänster.

Applikationer saknar förmågan att kunna kopplas ihop med omvärlden om man inte gör det på applikationens villkor. Dels mellan lager som gränssnitt, logik och data, men även tjänstevis. En SOA måste kunna erbjuda samma trygghet som en applikationen ger, men även uppfylla de delar som anses vara negativa med applikationer. Ett tjänstenätverk måste kunna gruppera tjänster i vita lådor, eller meta-applikationer. En meta-applikation är en paketering av tjänster i en SOA som ska garantera samma trygghet man fick med en vanlig applikation.

Meta-applikationen har en rörlighet som en traditionell applikation saknar. Den består av ett tjänstenätverk som en del av ett större nätverk. Gränserna för meta-applikationen manageras av verktyg som kan upprätthålla dess förväntade tjänstenivå.




Här måste SOA börja, d v s att applikationerna förändras. Att bygga en SOA är ett jobb som arbetar sig bottom-up. Sitter man på en applikationmiljö som behöver integreras m h a en broker-lösning eller ett middleware så kan man definitivt göra det som en start. Men en SOA handlar om att få bort applikationerna och byta ut dom mot meta-applikationer i ett tjänstenätverk.

Så trycket måste ligga på applikationsutvecklarna om SOA ska bli en realitet. Tillsvidare får IT nöja sig med applikationsintegration, vilket tyvärr ändå verkar vara det enda så gått fram till IT som en definition av SOA.

Måsteläsning

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf

Tjänsteorientering III - Vägen dit

Vägen till en SOA tar sig olika beroende på var man befinner sig. Många kan relatera till bilden nedan med ett antal applikationer sammankopplade till varandra efter behov och med webbar som gör anropar direkt mot applikationerna. Det här är en vanlig arkitektur och kallas i integrationskretsar för "spagetti" eftersom allt hänger samman genom peer-to-peer.



Andra har byggt ett Middleware á la 90-tal, baserat på ett integrationsramverk utvecklat på J2EE eller Windows DNA. Kostnaderna har här mest att göra med underhållsproblem och integrationskostnader när det ska ske tillägg eller förändringar i ramverket.



Möjligen har man investerat stora pengar i ett integrationsnav eller en "Integration Broker". I så fall har man skapat bra förutsättningar för att integrera applikationer. En integrationsplattform är en öppen lättskött miljö för att integrera applikationer.



Men för att nå en SOA så måste siktet vara inställt på att skapa ett komplett tjänstenätverk istället för applikationer. En SOA bygger på standarder och kan enbart fungera i en värld där man som konsument och producent av tjänster kan lita på sin motpart.



SOA handlar alltså om tjänster som i sin tur handlar om tillit. Tillit handlar om Service Level Agreements, standarder, kontrakt, policies och säkerhet. För att kunna bygga upp ett tjänstenätverk måste man bygga tillit på just dessa komponenter. OASIS och W3C definierar just dessa komponenter som ska garantera tillit i ett tjänstenäteverk. Produktleverentörer inom SOA måste förhålla sig till standarder för att nätverket ska fungera.

Tjänsteorientering II - En utopi

I Tjänsteorientering I illustrerades hur mycket bättre en SOA mappar mot en verksamhet jämfört med en applikationsmiljö. Anledningen till att man vill skapa en avbild av verksamheten gentemot arkitekturen beror på att man kan ta samma beslut för en arkitektur som man gör för en organisation. Det kan gälla omorganisation, förändringar, nedskärningar, utflyttning (out sourcing) , m m.

Applikationer paketerar tjänster, processer och aktiviteter i en svart låda där man är tvingad till att använda allt eller inget. Applikation löser ofta problem som hör hemma i en viss del av en verksamhet, men de tar ingen hänsyn till att det finns andra applikationer som lagrar samma information eller använder samma tjänster. Det är en stor dubblering av både data och funktion i en applikationsmiljö.

I en SOA existerar inga applikationsbarriärer. I ett tjänstenätverk finns det visserligen dubbletter av data och funktion, men det är under ordnade former. Dessa former är vad man inom SOA kallar för Service Management. Det kallas även Service Governance och är även det hämtat från affärsvärlden och har med styrning av en verksamhet att göra.

SOA är en utopi av en värld där IT-stödet består av tjänster som mappar mot tjänster i verksamheten vilket ska göra den lika kontrollerad som en organisation.

Tjänsteorientering I - En avbild

Det här är första av fem bloginlägg om tjänstorienteringens uppgång och fall.

En affärsverksamhet består av personal och tjänster som är representerade i en organisation.

Fig 1. En förenklad bild av en affärsverksamhet

Så här kan en verksamhet struktureras lite förenklat. Det stöd en organsiation normalt sätt får i en applikationsorienterad IT-miljö ser ut som nedan.

Fig 2. En förenklad bild av en generell IT-miljö

Som man ser döljer applikationens gränser en stor del av det verksamheten byggs upp av. D v s om verksamheten ska omstruktureras finns det inget genomslag i applikationen.

En bättre representation av verksamheten skulle man kunna få i en SOA som i bilden nedan.

Fig 3. En förenklad bild av en SOA

En SOA är en direkt avbild av en verksamhet.

• Varje behov av tjänst finns representerad i arkitekturen, varken mer eller mindre.
• Varje arbetsprocess finns representerad i arkitekturen, varken mer eller mindre.
• Varje aktivitet finns representerad i arkitekturen, varken mer eller mindre.

SOA inte bara framgång

Efter att ha läst resultatet från en undersökning om SOA-införanden så dyker frågorna upp. Varför misslyckas ett av sju projekt? Varför förutsåg man inte att ett införande av SOA skulle ta sådan tid? Vad hade man för bild av SOA och vilka problem försökte man lösa? Vilken metodik hade man vid införandet och vilka var förväntningarna? Vilken teknik användes och hur organiserade man sig? Var hittade man kompetensen och vilka var inblandade? Vad är kriteriet för misslyckande?

SOA & outsourcing

Outsourcing motiveras ofta med lägre kostnader, bättre kvalité, snabbare time-to-market, högre flexibilitet och rörlighet. Samma fördelar gäller även för en SOA, så vad har de med varandra att göra?

Läs det här dokumentet av Martin Eldracher som beskriver SOA och outsourcing.

Se även ett dokument från ZapThink i samma ämne.

Byta tjänsteleverantör borde vara lika enkelt som att gå till Konsum istället för ICA.

90-talets integrationsplattformar

På slutet av 90-talet var det två teknologier som dominerade det mesta, Enterprise Java Beans och COM. Det finns inte många företag som inte byggde sina integrationsplattformar på EJB eller COM. Tanken var som alltid med integrationsplattformar att skapa ett centraliserat integrationsramverk som applikationer, webbportaler och B2B kunde gå igenom för att kommunicera med bakomliggande system.

COM och EJB har många fördelar, men som ramverk för integration är de inte perfekta. Jag vill peka på fyra av problemen med dessa ramverk:

1. För det första så är det problem med interoperabiliteten. Både COM och EJB kräver sin motsvarighet för att kunna integreras, dvs har du EJB som ramverk, kräver det java på klienten och samma sak med COM.
2. Ramverken är skrivna i VB/C++ resp Java som kan anses vara lågnivåspråk i ett integrationssammanhang. Det gör ramverken svåra och dyra att underhålla.
3. Ramverken är "svarta lådor" som döljer vad som händer inom dom. Transparansen är obefintlig vilket är ett problem vid integrationssammanhang då extra god överblick är av vikt.
4. Java och COM har två olika protokoll som de använder för att kommunicera mellan klienterna och ramverket. Det protokollet var inte konstruerat för integration, utan snarare för klient/server-applikationer.

Web Services är ju svaret på problemet med interoperabiltet och kommunikationsprotokoll (nummer 1 & 4). Däremot så kvarstår problemen med implementationen. Många företag idag ser SOA som att exponera Web Services på sina existerande ramverk för att göra dem mer åtkomliga och samtidigt inte behöva ta en investering för att ersätta det gamla ramverket. Så kan man göra, men det ger ingen vinst när det kommer till integrationskostnader.

Kostnaderna med integration har att göra med punkt 2 och 3 ovan, d v s implementationen av tjänsterna. För att undvika det så ska integrationsramverket implementeras i en mer transparant och lättrörlig arkitektur. Enterprise Service Bus (ESB) eller Integration Brokers (IB) är skapta för att just ge dom fördelarna utöver interop och kommunikation som tillsammans skapar en flexibel integrationsplattform.

Falluckan med ett integrationsramverk baserat på EJB eller COM som ska migreras till en SOA är hur man ser på tjänsterna. Det är viktigt att man inte mappar det gamla ramverkets design direkt till ett tjänstenätvärk utan bygger det på den nya teknikens möjligheter och begränsningar.

Steg 1:
Steg 2:
Steg 3:

Vad är SOA utan distribuerade händelser?

I COM+ finns något som kallas för Loosely Coupled Events eller distribuerade händelser. Ett COM-objekt kan registrera sig för att prenumerera på händelser från ett annat COM-objekt utan att det andra är medveten om det första. Ur ett integrationsperspektiv så är distribuerade händelser en viktig ingridiens som förenklar mycket för både integratören och applikationsutvecklaren. Tekniken för det är implementerat inne i COM+ och är inte en del av varken prenumeranten eller servern. På liknande sätt har man specificerat det för Web Services genom WS-Eventing.

WS-Eventing beskriver hur man kan skapa prenumerationer på händelser över Web Services. Klienten skickar över en förfrågan av en prenumeration till en tjänst. Den förfrågan innehåller vilken händelse som är av intresse samt vart händelsen ska skickas när den inträffar. Allt som implementerar distribueringen av händelsen är inbyggt i WS-plattformen.

När behöver man distribuerade händelser? Händelser inträffar ju lite när som helst mellan och inom applikationer. En distribuerad händelse är bara aktuell då tjänsten eller applikationen som skapar den inte vet vem eller vilka som är intresserad av den. I första hand då något tillstånd har förändrats som man vill notifiera omvärlden om. En distribuerad händelse är dock inte intressant då en tjänst tagit emot en förfrågan från en klient som vill har ett svar, nu direkt eller senare. I det fallet känner tjänsten till klienten och svaret skickas enbart till den. Däremot kan tjänsten, som en sideffekt av det, skapa en distribuerad händelse för att notifiera övriga klienter om en tillståndförändring.

Distribuerade händelser är en naturlig del av en SOA. Den del av SOA vi känner väl är där orkestreringen av tjänster beskriver flödet och kommunikationen inom tjänstenätverket. Men det finns även en del som måste vara händelsestyrd och inte helt förutsatt. En SOA behöver WS-Eventing och innan plattformarna stödjer det så kan SOA anses vara en stel och statisk arkitektur.

Hur passar SOA in bland EAI, EII och ETL?

Integration
Enterprise Application Integration (EAI) kopplar samman applikationer och får dem att samverka på en högre (Enterprise) nivå. En EAI-lösning karraktäriseras av flödesbeskrivningar, transformationer och adaptrar som ska se till att rätt information kommer till rätt applikation. EAI implementeras i en Integration Broker. EAI ser exempelvis till att integrera order- och faktureringssystemet. Då kopplas en adapter till ordersystemet för att hämta ut orderinformationen, transformerar den till faktureringsunderlag och sedan genom ytterligare en adapter styra informationen till fakturasystemet. Den största fördelen med EAI är att det ger möjlighet att följa en order mellan de olika applikationerna, s k Business Activity Monitoring (BAM). En annan fördel är den åstadkomna abstraktionsnivån mellan processerna i verksamheten och applikationerna. Det ger ett löst kopplat processnätverk som möjliggör utbytbarhet och flexibilitet.

Enterprise Information Integration (EII) bygger på att man har en virtuell databas som inte innehåller någon information utan vet bara var den ska leta om någon frågar. Tillskillnad från EAI så löser EII en identitetskris, d v s problemet med informationens hemvist och korrekthet. Finns rätt kundinformation i applikation A eller B? Inkorrekt information kan vara kostsamt och katastrofalt i värsta fall. Därför är den här typen av system väldigt viktiga att implementera om man har en decentraliserad informationslagring. System som stödjer EII kallas för Information Brokers. De implementerar ett Meta Repository med information om var informationen finns, dess format, typ m m. En Broker hanterar även pub/sub vilket gör att applikationer kan prenumerera på informationsändringar när de inträffar i någon annan applikation.

Extract, Transform och Load (ETL) förutsätter däremot en riktig databas som innehåller information. Det är ett Data Warehouse som lagrar, indexerar och aggregerar information för analys. Ett Data Warehouse används inte som en uniform databas där alla applikationer läser och skriver, utan enbart för analys.

Business To Business (B2B) är som EAI fast mellan Enterprises.

Alla integrationsmetoderna ovan är skapta för att lösa olika problem som uppstår i en heterogen applikationsmiljö. EAI abstraherar applikationerna från processerna i en verksamhet vilket ger en överblick och inblick i flödet. EII säkerställer att informationen i en verksamhet är korrekt. ETL möjliggör analys och sökningar i stora datamängder som inte skulle vara möjligt annars.

Arkitektur
Så hur kommer SOA in i bilden? SOA är inte en integrationsmetod som de andra tre, utan en arkitektur för att undvika att hamna i ett integrationsscenario och alla problem som uppstår i samband med det. Det finns ett antal andra arkitekturer som provats med olika framgång.

Först och främst är väl den som SAP implementerar, Enterprise Resource Planning (ERP). D v s en homogen miljö där applikationerna som levereras kommer från en och samma leverantör och är byggda för att fungera tillsammans. Nackdelen med det är att man blir fullständigt leverantörsberoende samt att man förmodligen ändå någon gång kommer att hamna i ett integrationsbehov.

Nästa arkitektur som kan nämnas är datacentralisering där alla applikationer använder samma datakälla och skulle därmed dela informationsmodell. Lika osannolikt som det låter.

En populär arkitektur på 90-talet var är centralisering av transaktionerna i ett Enterprise Object Framework som stöds av olika EJB implementationer. Det bygger på att alla transaktioner hanteras av ett och samma ramverk. Använder man inte ramverket så fungerar inte modellen.

Till förra århundradet hör även portalerna. Webbplatserna som skulle ersätta allt GUI och prata direkt med APIer exponerade från applikationerna. Inte heller ett troligt scenario som skapade svåra underhållsproblem.

Portaler, EOF och datacentralisering lyfte inte utan skapade istället nya integrationsproblem som låste in IT-avdelningar i svårhanterade hemmabyggda arkitekturer.

Tjänsteorienterad arkitektur
SOA är en arkitektur som "lärt sig" av misstaget med portaler, EOF och datacentralisering. SOA tar EAI ett steg längre ned i arkitekturen och upplöser applikationsgränserna som ersätts med tjänster. Det som först och främst skiljer en SOA från EAI är att en riktig SOA bygger på standardiserade tjänster och inte adaptrar och applikationer. Fördelarna med EAI och BAM finns inbyggda överallt i en SOA. EAI är som en ofullständig SOA.

När det kommer till EII så har en SOA inbyggd hantering av lokalisering av information (data services). EII är en naturlig del av en SOA med möjligheter att slå upp var informationen finns åtkomlig. Det gäller inte bara information och data i en SOA. På samma sätt blir processer åtkomliga på ett intelligent sätt.

ETL och SOA har inte lika mycket med varandra att göra, men eftersom informationensåtkomsten är standardiserad så kan Data Warehouse enkelt fyllas med information.

B2B är bara en förlängning av SOA från Enterprise nivå till cross-Enterprise.

Alternativa arkitekturer
Det finns även en halvmesyr som kan anses vara den mest verklighetsförankrade arkitekturen. Nämligen en heterogen applikationsmiljö med EAI, EII, ETL och B2B som bygger helt och hållet på WS-Endpoints á la WS-*. Vi kan kalla det Enterprise Web Service Enabled Application Integration (EWSEAI). Tyvärr fortfarande med applikationer i grunden (vilket en SOA inte har (den har tjänster (tjänster i bemärkelsen Business Service (inte Web Services (som föranleder det globala missförståndet om SOA))))).

Det finns även en arkitektur som kallas Bus Architecture och bygger på en Enterprise Service Bus (ESB). Den fungerar som den ovan fast med en annorlunda decentraliserad topologi. En ESB och Integration Broker är i praktiken implementerade på samma sätt men ritas oftast ut i olika diagram på två olika sätt.

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!

Är SOA en nollvision?

Världsorganisationer strävar efter global fred, mänskliga rättigheter och rättvisa. Ett samhälle strävar efter att ingen medborgare ska gå arbetslös, vara sjuk eller stå som bostadslös. Mindre organisationer strävar efter att ingen ska dö i trafiken, av rökning eller alkohol. Att sträva efter något är att ha en nollvision som mål.

I vissa fall är andra mål än en nollvision oacceptabla, eller snarare omöjliga för att driva på arbetet med att nå målet. Nollvisioner sätts då målet aldrig kan realiseras pågrund av att målgruppen och motståndet är för stort. Nollvisionen är ouppnålig men ska driva på det bästa möjliga alternativet.

Motståndet inom målgruppen i nollvisionen består oftast av:

1) ovilja - "vissa vill inte sluta röka"
2) illvilja - "motstånd i eget intresse (ex. Swedish Match)"
3) konkurens - "oenighet om hur visionen ska uppnås"
4) inkompetens - "felaktiga tillvägagångssätt att uppnå visionen (ex. FIMPA NU!)"
5) begreppsförvirring - "tvetydighet runt definitioner"

Ju större grupp som innefattas av en nollvision och ju större motstånd det finns inom gruppen, desto svårare är det att uppnå målet. Världsfred är t ex svårare att uppnå än att alla Stockholmare ska sluta röka.

Jag skulle vilja påstå att SOA är en nollvision, dvs något man kan sträva efter men aldrig kommer uppnå pga dess komplexitet.

Man kan inte säga att man har en SOA förän man uppnått visionen av den gamla klyschan, att ha en fullständigt normaliserad modell. SOA-modellen består av ett tjänstenätverk där ingen tjänst förekommer mer än en gång och under varje tjänst utnyttjas tjänstenätverket om och om igen. Tjänstenätverket sprider sig ut från lokala resurser till globala och universella. När nätverket är komplett och normaliserat så har man uppnått SOA.

Det räcker med att en enda person inte slutat röka så har man inte nått målet med hela gruppen. Samma sak med SOA; det räcker med att en tjänst inte nyttjar tjänstenätverket, så har inte SOA uppnåtts. Antag att man genom ett lager exponerar ut tjänster för access till ett legacy-system. Det systemet använder inte tjänstenätverket och arkitekturen är därmed inte SOA.

Så vad betyder det här för de som ska satsa på SOA? Jo, att SOA bara är något man kan sträva efter och inte något man kan uppnå. Det gör inget om en tjänst inte utnyttjar tjänstenätverket, men man ska veta att det inte är en SOA man då åstadkommit. Men fortsätt att sträva efter en SOA! Det finns mycket att vinna bara genom att vara på väg mot målet.