Yksi tapahtuma pitää kaikki järjestelmät ajan tasalla
Publish-subscribe-malli (pub/sub) korvaa suorat yhteydet yhdellä tapahtumaväylällä. Järjestelmä julkaisee tapahtuman väylälle, ja muut järjestelmät tilaavat vain ne tapahtumat, joita tarvitsevat. Julkaisijan ei tarvitse tietää, kuka kuuntelee.
ERP:stä tuli vahingossa integraatiokeskus
Jokainen uusi järjestelmä kytkettiin ERP:hen sitä mukaa kuin se hankittiin. Lisäksi järjestelmien välille rakennettiin suoria yhteyksiä. Nyt ERP:tä ei voi päivittää koskematta kaikkeen muuhun.
- ✕Järjestelmät ovat tiukasti kytkettyjä, joten muutos yhdessä on riski kaikille
- ✕Lokia ei ole, joten virheet huomataan vasta, kun niitä on kertynyt paljon
- ✕ERP:n päivitys tai vaihto koskee jokaista siihen kytkettyä integraatiota
- ✕Datavirheet leviävät järjestelmästä toiseen huomaamatta
Järjestelmät julkaisevat ja tilaavat tapahtumia väylän kautta
Jokainen järjestelmä kytketään väylään vain kerran. Uusi järjestelmä on väylälle yksi uusi tilaaja. Muutos yhdessä järjestelmässä ei koske muita.
- ✓Järjestelmät ovat löyhästi kytkettyjä, joten muutos yhdessä ei vaikuta muihin
- ✓Jokaisesta tapahtumasta kirjataan aikaleima, lähde ja sisältö
- ✓Uusi järjestelmä lisätään yhtenä uutena tilaajana
- ✓Puhdas tapahtumavirta käy sellaisenaan tekoälyn ja analytiikan pohjaksi
Tämä kannattaa tietää etukäteen
Tapahtumalähtöinen arkkitehtuuri perustuu eventual consistency -malliin. Tieto ei päivity kaikkiin järjestelmiin täsmälleen samalla hetkellä, vaan tapahtumat etenevät sekunneissa eivätkä reaaliajassa. Useimmissa liiketoimintaprosesseissa tämä riittää hyvin. Jos teidän prosessissanne ei riitä, kerromme sen suoraan.
Muutosten hinta kahdessa arkkitehtuurissa
Suorissa yhteyksissä (point-to-point, P2P) jokainen muutos vaatii muutoksia n−1 järjestelmään. Pub/sub-mallissa muutos koskee vain yhtä järjestelmää. Laskin olettaa 3 kehitystyöpäivää jokaista muutettavaa järjestelmää kohden. Tulos on suuruusluokka-arvio, ja luvut ovat havainnollistavia. Ympäristönne todelliset luvut selviävät kuntokartoituksessa.
Viisi järjestelmää käsittelee saman tilauksen itsenäisesti
Etene vaihe kerrallaan ja seuraa, miten tapahtuma "order.created" kulkee tapahtumaväylän kautta. Jokainen järjestelmä reagoi omassa tahdissaan, eikä sillä ole suoraa yhteyttä muihin.
Integraatiomodernisaatio käytännössä
Esimerkki
Tapahtumalähtöinen integraatio
Integraatiomodernisaatio
Tilanne
Yrityksellä on käytössä useita järjestelmiä: ERP, CRM, varasto, verkkokauppa, taloushallinto ja logistiikka. Jokainen liitettiin suoraan ERP:hen sitä mukaa kuin se hankittiin. Nyt jokainen järjestelmämuutos on riski, koska jokin toinen järjestelmä voi lakata toimimasta. Integraatiokerros hidastaa kehitystä ja turhauttaa tiimejä, ja data vioittuu huomaamatta.
Ratkaisu
Suorat yhteydet korvataan tapahtumaväylällä. Jokainen järjestelmä julkaisee tapahtumia ja tilaa vain ne, joita tarvitsee. Muutos yhdessä järjestelmässä ei koske muita. Uusi integraatio valmistuu päivissä eikä kuukausissa.
Teknologia
• Julkaise ja tilaa -malli (pub/sub)
• Tapahtumaväylä pilvessä tai omassa ympäristössä
• Järjestelmäkohtaiset REST- ja webhook-adapterit
• Virhejonot (dead letter) ja automaattinen uudelleenyritys
• Keskitetty tapahtumaloki ja valvonta
Tulos
Järjestelmämuutos ei enää kaada muita järjestelmiä · Uusi integraatio valmistuu päivissä eikä kuukausissa · Kaikesta liikenteestä jää täydellinen tapahtumaloki · Tekoäly ja analytiikka saavat puhtaan datapohjan
Rakennamme demon teidän ympäristöönne
Kytkemme toimivaan tapahtumaväylään kolme järjestelmäänne tai realistisen simulaation. Näette, miten oikea liiketoimintatapahtuma kulkee päästä päähän. Jokainen vaihe kirjataan ja näkyy valvonnassa, ja tapahtuman voi toistaa. Kalvojen ja lupausten sijaan näette toimivan ratkaisun.
Demoskenaario
- 1Tilaus kirjataan verkkokaupassa tai ERP:ssä
- 2Tapahtumaväylä vastaanottaa tapahtuman "order.created" ja ohjaa sen tilaajille
- 3ERP saa tapahtuman ja tekee varastovarauksen automaattisesti
- 4Varastojärjestelmä saa tapahtuman ja luo keräilylistan
- 5Kaadamme yhden järjestelmän tarkoituksella ja näytämme, miten toimitus palautuu virhejonosta (dead letter) automaattisesti
Mitä demossa näkyy
- →Tapahtumat näkyvät valvontanäkymässä sekunneissa siitä, kun ne syntyvät
- →Jokaisesta tapahtumasta kirjataan aikaleima, lähde ja sisältö
- →Epäonnistunut toimitus ohjautuu virhejonoon ja käsitellään automaattisesti
- →Lisäämme kesken demon uuden tilaajan koskematta julkaisevan järjestelmän koodiin
- →Nykyisten suorien yhteyksien ja tapahtumaväylän vertailu
Tämä sopii teille, jos
Järjestelmämuutos rikkoi äskettäin jotain muuta · Uusien integraatioiden rakentaminen kestää kuukausia · Tekoälyhanke odottaa puhdasta dataa · Teillä on integraatiokoodia, jota kukaan ei enää täysin hallitse
Kolme vaihetta ilman pakollista sitoutumista
Kartoitamme tilanteen ennen kuin ehdotamme ratkaisua. Kuntokartoitus näyttää, mikä on teille kriittisintä ja missä järjestyksessä kannattaa edetä. Jokaisen vaiheen jälkeen päätätte itse, jatketaanko.
Vaihe 1
Integraatioiden kuntokartoitus
- Kartoitetaan kaikki nykyiset integraatiot ja riippuvuudet
- Arvioidaan jokaisen yhteyden hauraus ja liiketoimintariski
- Tunnistetaan kriittisimmät modernisointikohteet
- Selvitetään nykytilan piilokustannukset
- Tuloksena on priorisoitu etenemissuunnitelma
Vaihe on tuotteistettu palvelu, Aplikan kuntokartoitus.
Tutustu kuntokartoitukseen →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
- Näytetään demossa, miten yksi tapahtuma menee useille vastaanottajille
- Näytetään virheenkäsittely ja automaattinen uudelleenyritys
- PoC jää ympäristöönne ja on teidän omaisuuttanne
Vaihe 3
Täysi käyttöönotto
- Siirrytään vaiheittain, ei kaikkea kerralla
- Pub/sub-malli suunnitellaan järjestelmäkohtaisesti
- Valvonta, hälytykset ja virheenkäsittely
- Dokumentaatio ja arkkitehtuurikuvaukset
- Osaamisen siirto teidän tiimillenne