EdA - echte voordelen liggen bij de business

EdA is vooral een manier van kijken naar software architectuur dat vooral toegepast wordt bij technische uitdagingen. Echter, echte voordelen zijn vooral te behalen wanneer business het denken in bulkverwerking en webservices aanvult of soms vervangt met denken in afzonderlijke gebeurtenissen. EdA kent grote raakvlakken met SOA en data warehousing, maar vervangt deze niet. EdA gaat wel steeds meer batchprocessen vervangen met overduidelijke business voordelen als gevolg.

EDA vanuit business perspectief

EDA ofwel "Event-Driven Architecture" is een software architectuur patroon dat te maken heeft met gebeurtenissen. Deze gebeurtenissen kunnen technisch van aard zijn, maar nog veel interessanter zijn business gebeurtenissen. Een burger die verhuist, is een gebeurtenis dat een business proces initieert met een melding bij zijn/haar gemeente. Deze gebeurtenis doorloopt vervolgens een of meer business processen, veroorzaakt misschien weer andere gebeurtenissen en wordt grotendeels of helemaal door middel van berichtenuitwisseling en berichtenverwerking geautomatiseerd afgehandeld. Een totaal andere gebeurtenisvorm is een treinpositie of stand van een wissel op de spoorwegen dat gemeld wordt aan vele geïnteresseerde / consumerende systemen; of indices op de beurzen gemeld aan misschien miljoenen grote en kleine systemen (bijv. iPhone). Gebeurtenissen verschillen in hun betekenis, grofheid en frequentie. Een gebeurtenisbericht kan informatie bevatten over het betreffende object en de opgetreden wijziging.

Voordelen van EDA

Laatste twee voorbeelden illustreren de enorme kracht van EDA. De aard van dit architectuurpatroon zorgt voor grote schaalbaarheidsmogelijkheden met beperkte kosten, extreem grote ontkoppeling en distributie van systemen. De voorbeelden laten zien dat EDA niet nieuw is, maar echte mogelijkheden zijn nog lang niet volledig benut. Met name overheidswereld moet echte voordelen van EDA nog ontdekken. Een groot overheidsprobleem is - zoals in NORA beschreven - administratieve last dat burger ondervindt door eigen gegevens en wijzigingen steeds opnieuw moet opgeven bij iedere instantie. Soms informeren zelfs diensten binnen dezelfde gemeente elkaar onvoldoende of met een grote vertraging. Bij deze en vele andere automatiseringsuitdagingen wordt nog te vaak verwerking van bulkgegevens (batches) als oplossing gekozen. De belangrijkste nadelen zijn dure handmatige handelingen, fouten en vertragingen in de processen. Behalve batchverwerking kiest men ook vaak voor webservices met een request-response patroon. Het idee hierachter is dat consumerende systemen per bevraging gegevens via een webservice ontsluiten bij het bronsysteem. Het nadeel hiervan is de doorvoersnelheid bij grote hoeveelheden, complexiteit van verwerking, schaalbaarheid en beschikbaarheid van het bronsysteem.

Hoe past EDA bij SOA of andersom?

We kunnen EDA zien als basis SOA integratiepatroon: publish/subscribe met een aantal toevoegingen. Het belangrijkste is de event processing engine met verschillende vormen van processing (simple, stream en complex event processing). Behalve event processing engine´s, die meestal niet eens nodig zijn, is er technisch niks nieuws voor SOA experts onder de lezers. Het zijn asynchrone berichten verstuurd door een (bron)systeem, in EDA genoemd event generator. Deze berichten worden vervolgens verspreid naar meerdere afnemende systemen, eventueel met een tussenkomst van een ESB en/of event processing engine. Sommigen noemen EDA een specifieke SOA style, al lijken we hiermee EDA te kort te doen. Het nadruk ligt namelijk meer op gebeurtenissen en minder op services die ze verwerken.

Toekomst van EDA

EDA kent vele voordelen vanuit een technische invalshoek, maar deze zijn al min of meer bekend en grotendeels benut. Echter, zoals eerder vermeld, echte voordelen zijn te behalen als business EDA manier van denken omarmt. Business mensen begrijpen vaak bulkverwerking en webservices en bij het bedenken van een business architectuur houden ze, vaak onbewust, rekening met beperkingen van deze concepten. Dit heb ik concreet gemerkt bij mensen betrokken bij uitwisseling van basisgegevens op overheidsniveau tussen instanties zoals Belastingdienst, gemeenten, Kadaster en KvK.Wanneer de business de aard van een gebeurtenis begrijpt, ontstaan ook business processen die zelfs over meerdere bedrijven heen volledig geautomatiseerd op elkaar aansluiten. Bijvoorbeeld: als een burger een eenmanszaak bij KvK registreert, is dat een specifi eke entiteit genaamd eenmanszaak- registratie in vorm van een XML bericht dat eerst bij KvK | een registratie in de Handelsregister tot gevolg heeft. Vervolgens wordt dit bericht eventueel aangepast of aangevuld met additionele gegevens en verstuurd naar Belastingdienst. Hetzelfde bericht wordt ook naar het CBS, gemeente en nog meer instanties verstuurd. Het proces zou in theorie volledig geautomatiseerd kunnen zijn. Het valt te denken aan een webapplicatie voor een ondernemer waarin registratie volledig gevalideerd en afgerond wordt. Het bij de Belastingdienst ontvangen bericht een geautomatiseerd proces initieert met gevolg voor belastingaangifte processen en voor eigen rapportagedoeleinden. Het CBS zou dan over real-time statistieken kunnen beschikken dat op dit moment alleen in Science fiction films te zien zijn. Technisch is dit allemaal nu al mogelijk. Meer complexe technische uitdagingen zoals complexe regels m.b.t. de afhandeling van gebeurtenissen. Hier komen onder andere Event Processing Engines bij kijken. Een echt probleem is echter de diepgewortelde manier van werken en denken. Er zijn vele afdelingen of zelfs organisaties opgericht uit de noodzaak om batchverwerking te kunnen faciliteren of on-demand services in allerlei vormen te kunnen bieden. Vanuit technische en theoretische invalshoek zouden ze met de komst van EDA opgeruimd kunnen worden, maar vanuit een politieke en organisatorische invalshoek hebben we een hele lange weg te gaan. We zien nu vele tussenvormen waarin slechts een deel van het proces gebeurtenisgedreven is of een parallel batchproces gecreëerd wordt voor afdelingen en organisaties die nog op oude manier denken of zien technische problemen met hun verouderde omgevingen. Trouwens, deze technische problemen zijn vaak denkbeeldig. Zelfs technici weigeren soms om een overgang te maken naar deze nieuwe manier van denken en werken. Deze tussenvormen brengen ook voordelen met zich mee. Met name kostenbesparing op lokaal niveau. Ze brengen echter ook complexe uitdagingen op de plekken waar gebeurtenisgedre venverwerking overgaat naar batchgedreven. Op die plekken heeft men ineens behoefte aan lokale opslag met een initiële vulling. Er zijn vele uitzonderingen en herstelacties omdat database corrupt raakt door het weghalen van berichten. Deze complexiteit kan de business case in gevaar brengen. Met andere woorden, echt grote voordelen worden behaald als volledig proces gebeurtenisgedreven plaatsvindt.

EDA en datawarehousing

EDA is al datawarehousing concepten aan het veranderen. Met name als het gaat om real time of zogenaamde integrated datawarehouse. Basisconcept van een datawarehouse: ETL wordt dan TL. Bij toepassing van EDA worden gegevens gepusht in plaats van "extracted". Ieder afzonderlijk bericht produceert wijzigingen in de verschillende lagen van een datawarehouse architectuur.

Hoe introduceer je EDA in je architectuur?

Een grote voordeel van EDA is dat het geïntroduceerd kan worden zonder dat iemand daadwerkelijk die term noemt. Er komt vaak naar boven bij brainstormsessie wanneer integratieoplossingen moeten worden bedacht. Diegene die als eerst asynchrone berichten van type "gevent" noemt is al met EDA bezig. Het is bij introductie cruciaal de business voordelen van EDA te benadrukken.

Bij deze samengevat:

• Gestroomlijnde processen door eenduidigheid in gebeurtenissen en afhandeling
• Bijna relatie beschikbaarheid van informatie
• Minder kosten door substantieel minder routinematige handelingen en tussenstappen die gepaard gaan met batchverwerking
• Extreme ontkoppeling van systemen
• Extreme schaalbaarheidsmogelijkheden

Gevaren van EDA

Bij een grootschalige EDA uitrol waar gebeurtenisberichten massaal door de organisatie worden verspreid gaan systemen reageren op deze berichten en vervolgens zelf nieuwe gebeurtenisberichten produceren. Er kunnen dan onbedoelde en ongecontroleerde eventlawines ontstaan. Dit kan zowel binnen een systeem als over meerdere bedrijven heen ontstaan. Een vaak voorkomend probleem is historische opbouw van gegevens, volgordelijkheid en afhankelijkheid tussen de gebeurtenisberichten onderling. In vele schakels is de kans groot dat een bericht wegvalt of simpelweg ingehaald wordt door een ander bericht waar deze van afhankelijk is. Bijvoorbeeld, een eerder genoemde eenmanszaak registratie wordt ingehaald door een adreswijziging. Een ontvangend systeem kan met tweede niks doen zolang eerste niet is verwerkt.

Is EDA haarlemmerolie?

Nee, zeker niet. Het zal ook SOA of datawarehouses niet vervangen, maar slechts aanvullen. Ik hoop ook dat EDA geen nieuwe hype wordt, maar gewoon "good architecture". Onderliggende architectuurprincipes gekozen op basis van business behoefte moeten voorrang krijgen boven de term EDA en weer nieuwe tools die zogenaamd EDA voor je out-of-box leveren. Nogmaals, technologie bestaat er al! Deze is zeker voor de verbetering vatbaar, maar daar liggen geen echte problemen om EDA oplossingen succesvol te maken.

Een randvoorwaarde voor toepassing van EDA is de notie van gebeurtenis. Zodra iemand vanuit business over gebeurtenissen heeft, wat bijna onvermijdelijk onderdeel van procesmatig denken uitmaakt, kan EDA overwogen worden. Ieder proces begint namelijk met een gebeurtenis, al heeft deze in veel situaties geen bijzondere betekenis. Bijv. een abonnee leent een boek uit in een bibliotheek. De nadruk ligt hier niet op deze gebeurtenis, maar meer op toestandswijziging van het uitgeleende boek die in een database moet worden vastgelegd. In dit soort gevallen spreken we niet over EDA.