Tapahtumapohjainen arkkitehtuuri (EDA) on tapa rakentaa ohjelmistoja siten, että järjestelmän osat viestivät toisilleen ilmoittamalla, että jotain tapahtui, sen sijaan että ne kutsuisivat toisiaan suoraan. Yksi komponentti julkaisee tapahtuman, esimerkiksi ”lasku maksettu” tai ”sopimus allekirjoitettu”. Jokainen muu komponentti, jota asia koskee, reagoi siihen. Kummankaan osapuolen ei tarvitse tietää toisen olemassaolosta.

SaaS-yritykselle tällä on merkitystä selvästi ohjelmistokehitystä laajemmin. Sama ajatus on sujuvien CRM-talous-siirtymien, luotettavan automaation ja ajantasaiseen dataan perustuvien tekoälyagenttien taustalla. Tässä oppaassa kerrotaan, miten EDA toimii, miten tapahtumaväylä eroaa jonosta, miten yleiset virheet vältetään ja mihin EDA kuuluu ja mihin ei.

Tiivistelmä

Sisällysluettelo

Mitä tapahtumapohjainen arkkitehtuuri on

Microsoftin arkkitehtuuriohjeistus kuvaa tyylin näin: tapahtumatuottajat luovat tapahtumavirran, tapahtumakuluttajat kuuntelevat sitä ja tapahtumakanavat kuljettavat tapahtumat toisesta toiseen. Tämä kolmiosainen malli on koko ajatus. Kaikki muu on yksityiskohtia siitä, kuinka luotettavasti ja nopeasti kanava toimii.

Vastakohta on pyyntö/vastaus-malli. Pyyntö/vastaus-mallissa laskutuspalvelu kutsuu CRM:ää ja odottaa vastausta. Jos CRM on hidas tai alhaalla, laskutus jumittuu. Tapahtumapohjaisessa mallissa laskutus julkaisee tapahtuman ”maksu vastaanotettu” ja jatkaa eteenpäin. CRM, tuloraportti ja asiakasmenestyksen kojelauta poimivat tapahtuman kukin silloin, kun ovat valmiita.

Tästä seuraa kaksi ominaisuutta:

Mikä lasketaan tapahtumaksi

Tapahtuma on menneessä aikamuodossa esitetty tosiasia. Red Hat kuvaa sen näin: muuttumaton tallenne siitä, että jotain tapahtui, usein aikaleimalla varustettuna, joka säilyttää järjestyksen suhteessa tapahtuman tuottaneeseen järjestelmään. Tapahtumaa ei muokata jälkikäteen. Jos jokin muuttuu, uusi tapahtuma kirjaa muutoksen.

AWS toteaa, että tapahtumat voivat olla tilan muutos tai päivitys, ja ne voivat joko sisältää tilan tai olla tunnisteita. Kaksi esimerkkiä:

Tyyli Esimerkki Mitä kuluttaja saa
Tilan sisältävä tapahtuma Tilaus päivitetty: paketti, hinta, voimaantulopäivä, tilin tunniste Kaikki toimimiseen tarvittava ilman toista hakua
Tapahtuma tunnisteena Tilaus lähetetty: vain tilauksen tunniste Signaali. Kuluttaja hakee tiedot lähdejärjestelmästä

Ensimmäinen vaihtoehto on kätevä, mutta sitoo kuluttajat tapahtuman rakenteeseen. Toinen pitää tapahtumat pieninä, mutta lähettää kuluttajat takaisin lähdejärjestelmään, mikä nostaa esiin kysymyksen siitä, mikä järjestelmä on ensisijainen tietolähde. Palaamme tähän jäljempänä, koska juuri tässä useimmat SaaS-yritysten operatiiviset järjestelmäkokonaisuudet kompastuvat.

Komento ei ole tapahtuma. ”Lähetä lasku” on ohje tietylle vastaanottajalle. ”Lasku lähetetty” on tosiasia, johon kuka tahansa voi reagoida. Näiden sekoittaminen on yleinen suunnitteluvirhe, ja se rakentaa hiljaa uudelleen sen tiukan kytkennän, josta yritettiin päästä eroon.

Miten tapahtumapohjainen järjestelmä toimii vaihe vaiheelta

Google Cloudin dokumentaatio kuvaa kulun seuraavasti: tuottajat luovat tapahtumia, reititin tai välittäjä vastaanottaa ja suodattaa ne ja jakaa ne sitten kuluttajille tilausten tai triggerien perusteella. Käytännössä:

  1. Jotain tapahtuu. Kauppa siirtyy CRM-järjestelmässä tilaan “Closed Won”.
  2. Tuottaja julkaisee tapahtuman. Se kertoo tosiasian ja tietueen, jota se koskee.
  3. Välittäjä reitittää sen. Se suodattaa tapahtuman ja toimittaa sen jokaiselle tilaajalle.
  4. Kuluttajat reagoivat toisistaan riippumatta. Talous luo laskuluonnoksen. Customer Success avaa käyttöönottosuunnitelman. Käyttöoikeuksien luontiprosessi valmistelee pääsyn.
  5. Jokainen kuluttaja kuittaa. Välittäjä tietää, että tapahtuma on käsitelty, ja voi yrittää uudelleen, jos sitä ei ole käsitelty.

IBM kuvaa saman mallin tapahtumien julkaisuna, vastaanottona, käsittelynä ja tallennuksena ja huomauttaa, että tapahtuman arvo voi muuttua ajan myötä. “Uusi liidi” -tapahtumaan kannattaa reagoida minuuteissa. Vuoden kuluttua se on hyödyllinen lähinnä analyysiin.

Tapahtumapohjainen arkkitehtuuri ja mikropalvelut

Näitä pidetään usein samana asiana. Ne eivät ole sitä. Mikroservicet kuvaavat, miten sovellus jaetaan pieniin, itsenäisesti käyttöönotettaviin palveluihin. EDA kuvaa, miten nämä palvelut kommunikoivat keskenään. Mikroservicet voivat kutsua toisiaan synkronisesti, ja monoliitti voi julkaista tapahtumia sisäisesti.

Nämä toimivat hyvin yhdessä. Googlen ohjeistuksen mukaan mikroservicet voivat reagoida tapahtumiin asynkronisesti ja niiden tarvitsee tuntea vain tapahtuman muoto, ei toistensa liiketoimintalogiikkaa. Tämä yhteinen muoto on sopimus. Kaikkea sen takana olevaa voi muuttaa.

Microsoftin dokumentaatio kuvaa tyypillisen mallin seuraavasti: mikroservicet julkaisevat tapahtuman, kun jotain merkittävää tapahtuu, ja muut mikroservicet tilaavat sen.

Tapahtumaväylä, jono ja virta

Nämä kolme käsitettä sekoitetaan useimmin, ja valinta muuttaa järjestelmäsi toimintaa.

Tapahtumaväylä (publish/subscribe). Tapahtumaväylä on mekanismi, jossa julkaisijat ilmoittavat tapahtumista ja tilaajat vastaanottavat ne. Microsoft kertoo, että se voidaan toteuttaa viestinvälitysinfrastruktuurin, kuten jonon tai asynkronista publish/subscribe-mallia tukevan palveluväylän, päälle. Jono voi siis olla yksi väylän rakennuspalikoista. Väylä on tarkoitus. Jono on yksi tapa toteuttaa se.

Jono. Jono säilyttää viestejä, kunnes työntekijä ottaa ne käsiteltäväksi. Yleensä yksi kuluttaja käsittelee kunkin viestin. Jonot sopivat työn jakamiseen useiden työntekijöiden kesken ja kuormituspiikkien tasaamiseen. Azuren integraatio-ohjeistus mainitsee yhtenä syynä käyttää välittäjää sen, että viestit voidaan asettaa jonoon, kun taustajärjestelmä ei ole käytettävissä.

Tapahtumavirta. Azure erottaa publish/subscribe-mallin ja suoratoiston toisistaan. Publish/subscribe-mallissa tapahtumaa ei vastaanoton jälkeen säilytetä pysyvässä lokissa, joten uudet tilaajat eivät näe aiempia tapahtumia. Suoratoistossa tapahtumat kirjoitetaan lokiin, joka on pysyvä ja tiukasti järjestetty osion (partition) sisällä, ja asiakkaat lukevat lokia, voivat liittyä mukaan milloin tahansa ja toistaa tapahtumia.

Jono Publish/subscribe-väylä Tapahtumavirta
Toimitus Yksi kuluttaja viestiä kohti Jokainen tilaaja Mikä tahansa lukija, mistä tahansa kohdasta
Aiemmat tapahtumat Poistetaan käsittelyn jälkeen Ei uusien tilaajien saatavilla Säilytetään ja toistettavissa
Tyypillinen käyttö Työn jakaminen, puskurointi Usean järjestelmän tiedottaminen Historia, analytiikka, tilan uudelleenrakentaminen

Käytännön nyrkkisääntö: jos usean järjestelmän pitää reagoida samaan tosiasiaan, käytä publish/subscribe-mallia. Jos yhden työntekijän pitää hoitaa tehtävä, käytä jonoa. Jos tarvitset historiaa tai kykyä rakentaa jokin jatkokäsittelyjärjestelmä uudelleen, käytä tapahtumavirtaa. Red Hat lisää, että kaikille sopivaa ratkaisua ei ole, joten valitse teknologia tapahtumatyypin mukaan.

Onko Kafka tapahtumapohjainen arkkitehtuuri?

Ei. Kafka on teknologia, jolla sellaisen voi rakentaa. Apache Kafkan dokumentaatio kuvaa sen alustaksi, joka on tarkoitettu tapahtumavirtojen käsittelyyn: tapahtumien tallentamiseen reaaliajassa, niiden pysyvään säilyttämiseen, käsittelyyn ja reitittämiseen muihin järjestelmiin. Siksi se on yllä olevan taulukon mukainen tapahtumavirta.

Arkkitehtuuri on joukko suunnittelupäätöksiä: mitä tapahtumat ovat, kuka niitä omistaa, miten kuluttajat eristetään toisistaan ja mitä tapahtuu virhetilanteessa. Nämä päätökset voi tehdä ja toteuttaa hallitulla pilviväylällä, jonopalvelulla tai Kafkalla. Kafkaa käyttäen voi silti päätyä tiukasti kytkettyyn järjestelmään, jos jokainen palvelu riippuu toisen palvelun sisäisistä tapahtumista. Valitse työkalu vasta, kun olet määritellyt tapahtumat ja odottamasi todellisen volyymin.

Tapahtumapohjainen integraatio ja automaatio

Tässä EDA muuttuu merkitykselliseksi operatiivisille johtajille eikä vain insinööreille.

Integraatio

Useimmat SaaS-yritykset yhdistävät CRM-, laskutus-, tuki- ja tuotedatansa pisteestä pisteeseen -synkronoinneilla. Jokainen uusi työkalu lisää uuden ylläpidettävän yhteyden. Azure suosittelee asynkronista viestintää viestinvälittäjän kautta suorien synkronisten kutsujen sijaan neljästä syystä, jotka se luettelee: sovellusten erottaminen toisistaan, viestien jakelu usealle kuluttajalle, pitkäkestoisten työnkulkujen luotettava seuranta ja viestien jonottaminen, kun taustajärjestelmä ei ole käytettävissä.

Hyöty näkyy, kun lisäät järjestelmän. Publish/subscribe-palvelun kanssa uusia tilaajia voi lisätä päivittämättä lähettäjää. Uuden analytiikkatyökalun lisääminen ei vaadi muutoksia CRM-järjestelmääsi.

Automaatio

Tapahtumapohjainen automaatio tarkoittaa, että liiketoimintaprosessi käynnistyy, koska jotain tapahtui, eikä siksi, että joku painoi nappia tai yöllinen ajo käynnistyi. ServiceNowin flow-opas antaa käytännöllisen menetelmän: tunnista triggeri, suunnittele logiikka, valitse toiminnot ja tunnista uudelleenkäytettävä logiikka. Se suosittelee myös pitämään flowt kohdennettuina ja käyttämään yhtä verbiä toimintoa kohti.

Kun prosessi kattaa useita palveluita, Microsoftin mukaan tapahtumapohjaiset järjestelmät käyttävät työnkulun koordinointiin yleisesti koreografia- ja saga-orkestrointimalleja. Koreografiassa jokainen palvelu reagoi tapahtumiin ja lähettää omia tapahtumiaan. Orkestroinnissa koordinaattori kertoo jokaiselle vaiheelle, mitä tehdä, ja seuraa koko prosessia. Ensimmäisessä projektissa orkestroitu työnkulku on yleensä helpompi lukea ja auditoida.

Yksinkertainen SaaS-esimerkki:

Parhaat käytännöt ja yleiset haasteet

Azure luettelee keskeiset haasteet: eventual consistency eli lopullinen yhdenmukaisuus, asynkroninen virheenkäsittely, tietojen menetys, havainnoitavuus ja testaus, liian monet tai liian yhdistetyt tapahtumat sekä skeeman kehitys. Jokaiseen on olemassa vastaava käytäntö.

  1. Varaudu lopulliseen yhdenmukaisuuteen. Järjestelmät ovat hetkellisesti eri mieltä. Päätä, mikä järjestelmä on kunkin tiedon ensisijainen lähde, ja anna muiden seurata sitä.
  2. Lisää oma virheenkäsittelijä. Epäonnistuneille tapahtumille tarvitaan paikka, johon ne päätyvät, ja joku, joka tarkastaa ne.
  3. Säilytä tapahtumat, kunnes vastaanotto on kuitattu. Tämä suojaa tietojen menetykseltä, kun vastaanottaja on pois käytöstä.
  4. Käytä korrelaatiotunnisteita. Yksi tunniste, joka kulkee mukana jokaisessa vaiheessa, mahdollistaa yksittäisen asiakastoiminnon jäljittämisen järjestelmien välillä.
  5. Tasapainota tapahtumien rakeisuus. Yksi tapahtuma jokaisesta kentän muutoksesta tuottaa kohinaa. Yksi jättimäinen tapahtuma kaikesta luo takaisin tiukan kytkennän.
  6. Versioi skeemat ajoissa. Tapahtumien muodot muuttuvat. Päätä tavasta ennen kuin sinulla on kaksikymmentä vastaanottajaa.

Näiden lisäksi lisäisimme kolme toiminnallista tapaa: nimeä tapahtumat menneellä aikamuodolla, anna jokaiselle tapahtumatyypille yksi omistaja ja kirjaa ylös, mitkä vastaanottajat siitä riippuvat.

Mihin tapahtumapohjainen suunnittelu ei kuulu

EDA ei ole vastaus kaikkiin ongelmiin. Selvitä rajat tarkasti ennen sitoutumista:

Sama logiikka pätee tekoälyyn. Tekoälyavustaja, joka lukee järjestelmiäsi ja toimii niissä, on tapahtumien vastaanottaja ja tuottaja. Jos se lukee epäjohdonmukaista dataa tai toimii ilman käyttöoikeusrajaa, virheitä syntyy nopeammin.

Missä tämä kohtaa tekoälyagentit ja vaatimustenmukaisuuden

Tekoälyagentit, jotka hakevat dataa (kysyvät, raportoivat, etsivät) ja vievät dataa (päivittävät tietueen, käynnistävät prosessin, myöntävät käyttöoikeuden), käyttäytyvät kuin tapahtumapohjaisen järjestelmän osapuolet. Ne tarvitsevat luotettavan lähteen luettavaksi, selkeän joukon sallittuja toimintoja, hyväksynnän arkaluonteisille vaiheille ja kirjauksen tekemisistään. Tapahtumaloki on luonteva paikka tälle kirjaukselle.

Operaattori tarkastelee tekoälyagentin tapahtumalokia

Eurooppalaisissa yrityksissä GDPR, NIS2 ja EU AI Act vaikuttavat kaikki tällaisten järjestelmien suunnitteluun. Yleisesti ne koskevat sitä, mitä henkilötietoja tapahtumissa liikkuu, miten tietoturva ja häiriötilanteiden käsittely järjestetään sekä miten tekoälyjärjestelmiä hallitaan ja dokumentoidaan. Käsittele niitä suunnittelun lähtökohtina alusta alkaen ja pyydä lakimieheltä neuvoa siihen, miten ne koskevat juuri sinun tilannettasi. Yksikään arkkitehtuuriratkaisu ei yksin tee järjestelmästä vaatimustenmukaista.

Näkemyksemme

Useimmilla SaaS-yrityksillä, joiden kanssa keskustelemme, ei ole tapahtumaongelmaa. Heillä on omistajuusongelma. Useampi tiimi käyttää tekoälyä, useampi työkalu pitää sisällään version asiakkaasta, eikä kukaan vastaa siitä, mikä versio on oikea.

Siksi työskentelemme kiinteässä järjestyksessä. Ensin data foundation eli datapohja: CRM- ja talousdata sovittuna totuuden lähteenä. Sitten tekoälykerros, joka yhdistää tämän datan tiimisi jo käyttämään avustajaan. Sen jälkeen osastokohtaiset agentit Financelle, Salesille ja Customer Successille. Tapahtumista on hyötyä kaikissa kolmessa kerroksessa, mutta vasta kun niiden kuljettamat tiedot on sovittu.

Otamme myös käyttöön yhden prosessin kerrallaan ja aloitamme kalleimmasta. Uusimisprosessi tai laskusta maksuun -siirtymä on parempi ensimmäinen tapahtumapohjainen projekti kuin koko yrityksen kattava uudistus. Näet tuloksen, väkesi oppii mallin ja seuraava prosessi tulee halvemmaksi.

Koska hoidamme myös käyttöä emmekä vain suunnittele järjestelmiä, välitämme tylsistä osista: käyttöoikeuksista, hyväksynnöistä, auditointijäljistä ja luovutuksesta, jossa omistat koodin, dokumentaation ja infrastruktuurin.

Claus Nielsen

Alkuun pääseminen omassa yrityksessä

Sinun ei tarvitse valita ensin viestinvälittäjää. Aloita näillä kysymyksillä:

  1. Mikä prosessi maksaa sinulle eniten manuaalisen työn, viiveiden tai virheiden vuoksi?
  2. Mitkä ovat ne kaksi tai kolme tapahtumaa, jotka sen käynnistävät (esimerkiksi kauppa solmittu, lasku erääntynyt, uusiminen lähestyy)?
  3. Mikä järjestelmä on näiden tapahtumien datan totuuden lähde?
  4. Kuka omistaa kunkin tapahtumamäärittelyn?
  5. Mitkä vaiheet vaativat ihmisen hyväksynnän?

Jos et osaa vastata kolmanteen kysymykseen, data foundation eli datapohja tulee ensin. Jos osaat, pieni pilotti yhdellä prosessilla näyttää, kannattaako tapahtumapohjainen lähestymistapa.

Näin voimme auttaa

Jos tiimisi käyttää tekoälyä mutta kukaan ei omista sitä, voimme auttaa sinua päättämään, missä se kannattaa, ja rakentamaan sen oikeassa järjestyksessä. AI Readiness Assessment on saatavilla hintaan alkaen €4,500, ja se tarkastelee dataasi, järjestelmiäsi ja prosessejasi ennen kuin mitään rakennetaan. Jos haluat jatkuvaa johtamista, Fractional Chief AI Officer -sopimus alkaa hinnasta €1,500 kuukaudessa.

Toteutukset hinnoitellaan 30%:iin mitatusta ja todennetusta ensimmäisen vuoden säästöstä tai kiinteään hintaan, joka sovitaan ennen työn alkua. Voit myös varata maksuttoman 30 minuutin tutustumispuhelun sivustomme kautta. Tekoälyagenttimme Financelle, Salesille ja Customer Successille näyttävät, miltä osastokerros näyttää, kun pohja on kunnossa.

UKK

Mitä tapahtumapohjainen arkkitehtuuri tarkoittaa yksinkertaisesti?

Se on suunnittelumalli, jossa ohjelmistokomponentit ilmoittavat, että jotain tapahtui, ja muut komponentit reagoivat. Lähettäjä ei tiedä, kuka kuuntelee. Näin voit lisätä tai muuttaa järjestelmiä kirjoittamatta uudelleen niitä, jotka tuottavat tapahtumat.

Mitä eroa on tapahtumaväylällä ja viestijonolla?

Jono toimittaa yleensä jokaisen viestin yhdelle työntekijälle. Tapahtumaväylä toimittaa jokaisen tapahtuman kaikille tilaajille. Väylä voidaan rakentaa jonoinfrastruktuurin päälle, joten ero on tarkoituksessa ja toimitustavassa, ei aina tuotteessa.

Onko tapahtumapohjainen arkkitehtuuri sama asia kuin mikropalvelut?

Ei. Mikropalveluissa on kyse siitä, miten sovellus jaetaan palveluiksi. Tapahtumapohjaisessa arkkitehtuurissa on kyse siitä, miten osat kommunikoivat. Niitä käytetään usein yhdessä, mutta kumpikin voi olla olemassa ilman toista.

Milloin SaaS-yrityksen kannattaa käyttää tapahtumapohjaista automaatiota?

Käytä sitä, kun liiketoimintaprosessin pitäisi käynnistyä tosiasiasta, kuten suljetusta kaupasta tai lähestyvästä uusinnasta, ja useiden tiimien tai järjestelmien täytyy reagoida siihen. Aloita yhdestä kalliista prosessista ja varmista ensin, että lähdedatasta on sovittu.

Lähteet