Artikel

SOA voor gevorderden

Praktische realisatie van de nieuwe generatie systeemintegratie

SOA en EDA, een sterke mix of gaan beiden niet samen? SOA wordt steeds meer geaccepteerd binnen organisaties. In dit artikel wordt ingegaan op wat SOA is en hoe het bedrijven kan helpen. Een recente ontwikkeling is de toevoeging van EDA (Event Driven Architecture) bij SOA. Kan dit de architectuur van een organisatie nog meer versterken?

SOA wordt door velen gezien als dé oplossing om verschillende bedrijfssystemen flexibel via internet of een bedrijfsnetwerk met elkaar te laten communiceren. Het zou voor wereldwijd opererende bedrijven de oplossing zijn om diensten beschikbaar te maken voor diverse productlijnen en landen. Veel bedrijven zien het potentieel van SOA-oplossingen. Er kunnen namelijk op grote schaal ‘highly distributed’-oplossingen ingezet worden om gelijkmatig verdeelde bedrijfsprocessen te beheren. Maar bedrijven die in SOA een efficiënte, kosteneffectieve, allesomvattende oplossing zien voor hun IT-infrastructuur kunnen ook van een koude kermis thuiskomen.

SOA is een technische oplossing die maar al te vaak slecht toegepast kan worden op het organisatorisch model van een bedrijf. Niet iedere afdeling gebruikt dezelfde diensten of stelt dezelfde prioriteiten aan een applicatie. Hierdoor ontstaat een situatie waarin vraag, verantwoordelijkheden en geldstromen niet parallel lopen.

Neem bijvoorbeeld een bedrijf waarbij IT-budgetten per productlijn of regio worden vastgesteld. Vanuit het centrale kantoor wordt besloten dat de bedrijfsonderdelen in alle landen toegang moeten krijgen tot een dienst om postcodes te valideren. Hoewel de functie voor alle medewerkers noodzakelijk is, heeft niet iedereen dezelfde eisen. Sommige afdelingen hebben er baat bij als de gegevens 24/7 gecontroleerd worden, voor een ander is één keer per dag voldoende. Hierdoor is niet voor iedere budgetverantwoordelijke de gevraagde investering in verhouding met het afnameprofiel.

En hier wringt de schoen. De beperking van SOA is voornamelijk gelegen in niet-technische redenen. Veel business units willen niet zomaar een oplossing opgedrongen krijgen. Een dienst moet aan bepaalde randvoorwaarden voldoen om als betrouwbare oplossing geaccepteerd te worden. Gelukkig zijn recentelijk zowel medewerkers als bedrijven de voordelen van SOA gaan inzien. Op het gebied van flexibiliteit en besparingen op lange termijn is de acceptatie van op SOA-gebaseerde oplossingen sterk gestegen.

SOA en EDA - een sterke mix - SOA 2.0

EDA (Event Driven Architecture) versterkt de voordelen van SOA door asynchrone en sterk ontkoppelde service-patronen in de SOA-oplossingen binnen te halen. SOA is alleen effectief als zoveel mogelijk mensen van een dienst gebruik maken, EDA kan deze effectiviteit van SOA alleen maar verbeteren. Denk hierbij aan een service die het mogelijk maakt om een e-mailaccount aan te maken. Bij veel huidige bedrijfsmodellen, waar geldstromen en verantwoordelijkheden bepalend zijn voor handelingen en beslissingen, is een EDA effectiever. Door de schaalbaarheid van deze architectuur sluit deze beter aan bij de filosofie dat bedrijfsonderdelen hun eigen eisen en budgetten kunnen bepalen. Bedrijven die SOA hebben geïmplementeerd, hebben al gebruik gemaakt van of zijn gestart met het gebruik van EDA om highly distributed en operationeel beheerbare SOA-oplossingen aan te bieden. Nu de SOA-adoptie en -standaardisatie is toegenomen, zijn bedrijven gestart met het inzetten van SOA-oplossingen. Zo kunnen atomische en complexe scenario’s voor het beheer van bedrijfsprocessen aangepakt worden met SOA- en EDA-patronen. Dit gebeurt door gebruik te maken van BPEL en functies voor transactieprocessen die gedreven worden door SOA en EDA.

Veel bedrijven die eerder op een kleine schaal zijn begonnen met SOA willen SOA en EDA nu uitbreiden naar een zakelijk niveau. Zo kunnen de complexe eisen vanuit de organisatie beter beheerd worden, vaak betreft het namelijk meerdere business units met ieder hun eigen budgetten en beslissingen op regionaal niveau. Bedrijven zien de waarde van op SOA en EDA (SOA 2.0) gebaseerde zakelijke oplossingen die een hoge afhankelijke, maar gelijkwaardig ontkoppelde infrastructuur kunnen creëren. Deze oplossingen kunnen daarnaast een flexibele bedrijfsconnectiviteit faciliteren tussen de organisatie en zijn klanten, business partners, leveranciers en andere partijen binnen het ecosysteem van de organisatie.

Er kan dus geconcludeerd worden dat de recente vermenging van EDA-patronen met SOA, samen met een continue verbetering van ESB-, BPEL-, SCA-patronen en standaarden, SOA 2.0 verder hebben versterkt. Het is nu een van de belangrijkste en praktisch geaccepteerde zakelijke architectuurpatronen. Tegelijkertijd heeft de opkomst van cloud computing, met name SaaS-modellen die sterk gebaseerd zijn op SOA-architectuur, de acceptatie en uitrol van vele bedrijfskritieke SOA-oplossingen vergroot. Het motto is: ‘Maak gebruik van geavanceerde SOA, dat een sterke combinatie is tussen SOA en EDA, om zakelijke complexiteiten aan te pakken en om geld te besparen op de korte en lange termijn’.

Categorie:   
Auteur(s)
afbeelding van berthooyman
Bert Hooyman

Bert Hooyman is Chief Architect Europe bij MphasiS

 
Reacties
Harm op maandag 2 januari 2012 15:06

Je artikel lezende blijf ik zitten met 3 onbeantwoorde vragen en dat vindt ik jammer aangezien het onderwerp interessant/relevant is. Ten eerste stel je dat "De beperking van SOA is voornamelijk gelegen in niet-technische redenen.". Okee, alleen hoe gaat EDA deze beperking voor ons wegnemen? Gaat EDA in je voorbeeld wel de investering in verhouding brengen met het afnameprofiel?
Verder schrijf je dat "EDA de voordelen van SOA versterkt". Kan je aangeven waarom deze versterking nodig was? Waren of zijn de voordelen van SOA zo marginaal dat ze versterkt moesten worden? En tenslotte, wat doet EDA met de beperkingen van SOA?

Vriendelijke groeten.

Bert Hooyman op donderdag 5 januari 2012 15:14

Harm, bedankt voor je vragen. Ik heb hieronder geprobeerd zo goed mogelijk antwoord te geven:

1) Hoe gaat EDA deze beperking voor ons wegnemen? Gaat EDA in je voorbeeld wel de investering in verhouding brengen met het afnameprofiel?
De beperkingen van SOA zijn met name organisatorisch – in de praktijk blijkt het bijna onmogelijk om (web) services uit te rollen buiten het bedrijfsonderdeel waar ze aangeboden worden. Dat heeft te maken met vertrouwen en project-afhankelijkheden, met budgetten, met carrieres en succes (gunnen), en nog zo wat. In een al wat oudere presentatie voor TOGAF heb ik daarover uitgebreid gesproken (zie www.mphasis.com/knowledge-center/white-papers-all.asp#y2007 ; “Early Warning Signs for SOA Failures”). Dus het succes van SOA is in de praktijk beperkt tot het bedrijfsonderdeel waar services worden aangeboden. Dat staat haaks op het idee van service re-use: hoe vaker een service hergebruikt kan worden, des te succesvoller de service.
Wat een EDA doet is veel minder gekoppeld aan een bedrijfsstructuur of, anders gezegd, een EDA past zich makkelijk aan aan een bestaande bedrijfsorganisatie. Binnen elk bedrijfsonderdeel worden significante gebeurtenissen (“business events”) gepubliceerd voor consumptie binnen en buiten het betreffende bedrijfsonderdeel. Normaliter weet de aanbieder niet eens welke abonnees er zijn – het is niet de verantwoordelijkheid van de publisher om de subscribers te managen (dat is een wenselijke vorm van ontkoppeling, veel beter dan het request/reply model van een reguliere SOA). Er is vanuit de aanbieder ook geen extra inspanning nodig als een bepaald type business event opeens heel populair blijkt te zijn – er hoeft niet te worden geinvesteerd in snellere hardware of zo, iets wat wel nodig is in een klassiek request/reply model. In een EDA gaat het met name om de uitwisseling van informatie (gebeurtenissen), waarvoor slechts afstemming nodig is betreffende de definitie van die gebeurtenissen (data-modelering). Bij SOA worden processen of activiteiten geintegreerd, waarvoor niet alleen afstemming van data-modellen nodig is, maar daarbovenop ook nog afstemming van functionaliteit. Veel lastiger.

2) "EDA versterkt de voordelen van SOA". Kan je aangeven waarom deze versterking nodig was? Waren of zijn de voordelen van SOA zo marginaal dat ze versterkt moesten worden?
De ‘early warning signs for SOA failure’ (zie boven) leiden tot de conclusie dat de effectieve scope voor een SOA deployment beperkt is tot het bedrijfsonderdeel waar de services worden aangeboden (budgethouder of kostenplaats). Een grote organisatie kan dus meerdere SOA’s realiseren; ten minste één per bedrijfsonderdeel. Denk bijvoorbeeld aan verkoop, inkoop, voorraadbeheer, marketing, boekhouding, personeelszaken, productie, bedrijfsbureau enz. Er is dan nog geen integratie tussen deze bedrijfsonderdelen, geen ‘enterprise integratie’. En dat is waar EDA in beeld komt.

3) Wat doet EDA met de beperkingen van SOA?
EDA ontkoppelt de aanbieder en de gebruiker van services c.q. events en neemt daarmee een aantal belangrijke beperkingen weg:
- project-afhankelijkheden
- gedrag en side-effects van request/reply service calls
- kosten voor service-operation (Quality of Service mbt performance en availability)
- afgedwongen afname van services
- vertrouwen
Mijns inziens is met name het laatste punt relevant. Een EDA past zich relatief makkelijk aan aan een bestaande bedrijfscultuur c.q. organisatie-model. Elk bedrijfsonderdeel is vrij om te doen (en te laten) wat het wil met inkomende ‘business events’.

Tussen de bedrijfsonderdelen hoeft slechts consensus te bestaan over de betekenis van de diverse business events, zoals “er is een order geplaatst”, “er is een nieuwe klant geregistreerd”, “er is een factuur betaald”, “er is een klacht over een product”, enz.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.