SOA for borddamer (eller din direktør)

Sæsonen for grill-aftener, sommerfester og pinse-frokoster er over os. Tid til at møde nye mennesker eller gamle skole-kammerater ? tid til igen at skulle forklare hvad du egentlig går og laver. Dorte Toft har skrevet om det, jeg har fortalt om det og du har jo også oplevet det: Det fjerne blik og lidt stivnede smil når du entusiastisk fortæller om dit seneste SOA-projekt.

For hvordan gør du SOA bare en smule nærværende og interessant for ikke-it folk? Her er et bud:

Citat:

SOA er en meget succesfuld måde at understøtte en virksomhed på ? forudsat, naturligvis, at virksomheden arbejder med services.

Der er to ting jeg godt kan lide ved definitionen

  • Den er aldeles fri for teknik- og it-termer og derfor kan den formidles til andre end it-folk.
  • Den indeholder en væsentlig forudsætning for at SOA kan blive en succes, nemlig at forretningen allerede arbejder med services - eller har et presserende behov for at arbejde med services

For at tage det sidste (og mindst borddame-relevante) først: Hvis en virksomhed ikke arbejder serviceorienteret, fx hvis arbejdsgangene er tænkt i siloer eller i batch, har vi allerede en risiko for at gå galt i byen med en SOA. For hvorfor implementere en arkitektur, der faciliterer services, hvis forretningsprocesserne ikke kan udtrykkes i transaktionelle services? Eksemplet her kunne være månedlige pensionsudbetalinger til en masse mennesker.

Nu er det et stykke tid siden jeg har været ude for at skulle fortælle om mit arbejde til ikke-it folk, så jeg er nok noget rusten i at udtrykke SOA sexet. Har du et bedre bud?

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Liliendahl Sørensen

Generelt skal man jo passe på med at sige, at man arbejder med IT, når man er ude til private fester. Det plejer nemlig at betyde, at man straks bliver forsøgt shanghai’et til at tilslutte en gammel printer til den nye hjemme PC.

Jeg er dog så heldig, at jeg kan fortælle, at jeg laver små programmer som kan puttes ind alle steder og som kan vaske data. Altså rengøring. Se, det er noget alle sidekammeraterne kan følge og har brug for.

  • 0
  • 0
Jon Bendtsen

Generelt skal man jo passe på med at sige, at man arbejder med IT, når man er ude til private fester. Det plejer nemlig at betyde, at man straks bliver forsøgt shanghai’et til at tilslutte en gammel printer til den nye hjemme PC.

Så send dem en regning? For de forventer vel ikke at du arbejder gratis? Ellers kan de jo passende vaske tøj, gøre rent, eller andet for dig.

  • 0
  • 0
Marc de Oliveira

Uha, jeg synes der er problemer med begge dele af din definition:

1) "SOA er en meget succesfuld måde at understøtte en virksomhed på"

Er det nu også det? Det er en meget moderne og anvendt måde at understøtte en virksomhed på, men jeg har hørt om så mange problemer med SOA-projekter, at jeg ikke finder ordet "successfuld" velvalgt.

2)"forudsat, naturligvis, at virksomheden arbejder med services"

Uha uha! "services" er måske nok et ord, som mange mennesker kender, men jeg er ret sikker på, at de fleste du skal snakke med omkring grill'en ikke tænker på det samme som dig. De vil tænke på frisørsaloner, rengøring, undervisning osv og så er du lige langt.
Og forøvrigt... Kan argumentet ikke vendes om? Hvis din virksomhed allerede er serviceorienteret, hvad er så værdien i at omprogrammere det hele til SOA? Jo, chancen for at gennemføre projektet er større, når du bare skal gentage det, der allerede findes, men betyder det, at det også er der den største værdi kan hentes? Ikke nødvendigvis.

  • 0
  • 0
Henrik Jensen

Måske du skulle droppe SOA begrebet helt, for SOA er jo ikke målet, SOA er blot værktøjet, og det er måske det værktøj er er in lige nu, men hvad med om 3-4 år, der er det måske erstattet af endnu smartere ellere endnu mere hypede værktøjer.

Det er lidt ligesom hvis du er tømmer så starter du formentligt heller ikke med at forklare hvilke værktøjer du benytter, men fokuserer mere på selve udestuen du bygger

Så et forslag kunne i stedet værre:

Jeg hjælper organisationer med at implementere løsninger så de kan understøtte deres forretnings-processer på en hensigtsmæssig måde via brug af IT (Kan i den enkelte situation udskiftes med computerteknologi hvis ordet IT synes for ambitiøst) og som samtidigt er med til at sikre at de bedre kan modstå fremtidige forandringer i forretningen.

Og hvis du sporer udbredt forvirring frem for interesse så kan du evt. forsætte med:

Det er lidt ligesom sælgeren i radio/tv afdelingen i Bilka som rådgiver dig om at hvis du køber et minianlæg hvor at CD, radio og forstærker er samlet i én enhed så har du ikke den samme fleksibilitet som hvis du køber et HI-FI anlæg med separate enheder som kan udskiftes hver for sig og som kan placeres ved siden af hinanden eller oven på hinanden alt efter behov...... bare lidt mere avanceret. :-D

Det gode ved ovenstående forslag er at du kan benytte det samme om 3 år når "værktøjet" måske ikke hedder SOA men noget helt andet men målet er det samme. Så slipper du også for at en eller anden til sommerfesten faktisk kan huske hvad du sagde, og så stiller spørgsmålet "Jamen for 3 år siden forklarede du mig at SOA var det eneste rigtige, hvad har ændret sig?"

  • 0
  • 0
Peter Nørregaard Blogger

@Marc, måske skulle jeg sige ”naturlig” i stedet for ”succesfuld”. Det er i hvert fald mere objektivt, selvom objektivitet sjældent gør sig godt i selskabelige sammenhænge. At understøtte en service-orienteret virksomhed med en service orienteret arkitektur er jo ret naturligt.

I dag består understøttelsen typisk af indtastningsbilleder og rapporter i forskellige heterogene systemer, som ikke understøtter services og som kun kan bruges forskellige steder i en service-proces. Først når udvalgte processer understøttes, kan en virksomhed virkelig opnå værdi. Om der så skal en BPR / BPI til før processerne er, som de burde være, er en anden sag.

Men du har ret i at ordet ”services” ikke gør borddamen meget klogere. Jeg får næsten lyst til at melde afbud til den grillfest :-)

  • 0
  • 0
Lars Hansen

Har du overvejet at bruge legoklodser som en metafor?

Noget med at SOA handler om at få skåret IT-systemerne op i nogle mindre bidder (á la legoklodser)

Det giver så de fordele at man kan kombindere legoklodserne på forskellige måder, og at de individuelle legokloder er meget nemmere at håndtere end det store system.

Hvis man skal trække den helt ud, så kan man jo også bruge klodser fra andre leverandører, såfremt de er tilpas standardiserede.

  • 0
  • 0
Morten Hattesen

Legoklods-analogien ("man kan kombindere legoklodserne på forskellige måder") er da fantastisk til at sælge SOA.

Men det er kun 10% af historien. For det fortæller intet om, at for at der reelt skal bygges en speciel "adapter-klods" som gør at den blå og den grønne klods kan sættes sammen. Fordi den grønne klods har 5 runde knopper med en indbyrdes afstand på 12,7 mm, mens den blå har 6 sekskantede knopper med en indbyrdes afstand på 10 mm.

Hvis du fortalte det, ville borddamen spørge:
"hvorfor bliver man ikke bare enige om, at alle knopper skal have samme størrelse, form og afstand".

Og hvad ville du så svare? Mske:

  • "Det ville sætte urimelige begrænsninger for klodsdesignerens udtryksmuligheder"
  • "Klodsmajorerne ikke at gøre det alt for let at sætte klodser fra andre klodsmajorer sammen med deres"
  • "Det ville kræve at klodsmajorerne ville blive enige om en åben standard, og det vil nok tage 10 år at få igennem"
  • "Fordi så ville jeg ikke kunne tjene er formue på, som konsulent, at udvikle abstrakte klods-adaptorer"

;-)

  • 0
  • 0
Peter Nørregaard Blogger

@Morten, det lyder som om jeg er ved skabe mig nye problemer ved at bruge lego-klods metaforen. SOA er jo ikke lego-klodser - SOA faciliterer at logoklodser udstilles, kan sættes samme og at deres service-level overvåges. Og så sørger SOA for at sikkerheden omkring brugen af legoklodser er i orden. Med andre ord: SOA fremstår som alt andet end det sjove ved legoklodser :-D

@Martin, hvis min borddame er, som de fleste andre borddamer, bliver jeg næppe udfordret på hvad SOA er. Som Henrik siger, så er SOA som mål i sig selv jo netop ikke interessant. Forretningen/ direktøren / borddamen er mest interesseret i hvad SOA kan gøre – ikke hvordan.

Jeg kan faktisk godt lide Henriks definition til grill-brug, måske peppet op med nogle (lånte?) påfuglefjer til den festlige lejlighed á la:

Jeg hjælper organisationer med at implementere løsninger så de kan understøtte deres forretnings-processer hamrende effektivt ved brug af IT. Samtidigt gør jeg det muligt for dem at sparke deres konkurrenter af banen ved at give dem muligheden for hurtigt at forandre sig på forkant af markedet.

Men i modsætning til borddamen er direktøren nok også interesseret i at høre lidt om hvordan den grad af forretnings-understøttelse kan nås. Her er SOA et vigtigt budskab – også om 3 år. Måske er det blevet forfinet eller modnet med elementer af Enterprise arkitektur og kaldes derfor noget andet, men det er stadigt SOA inden i.

  • 0
  • 0
Morten Hattesen

Nu taler du vist om REST-klodser.

Og det gør det ganske vist enklere at holde på klodserne (de er ikke helt så fedtede som SÆBE-klodser). Men du har da stadig i høj grad brug for en adapter, når du skal sætte klodser med forskellig form sammen.

Du får nok brug for en SÆBE-til-REST og REST-til-SÆBE adapter, og sikkert også en XMLmodel1-til-XMLmodel2 adapter (eller transformer, om du vil).

Jeg er i hvert fald sjældent stødt på en situation, hvor XML-modellen fra et system overholdt det samme XML-schema (ja, jeg ved at REST ikke kræver et XML-schema, men det er en helt anden historie) som det system som det skulle kommunikere med, og dermed heller ikke, at man bare kunne sætte klodserne sammen uden videre.

Selv med en velfungerende ESB infrastruktur, er det en tilsnigelse at påstå, at det er som at "sætte klodser sammen". Transformationer til og fra en kanonisk datamodel, kan hjælpe, men det kræver stadig vedligeholdelse af modellen (schema) og mindst to XSL transformationer.

  • 0
  • 0
Kim Dalsgaard

@Morten
Der rammer du lige præcis et vigtigt punkt. Du har fået skilt besked-kompleksiteten fra transport-kompleksiteten - dermed får du en ca. liniær stigning i den samlede kompleksitet når der sker en stigning i enten transport- eller besked-kompleksiteten. Denne kompleksitetsstigning er kvadratisk ved en del andre løsninger.

  • 0
  • 0
Marc de Oliveira

"Jeg hjælper organisationer med at implementere løsninger så de kan understøtte deres forretnings-processer hamrende effektivt ved brug af IT. Samtidigt gør jeg det muligt for dem at sparke deres konkurrenter af banen ved at give dem muligheden for hurtigt at forandre sig på forkant af markedet."

Meget fint! Og nu har du en formulering, som alle EA'ere kan bruge uanset om de bruger SOA eller ej :-)

... men var det ikke netop SOA, som opgaven gik ud på at forklare?

  • 0
  • 0
Lars Hansen

"Jeg hjælper organisationer med at implementere løsninger så de kan understøtte deres forretnings-processer hamrende effektivt ved brug af IT. Samtidigt gør jeg det muligt for dem at sparke deres konkurrenter af banen ved at give dem muligheden for hurtigt at forandre sig på forkant af markedet."

Problemet med den definition er, at den kun fortæller noget om målet (eller effekten) uden at fortælle noget om hvordan du når målet. Den kunne næsten beskrive alt fra Objekt Orienteret programmering til løsninger lavet i Excel (mindre overdrivelse).

Spørgsmålet er hvad du skal svare når du bliver spurgt: "Og hvordan gør du så det?"

Overvej at droppe forsøget på at definere SOA og forsøg i stedet forklare hvorfor SOA giver værdi.

For mig er værdien af SOA klart evnen til at kunne dele sine IT-systemer op i nogle stumper (som så givet ikke er så standardiserede som legoklodser).* Disse stumper har dels en overskuelig størrelse og kan dels anvendes (og genanvendes) i forskellige sammenhænge.

Hvordan synes i andre at SOA giver værdi?

  • Når jeg skriver om "evnen til at dele IT-systemer op i stumper" så er det fordi SOA efter min mening både handler om at kunne definere services, men også at kunne etablere en arkitektur der tillader udstilling og anvendelse af services. Det er mao. forkert kun at tale om services (min legoklods analogi manglede netop lidt på det punkt).
  • 0
  • 0
Marc de Oliveira

Jeg vil nu driste mig til at påstå, at "evnen til at dele IT-systemer op i stumper" ikke er opfundet af SOA. Det er selvfølgelig også et centralt element i generel OO-prgrammering. Inden OO var procedural programmering også meget optaget af at man skulle undgå "spagettikode" ved at lave selvstændige procedurer med parametre, der efterfølgende kunne kaldes i mange sammenhænge.

For mig at se er SOA's værdi blot at man har lukket op for at disse "stumper" kan bruges på tværs af den teknologi, man har brugt til at implementere dem. Dvs at SOA primært har værdi i sammenhænge, hvor man absolut vil (eller skal) blande en lang række teknologier sammen.

Selv om SOA gør dette muligt, så ved vi jo alle, hvilke problemer der følger med at acceptere mange forskellige teknologier i en virksomhed, så det er, i mine øjne, bestemt ikke noget, man skal forfølge, bare fordi SOA gør det muligt.

  • 0
  • 0
Lars Hansen

@Marc

Rigtig godt indlæg.

Jeg vil nu driste mig til at påstå, at "evnen til at dele IT-systemer op i stumper" ikke er opfundet af SOA. Det er selvfølgelig også et centralt element i generel OO-prgrammering.

Helt enig. Det er vel et generelt sundt princip inden for IT.

For mig at se er SOA's værdi blot at man har lukket op for at disse "stumper" kan bruges på tværs af den teknologi, man har brugt til at implementere dem.

Det var i virkeligheden også lidt i den retning jeg ville hen med min lego-klods analogi. Blot giver lego-klodser en uheldig association til fuldkomment standardiserede klodser, hvilket der selvfølgelig ikke er tale om (det gælder dog i højere grad for REST end for SOAP/WSDL).

Dvs at SOA primært har værdi i sammenhænge, hvor man absolut vil (eller skal) blande en lang række teknologier sammen.

Det er vigtigt at være pragmatisk. Omvendt skal man også være varsom med at grave sig ned i en for specifik løsningsmodel. Engang imellem bør man også tænke i at der kan opstå uventede gevinster ved at tænke i retning af anvendelse af stumper/services distribueret i et heterogent miljø. Specielt fordi vi lever i en så foranderlig og kompleks virkelighed at det er svært at forudsige noget som helst. Men ok - balancen mellem at være specifik eller generel i sine løsningsmodeller er nok ret svær at finde.

Nu har du kommet med nogle gode kommetarer i denne tråd. Men hvordan ville du selv forklare SOA på en enkel måde?

  • 0
  • 0
Marc de Oliveira

Mit bud på en "SOA for borddamer"-forklaring vil nok se nogenlunde sådan ud:

"I dag findes der så mange måder at gøre tingene på med IT, at det kan være svært at finde rundt i. SOA hjælper IT-folk til at kunne bruge hinandens programmer, sådan at de ikke selv behøver at opfinde den dybe tallerken igen."

... og så ville jeg selvfølgelig forsøge at få hendes telefonnummer :-)

Spøj til side. Jeg har forøvrigt lavet en kort video om "elevatortaler", hvor jeg netop samler nogle gode råd om hvordan man forklarer komplekse emner i komprimeret form overfor folk der ikke kender til emnet i forvejen:

http://podcast.SimplifySys.dk (episoden fra 20/3)

  • 0
  • 0
Jakob Veje Hansen

... købte/byggede min virksomhed nogle kæmpe store programmer der stadig kører den dag idag. Et af problemerne med dem er, at de er meget svære at vedligeholde. Men hvad der er endnu værre er, når vi finder på noget nyt vi gerne vil sælge/producere/levere/yde til vores kunde. Indmaden i programmerne hænger sammen på kryds og tværs, og de er vildt tunge at rette i. Det betyder at vores salgsafdeling og kundeservice og mange andre bruger en masse tid på opgaver, som programmerne egentligt burde gøre [1], fordi det ville være for dyrt at skrive programmerne om til at kunne det.

Det prøver vi at lave om på nu, ved at søsætte en masse mindre programmer, der hver tager sig een ting.

Min opgave er at hjælpe med til at få den nye løsning skruet rigtigt sammen. Det synes jeg er rigtigt spændende, for hvis det lykkes betyder det at vi får mulighed for at sælge en masse nye spændende produkter langt hurtigere, nemmere og bedre, og blive meget bedre til kundeservice. Hvis vi gør det rigtigt, vil vi om 20 år også kunne glæde os over det! Det vil da være fedt!


[1] Indsæt gerne godt eksempel fra virkeligheden her

  • 0
  • 0
Marc de Oliveira

He, He,

"Indmaden i programmerne hænger sammen på kryds og tværs, og de er vildt tunge at rette i."

Det varer nok ikke længe før man kan sige det samme om SOA-arkitekturen :-) Der er masser af udfordringer i at rette i services (programmer), der anvendes i mange forskellige sammenhænge (på kryds og tværs).

Igen mener jeg ikke at forklaringen handler ret meget om SOA, men mere om arkitektur i det hele taget. Alle arkitekturer vil jo hævde, at "den nye løsning skal skrues rigtig sammen" og "Hvis vi gør det rigtigt, vil vi om 20 år også kunne glæde os over det".

  • 0
  • 0
Jakob Veje Hansen

Jeg er helt enig med dig Marc, i at udfordringen er i arkitektur klassen. Men er det mig der har misforstået noget, eller er SOA ikke "bare" arkitektur udfordring i det hele taget? Jeg opfatter egentligt, som andre også har gjort her, bare SOA som nogle af de gamle OO tanker krydret med service begrebet og tanken om den platformsuafhængige kommunikation.

Hvad kan Peter sige der særligt kendetegner hans SOA job, som ikke samtidigt kender alle arkitektur opgaver indenfor IT? Og værre endnu: som hans borddame faktisk forstår den subtile forskel imellem (endsige er relevant i forhold til Peter's forklaring til borddamen)? ;-)

Jeg vil dog stadig formode (og her kan det være jeg er håbløst naiv) at hvis man får tænkt sine services rigtigt (og rent faktisk får godkendt ressourcne til at implementere det), så slipper man lige præcis for spaghetti koden i fremtiden. Det er vel det der er meningen med at tænke i services og ikke i moduler eller applikationer?!

  • 0
  • 0
Marc de Oliveira

Jeg ville ikke kalde SOA for "arkitektur krydret med services og platformsuafhængighed". I SOA er services det helt centrale element (og dermed også platformsuafhængigheden), så hvis du skal fortælle om SOA, så må det handle om, hvad anvendelsen af services specifikt gør ved de løsninger, du skaber.

At man undgår spagettikode, mener jeg ikke er et argument, da dette (som tidligere nævnt) har været formålet med både procedural- og objektorienteret-programmering. Hvis din applikation er bygget op af fornuftigt strukturerede procedurer (eller objekter), der kan genanvendes, så har du stort set skabt en "service orienteret arkitektur" - blot 20-30 år før begrebet SOA blev opfundet...

Spagettikode er nok mest relateret til sprog som Maskinkode, Assembler og Basic, hvor sproget lagde op til ustrukturerede spring i koden. Allerede med sprog som Fortran, Pascal og C (i 80'erne) gik kampen ind mod spagettikoden, idet hver procedure var indkapslet og kun kunne kaldes i sin helhed med et antal parametre.

  • 0
  • 0
Peter Nørregaard Blogger

Forskellen mellem gamle dag og SOA er netop at arkitekturen er orienteret mod services. Det er ikke bare at man teknisk set kan kalde komponenter andre steder for det har man rigtigt nok kunnet i meeeget lang tid. Det er det yderligere som SOA byder på, nemlig en servicebus med overvågning (og forhåbentligt overblik) og nogle fælles sprog (XML, SOAP, REST, ...). At sprogene så hver især har nogle meget forskellige dialekter invaliderer ikke SOA som koncept, og dialekterne bliver vel luget ud med tiden. Desuden modnes SOA jo stadigt og udvides til at indeholde elementer af governance og Enterprise arkitektur hvilket vel også er (delvist) nyt

  • 0
  • 0
Jakob Veje Hansen

@Marc

Som du kan læse på mine indlæg, er jeg helt enig i at det centrale i SOA er services. "krydret med" var måske et forkert ordvalg.

Angående "spaghetti kode" mente jeg afhængighederne mellem (dele af) legacy applikationerne. Iøvrigt (men off topic) har jeg set meget spaghetti, også i 3G sprog. Jeg mindes stadig med gru det Natural kode jeg skulle vedligeholde engang... og softwareleverandøren kaldte endda Natural for 4G!

@Peter

Enig. Jeg mente egentligt at bussen var underforstået "services" begrebet. Men fint at få det gjort eksplicit.

  • 0
  • 0
Log ind eller Opret konto for at kommentere