Er du i gang med SOA? Tag en tudekiks

I sidste uge gengav både version2 og Computerworld Gartners SOA-undersøgelse med overskrifter, der tydede på dårligt nyt for SOA-projekter rundt omkring i virksomhederne.

Et nærmere eftersyn af tallene bag undersøgelsen viste dog, at SOA har det fantastisk godt og enten findes eller er på vej i over 70-80 % af alle virksomheder. Så hvor kommer tudekiksen ind i billedet?

Harold, som jeg tidligere har nævnt her på bloggen, fortalte at han havde haft en del succeser med at introducere SOA som et element i en enterprise arkitektur (EA). Men samtidigt havde han aldrig oplevet en SOA få succes uden EA, og det er der en god forklaring på.

Når it-afdelingen anskaffer en SOA uden at forretningen er klar til det, giver det problemer. Eller med andre ord, når anskaffelsen primært er teknologi-drevet, så opnår en SOA ikke sit potentiale. Hvis forretningen ikke er struktureret og ikke benytter EA i en eller anden form, så ender den dyre anskaffelse blot med at stå i serverrummet og være parat til at løse problemer, som aldrig bliver formuleret på en måde, så den kan løse dem. Den opnår typisk ikke andet end et stille liv hvor den varetager teknisk set solide men strategisk set irrelevante opgaver, fx som broker mellem filformater.

Når EA er en forudsætning for en succesfuld SOA, så skyldes det at EA hjælper forretningen med at få styr på sine processer på en måde, så de er i overensstemmelse med dens strategi. Samtidigt sikrer EA at processerne bliver understøttet af teknologi på et velovervejet og prioriteret grundlag. Scott Bernard har udtænkt den oversimplificerede men alligevel nyttige ligning:

EA = Strategy + Business + Technology

Til sammenligning kunne ligningen for SOA se sådan ud

SOA = Technology

Med andre ord, SOA mangler det vigtigste for at din forretning kan få succes!

Hvis du er i gang med en SOA uden at have resten af ligningen med, får du brug for en tudekiks. Så hvordan ser dit SOA-projekt ud?

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

Jeg citerer lige fra wikipedia:

”Serviceorienteret arkitektur (forkortes SOA) er en måde at opbygge en it-arkitektur. En serviceorienteret arkitektur består grundlæggende af en række services. Disse services kommunikerer med hinanden

En SOA kan opbygges bottom up ved at service-enable eksisterende funktioner. En SOA kan også angribes top down vha. forretningsmodellering.

Hovedformålet med SOA er at skabe mulighed for genbrug af services og øge fleksibiliteten i it-systemer. Fleksibilitet og time to market er i dag en meget vigtig faktor for enhver virksomhed. Med indførelse af SOA gives mulighed for at it kan understøtte forretningens krav om fleksibilitet og hurtig tilpasning til markedets krav.”

Ikke et ondt ord om EA – men, den service, der virker godt her og nu, kommer ikke dårligt igen.

Mit ”SOA projekt” går ud på at levere SOA komponenter til forbedring af datakvalitet – og det forhindrer både tudekiks og mange andre kiks.

  • 0
  • 0
#2 Peter Nørregaard Blogger

En serviceorienteret arkitektur består grundlæggende af en række services

  • et fremragende eksempel på at wiki ikke nødvendigvis indeholder essensen af en definition.

Definitionen er endnu dårligere end at sige "En lagdelt arkitektur består grundlæggende af en række lag". For en SOA består jo netop ikke af services, men stiller rammerne til rådighed for at services kan udstilles, forbruges, sammensættes og styres på en konsistent måde.

Wiki'en har rigtigt fat i at "Fleksibilitet og time to market er i dag en meget vigtig faktor for enhver virksomhed"

Til gengæld er det helt til hest at antyde, at SOA er alt hvad der er brug for til at opfylde forretningens krav om fleksibilitet og hurtig tilpasning til markedets krav!

Analogien kunne være (selvom man nu passe på med analogier…) at påstå "denne benzin-effektive motor opfylder dine behov for transport" for hvor er lige analysen af hvor du er og hvor du vil hen, hvordan du kommer frem og hvad du har brug for til at komme frem helskindet?

  • 0
  • 0
#3 Peter Nørregaard Blogger

PS, nu kender jeg ikke din forretning, Henrik, men umiddelbart lyder den til at gå ud på at levere en ret teknisk service?

Du kan uden tvivl få en teknisk succes ud af at bruge SOA uden resten (da SOA = Technology). Men hvis man også vil have forretningsmæssig og strategisk succes er SOA bare ikke nok.

  • 0
  • 0
#4 Henrik Liliendahl Sørensen

Peter, enig i at der er rum for forbedring på wiki’s danske SOA tekst. Den engelske er noget bedre.

For at citere fra denne:

”SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of business applications”.

Se her bevæger vi os lidt væk fra big-bang konceptet til noget mere praktisk og pragmatisk. Når man i dag fremstiller et stykke teknologi bør man tænke det ind i en SOA sammenhæng. Det vil først og fremmest sige løs kobling – optimalt set både teknisk og kommercielt.

De forretningsmæssige fordele opstår selvfølgelig først når SOA komponenterne bringes til at virke i forretningsløsningerne.

Fordelen ved SOA komponenterne ligger især i, at man ikke behøver at genopfinde den dybe tallerken, hvis man skal løse et generelt forretningsproblem, som måske findes mange steder i forretningen og som mange andre forretninger også har.

I relation til datakvalitet kan det for eksempel være en algoritme til tjek af dubletter i navne og adresser. Du er nu ikke afhængig af at CRM system X, ERP system Y eller hjemmelavet system Z gør dette hver for sig mere eller mindre godt. Du introducerer en service, som er tilgængelig for alle, og hvis du senere udskifter system X med system 2.0 i forbindelse med den store EA øvelse, ja så kører din datakvalitetsservice bare videre i den nye sammenhæng.

Der er derfor ingen grund til at vente med at implementere SOA komponenter på generelle områder med oplagte forretningsmæssige fordele at hente som for eksempel forbedring og sikring af datakvalitet.

  • 0
  • 0
#6 Jan Flodin

Peter siger SOA=teknologi og fremhæver i stedet EA som "det smarte". Problemet for mig at se er bare, at der ikke nødvendigvis er den store forskel - EA og SOA hænger sammen. Når der så alligevel er forvirring om begreberne skyldes det vores herlige industri, som lynhurtigt tager et godt management begreb som SOA og gør det til en teknologisk opfindelse. Min påstand er at man sagtens kan skære en virksomheds forretningsgange op i små moduler (services) og opnå en vis fleksibilitet i virksomhedens organisation uden at man overhovedet skal bruge teknologi. Når det er sagt er jeg selvfølgelig enig i at det i langt de fleste tilfælde vil være fordelagtigt at automatisere sine processer ved brug af IT - og når nu min virksomhed er modulariseret i services så vil det da også være naturligt at implementere min automatisering i moduler. Og det bedste overblik over både mine modulariserede processer og mine supporterende services får jeg ved at have en veldesignet EA. Men SOA=teknologi accepterer jeg ikke. Det er en udlægning, der er skabt af teknologinørder og som derved har gjort et godt begreb til en lang kamp om overholdelse af international standarder og uforståelige fremmedord.

  • 0
  • 0
#7 Peter Nørregaard Blogger

Jeg kom i tanke om et af Henrik tidligere gode indspark om SOA. I min præsentation, ”We don’t need no architect”[1] på Microsofts Arkitektur Forum i foråret bragte jeg flere citater fra Henrik under vores lille crowd-sourcing øvelse[2].

Specielt var jeg glad for ”AOS: Man skal passe på ikke at komme til at stave det bagfra –altså Arkitektur Orienterede Services.”

[1] http://www.version2.dk/artikel/7432-praesentationer-fra-maf-maj-2007 [2] http://www.version2.dk/artikel/7377-crowdsourcing-hvad-skal-en-soaarkite...

  • 0
  • 0
#8 Kim Dalsgaard

Jeg tror vi har gang i den klassiske æbler plus appelsiner. SOA som begreb er en Architectural Style hvorimod en Enterprise Architecture er en given virksomheds samlede arkitektur. En del af en EA kan derfor være en instans af SOA, lige som en del af en by's arkitektur kan være et område med huse efter Bauhaus stilen.

  • 0
  • 0
#9 Peter Nørregaard Blogger

@Jan og @Rune, I siger begge at EA og SOA hænger sammen. Men vi kan godt forestille os en succesfuld EA uden SOA – og det er så min påstand at det er svært at forestille sig en succesfuld SOA uden at væsentlige elementer fra EA bringes i spil (hvilket Rune også skriver).

Kim er ret præcis når han siger, at et element i en EA kan være en instans af en SOA. Dét er sammenhængen mellem EA og SOA. Nu findes der så næppe et arkitekturmønster pt., der understøtter EA bedre end SOA, men SOA er bare ikke altid en option i de konkrete virksomheder.

Der er så vidt jeg ved ingen SOA-metode, der giver et godt svar på hvordan strategi OG forretning OG teknologi koordineres!

Selvom et SOA-lignende mønster ifølge Jan godt kan anvendes på forretningen, så kender jeg ikke til nogen SOA metoder, der anviser hvordan det kan ske, eller som sikrer at det sker på en afbalanceret måde. Dét er SOAs store svaghed og lige dér ligge styrken i EA. For de fleste EA-metoder har et bud på hvordan strategi, forretning og teknologi kan koordineres.

  • 0
  • 0
#10 Peter Nørregaard Blogger

@Henrik. jeg kan ikke være uenig i, at en EA netop skal indføres pragmatisk efter behov og i faser. Her har EA-metoderne til gengæld det problem at de tilstræber at være komplette i stedet for at være præcise.

Men EA er også et ungt felt som vil modnes over tid. Der vil komme bedre retningsliner for hvordan vi kan etablere en konkret EA-instans hurtigt og med færrest mulige omkostninger.

  • 0
  • 0
#11 Kim Dalsgaard

Så mangler vi bare at få styr på processen versus instansen. En Enterprise Architecture har man hvis man har en større virksomhed der anvender IT - om man vil det eller ej. Detter er analog til at enhver by har en arkitektur, også byer der er opstået spontant og over tid. Processen at skabe en Enterprise Architecture, vi kunne kalde det Enterprise Architecturing, er derimod en proces. Denne proces kunne med fordel indeholde foranstaltninger der skal forsøge at sikre en alignment med den forretning den pågældende Enterprise Architecture skal understøtte.

Man kunne derfor forestille sig en Enterprise Architecturing med forretnings-alignment der anvendte stilen SOA til at frembringe en Enterprise Architecture.

  • 0
  • 0
#12 Jan Flodin

Hvis jeg forstår dig ret så bør dit fjerdesidste ord ikke være "frembringe". EA er der jo allerede, så bør der ikke stå "forbedre/forandre"?

Men bortset fra dette pedanteri så er det en fantastisk vinkling at skelne mellem proces og instans.

  • 0
  • 0
#13 Peter Nørregaard Blogger

EA bruges i flæng til at omtale en akademisk størrelse, mulige fremtidige mål og en proces:

Begrebet Enterprise Architecture kan godt bruges om en given virksomheds samlede, nuværende arkitektur, som eksisterer uanset om den dokumenteres eller ej (som Kim og Jan skriver). Det begreb er en ret akademisk størrelse og måske ikke så interessant i praksis. Analogi: Den totale arkitektur for en by.

Når Kim skriver "frembringe en EA" er det fordi begrebet Enterprise Architecture også kan bruges om en fremtidig mål-arkitektur. Altså er der tale om at ville forme hvordan kommende "instanser" fungere. Analogi: Forslag om højhuse på Krøyers plads i København.

Men når vi taler om at udføre EA eller bedrive EA, så taler vi om EA som disciplin. "SOA is an architectural style, EA is an architectural discipline". EA disciplinen handler om at have styr på både (1) dokumentation af arkitekturer og (2) en proces. Analogi: Byplanlægning.

(1) Dokumentationen af en nuværende eller fremtidig arkitektur kræver et dokumentations-rammeværk, fx en variant af Zachman, som udpeger hvad der bør beskrives, hvilke aspekter der skal beskrives samt hvordan beskrivelserne relaterer sig til hinanden.

(2) Og så er der processen som Kim har døbt Enterprise Architecturing. EA-metoden EA Cube kalder det for "EA Management Program". Processen planlægges med udgangspunkt i en hel række trin og check-lister der har til formål at sikre at processen bliver god, effektiv og forankret.

Typisk har EA-metoderne (metoder til at understøtte disciplinen) det til fælles, at processen indebærer dokumentation af den nuværende situation (arkitekturen i dag) og dokumentationen af visioner om hvor man skal hen (mulige arkitekturer om fx 5 år). Hertil kommer ofte en plan og businesscase til at gennemføre transitionen hen imod en bestemt fremtidig arkitektur.

Det er disciplinen EA som er nødvendig før SOA kan blive en succes!

  • 0
  • 0
#15 Kim Dalsgaard

Tager man følgende udtryk fra min tidligere post

"Man kunne derfor forestille sig en Enterprise Architecturing med forretnings-alignment der anvendte stilen SOA til at frembringe/forandre en Enterprise Architecture."

og sætter Enterprise 'uden for en døren', så får man følgende udtryk

"Man kunne derfor forestille sig en Architecturing med forretnings-alignment der anvendte stilen SOA til at frembringe en Architecture."

Dette synes jeg i sig selv er et validt udtryk - noget kunne derfor tyde på at det ikke er 'Enterprise' der gør alignment med forretningen til en vigtig størrelse.

  • 0
  • 0
#16 Peter Nørregaard Blogger

Nu er det ved at være eksoterisk :-)

Uanset hvad, så er dit mål jo at gøre SOA til en succes for forretningen. Det kan ikke lade sig gøre med SOA alene fordi ingen SOA-metode giver et godt svar på hvordan strategi, forretning og teknologi koordineres.

Derfor har SOA-arkitekten brug for disciplinen enterprise arkitektur for at lykkes med sit SOA-projekt.

Så mit råd er at læse om EA og lære hvordan EA anvendes. Læs fx - An Introduction To Enterprise Architecture (http://www.amazon.com/Introduction-Enterprise-Architecture-Scott-Bernard...) - Enterprise Architecture As Strategy (http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execut...)

eller få inspiration fra en annoteret bogliste fra John Gøtze her: http://gotzespace.dk/cgi-bin/blog/mt-search.cgi?blog_id=1&tag=b%C3%B8ger...

  • 0
  • 0
#17 Lars John Jørgensen

OIO giver i deres udgave af EA-metoden et glimrende bud på hvad målet med EA er:

"OIO EA’s vigtigste mål er at sikre at teknologi-beslutninger og teknologi-projekter er solidt forankrede i forretningens mål og strategier, og hjælper til at gennemføre disse"

se evt. http://ea.oio.dk/arkitekturmetode/introduktion/den-rode-trad-i-oio-ea-me...

Sagt på en anden måde går et forsimplet, projektlignende EA-forløb ud på allerførst at få beskrevet forretningen, herunder mission, vision og strategi. Herefter kan eksisterende workflows optimeres så de følger strategien. Først her kommer IT (applikationer, IT-arkitektur, data, ...) på banen som forretningsunderstøttende værktøjer.

I den efterfølgende vedligeholdelsesfase bruges EA-metoden til at sikre, at der til stadighed er sammenhæng mellem forretning og workflows og mellem workflows og IT-understøttelse.

Tager man udgangspunkt i SOA dumper man i EA-regi. IT og IT-metoder har ingen berettigelse hvis ikke de understøtter et forretningsbehov. Til gengæld er SOA en glimrende komponent i en fysisk enterprise arkitektur, altså den fysiske IT-arkitektur der bedst muligt understøtter forretningen.

Skal man til sammenligning bygge et redskabsskur farer man jo heller ikke som det første til byggemarkedet for at købe det fedeste værktøj. Først efter skuret er "kravspecificeret" og tegnet og styklisterne er lavet begynder man at se på hvilket værktøj der er nødvendigt at have for at bygge skuret. Hvorfor skulle det være meget anderledes i en professionelt styret virksomhed?

  • 0
  • 0
#19 Lars John Jørgensen

Ja, I holder værktøjskassen vedlige så teknologien bedst muligt kan understøtte forretningen.

Hvis en virksomhed (din kunde, måske) er interesseret i at optimere forretningen vil det være en fejl straks at udpege SOA som en del af løsningen. Her er det langt mere oplagt at tænke EA og se hvilke værktøjer der er nødvendige når man har analyseret og optimeret forretningsgange.

  • 0
  • 0
#20 Lars Hansen

Jo, jo – men hvad med os der laver værktøjet. Vi skal jo tænke SOA lang tid i forvejen.

Jeg tror stadig at der er lidt divergerende opfattelser af hvad SOA er i denne debat, og det skaber lidt uklarhed.

Hvis jeg forstår dine tidligere indlæg ret, så antager du lidt den position, at noget "bliver til SOA" hvis der indgår services i en arkitektur.

Det mener jeg ikke. Selvfølgelig er services den grundlæggende byggeklods i SOA, men det er også vigtigt at se på hvordan services interagerer i arkitekturen (interaktionsmodellen).

Man kan sagten inkludere services i en traditionel applikationsarkitektur med point-to-point kald af services indlejret i applikationskoden. Så bliver de services der anvendes bare en form for remote procedure calls. Det har bare ikke så meget med SOA at gøre.

Det er først når du betynder at tænke på et abtraktionsniveau højere end de enkelte services, at det begynder at blive til SOA. Derfor kan man heller ikke købe SOA.

Din opgave er vel ret beset at finde på den rigtige forretningsmodel og så implementere et produkt/værktøj der har veldefinerede interfaces der understøtter de "rigtige" standarder.

(bortset fra det så synes jeg at du har et spændende produkt)

  • 0
  • 0
#22 Peter Nørregaard Blogger

Det er rigtigt - jeg glemte helt OIO EA som informationskilde til EA (http://ea.oio.dk/arkitekturmetode)

En anden metode, som der er fin online information om, er TOGAF (http://en.wikipedia.org/wiki/TOGAF)

Det kan være svært at få et hurtigt overblik over metodernes styker og svagheder, men denne artikel af Roger Sessions kan hjælpe: http://msdn.microsoft.com/en-us/architecture/bb466232.aspx

  • 0
  • 0
#23 Henrik Liliendahl Sørensen

I den virkelige verden findes der både ”top down” og ”buttom up”.

Teknologi er anderledes end lommeuld. Teknologi opstår som regel fordi virksomhed A har et forretningsproblem i afdeling B. Hvis det problem løses med teknologi, er det allerede bevist, at et sådant problem kan løses med teknologi, i hvert fald i afdeling B hos virksomhed A.

Det er dog ikke utænkeligt, at samme problem findes i andre afdelinger i virksomhed A, samt i andre afdelinger i andre virksomheder – i samme by, i samme region, i samme land, ja måske i hele verden.

Hvis den teknologiske løsning er SOA baseret (løs kobling, modulær), ja så er det meget lettere og mindre omvæltende for de andre at tage den teknologiske løsning til sig. Det kan være efter den storstilede EA øvelse – men det kan også bare være god forretningsmæssig beslutning.

For det første løser teknologien mindst et konkret problem. Men hvis den er SOA baseret, indeholder den nogle egenskaber, som er mere fremtidssikret end en indlejret løsning. Den kan genbruges, den kan skaleres, den kan flyttes og den kan erstattes, uden at hele applikationsarkitekturen skal revolutioneres.

  • 0
  • 0
#24 Peter Nørregaard Blogger

Hvis den teknologiske løsning er SOA baseret (løs kobling, modulær), ja så er det meget lettere og mindre omvæltende for de andre at tage den teknologiske løsning til sig.

Med fare for at starte en pedanteri-diskussion, mener du så ikke "service-baseret", altså hvor funktionaliteten er udstillet i form af services med den rigtige granularitet og løse kobling? Dvs. uden SOA designelementerne workflow-motor, ESB, service-katalog, overvågning osv.?

Det kan være efter den storstilede EA øvelse – men det kan også bare være god forretningsmæssig beslutning.

EA-disciplinen kan virke som en tung ting når man læser EA-metoderne, men der er muligt at lave en meget værdifuld EA-øvelse som er meget mere letvægts.

  • 0
  • 0
#26 Glenn Petersen

Som det har været påpeget i de tidligere indlæg, er der divergerende meninger om, hvad SOA er.

Min egen definition lyder:

"Ved en Service-Orienteret Arkitektur (SOA) forstås en arkitekturstil med en lagdelt arkitektur, hvor integration mellem de enkelte lag udgøres af hhv. udstilling og brug af løst koblede services (ServiceProvider og ServiceConsumer).

SOA muliggør sammenkobling af services (og dermed komponenter) til fleksible systemløsninger, der kan restruktureres i overensstemmelse med ændringer i forretningsmæssige behov.

Services er udformet med henblik på at understøtte konkrete forretningsprocesser og kan f.eks. være baseret på beskrivelser i form af Use Cases."

Og jeg ynder også at nævne CBDi's definition, som tilføjer nogle væsentlige aspekter:

"The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer that can be invoked, published and discovered, which are abstracted away from the implementation using a single, standards based form of interface"

Så for mig er SOA langt fra Teknologi i form af nogle (Web) Services. Hvis man tror det, har man glemt, at der er et 'A' i SOA...

Og så det der med sammenhængen mellem EA og SOA. Også her er der tidligere nævnt navnene på nogle EA metoder eller frameworks. Men for mig at se er disse stadig på et meget akademisk niveau, hvor det er svært at relatere dem til virkeligheden på en fornuftig og forståelig måde.

Så er der noget mere kød på SOA Governance. Prøv at lave en søgning på Google. Til en lille start er her et par gode links:

http://www-128.ibm.com/developerworks/library/ar-servgov/ http://devresource.hp.com/drc/resources/soa_gov/index.jsp http://www.cbdiforum.com/secure/interact/2004-09/soa_governance_framewor... http://www.weblayers.com/gcn/whitepapers/Introduction_to_SOA_Governance....

Med Venlig Hilsen Glenn Petersen, 7N

  • 0
  • 0
#27 Lars Hansen

Og så det der med sammenhængen mellem EA og SOA. Også her er der tidligere nævnt navnene på nogle EA metoder eller frameworks. Men for mig at se er disse stadig på et meget akademisk niveau, hvor det er svært at relatere dem til virkeligheden på en fornuftig og forståelig måde.

Du har utvivlsomt ret i at EA befinder sig på et højere abstraktionsniveau end SOA og derfor kan være sværere at kommunikere betydningen af. Jeg ser det imidlertid sådan, at SOA Governance og EA dækker to forskellige ting (i en EA vil SOA governance nok ligge under EA'en).

SOA governance vedrører især spørgsmålet om "Hvordan?" altså hvordan håndterer vi SOA på en fornuftig måde. SOA governance vedrører derimod ikke (ihvertfald ikke primært) spørgsmålene om hvorfor vi skal lave SOA, hvor meget SOA vi skal lave og hvordan SOA hænger sammen med forretningen og strategien. Det er efter min mening her EA kommer ind i billedet. Jeg vil sige at der er 4 grundlæggende kendetegn ved moderne EA:

  • Holistisk: EA er holistisk, dvs. indeholder både strategi, forretning og teknik
  • Bredt: Som navnet antyder, så tages der et bredt syn på organisationen / enterprisen (omend man typisk vil scope indsatsen. Men der bør tages et bredt syn i det mindste på strategi og forretningsniveau)
  • Dokumentation: EA bruger i høj grad dokumentation og det er her Zachmanns rammeværk mv. kommer ind. Der vil være et stort overlap mellem artefakterne for SOA og så EA artefakterne. Men da EA er holistisk vil der være en langt bredere vifte af EA artefakter end SOA artefakter.*
  • Transformation: Det overordnede formål med EA er at skabe forandring eller forberede sig på forandring. Det medfører at EA arbejdet skal bidrage til at skabe en transformation af arkitekturen (forhåbentlig delt op mindre bidder)

Så når jeg synes at EA er vigtigt ift. SOA, så er det fordi EA kan sætte SOA ind i den større sammenhæng; igennem EA får du koblet SOA til den langsigtede forandring af organisationen og opfyldelsen af strategiske og forretningsmæssige mål.

  • Men jo mere moden/strategisk anvendelse af SOA der er, jo større vil sammenfaldet mellem EA og SOA artefakter være.
  • 0
  • 0
Log ind eller Opret konto for at kommentere