Tapahtumalähtöinen integraatiomodernisaatio

Miten se toimii

Yksi tapahtuma. Kaikki järjestelmät ajan tasalla.

Publish-subscribe-malli korvaa jokaisen point-to-point-yhteyden yhdellä tapahtumaväylällä. Järjestelmät julkaisevat tapahtumia. Muut järjestelmät tilaavat vain sen, mitä ne tarvitsevat. Kukaan ei tarvitse tietää, kuka kuuntelee.

OUT

Järjestelmä julkaisee

"Tilaus tehty" — lähetetään tapahtumaväylälle. Julkaisija ei tiedä, kuka tapahtuman saa.

›

⚡

Tapahtumaväylä reitittää

Reitittää, kirjaa ja takaa toimituksen. Epäonnistuneet toimitukset yritetään automaattisesti uudelleen.

›

Tilaajat reagoivat

ERP varaa varaston. Varasto käynnistää keräilyn. Taloushallinto kirjaa. Kukin itsenäisesti.

›

LOG

Kaikki kirjataan

Täydellinen audit trail: mitä tapahtui, milloin ja missä järjestelmässä. Tapahtumahistoria on aina toistettavissa.

Nykytila — point-to-point

Jokainen järjestelmä tietää liikaa

Järjestelmä A puhuu suoraan B:lle, C:lle ja D:lle. Kun A muuttuu, B, C ja D hajoavat. Jokainen uusi integraatio vaatii muutoksia useaan paikkaan.

↑ Klikkaa järjestelmää — näe mihin se on kytkettynä

✕Tiukka kytkentä — muutos yhdessä on riski kaikkialle
✕Ei lokia — virheet huomataan vasta kun ne ovat kasaantuneet
✕Uuden järjestelmän lisääminen vaatii muutoksia kaikkialle
✕Datavirheet leviävät järjestelmästä toiseen huomaamatta

Tavoitetila — tapahtumalähtöinen

Järjestelmät julkaisevat. Järjestelmät tilaavat.

Jokainen järjestelmä kytkeytyy väylään kerran. Uusi järjestelmä = yksi uusi tilaaja. Muutos yhteen järjestelmään ei koske muita.

↑ Klikkaa järjestelmää — pub/sub eristää muutokset

✓Löyhä kytkentä — muutos yhteen järjestelmään ei vaikuta muihin
✓Jokainen tapahtuma kirjattu: aikaleima, lähde, sisältö
✓Uuden järjestelmän lisääminen = yksi uusi tilaaja
✓Puhdas tapahtumavirta toimii suoraan pohjana tekoälylle ja analytiikalle

Tämä kannattaa tietää etukäteen

Tapahtumalähtöinen arkkitehtuuri tarkoittaa eventual consistency -mallia — data ei päivity kaikkiin järjestelmiin täsmälleen samalla hetkellä. Tapahtumat etenevät sekunneissa, ei reaaliajassa. Suurimmassa osassa liiketoimintaprosesseja tämä on täysin riittävää. Kerromme suoraan, jos se ei ole.

Muutoskustannuslaskin

Mitä arkkitehtuuri maksaa muuttaa?

P2P: jokainen muutos vaatii muutoksia n−1 järjestelmään. Pub/sub: yksi muutos, yksi järjestelmä. Luku olettaa 3 kehitystyöpäivää per kosketettu järjestelmä.

Järjestelmiä 7

Muutoksia / vuosi 12

Point-to-point

—

kehitystyöpäivää / vuosi

Pub / sub

—

kehitystyöpäivää / vuosi

Tapahtumavirta

Yksi tilaus. Viisi järjestelmää. Itsenäisesti.

Klikkaa eteenpäin — seuraa miten "order.created"-tapahtuma kulkee tapahtumaväylän kautta. Jokainen järjestelmä reagoi omassa tahdissaan ilman suoraa yhteyttä muihin.

Use Case

Integraatiomodernisaatio käytännössä

Use Case:
Tapahtumalähtöinen integraatio

Integraatiomodernisaatio

Tilanne

Yritys pyörittää useita järjestelmiä — ERP, CRM, varasto, verkkokauppa, taloushallinto, logistiikka. Jokainen liitettiin point-to-point sitä mukaa kuin se hankittiin. Nyt jokainen järjestelmämuutos on riski — joku muu voi hajota. Integraatiokerros hidastaa kehitystä, turhauttaa tiimit ja korruptoi dataa näkymättömästi.

Ratkaisu

Point-to-point-yhteydet korvataan tapahtumaväylällä. Jokainen järjestelmä julkaisee tapahtumia ja tilaa vain sen, mitä tarvitsee. Muutos yhteen järjestelmään ei koske muita. Uudet integraatiot syntyvät päivissä, ei kuukausissa.

Teknologia

• Julkaise-tilaa-malli (Pub/Sub)
• Tapahtumaväylä — pilvinatiivi tai oma ympäristö
• REST / webhook -adapterit järjestelmäkohtaisesti
• Dead-letter-jonot + automaattinen uudelleentoisto
• Keskitetty tapahtumaloki + monitorointi

Tulos

Järjestelmämuutokset eivät enää kaada muita järjestelmiä · Uudet integraatiot päivissä, ei kuukausissa · Täydellinen tapahtumaloki · Puhdas datapohja tekoälylle ja analytiikalle

Proof of Concept

Rakennetaan demo teidän ympäristöönne.

Kytkemme kolme teidän järjestelmistänne — tai realistisen simulaation — live-tapahtumaväylään. Näette oikean liiketoimintatapahtuman kulun päästä päähän: kirjattuna, monitoroituna ja toistettavana. Ei kalvoja. Ei lupauksia. Toimiva ratkaisu.

Demoskenaario

1
Tilaus kirjataan verkkokaupassa tai ERP:ssä
2
Tapahtumaväylä vastaanottaa "order.created"-tapahtuman ja reitittää sen tilaajille
3
ERP-tilaaja reagoi — varasto varataan automaattisesti
4
Varastotilaaja saa ilmoituksen — keräilylista luodaan
5
Yksi järjestelmä kaadetaan tarkoituksella — automaattinen palautus dead-letter-jonosta näytetään

Mitä näette livenä

→
Reaaliaikainen tapahtumavirta monitorointinäkymässä
→
Jokainen tapahtuma kirjattu: aikaleima, lähde, sisältö
→
Epäonnistunut toimitus käsitellään automaattisesti dead-letter-jonon kautta
→
Uusi tilaaja lisätään kesken demon — julkaisijakoodiin ei kosketa
→
Ennen/jälkeen-vertailu: vanha point-to-point vs. tapahtumaväylä

Tämä sopii teille, jos

Järjestelmämuutos rikkoi äskettäin jotain muuta · Uusien integraatioiden rakentaminen kestää kuukausia · Tekoälyhanke odottaa puhdasta dataa · Tiimissänne on integraatiokoodia, jota kukaan ei enää täysin hallitse

Miten työskentelemme yhdessä

Kolme vaihetta. Ei pakollista sitoutumista.

Kartoitamme tilanteen ennen kuin ehdotamme ratkaisua. Auditointi kertoo, mikä vaihe on teille kriittisin ja missä järjestyksessä kannattaa edetä. Jokaisen vaiheen jälkeen päätätte itse, jatketaanko.

Vaihe 1

Integraatioauditointi

Kartoitetaan kaikki nykyiset integraatiot ja riippuvuudet
Arvioidaan jokaisen yhteyden hauraus ja liiketoimintariski
Tunnistetaan kriittisimmät modernisointikohteet
Arvioidaan nykytilan piilotetut kustannukset
Toimitetaan konkreettinen, priorisoitu etenemissuunnitelma

Vaihe 2

Live-PoC

Rakennetaan tapahtumaväylä teidän ympäristöönne
Kytketään 2–3 järjestelmää väylään päästä päähän
Ajetaan live-demo: yksi tapahtuma, useita vastaanottajia
Näytetään virheenkäsittely ja automaattinen uudelleenyritys
PoC jää teidän ympäristöönne — se on teidän omaisuuttanne

Vaihe 3

Täysi käyttöönotto

Vaiheistettu migraatio — ei kerralla kaikkea
Publish/subscribe-malli suunnitellaan järjestelmäkohtaisesti
Monitorointi, hälytykset ja virheenkäsittely
Dokumentaatio ja arkkitehtuurikuvaukset
Osaamisen siirto teidän tiimillenne