Integration & Orchestration
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 breek.
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 konneksies, 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 afhang van die ding wat verander word 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 besit hul eie verbruikers teen ’n gepubliseerde kontrak |
| Kostevorm | Lisensiehernuwing plus bou per koppelaar | Infrastruktuur plus skema-beheer |
Gebeurtenisgedrewe argitektuur met Apache Kafka
Ons bou die integrasieruggraat op Apache Kafka. Stelsels publiseer domeingebeurtenisse (’n bestelling is geplaas, ’n betaling het deurgekom, ’n kliëntrekord het verander) na duursame, geordende onderwerpe. Enigiets wat moet reageer, teken in. Die uitgewer weet nie wat sy gebeurtenisse verbruik nie, wat presies is wat jou toelaat om later ’n datapakhuis, ’n verslagdoeningsinstrument of ’n nuwe kliëntgerigte toepassing by te voeg 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 falingsmodus wat stilweg data in bondellêer-integrasies 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 landgoed: MuleSoft waar API-bestuur en beheer oor ’n groot landgoed 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 vennoteportaal. Dit is die API-gelei patroon, en die waarde daarvan is dat om ’n onderliggende stelsel te verander beteken om een stelsel-API te herskryf 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 landgoed 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 onderwerp-eienaarskap voordat enige kode geskryf word. Dit is die stap wat die meeste oorgeslaan word, en om dit oor te slaan is waarom gebeurtenis-ruggrate net so onhandelbaar word soos die punt-tot-punt-gemors wat hulle vervang het.
-
3
Eerste snit na produksie
Een werklike besigheidsproses gaan van begin tot einde lewendig, met monitering en terugrol. ’n Smal snit in produksie vertel jou meer oor jou landgoed as ’n ses maande lange ontwerpfase, en dit gee die besigheid iets om te oordeel voordat verder verbind 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 skoon deur ’n volle besigheidsiklus geloop het. Niks word op ’n datum afgeskakel nie; dinge word afgeskakel wanneer hul vervanging homself bewys het.
-
5
Orkestrasie en selfdiens
Besigheidsprosesse skuif in die iPaaS-laag in, met die mense wat elke proses besit opgelei om hul eie werkvloei te verander. Die maatstaf van sukses is dat jou span ons nie meer vir roetineveranderings nodig het nie.
-
6
Oorhandiging en bedryf
Bedryfsboeke, skemaregister, moniteringspaneelborde en oproepbeskikbaarheidsprosedure word na jou span oorgedra, of ons bedryf die ruggraat onder ’n ooreengekome diensvlak. Albei is beskikbaar; nie een word aangeneem 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 landgoed 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 lewendig 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 individueel na die ruggraat, met die ou pad lewendig 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. Onderwerp-eienaarskap, skema-beheer en verbruiker-ontwikkeling is ontwerp om oorhandig te word aan die spanne wat elke domein besit. Ons loop die eerste snitte, paar deur die volgende, en dra bedryfsboeke, 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