Suurimman osan yritys-IT:n historiasta integraatio oli satunnainen tapahtuma. Järjestelmät olivat suuria, pitkäikäisiä ja harvalukuisia. Kahden järjestelmän yhdistäminen oli projekti, jolla oli alku ja loppu, ja organisaation raja oli myös suurin piirtein sen järjestelmien raja. Tuo maailma on mennyttä. Keskikokoinen suuri organisaatio ajaa nykyään satoja sovelluksia, joista suurin osa toimitetaan palveluna ja on toimittajan eikä IT-osaston omistuksessa. Uusi kyvykkyys saapuu tilauksena, ei rakentamalla, ja jokainen tilaus odottaa vaihtavansa tietoa kaiken ympärillään olevan kanssa.

Tämä muuttaa arkkitehtuurin painopistettä. Kun kyvykkyys rakennettiin itse, vaikeimmat päätökset koskivat sitä, mitä rakentaa. Kun kyvykkyys ostetaan, vaikeimmat päätökset koskevat sitä, miten ostetut asiat kytkeytyvät toisiinsa ja kuinka paljon ne tietävät toisistaan. Koostettava strategia, olipa se muotoiltu best-of-breed-, MACH- tai yksinkertaisesti pragmaattisen hankinnan lähtökohdaksi, on vain yhtä hyvä kuin osat yhteen sitova integraatio. Organisaatio voi koota erinomaisen joukon sovelluksia ja silti tuottaa epäyhtenäisen kokemuksen, jos tilaukset, asiakkaat ja varasto tarkoittavat kussakin rajapinnassa hienovaraisesti eri asioita.

Tällä on nyt merkitystä erityisestä syystä: muutosvauhti on ohittanut sietokyvyn tiukalle kytkennälle. Kun järjestelmiä uusittiin kerran vuosikymmenessä, hauras integraatio, joka piti kirjoittaa uudelleen jokaisen uusinnan yhteydessä, oli selviteltävissä. Kun järjestelmiä lisätään, vaihdetaan ja poistetaan jatkuvasti, jokaisesta tiukasti kytketystä yhteydestä tulee toistuva vero. Huonon integraation kustannus maksettiin ennen satunnaisesti ja unohdettiin. Nyt se maksetaan joka vuosineljännes: viivästyneinä projekteina, muutospyyntöinä, jotka aaltoilevat pidemmälle kuin kukaan ennusti, ja hitaana oivalluksena siitä, että kukaan ei uskalla turvallisesti koskea ydinjärjestelmään, koska liian moni muu asia on riippuvainen sen datan täsmällisestä muodosta. Tästä syystä integraatioarkkitehtuuri on siirtynyt toimituksen yksityiskohdasta hallituksen tason rajoitteeksi sille, kuinka nopeasti liiketoiminta voi muuttua.

Integraatioarkkitehtuurin ensimmäinen periaate on, että yhteys on suhde, ja kestävä suhde tarvitsee sopimuksen. Kahden järjestelmän välinen rajapinta ei ole kummankaan toteutuksen yksityiskohta. Se on jaettu sopimus siitä, mitä vaihdetaan, missä muodossa, millä merkityksellä ja millä takeilla. Kun tuo sopimus on nimenomainen, molemmat osapuolet voivat muuttaa sisäistä toteutustaan vapaasti niin kauan kuin ne noudattavat sitä. Kun se on implisiittinen ja selvitetään tarkastelemalla mitä tahansa dataa, jota sattuu saapumaan, jokaisesta sisäisestä muutoksesta tulee mahdollinen rikkoutuminen jossain muualla. API ymmärretään parhaiten ei koodinpätkänä vaan julkaistuna lupauksena.

Toinen periaate on löyhä kytkentä, johon vedotaan usein ja jota ymmärretään harvemmin. Kytkentä on se aste, jolla yhden komponentin on tunnettava toinen ja muututtava sen mukana. Sillä on useita ulottuvuuksia: kytkentä tietomuodossa, ajoituksessa, sijainnissa, teknologiassa ja siinä sisäisessä mallissa, jonka järjestelmä paljastaa. Hyvin suunniteltu rajapinta minimoi ne kaikki. Kuluttajan ei tarvitse tietää, missä tarjoaja toimii, mitä teknologiaa se käyttää, onko se saatavilla juuri tällä hetkellä tai miten se jäsentää tietokantansa. Sen tarvitsee tuntea vain sopimus. Löyhä kytkentä ei ole riippuvuuden puuttumista. Se on riippuvuutta, jota välitetään vakaan, tarkoituksellisesti kapean rajapinnan kautta eikä raakojen sisäistoteutusten kautta.

Kolmas periaate on, että rajapinnan tulee ilmaista toimialaa, ei toteutusta. Rajapinta, joka vuotaa tarjoajan taulukkorakenteen, sen sisäiset koodit tai tekniset erikoisuudet, pakottaa jokaisen kuluttajan ymmärtämään tarjoajan yksityisen maailman. Liiketoiminnan kielellä, tilausten, toimitusten, asiakkaiden ja laskujen kielellä, ilmaistu rajapinta piilottaa tuon yksityisen maailman ja pysyy vakaana, vaikka sen takana oleva toteutus rakennettaisiin uudelleen. Tämä on integraatiokerroksen syvempi merkitys: se ei ole pelkästään paikka, jonka kautta yhteydet fyysisesti kulkevat, vaan paikka, jossa kokonaisuuden merkitys tehdään nimenomaiseksi ja johdonmukaiseksi, niin että heterogeeninen järjestelmäjoukko voi esittää yhden yhtenäisen rajapintajoukon kaikelle, mikä tarvitsee toimia niiden yli.

Viime vuosien hallitseva muutos on siirtymä pyyntö-vastaus-mallista oletuksena kohti tapahtumia ensiluokkaisena kansalaisena. Synkronisessa mallissa järjestelmä pyytää toiselta jotakin ja odottaa. Tämä on luontevaa kyselyille, mutta se kytkee nämä kaksi ajallisesti: kutsuja ei voi edetä, ellei kutsuttava ole saatavilla ja nopea. Tapahtumapohjainen integraatio kääntää tämän. Järjestelmä julkaisee tosiasian jostakin tapahtuneesta, tilaus tehtiin, maksu läpäisi, osoite muuttui, ja muut järjestelmät reagoivat tuohon tosiasiaan omassa aikataulussaan. Julkaisija ei tiedä eikä välitä siitä, kuka kuuntelee. Juuri tämä ajallinen irrotus mahdollistaa sen, että kokonaisuus vaimentaa kuormaa, sietää osittaisia katkoksia ja lisää uusia kuluttajia koskematta tuottajaan.

Viesti- ja stream-pohjaiset alustat ovat kypsyneet tehdäkseen tästä käytännöllistä mittakaavassa. Kestävät lokit ja viestinvälittäjät tarjoavat selkärangan, ja käytäntö kohdella tapahtumavirtaa jaettuna totuuden lähteenä on levinnyt marginaalista valtavirtaan. Tämän rinnalla API-first on muuttunut toiminnalliseksi oletukseksi eikä pyrkimykseksi: sopimus suunnitellaan ja sovitaan ennen toteutusta, ja yhä useammin sopimus kuvataan koneluettavassa määrittelyssä, joka generoi dokumentaation, asiakaskoodin ja validoinnin. Sen, mitä OpenAPI teki synkronisille rajapinnoille, tekevät vastaavat määrittelyt nyt asynkronisille, tapahtumapohjaisille rajapinnoille.

Kaksi muuta liikettä ansaitsee maininnan. Ensimmäinen on API:en kohteleminen tuotteina eikä projektien sivutuotteina. API-tuotteella on omistaja, elinkaari, asiakkaina kohdeltava kuluttajajoukko ja tarkoituksellinen versiointikäytäntö, olipa se altistettu sisäisesti, kumppaneille tai julkisesti. Toinen on hallittujen integraatioalustojen ja gatewayiden nousu, jotka keskittävät läpileikkaavat huolet, tietoturvan, kuormanrajoituksen, havainnoitavuuden ja muunnokset, niin että nämä ratkaistaan kerran eikä toteuteta uudelleen jokaisessa yhteydessä. Suuntaus ei ole kohti yksittäistä teknologiaa vaan kohti kerroksellista kyvykkyyksien joukkoa: gatewayt synkroniselle liikenteelle, välittäjät ja streamit asynkronisille virroille sekä integraatioalustat, joilla tiimit voivat koostaa virtoja rakentamatta jokaista adapteria käsin.

Hyvä integraatioarkkitehtuuri erottuu vähemmän siitä, mitä teknologioita se käyttää, kuin siitä, mitä ominaisuuksia se takaa. Ensimmäinen on nimenomaiset, versioidut sopimukset taaksepäin yhteensopivuuden kurilla. Kuluttajien on voitava luottaa rajapintaan pelkäämättä, että hiljainen muutos rikkoo ne, ja tarjoajien on voitava kehittyä koordinoimatta synkronoitua julkaisua jokaisen kuluttajan kanssa yhdellä kertaa. Tämä tarkoittaa oletuksena lisäävää muutosta, selkeää versiointia silloin, kun rikkoutuminen on väistämätöntä, sekä määriteltyä ajanjaksoa, jonka aikana vanha ja uusi elävät rinnakkain. Rajapinta ilman versiointistrategiaa on aikataulua odottava rikkoutuminen.

Toinen ominaisuus on idempotenssi ja epätäydellisen toimituksen sietokyky. Verkot pettävät, viestejä yritetään uudelleen ja kaksoiskappaleita saapuu. Integraatio, joka olettaa täsmälleen kerran tapahtuvan, järjestyksessä pysyvän ja aina onnistuvan toimituksen, on integraatio, joka turmelee dataa heti kun todellisuus on eri mieltä. Operaatioiden suunnitteleminen niin, että saman tapahtuman vastaanottaminen kahdesti on vaaratonta ja että tapahtumia voidaan käsitellä uudelleen, ei ole reunatapaus. Se on perustaso kaikelle asynkroniselle.

Kolmas on tarkoituksellinen valinta orkestroinnin ja koreografian välillä. Orkestrointi asettaa keskitetyn koordinaattorin vastaamaan prosessista, mikä on selkeää ja helppo hahmottaa mutta keskittää kytkennän yhteen paikkaan. Koreografia antaa komponenttien reagoida tapahtumiin ilman keskitettyä johtajaa, mikä on erittäin irrotettua mutta vaikeampaa havainnoida ja hahmottaa kokonaisuutena. Kumpikaan ei ole oikea abstraktilla tasolla. Taito on tietää, kumpaa käyttää missäkin: orkestrointi prosesseille, jotka tarvitsevat selkeän omistajan ja auditoitavan tilan, koreografia tosiasioiden leviämiseen monille itsenäisille kuluttajille.

Neljäs on pidättyväisyys jaetun merkityksen suhteen. Yhteinen sanasto koko kokonaisuudessa on arvokasta, mutta pyrkimys määritellä yksi universaali malli jokaiselle entiteetille ja pakottaa se kaikkialle taipuu yleensä oman painonsa alla. Kypsä lähestymistapa lainaa domain-driven designista: tunnista rajatut kontekstit, joissa sama sana tarkoittaa oikeutetusti eri asioita, käännä rajapinnoilla ja pidä kanoniset määritelmät siellä, missä ne aidosti vähentävät kitkaa, eikä kaikkialla periaatteen vuoksi. Integraatiokerroksen tehtävä on välittää merkitystä, ei pakottaa jokaista järjestelmää yhteen sanakirjaan, joka ei sovi hyvin yhdellekään niistä.

Point-to-point-spagetti on klassinen ja kallein epäonnistuminen. Jokainen uusi integraatio rakennetaan suoraan kahden järjestelmän välille, koska se on nopein reitti edessä olevalle projektille. Riittävän monen projektin jälkeen kokonaisuus on tiheä verkosto, jossa jokainen järjestelmä tietää monista muista, kukaan ei näe kokonaisuutta ja mikä tahansa muutos aaltoilee ennalta-arvaamattomasti. Mahdollisten yhteyksien määrä kasvaa järjestelmien määrän neliössä, ja niin kasvaa ylläpitotaakkakin. Tragedia on siinä, että jokainen yksittäinen point-to-point-yhteys oli järkevä paikallinen päätös. Spagetti on emergentti ominaisuus siitä, ettei kerrosta koskaan suunniteltu.

Hajautettu monoliitti on epäonnistuminen, joka naamioituu moderniksi arkkitehtuuriksi. Järjestelmät ovat erotettuja, mutta ne on kytketty niin tiukasti synkronisten kutsujen ja jaettujen oletusten kautta, ettei mitään voida julkaista itsenäisesti. Muutos yhteen edellyttää koordinoituja muutoksia ja julkaisuja usean yli. Tämä on pahempaa kuin monoliitti, koska siinä on kaikki monoliitin kytkennät sekä hajautetun järjestelmän operatiivinen monimutkaisuus. Se on yleensä seurausta järjestelmien fyysisestä jakamisesta irrottamatta niitä loogisesti.

Kanoninen malli, joka söi yrityksen on ylikeskittämisen epäonnistuminen. Hyvää tarkoittava pyrkimys määritellä yksi jaettu tietomalli muuttuu pullonkaulaksi: jokainen integraatio on kartoitettava rönsyilevään universaaliin skeemaan, jokainen muutos siihen skeemaan vaikuttaa kaikkiin, ja malli kasvaa barokkiseksi yrittäessään mukautua jokaiseen erikoistapaukseen. Spagetin lääkkeestä tulee oma tautinsa. Lörppö synkroninen ketju on läheinen ansa, jossa yksi käyttäjän toiminto haarautuu pitkäksi jonoksi estäviä kutsuja monen järjestelmän yli, niin että hitain tai epäluotettavin lenkki määrää koko kokonaisuuden käyttäytymisen, ja yksittäinen aikakatkaisu jossain syvällä ketjussa ilmenee selittämättömänä virheenä huipulla. Sopimusten ajautuminen täydentää joukon: rajapinnat ovat olemassa mutta ovat dokumentoimattomia ja hallitsemattomia, versiot lisääntyvät epävirallisesti, eikä kukaan osaa varmuudella sanoa, kuka kuluttaa mitäkin, joten mitään ei voida turvallisesti poistaa.

Nashua kohtelee integraatiota suunniteltavana arkkitehtuurina, ei toimitettavien liittimien työjonona. Lähtökohtana on aina rehellinen kartta nykyisestä kokonaisuudesta: mitä järjestelmiä on olemassa, miten ne tosiasiassa vaihtavat tietoa tänään, mihin point-to-point-yhteydet ovat kertyneet ja mitkä niistä kuljettavat liiketoimintakriittisiä virtoja. Tämä kartta on usein ensimmäinen kerta, kun organisaatio näkee yhteyksiensä todellisen muodon, ja juuri siinä todelliset riskit ja todelliset mahdollisuudet tulevat näkyviin. Vastustamme kiusausta hypätä kohdeteknologiaan ennen kuin ongelma on ymmärretty.

Tuosta kartasta lähtien työskentelemme organisaation kanssa määritelläksemme integraation viitearkkitehtuurin: kerrokset ja niiden vastuut, rajapinnat, joilla merkitys käännetään, valinnan synkronisen ja tapahtumapohjaisen välillä kullekin virtaluokalle sekä standardit sopimuksille, versioinnille ja virheenkäsittelylle. Tämä on tietoisesti teknologiatietoista mutta ei teknologiavetoista. Viitearkkitehtuuri kertoo, mitä ominaisuuksia jokaisella integraatiolla on oltava, ennen kuin se määrää, mikä gateway, välittäjä tai alusta ne tarjoaa, niin että työkalut palvelevat suunnittelua eivätkä sanele sitä.

Toimitus on inkrementaalista ja näyttöön perustuvaa. Vuosien mittaan point-to-point-tyyliin kasvaneen kokonaisuuden selvittämistä ei tehdä yhdessä ohjelmassa, ja sen yrittäminen on itsessään epäonnistumisen muoto. Tunnistamme virrat, joissa irrottaminen ostaa eniten vapautta, tuomme integraatiokerroksen ensin niiden ympärille ja annamme mallin todistaa itsensä ennen sen laajentamista. Jokainen uusi rajapinta suunnitellaan sopimuksena, jolla on omistaja, dokumentoidaan koneluettavassa määrittelyssä ja rekisteröidään, niin että sen kuluttajat tunnetaan. Ajan myötä kokonaisuuteen kertyy API-luettelo, joka on aito voimavara: selattava, hallittu inventaario siitä, mihin organisaatio voi kytkeytyä ja miten. Yhdistämme tämän operatiiviseen puoleen, havainnoitavuuteen, rajapinnan tietoturvaan ja elinkaaren hallintaan, koska integraatio, jota ei voida valvoa ja versioida tuotannossa, on riski riippumatta siitä, kuinka tyylikkäältä sen suunnitelma näytti paperilla.

Nashuan tuoma ero on arkkitehtonisen kurin ja tuotantoon asti ulottuvan toimituksen yhdistelmä. Monilla organisaatioilla on kaavio siitä integraatiokerroksesta, jonka he toivoisivat omistavansa, ja todellisuus, joka ei muistuta sitä lainkaan. Näiden kahden välistä kuilua ei kurota umpeen vahvemmalla kaaviolla. Se kurotaan umpeen työskentelemällä niiden tiimien rinnalla, jotka rakentavat ja operoivat yhteyksiä, tekemällä oikeasta mallista helpon mallin ja hallitsemalla sopimuksia ja versioita riittävällä tarkkuudella ollakseen turvallinen ja riittävällä pragmatismilla pysyäkseen liikkeessä. Pidämme mielessä viitearkkitehtuurin pitkän näkymän ja tänä vuosineljänneksenä toimitettavan virran lyhyen näkymän, emmekä anna kummankaan hiljaa sabotoida toista.

Tähän liittyy myös käytännöllinen seuraus, joka muuttaa sen, mitä työ saa olettaa. Kun toimeksianto edellyttää 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 suunnittelun avulla: se, mitä tarvitaan, kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden sisällä ja tiukan laadunvarmistuksen alaisena, niin että nopeus ei koskaan tule yhtenäisyyden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee-tai-osta-rajaa, pitää valinnanvapauden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi sen mukaan, mitä sattui olemaan hyllyllä.

Se, mikä kestää työmme jälkeen, ei ole riippuvuus meistä. Se on kokonaisuus, jonka järjestelmät on liitetty toisiinsa tarkoituksellisten, dokumentoitujen rajapintojen kautta eikä yksityisten oletusten sotkun kautta, sekä organisaatio, joka voi lisätä, korvata ja poistaa järjestelmiä ilman, että jokaisesta muutoksesta tulee arkeologiaprojekti. Se on integraatioarkkitehtuurin todellinen tuotto: ei teknologia, vaan takaisin saatu kyky muuttua. Kun sidoskudos suunnitellaan huolella, heterogeeninen kokonaisuus lakkaa käyttäytymästä keskenään kiistelevien siilojen joukkona ja alkaa käyttäytyä yhtenä liiketoimintana, ja seuraavasta järjestelmästä, jonka organisaatio ostaa, tulee lisäys eikä uhka. Asiakkaidemme auttaminen saavuttamaan ja säilyttämään tuo tila, hiljaisesti ja kestävästi, on se, missä Nashua tekee eron.