Integraatiosta on hiljalleen tullut merkittävin kustannuserä useimmissa yritysten IT-ympäristöissä, ja se näkyy harvoin omana rivinään. Se piiloutuu projektien viivästyksiin, jokaista julkaisua ympäröivään varovaisuuteen ja niihin kokouksiin, joita tarvitaan muutoksen koordinointiin kolmen tiimin kesken, joista kukin omistaa jonkin muutoksen koskettaman järjestelmän. Kun ihmiset sanovat, että alustan parissa on vaikea työskennellä, he eivät yleensä tarkoita, että koodi olisi huonoa. He tarkoittavat, että järjestelmä on kietoutunut kiinni itseensä: yhtä osaa ei voi tarkastella ymmärtämättä useita muita, eikä yhtä osaa voi toimittaa siirtämättä muita.

Syy siihen, miksi tällä on nyt enemmän merkitystä kuin vuosikymmen sitten, on se, että integraation pinta-ala on moninkertaistunut. Yksi liiketoimintakyvykkyys voi ulottua ydinjärjestelmän, useiden software as a service -sovellusten, tietoalustan, mobiilikanavan ja yhden tai useamman ulkoisen kumppanin yli, jotka on kytketty omilla rajapinnoillaan. Asiakkaat odottavat muutoksia viikoissa, eivät neljännesvuosissa. Sääntely edellyttää, että tietovirrat ovat jäljitettävissä ja auditoitavissa. Samaan aikaan taustajärjestelmät ovat yhä useammin sellaisia, joita organisaatio ei omista eikä voi muokata, mikä siirtää koko mukautumisen taakan integraatiokerrokselle.

Seurauksena on, että integraation laatu määrää nyt toimitusnopeuden ylärajan. Organisaatio, jolla on selkeät rajapinnat ja eksplisiittiset sopimukset, voi lisätä kanavan tai vaihtaa toimittajan rajattuna, hyvin ymmärrettynä työnä. Organisaatio, jolla näitä ei ole, käsittelee jokaista tällaista pyyntöä tutkimusprojektina, koska kukaan ei osaa ennustaa, mikä hajoaa. Ero ei ole osaamisessa tai budjetissa. Se on siinä, suunniteltiinko IT-ympäristö muuttumaan, ja tämä suunnittelu asuu lähes kokonaan siinä, miten järjestelmät saadaan keskustelemaan keskenään.

On vielä yksi syy, miksi aihe on käynyt kiireelliseksi. Kun yhä suurempi osa kyvykkyydestä kootaan ostetusta ohjelmistosta ja ulkoisista palveluista, organisaation itse kirjoittama koodi kutistuu, kun taas asioita yhdistävä koodi kasvaa. Insinöörityön painopiste on siirtynyt yhden sovelluksen sisäisten ominaisuuksien rakentamisesta käyttäytymisen kokoamiseen monen sovelluksen yli. Tämä muutos palkitsee tiimit, jotka kohtelevat integraatiota suunniteltuna pääomana, ja rankaisee niitä, jotka pitävät sitä jälkiajatuksena, joka pultataan kiinni jokaisen projektin lopuksi. Ne IT-ympäristöt, jotka vanhenevat hyvin, ovat niitä, joissa joku omisti yhteyksien muodon tarkoituksellisesti sen sijaan, että olisi antanut niiden kertyä yksi määräaika kerrallaan.

Kestävän integraation ensimmäinen periaate on, että sopimus on tärkeämpi kuin yhteys. Yhteys on mekanismi, jolla kaksi järjestelmää vaihtavat tietoa. Sopimus on yhteisymmärrys siitä, mitä tuo tieto tarkoittaa, minkä muodon se saa, mitkä takuut pätevät ja mitä kumpikin osapuoli voi olettaa toisesta. Tiimit, jotka keskittyvät yhteyksiin, rakentavat asioita, jotka toimivat sinä päivänä, kun ne testataan. Tiimit, jotka keskittyvät sopimuksiin, rakentavat asioita, jotka toimivat edelleen, kun kumpikin osapuoli kehittyy, koska sopimus on se vakaa pinta, jonka takana kumpikin osapuoli saa vapaasti muuttua.

Hyvä sopimus on eksplisiittinen ja kapea. Se ilmaisee kuljettamansa tiedon eikä mitään satunnaista siitä, miten tarjoaja sattuu tallentamaan sen sisäisesti. Tämä ero rajapinnan ja toteutuksen välillä on koko juju. Kun kuluttaja alkaa nojata sisäiseen yksityiskohtaan, joka on vuotanut läpi huonosti suunnitellusta rajapinnasta, on muodostunut kytkentä, jota kukaan ei sopinut ja jota kukaan ei seuraa. Tarjoaja ei voi enää refaktoroida vapaasti, koska muutos sen sisäisiin osiin rikkoo nyt hiljaisesti jonkin kuluttajan. Hyvin suunnitellut API-rajapinnat ovat olemassa juuri tämän estämiseksi: ne julkaisevat harkitun, minimaalisen pinnan ja piilottavat kaiken sen taakse.

Sopimukset kantavat myös semantiikkaa, eivät pelkkää rakennetta. Kaksi järjestelmää voivat olla yhtä mieltä kentästä nimeltä status ja silti olla yhteensopimattomia, koska ne ovat eri mieltä siitä, mitä sen arvot tarkoittavat tai milloin se asetetaan. Vakava sopimussuunnittelu kattaa siksi merkityksen, versioinnin, virhekäyttäytymisen sekä toimitusta ja järjestystä koskevat takuut. Se käsittelee yhteensopivuutta ensiluokkaisena asiana: muutos on joko taaksepäin yhteensopiva, jolloin olemassa olevat kuluttajat eivät häiriinny, tai ei ole, jolloin se edellyttää versiointistrategiaa ja migraatiopolkua. Tuon eron tekeminen näkyväksi ja sen hiljaisen rikkomisen kieltäytyminen on yksittäisistä tavoista arvokkain, joka integraatiokäytännöllä voi olla. Kaikki muu tässä artikkelissa on tavalla tai toisella tekniikkaa sopimusten pitämiseksi rehellisinä.

Vanhin integraatiotyyli on pisteestä pisteeseen: järjestelmä A kutsuu järjestelmää B suoraan tarvitessaan jotain. Muutaman järjestelmän kohdalla tämä on täysin järkevää. Ongelma on, että mahdollisten yhteyksien määrä kasvaa paljon nopeammin kuin järjestelmien määrä, ja jokainen suora linkki sitoo kaksi komponenttia yhteen ajassa ja tiedossa. A:n on tiedettävä missä B on, sen on oltava käytettävissä silloin kun B on, ja sen on osattava käsitellä B:n hitaus tai poissaolo. Kerro tämä kasvavan ympäristön yli, ja päädyt tuttuun spagettiin: tiheään räätälöityjen linkkien verkkoon, jossa kukaan ei voi muuttaa järjestelmää jäljittämättä jokaista siihen koskevaa säiettä.

Vastaus, joka on kypsynyt viime vuosikymmenen aikana, on välittää viestintää sen sijaan, että se johdotettaisiin kovakoodattuna, ja yhä useammin tehdä siitä tapahtumaohjattua. Sen sijaan, että A komentaisi B:tä suoraan, A julkaisee tosiasian: tilaus tehtiin, maksu selvitettiin, osoite muuttui, ja mikä tahansa järjestelmä, jota asia kiinnostaa, tilaa tuon tosiasian. Julkaisija ei tiedä eikä välitä, kuka tapahtuman kuluttaa. Kuluttajia voidaan lisätä tai poistaa koskematta tuottajaan. Tämä käänteisyys on löyhän kytkennän ydin: järjestelmät eivät enää riipu toisistaan, ne riippuvat jaetusta, eksplisiittisestä sopimuksesta niiden välillä kulkevista tapahtumista.

Viestipohjainen ja tapahtumaohjattu integraatio irrottaa järjestelmät toisistaan myös ajassa. Kestävälle välittäjälle asetettu viesti toimitetaan, kun kuluttaja on valmis, mikä tarkoittaa, että hidas tai tilapäisesti saavuttamaton alavirran järjestelmä ei enää pysäytä ylävirran järjestelmää. Tämä asynkronisuus ei ole pelkkä suorituskyvyn kikka. Se muuttaa vikaantumismallia: vastapaine, uudelleenyritykset ja puskurointi korvaavat kaskadoituvat käyttökatkot. Suuntaus koko toimialalla, joka näkyy streaming-alustojen ja hallittujen viestipalveluiden nousuna, on juuri tämä siirtymä synkronisista pyyntöketjuista kohti tapahtumien virtoja, joita järjestelmät tarkkailevat ja joihin ne reagoivat. Se ei ole yleisesti sopivaa: synkroniset kutsut ovat edelleen oikea valinta silloin, kun kutsuja aidosti tarvitsee välittömän vastauksen, mutta oletusasentona monen järjestelmän integroinnille se on osoittautunut paljon kestävämmäksi kuin suora johdotus.

Löyhä kytkentä mainitaan usein tavoitteena ja määritellään harvoin riittävän täsmällisesti, jotta sen mukaan voisi toimia. Käytännössä sillä on useita erillisiä ulottuvuuksia, ja hyvä arkkitehtuuri huomioi jokaisen. On kytkentää sijainnissa: tarvitseeko järjestelmän tietää, missä toinen sijaitsee, vai osoittaako se loogiseen kohteeseen, jota voidaan siirtää. On kytkentää ajassa: onko molempien järjestelmien oltava käytettävissä samanaikaisesti, vai voivatko ne edetä itsenäisesti. On kytkentää muodossa: ovatko ne sidottuja jaettuun esitystapaan, vai kääntääkö välityskerros niiden välillä. Ja on kytkentää tiedossa: kuinka paljon yhden järjestelmän on ymmärrettävä toisen sisäisistä osista voidakseen toimia sen kanssa. Jokainen integraatiopäätös kiristää tai löysää yhtä näistä, ja tavoitteena on pitää kukin niin löyhänä kuin vaatimus sallii.

Useita suunnitteluperiaatteita seuraa suoraan. Välitä sen sijaan, että yhdistäisit suoraan, jotta välittäjä, gateway tai integraatiokerros imee järjestelmien väliset erot ja antaa kullekin yhden vakaan asian, jonka kanssa keskustella. Omista rajapintasi eksplisiittisesti: korruptionestokerros, joka kääntää ulkoisen mallin omalle kielellesi, estää kumppanin tai toimittajan suunnittelua vuotamasta omaasi ja sanelemasta sitä. Pidä rajapinnat pieninä, koska jokainen paljastamasi kenttä on lupaus, joka sinun on pidettävä. Tee viestinnästä idempotenttia ja uudelleenyrityksiä sietävää, koska missä tahansa hajautetussa järjestelmässä viestit saapuvat toisinaan kahdesti tai väärässä järjestyksessä, ja suunnittelu, joka olettaa täydellisen toimituksen, on suunnittelu, joka turmelee tietoa kuormituksen alla. Suosi tosiasioiden liikuttamista, ei komentoja, jotta järjestelmä ilmoittaa, mitä on tapahtunut, ja antaa muiden päättää, mitä tehdä, sen sijaan, että se kurottaisi rajan yli orkestroidakseen työtä, joka ei ole sen omaa.

Kaiken tämän taustalla on yksi koe: voiko kutakin komponenttia muuttaa, ottaa käyttöön ja tarkastella itsenäisesti. Kun vastaus on kyllä, IT-ympäristö voi kehittyä yksi pala kerrallaan, mikä on ainoa kestävä tapa, jolla suuret järjestelmät muuttuvat. Kun vastaus on ei, sinulla ei ole arkkitehtuuria vaan pikemminkin yksi hajautettu ohjelma, joka vain näyttää useilta järjestelmiltä, kaikkine sen tuomine hauraudenaan ja ilman mitään itsenäisyyttä. Löyhää kytkentää varten suunnittelu on tarkoituksellista, jatkuvaa työtä, jolla tuo vastaus pidetään kyllänä IT-ympäristön kasvaessa.

Integraatiovirheet ovat huomattavan yhdenmukaisia organisaatioiden välillä, mikä on rohkaisevaa, koska se tarkoittaa, että ne voidaan ennakoida. Muutamat toistuvat riittävän usein, jotta ne kannattaa nimetä.

Hajautettu monoliitti. Järjestelmät on jaettu erillisiin, käyttöönotettaviin palveluihin, mutta ne ovat niin tiukasti kytkeytyneet toisiinsa jaettujen tietokantojen, synkronisten kutsuketjujen tai vuotaneiden sisäisten mallien kautta, että ne on julkaistava yhdessä ja ne vikaantuvat yhdessä. Tämä on molempien maailmojen huonoin puoli: monen järjestelmän operatiivinen monimutkaisuus yhden järjestelmän jäykkyydellä. Se johtuu lähes aina jakamisesta teknisiä linjoja pitkin sen sijaan, että jaettaisiin omistajuuden ja muutoksen aitojen rajojen mukaan.

Jaettu tietokanta. Kaksi järjestelmää integroituu lukemalla ja kirjoittamalla samoja tauluja. Se tuntuu tehokkaalta ja on katastrofaalista muutokselle, koska tietokannan skeemasta tulee implisiittinen sopimus, jota kukaan ei suunnitellut ja josta kaikki riippuvat. Kumpikaan järjestelmä ei voi kehittää tallennustaan vaarantamatta toista, ja kytkentä on näkymätön, kunnes se rikkoutuu.

Hiljainen rikkova muutos. Tarjoaja muuttaa kenttää, merkitystä tai virhekäyttäytymistä ilman versiointia, ja kuluttajat vikaantuvat tavoilla, jotka nousevat esiin kaukana syystä. Tämä on sopimusrikkomus, ja siksi yhteensopivuuden on oltava eksplisiittinen, valvottu kuri eikä hyväntahtoisuuden kysymys.

Puheliaat ja hauraat synkroniset ketjut. Yksi käyttäjän toiminto laukaisee pitkän jonon estäviä kutsuja monen järjestelmän yli. Päästä päähän -luotettavuus on jokaisen lenkin tulo, joten koko ketjusta tulee vähemmän luotettava kuin mikään sen osa, ja yksi hidas komponentti pysäyttää kaiken ylävirrassa.

Integraatiologiikka ilman kotia. Muunnos- ja reitityssäännöt kertyvät skripteihin, tallennettuihin proseduureihin ja ajastettuihin töihin, joita mikään tiimi ei omista ja joita mikään testi ei kata. IT-ympäristö toimii edelleen, mutta kukaan ei ymmärrä sitä, ja jokainen muutos on arkeologian teko.

Kadonnut viesti. Järjestelmä julkaisee tai kuluttaa välittämättä siitä, mitä tapahtuu, kun toimitus epäonnistuu: ei uudelleenyritystä, ei dead letter -polkua, ei idempotenssia, ei tapaa toistaa. Normaalikuormituksessa se näyttää virheettömältä. Kuormituksen tai osittaisen katkon alla se hiljaisesti pudottaa tai käsittelee tietoa kahteen kertaan, ja vahinko löydetään viikkoja myöhemmin täsmäytyksessä, joka ei täsmää. Tämä on se vikaantumistapa, joka useimmin nakertaa luottamusta integraatioon, koska sen oireet ovat hiljaisia ja sen syy on haudattu oletukseen täydellisestä toimituksesta, jota mikään hajautettu järjestelmä ei voi lunastaa. Kaikkien näiden yhteinen lanka on sama: syntyi kytkentä tai oletus, jota kukaan ei tehnyt eksplisiittiseksi ja jota siksi kukaan ei hallitse. Niiden nimeäminen on ensimmäinen askel niiden suunnittelemiseksi pois, ja kypsä käytäntö tarkastelee jokaista uutta integraatiota juuri tätä listaa vasten ennen sen toimittamista.

Nashua kohtelee integraatiota ensin arkkitehtuurikurina ja vasta toiseksi teknologiavalintana. Toimeksiannot alkavat tekemällä olemassa olevasta ympäristöstä luettava: kartoittamalla järjestelmät, niiden väliset virrat ja ennen kaikkea kytkennät, mukaan lukien ne dokumentoimattomat, jotka piileskelevät jaetuissa tietokannoissa ja huolehtimattomissa töissä. Tähän karttaan asuu todellinen riski, ja sen esiin tuominen muuttaa keskustelun työkalulistasta joukoksi tarkoituksellisia päätöksiä rajoista. Vasta kun rajat ovat selvät, mekanismin kysymykseen, API, tapahtumavirta, viestijono, voidaan vastata, koska oikea mekanismi riippuu täysin siitä, mitä kytkentää yrität löysätä.

Siitä eteenpäin työ noudattaa edellä esitettyjä periaatteita. Sopimukset suunnitellaan eksplisiittisesti ja versioidaan tarkoituksellisesti, jotta tarjoajat voivat kehittyä rikkomatta kuluttajia ja molemmat osapuolet tietävät tarkalleen, mihin ne voivat luottaa. Kun järjestelmien on reagoitava muutokseen sen sijaan, että ne komentaisivat toisiaan, Nashua suosii tapahtumaohjattuja ja viestipohjaisia malleja, jotka välitetään integraatiokerroksen kautta, korvaten pisteestä pisteeseen -linkit selkärangalla, jonka kanssa kukin järjestelmä keskustelee kerran. Kun välitöntä vastausta aidosti tarvitaan, käytetään hyvin suunniteltuja synkronisia rajapintoja, joilla on selkeä aikakatkaisu-, uudelleenyritys- ja vikakäyttäytyminen. Tavoitteena on läpi linjan ohjelmisto, jota on turvallista muuttaa: komponentit, jotka voidaan julkaista, korvata ja joita voidaan tarkastella itsenäisesti, suojattuna toisiltaan sopimuksilla ja korruptionestokerroksilla eikä toivolla.

Toimituskäytäntö vahvistaa arkkitehtuuria. Sopimustestit pitävät rajapinnan molemmat puolet rehellisinä ja nappaavat rikkovat muutokset ennen kuin ne ehtivät tuotantoon, mikä muuttaa yhteensopivuuden kurin kysymyksestä joksikin, jonka pipeline valvoo automaattisesti. Automatisoidut rakennus- ja julkaisupipelinet tekevät käyttöönotoista pieniä, tiheitä ja peruutettavia, mikä on mahdollista vain siksi, että rajat ovat riittävän selkeät yhden komponentin käyttöönottoon kerrallaan. Havainnoitavuus on rakennettu virtoihin sisään, korrelaatiolla tapahtumien ja viestien yli, jotta ongelma voidaan jäljittää lähteeseensä eikä päätellä oireista jälkikäteen. Integraatiologiikalle annetaan koti: omistettu, testattu, versioitu paikka eikä huolehtimattomien töiden hajanaisuus, jotta IT-ympäristö pysyy luettavana niille, jotka perivät sen.

Yhtä tärkeää on se, mistä Nashua kieltäytyy. Se ei tartu tapahtumavirtaan siellä, missä yksinkertainen kutsu on selkeämpi, eikä jaa järjestelmää palveluihin, joilla ei ole mitään syytä olla erillisiä, eikä lisää välittäjää ongelmaan, jolla ei ole löysäämisen arvoista kytkentää. Aiemmin kuvatut vikaantumistavat koskevat yhtä lailla ylimäärää kuin laiminlyöntiä, ja pidättyväisyys on osa käsityötä. Mikään tästä ei ole eksoottista, ja siinä on koko pointti. Kestävä integraatio syntyy pienen periaatejoukon johdonmukaisesta soveltamisesta ja sen tietämisestä, milloin kukin pätee, ja Nashuan panos on tuoda tämä johdonmukaisuus ja kokemus siitä, missä ympäristöt menevät pieleen, jotta se, mitä rakennetaan, on suunniteltu muuttumaan eikä pelkästään saatu toimimaan sinä päivänä, kun se toimitetaan.

Ero, jonka Nashua tuo, ei ole yksittäinen teknologia vaan ajattelutapa, joka kohtelee muutettavuutta ensisijaisena vaatimuksena ja pitää siitä kiinni toimituksen paineen alla. Monet toimittajat osaavat rakentaa yhteyden, joka toimii esittelyssä. Paljon harvempi suunnittelee IT-ympäristön, jota on yhä helppo muuttaa kolme vuotta ja kolmekymmentä integraatiota myöhemmin, kun alkuperäinen tiimi on siirtynyt muualle ja liiketoiminta on pyytänyt asioita, joita kukaan ei ennakoinut. Tuolla pitkällä horisontilla sopimusten, löyhän kytkennän ja välitetyn viestinnän kuri ansaitsee paikkansa, ja siellä syvä, kärsivällinen insinöörikokemus on arvokkaampaa kuin mikään tietty tuote.

On myös käytännöllinen seuraus, joka muuttaa sen, mitä työ saa olettaa. Kun toimeksianto vaatii kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen vauhdilla, agenttipohjaisen insinöörityön kautta: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alla, jotta nopeus ei koskaan tule johdonmukaisuuden, turvallisuuden tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee tai osta -rajaa, pitää optioiden hinnan alhaisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi sen mukaan, mitä sattui olemaan hyllyllä.

Sitä, mikä sitoo tämän yhteen, on harkinta: sen tietäminen, milloin tapahtuma sopii paremmin kuin kutsu, milloin rajaa tulisi puolustaa korruptionestokerroksella, milloin rikkova muutos on migraation arvoinen ja milloin ei, milloin kannattaa investoida versiointistrategiaan ja milloin yksinkertaisempi polku on kylliksi rehellinen. Näitä päätöksiä ei voi ostaa hyllystä, ja ne kertautuvat. Yksittäinen järkevä valinta on tuskin näkyvissä. Tuhat tällaista, tehtynä johdonmukaisesti IT-ympäristön elinkaaren aikana, ovat ero järjestelmän, joka käy hauraammaksi jokaisen julkaisun myötä, ja sellaisen välillä, joka pysyy notkeana. Hyvin ja johdonmukaisesti tehtyinä ne tuottavat IT-ympäristön, joka imee uudet kanavat, kumppanit ja säädökset tavanomaisena työnä eikä kriisinä. Se on tulos, johon Nashua tähtää: ei integraatioita, jotka pelkästään toimivat, vaan järjestelmiä, joita on turvallista muuttaa niin kauan kuin liiketoiminta niitä tarvitsee, mikä loppujen lopuksi on ainoa integraation mittari, jolla on merkitystä.