av Jason Bloomberg och Ronald Schmelzer.
Boken ”Service Orient or Be Doomed!” är ett efterlängtat undantag från alla de teknikböcker om SOA som hittills publicerats. ”SOA handlar om kultur inte om teknik”, framhöll Anne Thomas Manes nyligen vid sitt besök i Stockholm. Hon är SOA-analytiker vid Burton, en nischad konkurrent till Gartner.
Författarna till boken, Jason Bloomberg och Ronald Schmelzer, inser också, trots sin tekniska bakgrund, att det är på verksamhetssidan den stora utmaningen finns. Den första delen av boken ger en ingående beskrivning av hur illa det ser ut idag i många verksamheter och hur vi hamnat där. Hur vi under lång tid byggt upp en besvärlig och resurskrävande integration mellan olika system och där flera system ofta hanterar samma data och funktioner. En situation som flertalet svenska CIOer är väl medvetna om.
Finns det någon arkitekt på plats
Att arkitektur är en del av SOA framgår av namnet Service Oriented Architecture, men den delen av begreppet har hittills fått väldigt lite uppmärksamhet. I den här boken ges den däremot stort utrymme, när man ska ta itu med att rensa upp i dagens tilltrasslade systemstruktur. Det är naturligt att man tar utgångspunkt i Zachman Framework för verksamhetsarkitektur, som lanserades av John Zachman redan 1979 och sedan dess har nått en global acceptans. Den ger en fyllig beskrivning med de olika interrogativen ”varför, hur, vad, vem, var och när” i sex kolumner. De översta raderna är verksamhetsinriktade och hanteras av en verksamhetsarkitekt och de undre raderna är mer tekniska och kan hanteras av en IT-arkitekt.
Svenska arkitekter på plats!
En arkitekturplan är inte tillräckligt; det krävs också kompetens och disciplin att följa planen. Bristen på arkitekter kan hota hela genomförandet av SOA menar författarna. Här i Sverige är vi lyckligt lottade. Vi har genom Dataföreningens försorg idag 1000-talet certifierade verksamhetsarkitekter och IT-arkitekter på plats!
Varför behöver vi arkitekterna
Ett SOA-projekt är inte ett typiskt IT-projekt. Ett typiskt IT-projekt startar med ett antal spikade verksamhetskrav, påstår författarna något överdrivet. I ett SOA-projekt måste lösningen även ta hänsyn till framtida krav. Ett arkitekturarbete som tar sin början i verksamhetens affärsidé och utvecklar de verksamhetsprocesser som kan skapa motsvarande kundvärden är en god början. Den verkligt viktiga kolumnen i Zachman är vad-kolumnen. Här har vi en matematisk spårbarhet skapad av den engelska matematikern Ted Codd. Med en datamodell över verksamheten kan vi spåra att realiseringen i utvecklade eller upphandlade databaser stämmer med arkitekturplanen, denna spårbarhet gäller inte för andra kolumner. Så kan vi åstadkomma samverkan mellan IT och verksamheten.
CIO:n etablerar arkitekturfunktioner
För att verksamheten ska bli framgångsrik med ett SOA-införande är det absolut nödvändigt att man har ett antal personer som hanterar verksamhetsarkitekturen. Dessa bör rapportera direkt till verksamhetens CIO. Verksamhetsarkitekten måste få fram arkitekturplaner och säkerställa att de genomförs, t ex genom kontrakt mellan verksamhet och IT.
Återanvändning
”Reuse does not happen by accident” är ett av John Zachmans träffsäkra uttalanden. Istället för att dela kod, delas i SOA fungerande tjänster. Vi behöver etablera en särskild fristående ”SOA-fabrik”, som utvecklar återanvändbara tjänster. Även här kan CIO:n spela en avgörande roll.
Svårt och komplext
Trots svårigheterna har vi inget alternativ till SOA. Konceptet stöds idag av samtliga globala IT-aktörer. De verksamheter som lyckas med SOA kommer att blomstra, medan de som misslyckas är dömda, avslutar författarna.