SOA - den röda tråden

SOA - den röda tråden SOA tjänsteorienterad arkitektur - skapar enorma möjligheter att förbättra verksamhetens informationsbehandling, men är samtidigt svårt att ta till sig. SOA har ingen talesman att jämföra med hur Ted Codd med början 1970 beskrev datamodellering och hur Michael Hammer från 1990 alltjämt beskriver verksamhetsprocesser. Du behöver inte hålla med om allt, men du kan alltid relatera till talesmannen. Alla ledande IT-aktörer känner sig därför manade att presentera sin egen bild av SOA. Risken är att ju mer du läser och lyssnar ju mer förvirrad blir du. Syftet med den här röda tråden är att försöka ge dig en stabil grundkunskap kring SOA. Den bör förstås ifrågasättas, men då har du något att relatera olika synpunkter och förslag till. Den här röda tråden bygger på Thomas Erls lysande bok SOA: Principles of Service Design och IRMs process för verksamhetsarkitektur och SOA. Erl kommer från tekniksidan medan vi på IRM tar utgångspunkt från verksamhetssidan. Förhoppningsvis blir det ett fruktbart möte, där ljuv musik kan uppstå. Den röda tråden är också svår för att den nu för första gången sträcker sig hela vägen från verksamhetens vision till den tekniska lösningen. Vi har alla någon del där vi vet mer och några delar där vi är mera okunniga. Den här röda tråden syftar till att beskriva en sammanhängande process, där du sedan kan fördjupa det du är speciellt intresserad av. Som SOA-specialist är det helheten, som kommer i första hand och därefter djupare detaljkunskap. Du bör också ha i åtanke att den tekniska utvecklingen, det må gälla bilmotorer, mobiltelefoner eller SOA inte gör saker och ting mindre komplicerade, men förbättrar förhoppningsvis funktionen. SOA kräver mer utbildning, erfarenhet och kompetens på samma sätt som att underhålla en bilmotor idag är mer krävande än det var att sköta en bilmotor förr i tiden. 1

1 Introduktion IT-lösningen ska stödja verksamheten på bästa sätt och den ska vara lätt att ändra när verksamheten ändras. Vi eftersträvar en ökad flexibilitet. Men detta kräver samtidigt en ökad spårbarhet hela vägen så vi kan kvalitetssäkra att en SOAlösning kan stödja verksamheten på bästa sätt. På samma sätt som vi kan följa att en stadsplan realiseras med byggnader som byggts enligt det byggnadslov som beviljats i överensstämmelse med en godkänd stadsplan. Utan spårbarhet till resultatet blir alla planer ganska meningslösa. 1.1 Verksamhetsarkitektur Att etablera SOA inleds med ett arkitekturarbete, som ger ett underlag att successivt utveckla SOA-tjänster. En verksamhetsarkitektur tar vi fram i tre huvudsteg. Först en processkarta över verksamheten, sedan en övergripande datamodell och till sist själva arkitekturen, som vi beskriver i en så kallad IRM-matris. Matrisen anger hur de grundläggande byggstenarna dataobjekten grupperats till objektgrupper och vilka beroende som finns mellan de olika objektgrupperna. Vår utgångspunkt är sedan att varje objektgrupp kan utgöra en SOA-tjänst. Vi utgår ifrån att verksamheten har arbetat fram tydliga visioner och strategier, som beskriver hur den ska utvecklas. Vi kallar detta affärsplan eller verksamhetsplan. När vi ska börja bygga den tjänsteorienterade arkitekturen är det rimligt att börja med de tjänster, som är viktigast för verksamhetens visioner och strategier. Då får vi utvecklingsprojekt som verksamhetens ledning stödjer och engagerar sig i. 1.2 Hammer och verksamhetsprocesser Michael Hammer lanserade verksamhetsprocesser 1990. Det som får allt fler verksamheter att arbeta med sina processer är fokus på kunden och de kundvärde vi vill åstadkomma. Kundfokus ökar konkurrenskraften och gör verksamheten mer effektiv. Vi går igenom affärsplan och ser vilka av verksamhetens processer som är viktigast att utveckla för att genomför de visioner och strategier, som tagits fram. Dessa kallar vi strategiska processer, eftersom de är viktiga för verksamhetens effektivitet och konkurrensförmåga. Dessa är viktiga att identifiera och har ledningens uppmärksamhet. De projekt som relaterar till de strategiska processerna ges resurser och har ledningens uppmärksamhet. 2

1.3 Zachman Ramverk Den röda tråden relaterar också till Zachmans ramverk. Han bygger detta på interrogativ, där vi prioriterar varför (verksamheten finns), hur (processerna) och vad (data och information). Denna ordning är viktig när vi samtalar med verksamhetens ledning. De övriga vem, när och var lämnar vi tills vidare utanför. När Zachman i början på 80-talet under sin tid på IBM tog fram sitt ramverk var det framför allt kolumnen för data (vad) som han prioriterade. Han hade saknat den i sitt arbete på IBM. Det ledde till att utvecklingsplanerna (BSP) på den tiden saknade stabilitet och spårbarhet. Spårbarheten är enklast att tydliggöra i datakolumnen. Den har en matematisk stringens som processer inte har. Codd var ju matematiker. Därför kan spårbarheten i vad-kolumnen stödja spårbarheten i hur- och varför-kolumnen. Allt för att planen ska kunna jämföras med lösningen! 1.4 Codd och datamodellen Därför är också nästa steg att se vilken data som krävs för att hantera de strategiska processerna. Processerna ändras år från år, men data är stabilt och därför en viktig och avgörande grund för det fortsatta arbetet. Vi tar fram datamodeller (kallas ibland informationsmodeller eller objektmodeller), som visar hur de viktiga begreppen i verksamheten relaterar till varandra. Det var Ted Codd, som 1970 tog fram den teori kring normalisering, som alltjämt är helt central för att ta fram datamodeller av hög kvalité. Detta är svårt och kräver mycket träning, men är samtidigt helt centralt för att lyckas med en SOA-insats. 1.5 SOA-tjänster Nu närmar vi oss det mest centrala i SOA nämligen tjänsterna (eller tjänstekomponenterna). Att jämföra med LEGO-bitar ger en bra bild. Tjänsterna ska vara stabila och ha tydliga gränssnitt som gör att bitarna passar ihop. De är viktigt att du inte förväxlar SOA-tjänster med de tjänster som verksamheten levererar till sina kunder. En av många tillfällen till missförstånd och otydligheter finns när vi närmar oss SOA. Gränssnitten är standardiserade och publicerade. När du använder tjänsten använder du de publicerade gränssnitten. Tjänsterna har funktioner, som hanterar data i verksamheten. Ett exempel på tjänst är kund. Här hanterar vi all data kring kund, som till exempel kundidentitet, namn, adress, telefon och kreditvärdighet. Vi säger ofta att tjänsterna är CRUDorienterade. CRUD står för Create, Read, Update och Delete. Tjänsten har minst ett gränssnitt för varje CRUD-funktion, skapa, läsa, ändra och ta bort. Men särskilt för läsa kan det finnas flera olika gränssnitt. När du vill ha uppgifter om en specifik kund i din verksamhet ställer du din fråga på ett standardiserat och överens- 3

kommet sätt. Då talar du också om att du är behörig att ställa frågan. Sedan svarar tjänsten dig på överenskommet sätt med till exempel namn, adress och telefon. Man kan välja att göra ganska små tjänster, som då blir många till antalet eller ganska få men större tjänster. Vi förespråkar ganska få men stora tjänster. De erfarenheter, som hittills publicerats bland annat i Erls bok, tyder på att detta synsätt är riktigt. 1.6 Thomas Erl Hur vi utformar tjänsterna är ganska naturligt det mest centrala i ett SOAinförande och här ska vi stanna till och ägna detta ordentlig uppmärksamhet. Av alla de böcker, artiklar och presentationer som skrivits om SOA börjar Thomas Erl alltmer att framstå som talesmannen för SOA. Thomas kommer från tekniksidan, men har successivt närmat sig verksamhetssidan. Han är bosatt i Vancouver och har skrivit fyra stora verk om SOA, varav den senaste SOA: Principles of Service Design är ett imponerande försök att transformera tyst kunskap och göra den till explicit kunskap. Se not 1. Ungefär som en bagare skriver ned sitt bakrecept. För att förstå och utvärdera om det är ett bra bakrecept måste du faktiskt kunna baka. Det gäller samma med Thomas explicita designregler du kan bara förstå dem och ifrågasätta dem om du kan en hel del om SOA. Genom att reglerna är explicita kan de också utvecklas på samma sätt som ett bakrecept kan förfinas och anpassas till dina egna behov och egenskaperna hos din egen ugn. När de är explicita kan de också spridas så att alltfler lär sig dem och använder dem. 4

2 De åtta grundsatserna När han nu formulerar åtta grundsatser om hur tjänster ska utformas är några enklare att förstå och ta till sig och andra är svårare. När man utformar sina egna tjänster känns det rimligt att man kan resonera kring de åtta grundtankarna. Ingen av dem är svart eller vit och kan genomföras till 100 % eller helt negligeras. De fyra första grundsatserna relaterar till verksamhetsarkitekturen och härleds ur en IRM arkitekturplan 1. Återanvändbara tjänster 2. Tjänstestruktur 3. Standardiserade gränssnitt (tjänstekontrakt) 4. Tjänstekatalog De övriga fyra grundsatserna relaterar till designfasen. 5. Löst kopplade tjänster 6. Begränsa information om gränssnitten 7. Autonoma tjänster 8. Statusbefriade tjänster 2.1 Grundsats 1 Återanvändbara tjänster Låt oss ta en av grundsatserna återanvändbarhet och titta lite närmare på den. Idealt skulle det innebära att hela verksamheten har en enda tjänst som hanterar till exempel kund. Då finns kunden adress bara på ett enda ställe. Den andra ytterligheten är att vem som helst får skapa och utveckla sin egen kundtjänst och definiera kund helt efter eget tycke. De flesta håller nog med om att en gemensam kunddatabas vore önskvärt, men att det kan vara svårt att nå dit. Att ha samma data i flera olika system och databaser håller på att förlama IT utvecklingen. En allt större andel av en IT verksamhets resurser går åt att underhålla gamla system och integrationen mellan dem. Denna trend måste brytas och den viktigaste åtgärden är att undvika att hantera samma data flera gånger i olika system. Vilket i sin tur leder till att vi skickar en stor mängd data mellan olika system. Kan vi öka återanvändningen och skapa en gemensam kundtjänst kan vi uppnå stora fördelar i form av mindre kostnader (säkert mer än 50 % i de flesta större 5

verksamheter), högre datakvalité (ger bättre beslut) och kanske allra viktigast, snabbare utveckling av IT-lösningar i takt med att verksamheten utvecklas. Med en hög grad av återanvändning talar vi om 25 50 större tjänster och med en mindre grad av återanvändning och mindre tjänster talar vi kanske om 1000-talet tjänster. Detta är ett strategiskt avgörande vägval i en verksamhet som bör fattas på företagsledningsnivå. Beslutet har ett avgörande inflytande på framtida ITlösningar och verksamhetens konkurrensförmåga och förmåga att hantera framtida förändringar. Vi förordar bestämt återanvändning och ett mindre antal större tjänster. Men vad krävs för att komma dit? För att kunna skapa gemensamma lösningar krävs förstås att de kan användas av alla i verksamheten. Hittills har detta ofta förhindrats av att olika IT-lösningar funnits på olika tekniska plattformar. Detta i sin tur har förhindrat gemensamma lösningar. När nu detta hinder är på väg att försvinna vilka utmaningar finns då kvar? Vi måste basera gemensamma tjänster på datastrukturen för den är stabil och vilar på en matematisk grund. Processer är inte lika stabila och har inte samma teoretiska grund. Processer, som fokuserar på kund och kundvärden är kritiska för verksamhetens konkurrensförmåga, men processer ska inte användas för att utforma tjänster. Vi kan betrakta detta som ett strategiskt avgörande vägval av samma dignitet, som ovanstående vägval om återanvändning. Om vi nu tror på att utforma ett mindre antal större tjänster baserat på en stabil datastruktur. Hur ska vi då gå tillväga och vilka fallgropar finns det? Ja, det går med en datamodell av hög kvalité med väldefinierade begrepp. Sedan 1970 när Codd lanserade sin teori har utvecklingen släpat efter och datamodellen inte fått en självklar spridning. Det är lätt att komma in i en ond cirkel, där dåliga datamodeller inte skapar den utlovade nyttan, och därför slutar vi att ta fram datamodeller. SOA kräver en god cirkel, där vi gör bra datamodeller, som genererar den utlovade nyttan. Vi i Sverige är världsledande användare av datamodeller. Alltsedan Linné och Berzelius har struktur och en viss ordning och reda accepterats som goda värdegrunder. Se not 2. SOAs drivkrafter 6

3 Drivkrafter till SOA Innan vi går vidare med själva SOA-processen kan det vara på sin plats att titta på de drivkrafter som gör att SOA redan har fått en stor uppmärksamhet. Vi begränsar oss inledningsvis till två av dem. 3.1 Den globala konkurrensens krav på snabbhet De flesta stora företag är idag globala och möter kunder i stora delar av världen. De utsätts ständigt för allt snabbare förändringar; produkternas livscykel minskar, produktionen behöver flyttas, delar av verksamheten säljs och nya delar köps. Den viktigaste förändringen är nog ändå den ständiga utvecklingen och förändringar i verksamhetens processer. Att då ha IT-system som inte snabbt kan förändras är inte acceptabelt. Det hjälper inte att vi byter IT-chefer och CIO:er allt oftare. Något mer radikalt måste göras. Ett väl genomfört SOA-initiativ kan vara lösningen. Här har du som SOA-specialist en avgörande roll. Dels att ha en grundläggande kunskap över hela SOA-processen och dels styrkan att avstå från de genvägar, som hela tiden dyker upp. Säkerställ den goda spiralen och undvik den dåliga. 3.2 Undvik big-bang med successiva införande De flesta stora företag har en systemportfölj, som ofta kan karaktäriseras som spagetti. Till stor del självförvållat av en passiv IT-verksamhet, men också resultatet av de förändringar som beskrivits ovan. Att ta ett samlat grepp och på en gång skaffa en bättre systemstruktur lockar förstås, men misslyckas nästan alltid. Stora projekt har en genomförandefaktor som ligger nära noll och borde avskräcka de flesta företagsledningar. Ibland lyckas införandet av ett affärssystem, som ersätter ett antal enskilda system, efter stora insatser. Samtidigt riskerar man att låsa in verksamheten i standardiserade lösningar, som förhindrar utvecklingen av nya konkurrenskraftiga processer. SOA erbjuder en successiv och mera riskfri övergång från spagetti till något som den amerikanske professorn David Robertson i Lausanne beskriver som ravioli. Jämför med LEGO-bitarna ovan. Det innebär att vi använder de relativt stora tjänsterna vi förordar och skapar ett gränssnitt till de gamla systemen. Det innebär att vi kan utnyttja funktionaliteten i de gamla systemen och på så sätt utnyttja den gjorda investeringen. Något som verksamhetens ledning ger sitt fulla stöd. 7

På så sätt kapslar vi efterhand in hela systemet och alla kontakt med systemet kan ske via de nya tjänster vi skapat. Det gör inget om denna förändring tar lång tid. Vi gör den i den takt som de strategiska processerna i verksamheten kräver nya lösningar. De övriga kärnprocesserna av standardkaraktär kan vi lugnt hantera i sin befintliga och väl beprövade miljö. Detta så länge den tekniska plattform som det gamla systemet är byggt på ännu existerar och kan underhållas. 8

4 Flera grundsatser 4.1 Grundsats 2 Tjänstestrukturen De olika tjänsterna kan förstås inte vara helt oberoende av varandra men vi vill så långt möjligt skapa en tjänstestruktur som fungerar så effektivt som möjligt. Den del av tjänstestrukturen som hanterar objekttjänster härleder vi direkt ur den IRM Arkitekturmatris vi tagit fram i en Arkitekturplan. Där har vi angivit hur de olika objektgrupperna eller tjänsterna är beroende av varandra. Vi skiljer på masterdata (kund, produkt etc) och händelsedata (kundorder, bemanning). Masterdata har inbördes mycket begränsade beroende till andra tjänster; däremot är händelsedata alltid beroende av en eller flera masterdata-tjänster. Utöver objekttjänster har vi olika infrastrukturtjänster som hanterar till exempel loggning, säkerhet, meddelande eller avvikelser. De kallas ibland utility-tjänster eller tekniska tjänster. Vi återkommer till tjänstestrukturen och hur denna påverkas av de andra grundsatserna när vi gått igenom dessa. 4.2 Grundsats 3 Standardiserade gränssnitt Gränssnitten (kontrakten) talar om hur vi kommunicerar med våra tjänster. Varje kommunikation kräver oftast ett gränssnitt som vi sänder till tjänsten och ett gränssnitt när vi får svar av tjänsten. Gränssnitten ska vara publicerade och så stabila som möjligt. Det innebär att vi inte vill ändra dem så snart något nytt behov att kommunicera med tjänsten dyker upp. Är då tjänsten baserad på en väl normaliserad datamodell kan också gränssnitten göras stabila. Vi vill undvika att ha en stor mängd gränssnitt för varje tjänst. Vi vill åstadkomma gränssnitt som täcker flera olika kommunikationsbehov. Idealt vill vi därför också göra gränssnitten så stora som möjligt, det vill säga när vi ber att få läsa någon del av tjänstens information får vi till svar allt som vi är behöriga att läsa. Samtidigt är det en avvägning gentemot svarstid och komplexitet, där vi vill öka sannolikheten för att gränssnittet ska gå att återanvända. Att definiera tjänsterna är en del av processen för att ta fram en verksamhetsarkitektur. Tjänsterna baseras på en övergripande datamodell för verksamheten. Även gränssnitten bör definieras som en del av verksamhetsarkitekturen. Där finns en större överblick än i de enskilda projekten och deras kravspecifikationer. 9

Att tvingas ändra i redan publicerade gränssnitt och skapa nya versioner är ett tecken på att vi inte gjort förarbetet ordentligt. Versionshantering är något som kräver stora resurser och lätt genererar fel, så låt oss undvika detta genom att göra rätt från början. 4.3 Grundsats 4 Tjänstekatalog Efterhand som tjänster etableras är det viktigt att dokumentera dem och göra dem tillgängliga. Ett viktigt syfte är förstås att de ska återanvändas och ingen ska behöva skapa en tjänst som redan finns. Ett alternativ (som sällan nämns) är förstås också att komplettera en tjänst som redan finns med ny funktionalitet eller ett nytt gränssnitt. Tjänsterna är relaterade till den övergripande datamodellen, så det är lätt att se vilken tjänst, som behöver hanteras i en ny funktion. Verksamhetsarkitekten bör ansvara för tjänsteförteckning och göra den tillgänglig för alla i verksamheten. Vid en gemensam analys bedöms om existerande tjänst täcker behovet eller behöver kompletteras. Om existerande gränssnitt täcker behovet eller nya gränssnitt behöver tas fram. Alternativt kan det vara frågan om att skapa en helt ny tjänst. I en tjänsteförteckning bör också redovisas hur antalet tjänster och tillhörande gränssnitt växer och hur graden av återanvändning utvecklas. Grundsatserna 5 8 nedan baseras på tidigare grundsatser och hanteras under designfasen. 4.4 Grundsats 5 Löst kopplade tjänster Grundsatsen innebär att vi kan kommunicera med tjänsten helt oberoende av teknisk plattform. Håller vi oss bara till det publicerade gränssnittet har det ingen betydelse vilken teknisk plattform som tjänsten hanteras på. Detta är direkt baserat på utvecklingen av WEB Services. Det är också viktigt att minimera beroende mellan olika tjänster. Det gör vi enklast genom att bara hantera samma data i en tjänst, på det sättet som vi beskrivet ovan. Skulle vi däremot tillåta varje projekt att själva skapa sina tjänster och sina gränssnitt riskerar vi snabbt att hamna i en spagettisituation som är lika illa som den vi försöker frigöra oss ifrån. Den optimala SOA-strukturen med minimalt beroende mellan tjänsterna härleder vi från IRM-matrisen, där vi markerar beroende mellan olika objektgrupper. IRM-matrisen ingår som en del av arkitekturprocessen. 10

4.5 Grundsats 6 Begränsa information om gränssnitten När vi beskriver gränssnitten ska vi begränsa informationen om gränssnitten så mycket som möjligt. Detta för att kunna behålla frihetsgraden i tjänstearkitekturen. Information vi ska undvika att publicera är teknisk information, funktionell information, programlogik eller kvalitén på tjänsten som till exempel SLA (Service Level Agreement). Varje gång vi vill förändra eller vidareutveckla något som vi redan har publicerat får vi problem. 4.6 Grundsats 7 Autonoma objekttjänster Grundsatsen innebär att vi ska sträva efter maximal självständighet. Om vi utgår ifrån att vi har byggt vår tjänstestruktur baserat på en övergripande datamodell av hög kvalitet kan vi också uppnå en hög grad av självständighet. För de objekttjänster som är av typen masterdata, som kund och produkt, är självständigheten stor. För de entitetstjänster som är händelsetjänster finns ett beroende till berörda masterdata. Kundorder har till exempel beroende till kund och produkt. Skapar vi processtjänster har de beroende till alla de tjänster som hanteras i processen. Alternativet att varje process eller projekt bygger egna helt självständiga tjänster visar sig ge dålig återanvändning och stort underhåll. Ett antal publicerade praktikfall visar att detta bör undvikas. Inkapsling av gamla system för att kunna ta tillvara investeringen och göra successiva avvecklingar kan ge problem för självständigheten hos berörda tjänster. När inkapsling ska göras är det viktigt att noga begrunda tjänsternas autonomi. Försök att med olika åtgärder bibehålla självständigheten hos tjänsterna. 4.7 Grundsats 8 Statusbefriade tjänster När vi till exempel ska hantera en kundorder löper den igenom flera olika steg, som att hitta kund, skapa orderhuvud och skapa de orderrader som behövs. Bearbetningen kan hänga upp sig genom att man till exempel inte hittar en viss produkt. Ska vi då spara status och vänta på åtgärd kring den sökta produkten. Nej det bör vi inte göra om vi ska följa grundsatsen. Då tappar vi lätt kontrollen över tjänsten och dess prestanda. Försök lösa det på annat sätt. Amazon och flera andra WEB-siter löser det genom att först skapa orderrader i en särskild tjänst och sedan gå vidare och skapa orderhuvud och lösa betalning är nöjd med sina orderrader. 11

En tjänst kan under en session förändras från status- lös till mer eller mindre status- full. När tjänsten anropar en annan tjänst är den statusfull tills den fått sitt svar från den anropade tjänsten. Det är svårt är att backa i en processtjänst om något gått fel. En reseprocess där flyg, hotell och hyrbil bokas och betalas separat blir mycket besvärlig att backa om någon del inte kan lösas. 4.8 Mera om grundsats 4 Tjänstestruktur Den ideala tjänstestruktur som vi härleder direkt ur IRM-matrisen kan behöva justeras av designskäl eller av driftsskäl. Erl har gjort en grundlig genomgång av hur varje grundsats påverkar tjänstestrukturen under på designfasen och driftssättning. Att göra dessa bedömningar är viktigt och Erl rekommenderar att man noga testar en ny tjänstestruktur innan man slutför design eller driftssättning. 12

5 Fördelar med SOA Om man lyckas väl med SOA finns det flera fördelar gentemot ett traditionellt sätt att hantera IT-lösningar. Många går in i varandra, men vi försöker renodla de viktigaste. I sin bok behandlar Erl detta i kapitel 3.3 och 16. 5.1 Minskade IT-kostnader Återanvändning av tjänster ger stora kostnadsbesparingar. Att ha flera olika system som hanterar samma data är onödigt. Vi kan enklast följa detta genom antalet svarta prickar i en systemmatris. Vi markerar här vilken data som varje system hanterar. Genomsnittligt hanteras samma data 5 gånger grundat på våra genomgångar av hundratalet skandinaviska större företag. Minskar vi till i genomsnitt 2 har varje företag sparat miljontals kronor. Räkna ut vad varje prick kostar att hantera kan vara 1 10 miljoner per år. Minskar du antalet prickar med hälften genom att återanvända tjänster är det en besparing på 100-tals miljoner. Glöm inte att det finns en initial investeringskostnad! 5.2 Frigör IT-resurser Att underhålla och integrera ett stort antal onödiga IT-lösningar hotar att lamslå många IT-verksamheter. Alla resurser går åt till detta värdelösa arbete; dvs ett arbete som inte skapar något ökat värde i verksamheten. Det blir inga över som kan utveckla nytt IT-stöd åt nya affärsmodeller och processer. IT-verksamheten blir en propp i försöken att öka eller åtminstone behålla konkurrenskraften i verksamheten. 5.3 Ökad konkurrenskraft och snabbare utveckling När nu all data bara behöver hanteras en gång i en tjänst går det snabbt att förse nya processer med ändamålsenligt IT-stöd. Det sätter fart på processutvecklingen. Vi kan sträcka ut processerna mot både kund och leverantör. Vi kan göra kundspecifika processer. Vi kallar detta orkestrering och det skapar en väldig flexibilitet och smidighet. Det nya modeordet för detta är agility. Denna agility får inte förväxlas med agila metoder. Dessa skapar ingen agility, men kan ha sina fördelar när snabbheten är viktigare än långsiktigheten. 13

5.4 IT en möjliggörare Många betraktar idag IT som en belastning för verksamheten och dess utveckling. Det tar lång tid och är kostsamt att få fram nya IT-lösningar. SOA erbjuder ITverksamheten att istället bli en möjliggörare, som aktivt kan bidra till att uppnå verksamhetens mål och visioner. Släpp processerna loss, det är vår. 5.5 Standard skapar kvalitet När samma data hanteras en gång i en tjänst istället för flera gånger i olika ITsystem skapar detta en standard, som gör det möjligt att öka datakvalitén i verksamheten. Detta skapar ett förtroende för informationen och de beslut, som ledningen fattar baserat på tillgänglig information. Idag genererar olika system olika beslutsunderlag, som skapar osäkerhet och kräver extra och resurskrävande utredningar om vilken information som kan vara riktig. 5.6 Minskad risk när big-bang undviks Verksamhetsledare vill undvika onödiga risker. Att ersätta ett gammalt legacysystem i ett stort big-bang-projekt där hela skiftet ska ske vid ett enda tillfälle är alltid mycket riskfyllt. Erfarenheter visar att sannolikheten att lyckas är nära noll! Att kapsla in legacy-systemen och kunna göra en stegvis ersättning är därför mycket lättsålt. Särskilt som man i stora företag ofta har egna exempel på misslyckade big-bang-projekt. Var noga med att göra det i två steg där nya tjänstestrukturen skapas först och i steg två frigöres tjänstens funktioner från legacysystemet. Allt för att reducera risken och undvika dåliga implementationer. 14

6 Avrundning Konsten att förstå en röd tråd kräver tålamod och ödmjukhet. Hönan och ägget Den röda tråden är svår att förstå innan man känner till de olika delarna. Samtidigt är de olika delarna svåra att förstå om man inte ser sammanhangen. När vi efterhand fördjupar de olika delarna ska vi hela tiden försöka relatera till den röda tråden. Vi ska också redovisa de alternativa synsätt som olika aktörer förordar, som till dels avviker från vårt synsätt, men ibland mest beror på annat språkbruk eller en annan utgångspunkt för resonemanget. En metamodell som beskriver de olika begrepp man använder tydliggör vad man menar. En metamodell är en datamodell över en verksamhet i det här fallet SOAverksamheten. Många av begreppen i SOA kommer från tekniksidan och kan vara svåra att förstå om du själv kommer från verksamheten. IRM:s metamodell finns publicerad på http://www.tdan.com/i039fe04.htm 15

7 Fotnoter 7.1 The Knowledge Creating Company Den japanska professorn Ikujiro Nonaka skrev 1995 en mycket uppmärksammad och diskuterad bok om hur kunskap kan hanteras. Hur japanska företag som till exempel Toyota mycket ambitiöst hanterar kunskap. Det mest bestående modellen är hur kunskap och information hela tiden transformeras från tyst kunskap (bagaren som knådar degen) till explicit kunskap (ett nedskrivet recept) och omvänt. Den som använder den explicita kunskapen får på så sätt ny tyst kunskap som igen kan justera och utveckla den explicita kunskapen. Vi västerlänningar tar ofta alltför lätt på hur svårt det är att skaffa sig tyst kunskap. Vi hade en gång i tiden ett avancerat lärlingssystem, som vi till stora delar monterat ner. Men vi ser också tecken på hur vi försöker återinföra det. Olika mentoransatser, som till exempel Ruter Dam, är ett bra exempel på detta. Här är det företagsledare som avsätter tid att stödja kvinnor, som vill nå ledande positioner. Om du vill bli duktig i SOA bör du se till att få arbeta nära dem eller lära av dem, som redan har god kunskap och erfarenhet. 7.2 DM Competence Network Ett nätverk, (DM Competence Network) för att vidareutveckla datamodellering har i slutet på 2007 etablerats med deltagande ledande svenska företag (Ericsson, H&M, IKEA, Saab m fl). Nätverket har också knutit till sig ett antal noga utvalda globala experter på området inklusive Bo Sundgren, svensk professor på området. Syftet är att vidareutveckla och sprida datamodellering som en viktig metodik och arbetssätt. Nätverket leds av DAMA Chapter Scandinavia, som ingår globala DAMAnätverket (DAta MAnagement). John Zachman var en av initiativtagarna i slutet på 80-talet. Ett 50-tal Chapters finns nu runtom i världen, där det senaste i Kina nu etableras med stöd från Chapter Scandinavia. Röda tråden för SOA är framtagen i januari 2008 av Eskil Swende, IRM. Synpunkter och förslag kan du maila honom på eskil.swende@irm.se 16