SOA en EDA gebeurt er nog wat?

Alles wijst erop dat we met SOA na een periode van hoge verwachtingen in de vallei van teleurstelling zijn aangekomen. SOA is dood verklaard. En vervolgens wordt de vraag gesteld: en wat komt er dan na SOA? Sommigen beantwoorden deze vraag met: nu is het de tijd voor Event Driven Architecture (EDA). Dit artikel gaat in op EDA en hoe dat zich verhoudt tot SOA.

Wat is EDA?

In een EDA worden deze significante verandering van toestand expliciet gemaakt door (het versturen van) een event. Dit maakt het mogelijk op een losstaande gebeurtenis of op een combinatie van gebeurtenissen te reageren.

De belofte van EDA is dat het bedrijven in staat stelt om tijdig te reageren op verandering en de bijbehorende bedreigingen en kansen.Daarbij is het dan wel noodzakelijk de technische notie van EDA, namelijk het idee dat de events alles aansturen, om te zetten naar een bedrijfsmatige notie van EDA, waarbij het bedrijf vanuit events wordt (bij)gestuurd.

Verwachting - werkelijkheid = afwijking

De werkelijkheid om ons heen wijkt vaak af van de verwachting erover. Een kenmerk van EDA-toepassingen is dat deze zich richten op het detecteren van deze afwijkingen tussen verwachting en werkelijkheid:

Verwachting - Een pakket moet 6 februari voor 11.00 uur worden afgeleverd.

Werkelijkheid - Het transport komt in een verkeerschaos terecht. Om 10.00 uur geeft het navigatiesysteem aan dat de resterende reistijd nog 1 uur en 30 minuten is.

Afwijking - De vaststelling dat het pakket niet meer op tijd geleverd kan worden is een afwijking in toestand, waarover de verzender wordt geïnformeerd.

Stel vast - Combineer - Analyseer - Beslis - Voer uit

Een EDA kent de volgende essentiële taken:

Stel vast - Een afwijking tussen verwachting en werkelijkheid moet vastgesteld worden. Hiervoor is een "sensor" nodig, die de afwijking expliciet maakt door
een "event" te genereren. De organisatie moet hiervoor een goed inzicht hebben in wat relevant is, en daarmee waar men een sensor wil plaatsen.

Combineer - In sommige gevallen is het nodig meerdere events te combineren om de significante gebeurtenis vast te stellen. Hierbij speelt tijd vaak een belangrijke rol. Denk aan het feit dat er op vrijwel hetzelfde moment dezelfde pinpas wordt gebruikt in Amsterdam en Londen (pinpasfraude?). Of dat erbinnen zeer korte tijd diverse bedragen die net onder de grens voor controle op witwassen worden overgeboekt tussen twee rekeningen. Hiervoor wordt Complex Event Processing (CEP) ingezet. Dat kan leiden tot een nieuw event.

Analyseer - Niet op alle events hoeft gereageerd te worden. Na het ontstaan van een event zal er in de meeste gevallen een analyse plaatsvinden om te bepalen wat in een gegeven context de betekenis is van dit event. In figuur 1 hangt dat af van het soort pakket dat wordt verstuurd, en de afspraken tussen verzender en ontvanger. Het kan zo zijn dat als het pakket niet op tijd wordt afgeleverd, de ontvanger er geen belang meer in stelt, en het transport dus rechtsomkeert kan maken. Maar gaat het om een orgaantransport voor een patiënt in kritieke toestand, dan zal er wellicht een helikopter nodig zijn om ervoor te zorgen dat het orgaan alsnog op tijd wordt afgeleverd. Het event wordt daarom geclassificeerd op basis van de significantie van het event voor het bedrijf. Deze bedrijfsmatige insteek geeft ook meteen aan dat je een beslissing over het wel of niet relevant zijn van een event niet aan de sensor kan en wil overlaten.

Beslis - Op basis van het geclassificeerde event wordt nu een beslissing genomen over de te nemen vervolgacties.

Voer uit - Eventuele vervolgstappen worden uitgevoerd.

Mens versus Machine

Kijkend naar de bovenstaande taken is de conclusie dat taken als vaststellen, combineren en uitvoeren goed geautomatiseerd kunnen worden en zelfs geautomatiseerd moeten worden indien er sprake is van grote aantallen events, of de eis om snel te reageren. Ook analyse kan voor een deel geautomatiseerd worden, maar het is belangrijk om vast te stellen dat het bij EDA vaak gaat om onverwachte gebeurtenissen. Daarom volstaat het niet om uitsluitend verwachte patronen te automatiseren. Criminelen zullen als bekend is welke fraude gedetecteerd wordt altijd zoeken naar een creatieve wijze die nog niet wordt gedetecteerd. Daarentegen zou een zelflerend systeemprima kunnen helpen om afwijkingen van bestaande patronen vast te stellen. Ook beslissen kan geautomatiseerd worden, maar het hangt van de toepassing of dit wel wenselijk is. In veel gevallen wordt de eindbeslissing genomen door een menselijke expert, ondersteund door de informatie uit de combinatie- en analysefase. Er moet ook specifiek rekening worden gehouden met foute classificaties, ook wel aangeduid als "False Positives" en "False Negatives".

SOA versus EDA

Het bovenstaande geeft aan dat EDA met zijn gericht zijn op afwijkende gebeurtenissen een heel andere insteek heeft dan SOA, dat uitgaat van duidelijk gedefinieerde functionele bouwblokken die als diensten worden aangeboden en volgens binnen een vooraf gedefinieerd proces worden georkestreerd. Binnen EDA ontbreekt een dergelijke vorm van sturing. Dit maakt EDA minder geschikt voor het deel van de bedrijfsapplicaties waarin sturing en verantwoording van groot belang zijn. Daarom EDA kan nooit gelden als de vervanger van SOA. EDA is veel meer complementair aan SOA. Vanuit een SOA-omgeving kunnen bijvoorbeeld events ontstaan, en een proces of service in een SOA kan worden gestart door een event. Als je dat toevoegt aan de SOA stack, dan ziet dat er als volgt uit:

Componenten van een EDA

Het is onze ervaring dat de meeste bedrijven die geïnvesteerd hebben in SOA-componenten deze kunnen hergebruiken voor EDA.

De volgende zaken zijn te hergebruiken:

• ESB, met betrouwbaar transport (Message Queues) en een Publish/ Subscribe-mechanisme. Er moet wel sprake zijn van zogenaamde "durable subscriptions", zodat er in geen enkel geval events verloren gaan op het moment een ontvanger niet beschikbaar is.
• Een BPM- of Orkestratietool voor het reageren op events.
• Een portal met daarin:
  • Een dashboard voor weergave van Alerts.
  • BAM/BI-dashboards voor weergave van overzichten en grafieken.

Specifieke nieuwe componenten die wellicht nodig zijn:

• Sensoren voor vaststellen van events.
• Complex Event Processing- (CEP) en filtersoftware voor combineren en analyseren van events.

Event-driven toepassingen en hun businessrelevantie

Dit zijn voorbeelden van de toepassing van EDA:

• Financiële sector: de detectie van fraude en witwassen;
• Automatische handel in aandelen en derivaten;
• olgen van goederenbewegingen middels RFID;
• Operationeel beheer, monitoring;
• Militaire detectiesystemen;
• Bewaken van objecten en installaties waar calamiteiten een zeer hoog risico met zich meebrengen;
• Interactieve TV, gaming.

Maar het zou onverstandig zijn om daar te stoppen met het creatieve proces. Er is absoluut nog ruimte voor innovatie rond de toepassing van EDA. Een interessante manier om dit proces te starten is om uit te gaan van metrics die nu al getoond worden in bijvoorbeeld een BAM-dashboard en zich af te vragen welke afwijkingen daarop aanleiding zouden kunnen zijn voor een alert of geautomatiseerde reactie.

Waar begin je met EDA?

Laat ik beginnen met het intrappen van de open deur dat EDA geen doel op zich is. De techniek kan boeiend zijn, maar het heeft uiteraard geen zin om in EDA te investeren als er geen businesscase is. En hoe bepaal je of er een businesscase is voor EDA in de organisatie waar je werkt? Uiteraard kun je wachten tot er vanuit de business een vraag komt die bij nadere analyse geschikt blijkt te zijn voor oplossing in een EDA - waarop jij dan alles uit de kast haalt om te laten zien hoe EDA de oplossing is de gaat helpen deze vraag te beantwoorden. Als dat je aanpak is, dan wens ik je veel geduld. Maar het is natuurlijk de vraag of de business zich realiseert welke nieuwe mogelijkheden er door het toepassen van EDA ontstaan. Dus om mensen in business en IT "out-of-the-box" te laten denken is het raadzaam een workshop van een dagdeel in te plannen, met de volgende agenda:

• 30 min Korte introductie van EDA en wat het voor de business kan betekenen, met een aantal voorbeelden.
• 2 uur Brainstorm met business- en IT-innovators. Bedenk zoveel mogelijk businessscenario´s op basis van de ideeën die in de eerste 30 minuten zijn gegeven.
• 30 min Pauze, maak spreadsheet met alle voorgestelde scenario´s.
• 1 uur Loop nog een keer door alle voorgestelde scenario´s heen en hang hier de potentiële opbrengst aan.

Het uiteindelijke resultaat van de workshop is een op aflopende opbrengst gesorteerde lijst met scenario⿿s. Op basis van deze lijst kun je de business case van de twee of drie meest veelbelovende scenario⿿s verder uitwerken. Hierdoor verkrijg je een beter inzicht in de complete businesscase voor elk van die gevallen. Als duidelijk is dat er een voldoende concrete businesscase is, kun je op basis van terugverdientijd gecombineerd met criteria als risico en omvang uiteindelijk komen tot de definitie van een EDA-pilot. Maar er blijven andere criteria over die je zult moeten checken:

• Is er een sponsor vanuit de business, en is deze enthousiast over de mogelijkheden?
• Is er in de betrokken businessunit(s) of afdeling(en) ook daadwerkelijk capaciteit om mee te werken.
• Pas het project erbij in het (IT) Project Portfolio?

Stuk voor stuk zijn dit belangrijke voorwaarden voor een succesvolle pilot. Vanaf dat moment is het van belang om de juiste mensen bij elkaar te brengen om te komen tot een feitelijke beslissing over een EDA-pilotproject.

Een EDA- (pilot)project

Uiteraard is een EDA-pilotproject in heel veel opzichten net een gewoon project. Er is dus een projectorganisatie voor nodig. Inhoudelijk pakt Inter Access een EDA-pilot als volgt aan:

Workshops

• Aan het begin van een project worden een aantal workshops gehouden:
• Functioneel, vastleggen van de business requirements, in dit geval gericht op een analyse van de scenario⿿s waarop gereageerd moet worden, en de relatieve prioriteit van elk van de vastgestelde scenario´s.
• Interactieontwerp, voor die delen van het systeem waar gebruikersinteractie is.
• Architectuur, uitwerken van koppelingen, definitie van de te gebruiken systeemcomponenten, aansluiting op en gebruik van al beschikbare infrastructuur.

Modelering - in deze fase worden de scenario´s en beslisregels verder uitgewerkt.

Architectuurontwerp - er wordt een ontwerp gemaakt waarin alle systeemcomponenten en hun samenhang worden gedefinieerd.

Tool- of pakketselectie - zijn er nieuwe softwarecomponenten nodig, dan zal hiervoor een tool- of pakketselectie moeten plaatsvinden.

Softwareontwikkeling - ontwerp, ontwikkeling en testen van alle maatwerkcomponenten. (Denk hierbij aan sensoren of klantspecifieke dashboards).

Installatie en configuratie van alle componenten.

Inregelen en testen van de toepassing.

Implementatie - opleiden van gebruikers en inrichten van beheer rond de pilot

Evaluatie - Na afloop van de pilot zal worden bepaald of de pilot heeft voldaan aan de doelstellingen, en weke leerpunten er zijn.

Bedrijfsbrede EDA?

Na het succesvol afronden van een pilot kan beslist worden over verdere projecten, wellicht gestructureerd in een EDA-programma. Doe daarbij eerst uitgebreid ervaring op voor je gaat praten over een "bedrijfsbrede EDA".

Conclusie

Eda is complementair aan SOA door het toevoegen van de mogelijkheid van het omgaan met onverwachte gebeurtenissen. In die zin kan EDA incidenteel het beste gezizen worden als een specifiek type applicatie en niet ale een bedrijfsbrede infrastructuur.

Door Theo Stolker en Peter Paul van de Beek van Inter Access