luxshan ratnaravi bloghoved

Nu må vi da snart forstå det der SOA...

Vi skal blive bedre til den slags integration, som politikerne ikke snakker om, nemlig den af it-applikationer med hinanden. For blot fordi systemer kan udveksle data med hinanden, er integrationen ikke nødvendigvis optimal. Måske teknisk, men ikke altid i et bredere perspektiv; det handler om at kunne skabe den røde tråd fra et forretningsbehov til den fysiske implementation, fx fra en business capability hele vejen ned til et dataelement, samt at håndtere disse forbindelser som afhængigheder. Hvis ikke dette sker, vil virksomheder blive ved med at hælde penge ned i et dogme, der aldrig leverer et return-on-investment.

Levende, død, genopstået og død igen

En fordelagtig (og, hvis misforstået, oldnordisk) måde at integrere på er via en serviceorienteret arkitektur (SOA). Men SOA i sin oprindelige tekniske servicebus-centriske form er efterhånden uddød for længe siden.

Dette skete, da man indså, at det handlede om mere end at vedligeholde en servicebus, lave WSDL'er og modellere XSD'er. Genopstandelsen manifesterede sig dermed ved åbenbaringen om, at forretningen skulle inddrages meget mere, end den oprindeligt blev, for nu skulle den jo vide, hvad en (web)service er. Det blev den til dels, og SOA levede igen.

Senere blev SOA atter proklameret dødt, da teknologier og buzzwords som REST, JSON og microservices kom på banen. Men noget af den påstand baserer sig på misforståelser, for fx microservices er blot et andet middel end webservices til at implementere SOA. Nogle mener endda, at microservices er SOA 'done right'.

Uanset fortolkningen har serviceorientering aldrig været så moden og udbredt som i dag. Selvom mange virksomheder for 15 år siden, mere eller mindre succesfuldt, købte ind på SOAs mange gevinster/floskler såsom løs kobling, genbrug, lave udviklingsomkostninger og ditto time-to-market, skal serviceorienteringen gentænkes endnu en gang, før de reelle fordele kan høstes i disse microservices- og cloud-tider. Mere specifikt bør man fokusere mere på, hvordan man definerer, håndterer og vedligeholder integrationen af applikationer på tværs af heterogene, distribuerede it-landskaber - og mindre på, hvordan man optimerer implementeringen.

Selvom beslutningstagerne oprindeligt alt for længe så på integration og serviceorientering som en teknisk øvelse, hvor det gjaldt om at implementere eller udvikle det rigtige softwareprodukt på tværs af it-landskabet, skal selvsamme beslutningstagere stadig blive endnu bedre til at fokusere på, hvilke forretningsmæssige evner (capabilities) virksomheden har, og hvordan it-integration og serviceorientering kan understøtte disse. Dermed kan SOA hjælpe med at udfylde forskellen mellem virksomhedens nutidige evner og de ideelle fremtidige evner, der skal til for at understøtte forretningsstrategien. Det er nemlig ikke kun en enterprise-arkitektur-disciplin, men også en kombineret forretningsmæssig og teknisk øvelse.

Illustration: Privatfoto

Siloopdelingen fører til mange applikationer

Symptomet på det engang alt for tekniske fokus er, at mange virksomheder uanset branche har et hav af applikationer, der understøtter forretningens mange arbejdsgange. Alle virksomheder mener nemlig, at lige præcist deres forretning er meget mere kompliceret end alle andres - at lige netop deres virksomhed er unik.

Men fællesnævneren er, at arbejdsgangene unægteligt går på tværs af organisatoriske siloer og afdelinger, så der oftest er et behov for minimum et tilsvarende antal applikationer, som der er afdelinger. Når disse applikationer skal udveksle data med hinanden, skal der naturligvis integreres på den eller anden måde. Risikoen for eksistensen af denne fællesnævner bekræftes indirekte af Conways lov, der siger, at en organisation er begrænset til kun at kunne skabe designs (og dermed it-integrationer), som svarer til organisationens kommunikationsstruktur.

Så hvis en virksomhed for at kunne oprette en ny kunde skal have dennes informationer ind til forskellige afdelinger, såsom først Marketing, så Salg, dernæst Økonomi og til sidst Kundeservice, er der stor sandsynlighed for, at mindst fire forskellige applikationer - som selvfølgelig er integreret med hinanden - har haft med kundedataene at gøre, før forretningsprocessen er gennemført.

Forestillingen om ét monolitisk kæmpesystem er selvfølgelig utopisk i de fleste brancher. Mange systemer er derfor til at leve med - bare man har overblik over afhængighederne på tværs, en forbindelse til hvilke forretningsgange, de understøtter, samt en dyb forståelse af de nødvendige relevante services.

Stop med kun at snakke teknik - igen

Services, af den eller anden slags, er stadig et oplagt middel til at integrere med, da man på den måde logisk kan afgrænse forretningsbehov og udstille applikationers funktionaliteter på tværs. Problemet er bare, at man igen er begyndt at se på SOA som en teknisk øvelse, nu hvor nyere serviceteknologier dukker op - selvom det stadig er alt andet end teknik. SOA handler ikke om udveksling af data vha. fx SOAP, XML eller JSON, eller om, hvordan man orkestrerer en consumers kald af en given service, der implementeres af en provider. Det handler om, at vurdere, hvilke forretningsmæssige organisatoriske enheder og arbejdsgange, som skal være afhængige af hinanden - og derefter etablere understøttelsen af disse afhængigheder via services, hvor afgrænset forretningsfunktionalitet udstilles til interessenter.

Mange arkitekter og udviklere vil selvsagt ytre, at ,,Vi har lavet SOA med vores servicebus i mange år," ,,Vi har RESTful arkitekturer i hele biksen", og ,,microservices giver os sindsygt lav time-to-market". Det klinger imidlertid lidt hult, når man spørger dybere ind til, hvordan de så skaber og styrer sammenhængen mellem forretningsbehov og implementation af arkitekturen - for her vil svaret i værste fald lyder noget ala: ,,Vi fokuserer på den tekniske implementation, og så står Enterprise Architecture-folkene for at skabe sammenhængen." Om SOA implementeres af SOAP- eller JSON-services er underordnet. SOA er mere en tankegang og et mindset end en teknisk arkitektur.

Hvis man implementerer SOA med håndteringen af forretningsmæssige afhængigheder for øje, vil både enterprisearkitekter, løsningsarkitekter, udviklere og forretningsfolk kunne se den røde tråd fra det enkelte dataelement hele vejen op til det forretningsbehov, der understøttes i integrationen af applikationerne - uanset, hvordan afhængigheden teknisk er implementeret. Dermed skabes der ikke kun overblik over sammenhængen mellem de integrerende parter, men også deres rationale for integrationen.

Afhængigheder frem for integrationer

Som nævnt indledningsvist mener jeg, at fokus på integrationer generelt har været det forkerte sted; man har dykket for meget ned i kunsten at optimere og smidiggøre teknisk dataudveksling i stedet for at tage et holistisk syn på forretningsmæssige afhængigheder og it-understøttelsen af dem, ad flere omgange. Dette er også budskabet i den indisk-australske SOA-arkitekt Ganesh Prasads bøger om Dependency-Oriented Thinking.

Et eksempel på, hvordan man kunne tænke på afhængigheder i stedet for integrationer mellem applikationer er, hvis man igennem årene udelukkende har set på, hvordan en prisberegningsapplikation teknisk skal kunne udveksle data med et kunderegistersystem. I stedet bør man vurdere, om afdelingerne Produktudvikling og Kundeservice overhovedet bør have afhængigheder til hinanden på et forretningsmæssigt plan. Eller i hvert fald genoverveje det.

Serviceorientering er kommet for at blive, og selvom SOA har været dødt, levende og dødt igen, så har nutidens forretningsfolk og beslutningstagere faktisk fået øjnene op for, hvilke fordele SOA kan give. Så vi skylder både os selv og dem at gøre det på den rigtige måde, så de kæmpe gevinster ved serviceorientering realiseres - igen og igen på en up-to-date måde.

I senere indlæg går jeg mere i dybden med, hvordan man kan illustrere og definere hensigtsmæssige hhv. uhensigtsmæssige afhængigheder i et SOA-landskab.

Ser din virksomhed på integration af applikationer som understøttelsen af forretningsmæssige afhængigheder, eller fungerer det fint for jer som værende en teknisk øvelse - eller er I et sted i midten?

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Rosenberg

måske vil du i din næste skriv, komme ind på netop det med Dependencies, dels mellem 'Forretningen' og 'Services' samt 'Service-til-Service' både Internt og Eksternt ?
Det var ihvertfald min 'dom' for SOA på den præsentation jeg selv holdt i IT Service Management forum itSMF efteråret 2009.

Essensen ved den er: Man SKAL anvende Meta-IT for at styre Fremtidige, Nuværende og Tidligere konfigurationer, som holder rede på den Normative anvendelse af Services, og Koblingen til Forretningen.
Man kan med fordel anvende Kontraktmetaforen, der skal jo være (mindst) 2 parter til en aftalt Kommunikation.

Jeg deep-linker min præsentation her:
http://itsmf.dk/Admin/Public/DWSDownload.aspx?File=%2fFiles%2fFiler%2fKo...

  • 0
  • 0
Jeppe Cramon

Rigtig godt indlæg :)

Jeg er helt enig - det hele starter og slutter med forretningen og dens business capabilities. Dernæst handler det om hvordan vi kan skabe en sund sammenhæng mellem business capabilities, services og applikationer: https://www.tigerteam.dk/2015/microservices-its-not-only-the-size-that-m...

Teknikken er i grunden den mindst interessante del.

Jeg ser frem til flere indlæg :)

/Jeppe

  • 4
  • 0
Nicklas Moestrup

Hej Lux

Gode ord. Jeg kan regne ud den røde pille er sunket. :-)

Tror du får god vind herfra, men det er virkelig et ændret mindset for os alle der skal til. Men jo flere vi er der tænker disse tanker...

Hvis du får brug for at kunne vise konkrete eksempler på de mange afhængigheder fra den øvrige verden, kan jeg kun varmt anbefale dig at følge/studere Jeppe's indlæg.

For at svare på dit spørgsmål vil jeg sige vi hos os ikke kun betragter afhængigheder mellem systemer som "kun" tekniske afhængigheder. Disse er i sagens natur også forretningsmæssige afhængigheder. :-)

//Nicklas

  • 2
  • 0
Luxshan Ratnaravi

Tak for kommentarerne. Vi er pt. i fuld gang med at finde ud af, hvordan vi netop kan håndtere afhængighederne fra en business capability og hele vejen ned til den fysiske implementation, via et SOA Blueprint. Så der går lidt, inden jeg kommer til at dække dét emne.

Nicklas, tak for at vise retningen og rådene - jeg skal prøve at holde det høje niveau af SOA Governance, du har lagt i PFA :-)

  • 2
  • 0
Peter Sjoelin

Hej Luxshan

Kasper og Elizabeth er vel i fuld sving med den del af arbejdet, men lidt inspiration kan vist også hentes i bogen "The Essential Advantage" og "SOA for Profit" eller "Next Generation SOA" af Thomas Erl.

None the less - enjoy.

Med venlig hilsen
Peter.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize