Artikel

SOA en EDA - Waarom nemen deze architectuurstijlen juist nu een grote vlucht?

We beschouwen het als vanzelfsprekend, SOA (Service Oriented Architecture) en EDA (Event Driven Architecture). We zijn gewend aan het woord architectuur, zoals in deze beide trends op enterprise niveau. Maar hebben we een eenduidig beeld van de betekenis van het woord architectuur? Bedoelen we allemaal hetzelfde en is er niet sprake van een onbewuste spraakverwarring? Ook in de literatuur is niet altijd even duidelijk wat er onder architectuur wordt verstaan; het accent ligt hier meestal op het doel van architectuur: wat kun je ermee bereiken? Maar wat is architectuur nu feitelijk? Op die vraag wordt in dit artikel een antwoord gegeven. Eerst positioneren we architectuur in het algemeen. Daarna kijken we wat specifieker hoe architectuur in de context van SOA en EDA gezien kan worden.

Definitie van architectuur

Het standaardisatie-instituut IEEE [1]  heeft een definitie geformuleerd voor architectuur. Deze definitie (IEEE 1471) is wereldwijd door een groot aantal instellingen en bedrijven geadopteerd. Volgens IEEE is de definitie van architectuur: “The fundamental organisation of a system embodied in its components, their relations to each other, and to the environment, and the principles guiding its design and evolution.”

Architectuur vormt weliswaar een structuur, zoals uit de IEEE 1471 definitie is af te leiden, maar een structuur is daarmee nog niet altijd een architectuur. Deze verwarring van structuur met architectuur komt men vaak tegen. Iedere mus is een vogel, maar iedere vogel is daarom nog geen mus.

De soms gebezigde uitspraak “een boom heeft een architectuur” gaat alleen op als dat met het scheppingsverhaal in verband wordt gebracht. Darwin zou zeggen: “een boom heeft een structuur die spontaan (onbewust en dus ook ongestuurd) door natuurlijke selectie tot stand is gekomen.” Daarmee heeft een boom dus nog geen architectuur. Of sterker, vanuit Darwin geredeneerd: een boom is een ultiem voorbeeld van een structuur zonder architectuur. Daarentegen is de structuur van een doelbewust aangelegde tuin wel degelijk een architectuur.

Essentieel is dus (IEEE 1471): …and the principles guiding its design and evolution. Als gekeken wordt naar de gemeenschappelijke kenmerken van architectuur in de verschillende domeinen, dan valt op dat het altijd gaat om een ordening, waarbij men bepaalde doelstellingen met die ordening voor ogen heeft.

De IEEE 1471 definitie is in twee woorden samen te vatten, namelijk:

DOELBEWUSTE ORDENING

Ordening als toestand, is het resultaat van een spel van decompositie en compositie, van scheiden en samenvoegen. Dit impliceert dat er een zinvolle opdeling van het geheel in meerdere componenten in hun onderlinge samenhang wordt onderkend. Doelbewust impliceert dat er bepaalde redenen zijn voor de gekozen wijze van decompositie en compositie.

Architectuur gaat over componenten, scheiding, samenstelling, verbindingen en doelstellingen. Dit zegt nog niets over het domein. Het kan gaan over muziek, elektronische schakelingen, gebouwen, IT, organisaties, landschappen. Overal waar structuren van afzonderlijke componenten te onderkennen zijn die met elkaar gekoppeld zijn op basis van één of meerdere vooraf gedefinieerde doelen, zou men kunnen stellen dat er sprake is van architectuur.

Ordeningsprincipes

Om de ordeningsdoelen te kunnen bereiken worden ordeningsprincipes toegepast. Hieronder volgen een aantal in de IT-wereld veel voorkomende ordeningsprincipes. Welk ordeningsprincipe het meest adequaat is, is afhankelijk van het doel dat met de ordening wordt nagestreefd. In de praktijk zijn combinaties van ordeningsprincipes gangbaar. Het aantal mogelijke ordeningsprincipes en de vorm waarin deze worden afgebeeld, is slechts gelimiteerd door de creativiteit van de architect.

Gangbare ordeningsprincipes in de IT zijn:

  • Clustering - Differentiatie naar samenhang: De componenten worden onderscheiden en in groepen geordend op basis van hun onderlinge interactie op een dusdanige wijze, dat er minimale koppelingen tussen de groepen en maximale samenhang binnen de groepen ontstaan.
  • Tiers - Differentiatie naar functie: De componenten worden onderscheiden en in groepen geordend op basis van hun functionaliteit op één bepaald hiërarchisch niveau, zoals de three-tier applicatiearchitectuur, waarbij user interface, bedrijfslogica en opslag als aparte tiers worden onderkend.
  • Layers - Differentiatie naar abstractieniveau: De componenten worden onderscheiden en in groepen geordend op basis van hun abstractieniveau in een hiërarchie; inkapseling, stack, zoals het OSI-referentiemodel voor digitale communicatie.
  • Raamwerk - Multidimensionale classificatie: De componenten worden onderscheiden en geordend naar hun onderlinge relatie in diverse dimensies. Hiermee kunnen onder andere tiers en layers met elkaar in verband worden gebracht. Denk bijvoorbeeld aan het IAF-architectuurraamwerk.
  • Topologie - Onderling fysieke positie: De componenten worden fysiek ten opzichte van elkaar geordend. Dit ordeningsprincipe is bijvoorbeeld van belang in client-server omgevingen en bij het ontwerp van infrastructuur waar servers in verschillende netwerkzones en in verschillende datacentra worden geplaatst.

Balans tussen meerdere doelen

Er zijn meestal meerdere ordeningsdoelen die men nastreeft. Deze doelen kunnen conflicterend zijn met elkaar. De ordening moet op een dusdanige wijze plaatsvinden, dat een evenwichtige balans ontstaat tussen de ambitieniveaus voor de verschillende doelen, terwijl er toch een consistent geheel ontstaat. Dit wordt in de literatuur aangeduid als conceptuele integriteit. Het is de taak van de architect om deze balans tot stand te brengen en de conceptuele integriteit te borgen. Hoe minder ordeningsdoelen er zijn, des te meer vrijheden heeft de architect om zijn architectuur vorm te geven.

In de kunst zijn de ordeningsdoelen vaak niet veel meer dan esthetiek en het opwekken van emotie. Soms is het opwekken van emotie, in welke vorm dan ook, zelfs het enige doel. Dit geeft de kunstenaar - de architect van het kunstwerk - veel vrijheden om zijn werk vorm te geven.

In de bouwkunde zien we esthetica, functionaliteit en comfort (naast veiligheid en voldoen aan wetgeving) als belangrijkste doelen. Het gaat hier om ordening van ruimte, kleur, vorm en materiaal om te komen tot ooglijkheid (esthetica) en bruikbaarheid (functionaliteit en comfort). Een mooie, kartonen muur zal geen dak kunnen dragen en op een schitterende bolle vloer kunnen geen meubels staan. In de bouwkunde is duidelijk waarneembaar dat de accenten die de verschillende ordeningsdoelen krijgen, sterk worden beïnvloed door de tijdgeest. De aspecten esthetica, functionaliteit en comfort willen in de verschillende tijdsgewrichten nogal eens verschillende gewichten in de schaal leggen.

In de IT-wereld op enterprise niveau is het primaire ordeningsdoel het borgen van continuïteit van de vereiste businessfunctionaliteit welke in de vorm van IT wordt geleverd. De uitdaging hierbij is dat de vereiste functionaliteit geen constante is, maar wijzigt in de tijd, en geld kost. Er is dus behoefte aan flexibiliteit én kostenefficiëntie. Het mag gezien worden als de ultieme uitdaging van de IT-architect om een “verkoopbare” balans te vinden tussen deze twee aspecten; een hogere flexibiliteit vermindert de kosten later, maar vereist vaak een hogere investering nu.

Nu we een beeld hebben gevormd van wat architectuur is, kunnen we betekenis geven aan de ‘A’ van EDA en SOA. Welke ordeningsdoelen liggen er achter EDA en SOA en welke principes worden daarvoor gehanteerd?

EDA en SOA

De scope van EDA en SOA is het raakvlak tussen de bedrijfsprocessen en het applicatielandschap op enterprise niveau. EDA en SOA zijn ordeningsbenaderingen die het best tot hun recht komen als de architectuur organisatiebreed zijn beslag krijgt. Maar juist door implementatie van een architectuur gebaseerd op de principes van SOA en EDA zullen de organisatiegrenzen gaan vervagen. SOA en EDA maken het gemakkelijker om met de omgeving van de organisatie te communiceren. Deelprocessen kunnen worden uitbesteed en toch deel uit maken van de eigen bedrijfsprocessen. Dit geldt ook voor de ondersteunende IT. Waar draait wat en wie is ervoor verantwoordelijk? Alle kinderen in de straat bouwen met hun eigen LEGO-blokken mee aan jouw kasteel.

Koppeling en samenhang

Het doel van IT-architectuur op enterprise niveau is, zoals gesteld, het borgen van continuïteit van de vereiste businessfunctionaliteit. Dit vertaalt zich naar het vermogen om als IT-organisatie tijdig en betaalbaar op wijzigingen in de organisatie van het bedrijf te kunnen inspelen. De IT-componenten die de vereiste functionaliteit aan de organisatie leveren, moeten eenvoudig ontkoppeld kunnen worden en opnieuw in andere samenstellingen kunnen worden opgebouwd, waarbij weer de volledige vereiste functionaliteit wordt geleverd. Dit stelt eisen aan de ordening van de componenten. Een ordeningsprincipe om dit doel te bereiken is het op een specifieke wijze clusteren van de componenten.

Op de plaatsen waar de waarschijnlijkheid om in het systeem te knippen groot is, moet de koppeling tussen de componenten zo minimaal mogelijk zijn. Daar waar de waarschijnlijkheid van opknippen klein is, dienen de componenten zo efficiënt mogelijk samen te werken en dus hecht gekoppeld te zijn.

Binnen elementaire bedrijfsfuncties is de samenhang van activiteiten groot en de kans van opknippen klein. Dit staat een sterke binding tussen de - fijnmazige - componenten van het ondersteunende systeem toe. Tussen elementaire bedrijfsfuncties onderling is er een reële mogelijkheid dat er geknipt gaat worden en zou het ondersteunende informatiesysteem een lossere koppeling tussen de betreffende componenten moeten hebben. Op het niveau van bedrijfsdomeinen bestaat van nature een drang naar autonomie en zullen de koppelingen tussen de betreffende softwarecomponenten uiterst “los” moeten zijn. Op deze wijze kan vanuit de IT worden geanticipeerd op toekomstige wijzigen in de organisatie.

In de literatuur staat dit ordeningsprincipe bekend als “loose coupling and strong cohesion”. Het werd voor het eerst begin jaren 70 genoemd door Constantine, Myers en Stevens als belangrijk basisprincipe voor “Stuctured Design” [2].

Figuur 1: Ordening op basis van “loose coupling” en “strong cohesion”

Bouwblokken: services én berichten

Vanuit een IT-perspectief is SOA een benaderingswijze die zich richt op maximale samenhang en is EDA een benaderingswijze die gericht is op minimale koppeling. In de SOA-benadering zijn samenhangende services het uitgangspunt voor modelleren. In de EDA-benadering zijn de representaties van events (berichten) het uitgangspunt. Beide benaderingstijlen richten zich vanuit een invers gezichtspunt op dezelfde architectuur. Er wordt in beide benaderingen expliciet uitgegaan van een bouwblokkenprincipe (LEGO-metafoor) en gemeenschappelijk gebruik van de componenten (in de literatuur vaak aangeduid met “reuse”).

Opmerkelijk is dat dit ordeningsprincipe in de literatuur algemeen geaccepteerd is voor services, maar dat het nauwelijks genoemd wordt voor berichten. Een berichttype kan echter door meerdere services worden gepubliceerd en ook door meerdere services worden geconsumeerd. Een berichtentype heeft bovendien een formele definitie en berichten zijn self-contained (ze bieden alle vereiste informatie over het event). Dat betekent dat berichttypen analoog aan services gemeenschappelijk bruikbare bouwblokken zijn.

Uiteindelijk levert toepassing van het ordeningsprincipe achter SOA en EDA geen betere bedrijfsprocessen op, maar het vermindert de vereiste inspanning voor aanpassing van de IT bij het wijzigen van de bedrijfsprocessen. Een juiste toepassing van het ordeningsprincipe achter SOA en EDA maakt de informatiesystemen ongevoeliger voor wijzigingen in de organisatie. Zelfs al worden de bedrijfsprocessen veranderd van slecht naar nog slechter.

Toekomst

Het ordeningsprincipe achter SOA en EDA bestaat - zoals aangegeven - in formele zin al enkele decennia voor softwarearchitecturen. De ideeën erachter komen voort uit de systeemleer welke haar oorsprong nog veel verder in het verleden heeft. Niets nieuws onder de zon dus. Of toch wel? Jawel. De reden dat het ordeningsprincipe achter SOA en EDA juist nu een grote vlucht neemt heeft te maken met het feit dat interoperabiliteitsstandaarden ook op applicatieniveau een marktbrede acceptatie hebben weten te bereiken. De toenemende communicatiemogelijkheden (IP-adres in de broekzak) is een belangrijke enabler voor globalisering en dat stimuleert weer de vraag naar standaarden voor interactie tussen applicaties.

Cloud Computing is een voorbeeld van nieuwe IT-business modellen die bestaan bij de gratie van verregaande connectiviteit en interoperabiliteit, gebaseerd op breed geaccepteerde standaarden. Anderzijds maken de huidige ontwikkelingen met betrekking tot connectiviteit en gestandaardiseerde interoperabiliteit het zeer aantrekkelijk om procesketens over verschillende bedrijven heen verregaand te automatiseren in wereldwijde value chains.

Het ordeningsprincipe achter SOA en EDA maakt het in combinatie met de marktbrede standaarden en verregaande communicatiemogelijkheden mogelijk om optimale applicatiestructuren te creëren voor omgevingen waarin Cloud oplossingen moeten samenwerken met eigen in-house oplossingen en applicaties van business partners, leveranciers en klanten. Structuren die steeds weer snel en onverwachts veranderen.

Vanuit applicatieperspectief mag verwacht worden dat het komende decennium in het teken zal staan van verdergaande, uiterst flexibele integratie gebaseerd op het architectuurprincipe achter SOA en EDA.

Categorie:   
Auteur(s)
afbeelding van jackvanhoof
Jack van Hoof
NS - Enterprise IT architect

Jack van Hoof is Enterprise IT architect bij CIO-office Nederlandse Spoorwegen.

 
Reacties
Ad Gerrits op donderdag 10 februari 2011 12:05

Goed artikel. Tweetal opmerkingen:
- zie de scheiding tussen SOA=samenhang en EDA=ontkoppeling niet zo strikt
- in praktijk kan SOA/EDA wel degelijk leiden tot verbetering van bedrijfsprocessen omdat gestructureerd kijken naar processen als nuttig 'bijeffect' kan hebben dat daar verbeteringen worden doorgevoerd.

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.