Integrasie en orkestrasie
Maak dat die stelsels wat jy reeds besit soos een stelsel optree. Sonder om hulle te vervang, en sonder nog ’n dekade van punt-tot-punt-skripte.
Wat ondernemingstelselintegrasie is
Ondernemingstelselintegrasie is die praktyk om afsonderlike besigheidstelsels (ERP, CRM, finansies, pakhuis, MH, kliëntgerigte toepassings) te koppel sodat data en gebeurtenisse outomaties tussen hulle beweeg, in ’n vasgestelde formaat, sonder dat ’n persoon enigiets kopieer. Moderne integrasie doen dit deur ’n gebeurtenisgedrewe argitektuur en ’n API-laag eerder as direkte databasistoegang of lêeroordragte, sodat elke stelsel intern kan verander sonder om die ander te ontwrig.
Die probleem met verouderde middleware
Die meeste organisasies bereik ons met een van twee argitekture, en albei misluk op dieselfde manier.
Die eerste is punt-tot-punt. Elke stelsel praat direk met elke ander stelsel wat dit nodig het, deur ’n skrip, ’n geskeduleerde uitvoer, ’n databasisskakel of ’n verskafferskoppelaar. Dit werk vir die eerste drie stelsels. By tien stelsels is daar tot vyf-en-veertig moontlike verbindings, niemand het ’n volledige inventaris van watter bestaan nie, en die persoon wat die helfte daarvan geskryf het, is weg. Enige verandering is ’n risiko omdat niemand met vertroue kan sê wat van die stelsel wat verander word, afhanklik is nie.
Die tweede is ’n sentrale ondernemingsdiensbus wat in die 2010's gekoop is. Die topologie is skoner, maar die bus word ’n bottelnek: roeteringslogika en besigheidsreëls hoop op binne eiendomskonfigurasie, die lisensie hernu teen ’n bedrag wat niemand kan regverdig nie, veranderings staan in ’n tou agter ’n enkele integrasiespan, en die verskaffer se padkaart bepaal jou pas. Wanneer die bus af is, is alles af.
Albei argitekture misluk omdat hulle stelsels aan mekaar koppel. Die oplossing is om stelsels eerder aan gebeurtenisse te koppel, ’n duursame rekord van wat gebeur het, wat enige stelsel kan verbruik sonder dat die uitgewer weet of omgee wie luister.
Punt-tot-punt en ESB teenoor gebeurtenisgedrewe integrasie
| Dimensie | Punt-tot-punt / verouderde ESB | Gebeurtenisgedrewe argitektuur |
|---|---|---|
| Koppeling | Stelsels weet van mekaar; ’n verandering rimpel na buite | Stelsels publiseer en teken in op gebeurtenisse; uitgewers ken nie verbruikers nie |
| Om ’n stelsel by te voeg | ’n Nuwe koppelaar per bestaande stelsel wat dit moet bereik | Een intekening op die gebeurtenisse wat dit nodig het |
| Falingsgedrag | ’n Stroomaf-onderbreking blokkeer of verloor die boodskap | Gebeurtenisse is duursaam en herspeelbaar; verbruikers haal in wanneer hulle terugkeer |
| Ouditeerbaarheid | Toestand word uit logs herbou, as hulle bestaan | Die gebeurtenislog is die ouditspoor, met ordening en behoud |
| Veranderingsbeheer | Veranderings staan in ’n tou agter een integrasiespan | Spanne is verantwoordelik vir hul eie verbruikers volgens ’n gepubliseerde kontrak |
| Kostevorm | Lisensiehernuwing plus bou per koppelaar | Infrastruktuur plus skemabestuur |
Gebeurtenisgedrewe argitektuur met Apache Kafka
Ons bou die integrasieruggraat op Apache Kafka. Stelsels publiseer domeingebeurtenisse (’n bestelling is geplaas, ’n betaling is vereffen, ’n kliëntrekord het verander) na duursame, geordende onderwerpe. Enigiets wat moet reageer, teken in. Die uitgewer weet nie wat sy gebeurtenisse verbruik nie, en juis daarom kan jy later ’n datapakhuis, ’n verslagdoeningsinstrument of ’n nuwe kliëntgerigte toepassing byvoeg sonder om aan die rekordstelsel te raak.
Drie eienskappe maak dit die migrasie werd. Gebeurtenisse is duursaam, sodat ’n verbruiker wat vir twee uur vanlyn is, die agterstand verwerk eerder as om dit te verloor. Gebeurtenisse is herspeelbaar, sodat ’n nuwe stelsel teen die afgelope twaalf maande se geskiedenis gebou kan word in plaas daarvan om te wag vir vars data om op te hoop. En gebeurtenisse is per sleutel georden, sodat ’n reeks veranderings aan dieselfde rekord aankom in die volgorde waarin dit gebeur het, die mislukkingsmodus wat stilweg data in bondellêerintegrasies korrupteer.
Die werk is meestal ontwerp, nie loodgietery nie. Ons definieer die domeingebeurtenisse, die skema vir elkeen, die verenigbaarheidsreëls om hulle te verander, en die eienaarskap van elke onderwerp. Om dit reg te kry is wat keer dat die gebeurtenislog die volgende onhandelbare gemors word.
Die KI-aangedrewe integrasielaag
Sodra gebeurtenisse deur ’n enkele ruggraat vloei, word twee vermoëns prakties wat nie die moeite werd is om oor punt-tot-punt-skakels te bou nie.
Voorspellende dataroetering. Die integrasielaag leer die normale vorm van verkeer (watter gebeurtenisse wanneer aankom, in watter volume, in watter volgorde) en roeteer of prioritiseer dienooreenkomstig. Versoeningsgebeurtenisse wat altyd maandeindsluiting voorafgaan, kan kopruimte gegee word voordat finansies daarvoor vra, en ’n ongewone piek kan na ’n stadiger pad afgelaai word eerder as om ’n stroomaf-stelsel daarmee saam te neem.
Outomatiese nakomingsmonitering. Elke gebeurtenis wat die ruggraat kruis, is inspekteerbaar. Reëls loop deurlopend: persoonlike inligting wat ’n vasgestelde grens verlaat, ’n rekord wat buite ’n goedgekeurde proses verander, ’n transaksiepatroon wat by ’n bedrog-handtekening pas, ’n databehoud-venster wat verstryk. Onder POPIA is die vermoë om te demonstreer wat met persoonlike inligting gebeur het, nie net om dit te beweer nie, ’n beheer wat die moeite werd is, en ’n gebeurtenislog maak dit ’n navraag eerder as ’n projek.
Data en analise. Dieselfde ruggraat is wat sake-intelligensie hanteerbaar maak. Eerder as dat elke verslag op sy eie skedule in ’n produksiedatabasis ingryp, verbruik analise die gebeurtenisstroom, wat een definisie beteken van wat "’n bestelling" is en geen verslagdoeningslas op operasionele stelsels nie.
iPaaS-orkestrasie met MuleSoft en Workato
Gebeurtenisse beweeg data. Orkestrasie besluit wat ’n besigheidsproses daarmee doen, in watter volgorde, met watter goedkeurings, en wat gebeur wanneer ’n stap misluk. Vir daardie laag werk ons met integrasie-platform-as-’n-diens-instrumente (MuleSoft en Workato die meeste) eerder as om elke werkvloei as pasgemaakte kode te skryf.
Die rede is eienaarskap. ’n Proses wat in ’n iPaaS-resep leef, kan gelees, geoudit en dikwels verander word deur ’n ontleder wat die besigheidsreël verstaan, eerder as om agter ’n ingenieurs-sprint in ’n tou te staan. Goedkeurings, herprobeer, foutrye, mens-in-die-lus-stappe en koppelaar-onderhoud kom saam met die platform.
Ons is doelbewus nie ’n enkel-verskaffer-winkel nie. Watter platform pas, hang af van die stelsellandskap: MuleSoft waar API-bestuur en beheer oor ’n groot stelsellandskap die primêre bekommernis is, Workato waar besigheidsgebruiker-outomatisering en die omvang van SaaS-koppelaars meer saak maak, en pasgemaakte dienste waar ’n werklas hoëvolume, latensie-sensitief of te spesifiek is om lisensiekoste te regverdig. Deel van die assessering is om jou te vertel in watter van die drie ’n gegewe proses hoort, insluitend die gevalle waar die eerlike antwoord is dat jy glad nie ’n platform nodig het nie.
API-gelei integrasie
Tussen die gebeurtenisruggraat en die orkestrasielaag sit ’n API-laag, ontwerp in drie vlakke: stelsel-API’s wat elke onderliggende platform in ’n stabiele vorm blootstel, proses-API’s wat hulle in besigheidsvermoëns saamstel, en ervaring-API’s gevorm vir ’n spesifieke verbruiker soos ’n mobiele toepassing of ’n vennootportaal. Dit is die API-gelei patroon, en die waarde daarvan is dat ’n verandering aan ’n onderliggende stelsel beteken dat slegs een stelsel-API herskryf hoef te word, eerder as elke verbruiker wat daaraan geraak het.
Hoe ons lewer
Integrasiewerk misluk meer dikwels op volgorde as op tegnologie. Die volgorde hieronder is doelbewus: verstaan die stelsellandskap voordat gebeurtenisse ontwerp word, bewys een proses in produksie voordat die res gemigreer word, en dra eienaarskap oor voordat die verbintenis eindig eerder as daarna.
Hoe ’n integrasieverbintenis verloop
-
1
Argitektuurassessering (2–3 weke)
Ons inventariseer die stelsels, die integrasies wat reeds bestaan (insluitend die ongedokumenteerde), die data wat beweeg, en die handwerk wat die gapings vul. Uitset: ’n huidige-toestand-diagram, ’n teikenargitektuur, en die integrasiepunte gerangskik volgens die koste wat hulle vandag dra.
-
2
Gebeurtenis- en kontrakontwerp
Ons definieer die domeingebeurtenisse, hul skemas, verenigbaarheidsreëls en onderwerpeienaarskap voordat enige kode geskryf word. Dit is die stap wat die meeste oorgeslaan word, en om dit oor te slaan is waarom gebeurtenisruggraatstelsels net so ononderhoubaar word soos die punt-tot-punt-gemors wat hulle vervang het.
-
3
Eerste snit na produksie
Een werklike besigheidsproses word van begin tot einde in produksie gebruik, met monitering en terugrol. ’n Beperkte produksiesegment vertel jou meer oor jou stelsellandskap as ’n ses maande lange ontwerpfase, en gee die besigheid iets om te beoordeel voordat verdere werk aangegaan word.
-
4
Strangler-migrasie
Bestaande integrasies skuif een op ’n slag na die ruggraat, elk met die ou pad steeds beskikbaar totdat die nuwe een ’n volle besigheidsiklus sonder probleme deurloop het. Niks word op ’n bepaalde datum afgeskakel nie; dinge word afgeskakel wanneer hul vervanging homself bewys het.
-
5
Orkestrasie en selfdiens
Besigheidsprosesse skuif na die iPaaS-laag, met die mense wat vir elke proses verantwoordelik is, opgelei om hul eie werkvloeie te verander. Die maatstaf van sukses is dat jou span ons nie meer vir roetineveranderings nodig het nie.
-
6
Oorhandiging en bedryf
Bedryfsprosedures, skemaregister, moniteringspaneelborde en diensdoenprosedure word aan jou span oorgedra, of ons bedryf die ruggraat onder ’n ooreengekome diensvlak. Albei is beskikbaar; nie een word veronderstel nie.
Integrasievrae
Wanneer moet ons ’n ondernemingsdiensbus met gebeurtenisgedrewe argitektuur vervang?
Wanneer verandering in ’n tou staan. Die tegniese seine is ’n lisensiehernuwing wat jy nie kan regverdig nie, roetering en besigheidslogika wat net in verskafferkonfigurasie leef, en ’n integrasiespan wat ’n bottelnek vir elke ander span geword het. Die kommersiële sein is eenvoudiger: as dit maande eerder as weke neem om ’n stelsel by te voeg, kos die bus meer as wat dit spaar. Migrasie is inkrementeel: die bus loop aan terwyl prosesse een op ’n slag daarvan afskuif.
Gebruik julle MuleSoft, Workato, of bou julle pasgemaakte integrasies?
Al drie, gekies per werklas. MuleSoft waar API-bestuur en beheer oor ’n groot stelsellandskap die prioriteit is. Workato waar besigheidsgebruiker-outomatisering en die omvang van SaaS-koppelaars meer saak maak. Pasgemaakte dienste waar volume, latensie of spesifisiteit lisensiekoste onverdedigbaar maak. Om te besluit watter een is deel van die assessering, en ons sal jou vertel wanneer die antwoord is dat geen platform nodig is nie.
Hoe lank voordat die eerste integrasie in produksie aktief is?
Die argitektuurassessering neem twee tot drie weke. ’n Eerste produksiesnit, een werklike besigheidsproses, gemonitor, met terugrol, volg tipies binne vier tot agt weke ná die assessering, afhangende van hoeveel toegang tot bronstelsels beskikbaar is en hoe skoon hul data is. Volledige migrasie weg van ’n bestaande bus word in kwartale gemeet, en loop saam met die ou pad eerder as om dit op ’n datum te vervang.
Hoe hanteer julle POPIA en dataverblyf in ’n integrasie?
Persoonlike inligting word tydens gebeurtenisontwerp geklassifiseer, nie daarna nie. Gebeurtenisse wat persoonlike data dra, word gemerk, hul verbruikers word opgesom, behoudvensters word per onderwerp gestel, en reëls loop deurlopend om persoonlike inligting te merk wat ’n grens kruis wat dit nie behoort te doen nie. Waar verblyf vereis word, word die ruggraat en sy berging in die streek ontplooi. Die gebeurtenislog dien ook as die bewys wat ’n reguleerder of ouditeur vra.
Wat gebeur met die integrasies wat ons reeds het?
Hulle bly loop. Migrasie volg die strangler-patroon: elke bestaande integrasie skuif afsonderlik na die ruggraat, met die ou pad aktief totdat die nuwe een ’n volle besigheidsiklus sonder afwyking voltooi het. Ongedokumenteerde integrasies word tydens die assessering geïnventariseer, wat dikwels die eerste volledige lys is wat ’n organisasie gehad het.
Kan ons eie ontwikkelaars aan die integrasielaag werk?
Ja, en dit is die beoogde eindtoestand. Onderwerpeienaarskap, skemabestuur en verbruikerontwikkeling is ontwerp om aan die spanne wat vir elke domein verantwoordelik is, oorhandig te word. Ons loop die eerste segmente, werk saam aan die volgende, en dra bedryfsprosedures, die skemaregister en monitering oor. Om ons daarna vir bedrywighede te behou, is ’n opsie, nie ’n afhanklikheid nie.
Bespreek ’n integrasie-assessering
Twee tot drie weke, wat eindig met ’n huidige-toestand-diagram, ’n teikenargitektuur en ’n gerangskikte lys van die integrasiepunte wat jou die meeste kos.
Begin die assessering