Rajapinta ylittää muutakin kuin verkkorajan
Yhden tiimin sisällä puuttuva konteksti voidaan paikata epävirallisesti. Kehittäjä kysyy prosessin omistajalta, operaattori tunnistaa poikkeuksen tai tietokantakäytäntö tunnetaan yleisesti. Organisaatioiden välillä nämä oikopolut katoavat. Jokaisella osapuolella on oma sanastonsa, julkaisurytminsä, toimivaltansa, hallintakeinonsa ja tulkintansa onnistumisesta.
API- tai tiedostomäärittely voi olla teknisesti kelvollinen, vaikka liiketoimintavuorovaikutus jäisi tulkinnanvaraiseksi. Vastaus ”hyväksytty” voi tarkoittaa rakenteellisesti vastaanotettua, tarkistusjonoon asetettua, kaupallisesti hyväksyttyä tai valmiiksi suoritettua. Ellei merkityksestä ole sovittu, molemmat järjestelmät voivat toimia täsmälleen suunnitellusti ja silti tuottaa kiistanalaisen lopputuloksen.
Suunnittele integraatiosopimuksen viisi kerrosta
Kattava integraatiosopimus sisältää vuorovaikutuksen, semantiikan, käyttäytymisen, operoinnin ja muutoksen. Vuorovaikutus määrittelee aloittajan, tapahtumajärjestyksen ja vastuun siirtymisen. Semantiikka määrittelee liiketoimintakohteet, kentät, mittayksiköt ja tilat. Käyttäytyminen määrittelee validoinnin, vastaukset, virheet, uudelleenyritykset ja idempotenssin. Operointi kattaa havainnoitavuuden, tuen, täsmäytyksen ja palautumisen. Muutos kattaa yhteensopivuuden, versioinnin, ilmoitukset ja käytöstä poistamisen.
Jokainen rajapinta ei tarvitse pitkää muodollista asiakirjaa. Yksityiskohtaisuuden on vastattava seurausten vakavuutta ja organisaatioiden välistä etäisyyttä. Olennaista on tehdä jokaisesta kerroksesta harkittu päätös. OpenAPI-kuvaus, tapahtumaskeema tai tiedostoasettelu voi sisältää osia sopimuksesta, mutta mikään niistä ei automaattisesti määritä vastuuta tai operatiivista merkitystä.
Säilytä identiteetti ja korrelaatio siirtotavasta riippumatta
Tapahtuma voi saada paikallisia tietokanta-avaimia, viestitunnisteita ja eräviitteitä liikkuessaan järjestelmästä toiseen. Järjestelmä tarvitsee silti vakaan tavan ratkaista, koskevatko kaksi tietuetta samaa liiketoimintatapahtumaa. Korrelaation on oltava nimenomainen, kestävä ja tukitiimien käytettävissä, ei piilossa integraatiokomponentin sisäisissä lokeissa.
Identiteettisuunnittelu määrittää myös kaksoiskappaleiden käsittelyn. Jos lähettäjä yrittää uudelleen epävarman aikakatkaisun jälkeen, vastaanottajan on tunnistettava, tarkoittaako pyyntö samaa tavoiteltua vaikutusta. Idempotenssiavain auttaa vain, jos sen soveltamisalasta, voimassaoloajasta ja liiketoiminnallisesta merkityksestä on sovittu. Muuten epäselvyys vain siirtyy uuteen kenttään.
Tila on liiketoiminnallinen lupaus, ei näytöllä näkyvä nimike
Jokaisella ulospäin näkyvällä tilalla pitäisi olla yksi merkitys, määräävä omistaja, sallitut siirtymät ja odotettu seuraava toimi. Vastaanotettu, validoitu, hyväksytty, käsittelyssä, valmis ja hylätty eivät ole keskenään vaihdettavia tiloja. Jos sisäinen tila on yksityiskohtaisempi, sen muunnoksen kumppanisopimuksen tiloiksi on oltava harkittu ja tuen kannalta riittävästi palautettavissa.
Hyödyllinen tilavastaus sisältää korrelaation, ajan, tilan, syyn ja vastuun. Se erottaa lopullisen hylkäyksen väliaikaisesta tilanteesta ja kertoo, saako pyyntöä yrittää uudelleen. Ilman tällaista käyttäytymistä lähettäjät tekevät omat oletuksensa ja piilossa olevista manuaalisista tukiprosesseista tulee osa integraatiota.
Suunnittele häiriötilanteet ja palautuminen ennen normaalipolun viimeistelyä
Osittaiset häiriöt ovat normaaleja riippumattomien järjestelmien välisessä viestinnässä. Vastaanottaja voi suorittaa työn, vaikka sen vastaus katoaisi. Jatkovaihe voi epäonnistua ensimmäisen kuittauksen jälkeen, ja erä voi sisältää sekä kelvollisia että virheellisiä kohteita. Sopimuksen on määritettävä merkityksellisissä tilanteissa atomisuus, uudelleenyritykset, käsittelyjärjestys, uudelleenkäsittely, korvaavat toimet ja täsmäytys.
Palautuminen on sekä tekninen että organisatorinen kyvykkyys. Jollakin on oltava toimivalta käsitellä tapahtuma uudelleen tai korjata dataa, osapuolten on saatava riittävä näyttö tapahtuneesta, ja tuen on tiedettävä, milloin automaattiset uudelleenyritykset ovat päättyneet. Liiketoiminta tarvitsee myös menettelyn vaikutuksiin, joita ei voi perua. Näiden vastuiden on oltava testattavissa hyväksymisskenaarioissa.
Tee kumppanin käyttöönotosta arkkitehtuurin tuote
Jos jokainen uusi kumppani tarvitsee hiljaista, vain harvojen hallussa olevaa tietoa, organisaatiolla ei vielä ole toistettavaa integraatiokyvykkyyttä. Toimiva käyttöönottomalli sisältää liiketoimintavuorovaikutuksen kuvauksen, sopimusesimerkit, vaatimustenmukaisuustestit, testidatan säännöt, tunnusten hankintamenettelyn, etenemisen ympäristöstä toiseen, operatiiviset yhteyshenkilöt, valmiuskriteerit ja versiointiperiaatteet.
Standardoi vakaat osat ja salli perustellut erot. Kaikkien kumppanien pakottaminen samaan fyysiseen muotoon voi synnyttää hauraita muunnoksia rajapinnoille. Yhteinen semanttinen malli tai sopimussanasto on hyödyllinen, jos se vähentää tulkinnanvaraisuutta — ei jos siitä tulee jälleen yksi keskitetty malli, jota kukaan ei omista.
Hallitse rajoja todistein
Organisaatioiden välisen hallinnan on näyttävä käytännön artefakteissa: nimetyissä omistajissa, versiotiedoissa, palveluodotuksissa, virheluokissa, hyväksymisnäytössä ja tarvittaessa yhteisessä muutoskalenterissa. Kokoukset ilman sopimusta koskevaa näyttöä eivät korvaa määrittelemätöntä käyttäytymistä.
Aloita yhdestä tärkeästä tapahtumasta ja seuraa sitä liiketoiminnallisesta tarkoituksesta molempien organisaatioiden läpi. Sisällytä tarkasteluun myös epävarma vastaus ja sääntömuutos. Tällaisessa läpikäynnissä löytyvät aukot kertovat usein enemmän kuin laaja integraatioteknologioiden luettelo.