”Affärsfolk har spaghettihuvuden”

Bloggande terriern har härmed glädjen att presentera sin första gästbloggare. Herbjörn och jag har träffats en del på konferenser. Han berättade i veckan att han hade gjort en intervju med Jim Webber på Thoughtworks som för närvarande inte fanns på nätet och undrade om jag ville publicera den. Det vill man ju inte undanhålla sina läsare! Håll till godo.

– Joakim

”Affärsfolk har spaghettihuvuden”

av Herbjörn Wilhelmsen

Som arkitekt eller utvecklare försöker vi kämpa emot komplexitet i alla dess former. Det är sällan framgångsrikt och enligt Jim Webber som leder brittiska konsultbolaget ThoughtWorks globala arkitektursatsning är det inte heller ändamålsenligt.

Att förstå affärsprocesserna är en utomordentligt viktig förutsättning för att kunna bygga en tjänstearkitektur, Service Oriented Architecture – SOA, som verkligen stödjer verksamheten.

-Om du inte involverar affärssidan så vet du inte om du gjort rätt eller om du gjort fel. Med SOA får vi chansen att spegla affärsprocesserna i systemen så att de kan förändras och utvecklas på ett samordnat sätt.

Oberoende av teknik så baseras en bra SOA på en god förståelse av affärsprocesserna . När den förståelsen ökar kommer också förståelsen om vilka tjänster som behövs öka.

IT-proffs vill ofta minska spaghettin i system samtidigt som de önskar att bygga system som avbildar verksamhetens behov på ett bra sätt. Dessa två önskemål står i konlikt med varandra. Jim Webber förklarar:

-Affärsfolk har spaghettihuvuden, och det menar jag på ett sympatiskt och medkännande sätt. IT-proffs tänker mer i abstraktioner, olika lager i lösningarna och framförallt gillar vi raka linjer i systemkartorna. Affärsfolket däremot arbetar ute i den verkliga världen. Vi sitter i en europeisk stad och jag kan inte se en enda rak gata utanför, för så fungerar det i den verkliga världen. Det är rörigt, grötigt och spaghettiaktigt.

Jim Webber hanterar spagetti

Jim Webber är van vid att hantera spaghetti

Nya och mer eller mindre slumpmässiga kontakter är en viktig del i det som för affärerna framåt. De kontakterna kan vara, och är ofta, annorlunda än den egna verksamheten. En beskrivning av en sådan rörig verklighet kan kännas motbjudande för många IT-proffs . Deras omedelbara reaktion är att försöka räta ut spaghettin, men detta lyckas sällan och om det lyckas tillför det inte så mycket värde. Så istället för att försöka få bort all spaghetti behöver vi en spaghettivänlig integrationsstrategi – och det är just det SOA är enligt Jim Webber.

Organisationer har alltid varit intresserade av företagsövergripande arkitektur, s.k. Enterprise Architecture, det är det som får affärsverksamheten att fungera ihop med IT-stödet. Enligt Jim Webber är lösningen på problemet enkel:

-Vi borde sätta affärsfolket in i förarsätet som arkitekter. Att uppnå verklig Business Agility är endast möjligt om affärsprocesserna avbildas i tjänsterna så att när en process ändras så kan tjänsterna ändras på samma sätt.

Det är inte nödvändigtvis enkelt att bygga en SOA på det sätt som Jim Webber förespråkar, eftersom det kräver hårt arbete och omfattande ingenjörskunskaper. Målet är att ekosystemet av tjänster som produceras enkelt och rättframt matchar det som verkligen pågår i affärsverksamheten. Alternativet är knappast önskvärt:

-I den värsta av alla världar går affärsverksamheten och IT-systemen i olika riktningar. Det gör det svårt att föra ihop dem för det gemensamma syftet som självklart är att skapa affärsnytta.

Fakta: Dr Jim Webber har en doktorsgrad i högpresterande databehandling (high performance computing) men har efter sin akademiska karriär fokuserat på informationsintensiva system, Web Services och SOA. Han höll ett föredrag om ”Guerila SOA” på konferensen Developer Summit i Stockholm 2008 och intervjuades i samband med denna konferens. Intervjun spelades in och återfinns här.

5 thoughts on “”Affärsfolk har spaghettihuvuden”

  1. Jag saknar själv erfarenhet av att utveckla SOA-lösningar men tilltalas av idén med system som överlever dagens affärsprocesser. Tyvärr gör många av SOA-förespråkarna ett utomordentlig jobb med att skrämma iväg alla oss lättrörliga förespråkare. Senaste exemplet var ju SOA-manifestet (Herbjörn hoppas att mina åsikter inte framstår allt för påhoppande) som (upplever jag det) pekar med hela handen tillbaka till den verklighet vi “vanliga” utvecklare levde i för 10 år sedan.

    Jag är övertygad om att det borde gå att pragmatiskt utveckla tjänster som uppfyller SOA-kriterierna utan att behöva bromsas fullständigt av den trägenhet efter strategi och generalism som genomsyrar manifestet. Jag vet att det finns kritiska röster mot stora delar av manifestet även inom den etablerade SOA-världen (och utanför) så det är inte bara jag som inbillar mig. Det vore underbart om vi kunde hitta en spelplan där vi kan blanda “business agility” med “development agility” för jag kan inte tänka mig att dessa koncept skall vara uteslutande.

    Mvh

    • Jag såg just att Jim Webber hade uttryckt tankar liknande mina, dock något mindre inlindat i sitt blogginlägg om Snake Oil Association. Det är glädjande att se krafter som verkar mot den bild som presenteras av (i första hand) ESB-månglarna. Det vore roligt om detta också var den spontana bilden man fick av SOA, då vore nog halva arbetet, som jag efterlyste ovan, redan gjort.

      Mvh

  2. Morgan

    SOA Manifesto använder samma format som Agile Manifesto, dvs att man visar vad man värdesätter genom att göra ett svårt val. Projektmål och taktik är bra och vi borde sträva efter det. Men om det strider emot strategin så får vi tänka oss för. Om detta projektmål ger mycket affärsvärde och inte går att implementera med nuvarande strategi så får man kanske ändra strategin (första värde-satsen i manifestet) – om inte så får det projekt-specifika målet ge vika (andra värde-satsen). Om man alltid prioriterar taktiskt kan det bli mycket svårare att förändra det sätt som företaget gör affärer på i ett senare skede. Om man prioriterar endast vad som skall göras i ett projekt är det dessutom svårt att ha en god översikt över vad som borde gagna företaget som helhet, man suboptimerar – inte för att man är korkad men för att man inte fokuserar på helheten. Om man endast ser den stora bilden är det svårt att ta tillvara alla de goda möjligheterna som finns på kort sikt och som kan leda till många bra saker i förlängningen – t.ex. att företaget överlever. En svår balansgång – som vi försöker visa med de två första värde-satserna.

    Angående “ESB-månglare” så var det kanske några sådana med i skrivandet av manifestet. Men det är enligt min åsikt fel att döma ut manifestet av den anledningen. Det som fått mest kritik (som jag sett) är uttrycket “Intrinsic interoperability”. Anledningen är att det har tolkats som en uppmaning att köpa en ESB. Detta är helt fel tolkning av begreppet så som vi diskuterade det när manifestet togs fram. Vi pratade snarare om att från början designa tjänsterna med interoperabilitet i åtanke. Detta betyder att men skall försöka underlätta för en tjänst att anropa en annan tjänst. Eller underlätta för en klient att anropa två tjänster. Att skapa återanvändbara tjänster är mycket svårt och kanske inte värt mödan, men att inte tänka på interoperabiliteten gör det mycket svårare att återanvända tjänster eller göra nya klienter som använder flera tjänster etc.

    Om man inte tänker på interoperabiliteten så kommer man i slutändan har tjänster som exponerar gränssnitt på olika sätt; .Net remoting, JMS, filöverförningar, Web Services (med Java eller .Net smak), REST (med Java eller .Net smak), FTP, AMQP, SMTP… En annat vanligt problem är att översättningar mellan olika datastrukturer blir mycket komplicerade; många specialfall, några specialfall kan hanteras här, andra där. När allt detta inträffar har “ESB-månglarna” mycket goda förutsättningar för att göra stora affärer!

    /Herbjörn

  3. Tack för ditt uttömmande svar Herbjörn. Jag har inte för avsikt att göra Jockes blogg till ett forum för en utdragen debatt om de ingående komponenterna i SOA-manifestet (en debatt som jag för övrigt antagligen inte skulle gå i mål med ändå om man ser till din gedigna bakgrund i ämnet kontra min lekmannavy). Det finns dessutom ett antal betydligt mer insatta människor än jag som för en bättre argumentation runt dessa punkter ute på nätet (bland annat Dr Webber).

    Jag vill dock understryka den efterlysning som jag gjorde i mitt första inlägg, efter en gemensamma grund där vi kan låta “agile business” och “agile development” mötas. För oavsett vilka intentioner som fanns när SOA-manifestet skrevs så har det inte lyckats förmedla någon lättrörlig och/eller pragmatisk syn på utveckling med tjänsteorienterade arkitekturer till mig och många andra. Tvärtom så har det ytterligare cementerat synen på SOA som ett väldigt tungrott skepp som kommer att dra stora resurser innan det börjar generera några intäkter. Jag vägrar tro att det skall behöva vara på det sättet; att man skall behöva designa för alla eventualiteter för att få kalla det SOA. Jag tycker att Webber uttryckte det bra med “Re-use is great, but I’ll start with use and move on from there.”. Innan vi börjat köra en första version av vårt applikation så är det irrelevant hur väldesignat systemet är. Eller som en gammal kollega till mig uttryckte det till kunden; “Bortsett från att det inte funkar, hur tycker ni att det verkar?”.

    Mvh

    Morgan

  4. Morgan

    Först vill jag bara säga att jag tycker det är synd att manifestet upplevs kommunicera en tungrodd syn på SOA. Jag håller med Jim Webber i väldigt många avseenden, att börja leverera värde tidigt är en synpunkt vi delar. Jag försöker praktisera detta hela tiden. För mig finns inte denna tungrodda syn med i manifestet. Den sista värde-satsen säger att vi inte borde försöka skapa perfekta tjänster första vändan utan snarare använda tid och den erfarenhet vi kan samla på oss genom att observera hur tjänsterna används till att få fram bättre tjänster – genom evolution helt enkelt. Helt i linje med att leverera värde tidigt.

    Om SOA blir tungt och komplicerat borde orsaken till detta vara att den verklighet vi försöker hantera är komplicerad. Att hantera tjänster som skall kunna användas tillsammans (en konsument skall enkelt kunna använda flera tjänster) eller tjänster som har flera användare (dvs återanvändning) är svårt: Att komma överens med andra är något av det svåraste som finns, och ju fler som skall vara överens ju svårare är det. Att ha en omfattande strategi när man skall lösa ett litet problem är inte ändamålsenligt, men när många skall komma överens kommer det som ett brev på posten att vi måste kompromissa.

    Eftersom detta är svårt skall man vara noga med vad man behöver komma överens om. Att komma överens om väldigt mycket är att be om problem. Men att inte komma överens om någonting är också att be om problem.

    Agil utveckling är jättebra, agil arkitektur är också jättebra. Och de kan existera tillsammans. Men de kan inte (dvs ingen av dom) agera som om den andra inte fanns. De som utvecklar tjäsnter måste ta hänsyn till arkitekturen som finns utanför själva tjänsten. De som jobbar med övergripande arkitektur måste ta hansyn till hur tjänster implementeras. Både arkitektur och implementation måste utvecklas och gå hand i hand. Annars går det illa.

    PS SOA Manifestet skrevs på samma format som det Agila Manifestet och detta format har en svaghet: Det går att tolka på många olika sätt. Innan året är slut kommer mer information om hur författarna till SOA Manifestet tolkar de olika delarna i manifestet att publiceras.

    /Herbjörn

Comments are closed.