Egy interfész nem csupán hálózati határt lép át
Egy csapaton belül a hiányzó kontextus informálisan pótolható. A fejlesztő megkérdezi a folyamatgazdát, az üzemeltető felismer egy kivételt, vagy mindenki ismeri az adatbázis-konvenciót. Szervezetek között ezek a rövid utak eltűnnek: minden félnek saját szókészlete, kiadási ciklusa, döntési jogköre, kontrollrendszere és sikerértelmezése van.
Egy API- vagy fájlspecifikáció műszakilag érvényes lehet, miközben az üzleti interakció kétértelmű marad. Az „elfogadva” jelenthet szerkezeti átvételt, ellenőrzési sorba állítást, üzleti jóváhagyást vagy tényleges teljesítést. Ha a jelentés nem része a szerződésnek, mindkét rendszer pontosan a terv szerint működhet, mégis vitatott eredményt hozhat létre.
Az integrációs szerződés öt rétegének megtervezése
A teljes integrációs szerződés az interakciót, a szemantikát, a viselkedést, az üzemeltetést és a változást is lefedi. Az interakció rögzíti, ki kezdeményez, milyen sorrendben történnek a lépések, és hol adódik át a felelősség. A szemantika meghatározza az üzleti entitásokat, mezőket, mértékegységeket és állapotokat. A viselkedés lefedi az ellenőrzést, válaszokat, hibákat, újrapróbálást és idempotenciát. Az üzemeltetés a megfigyelhetőséget, támogatást, egyeztetést és helyreállítást, a változás pedig a kompatibilitást, verziózást, értesítést és kivezetést határozza meg.
Nem minden interfészhez kell hosszú, formális dokumentum. A részletezettség igazodjon a következményekhez és a szervezeti távolsághoz. A lényeg, hogy minden réteg tudatos döntés eredménye legyen. Az OpenAPI, az eseménysémák vagy a fájlformátumok hordozhatják a szerződés egyes részeit, de egyik sem határozza meg automatikusan a felelősséget és az üzemeltetési jelentést.
Az identitás és a korreláció megőrzése az átviteli módtól függetlenül
Egy tranzakció haladása közben helyi adatbáziskulcsokat, üzenetazonosítókat és köteghivatkozásokat kaphat. A rendszernek mégis stabil módon kell megállapítania, hogy két rekord ugyanahhoz az üzleti eseményhez tartozik-e. A korreláció legyen egyértelmű, tartós és a támogató csapatok számára elérhető, ne egy integrációs komponens belső naplóiban rejtőzzön.
Az identitástervezés a duplikátumok kezelését is meghatározza. Ha a küldő egy bizonytalan időtúllépés után újrapróbálkozik, a fogadónak fel kell ismernie, hogy a kérés ugyanazt a kívánt üzleti hatást képviseli-e. Az idempotenciakulcs csak akkor hasznos, ha a hatóköre, élettartama és üzleti jelentése egyeztetett; ellenkező esetben csupán egy új mezőbe helyezi át a kétértelműséget.
Az állapot üzleti ígéret, nem képernyőcímke
Minden kívülről látható állapotnak egyetlen jelentéssel, hiteles felelőssel, megengedett átmenetekkel és elvárt következő lépéssel kell rendelkeznie. A beérkezett, ellenőrzött, elfogadott, folyamatban lévő, teljesített és elutasított állapotok nem felcserélhetők. Ha a belső állapot részletesebb, a partnerszerződésre történő leképezés legyen tudatos és a támogatáshoz kellően visszakövethető.
Egy hasznos állapotválasz korrelációt, időpontot, állapotot, indokot és felelősséget hordoz. Megkülönbözteti a végleges elutasítást az átmeneti helyzettől, és jelzi, engedélyezett-e az újrapróbálás. E viselkedés nélkül a küldők saját feltételezéseket alkotnak, a rejtett kézi támogatási folyamatok pedig az integráció részévé válnak.
A hibát és a helyreállítást még a sikeres alapfolyamat lezárása előtt tervezze meg
Független rendszerek kommunikációjában a részleges hiba természetes. A fogadó elvégezheti a munkát, miközben a válasz elveszik. Egy későbbi lépés meghiúsulhat egy korábbi visszaigazolás után. Egy köteg érvényes és érvénytelen elemeket egyaránt tartalmazhat. A szerződésnek a lényeges esetekre ki kell térnie az atomikusságra, az újrapróbálásra, a sorrendre, a visszajátszásra, a kompenzációra és az egyeztetésre.
A helyreállítás egyszerre műszaki és szervezeti kérdés. Valakinek jogosultság kell az adatok visszajátszásához vagy javításához; az érintett feleknek bizonyítékra van szükségük; a támogatásnak tudnia kell, mikor állt le az automatikus újrapróbálás; az üzletnek pedig kezelési útvonal kell a visszafordíthatatlan eredményekhez. Ezeket a felelősségeket elfogadási forgatókönyvekben is tesztelni kell.
A partnerbekapcsolás legyen az architektúra terméke
Ha minden új partner bekapcsolásához csak néhány ember fejében lévő tudás kell, a szervezetnek még nincs ismételhető integrációs képessége. Egy jó bekapcsolási minta tartalmazza az üzleti interakciót, szerződéspéldákat, megfelelőségi teszteket, tesztadat-szabályokat, a hozzáférési adatok folyamatát, a környezetek közötti útvonalat, üzemeltetési kapcsolattartókat, készenléti feltételeket és verziópolitikát.
A szabványosítás a stabil részekre összpontosítson, miközben teret hagy az indokolt eltérésnek. Ha minden partnert egyetlen fizikai formátumba kényszerítünk, törékeny leképezések jöhetnek létre a rendszer szélén. A kanonikus szemantikai modell vagy szerződéses szókészlet akkor értékes, ha csökkenti a kétértelműséget — nem akkor, ha egy újabb, felelős nélküli központi modellé válik.
A szervezeti határ irányítása bizonyítékokon keresztül
A szervezetek közötti irányításnak láthatónak kell lennie az üzemeltetési munkaanyagokban: megnevezett felelősökben, verziónyilvántartásokban, szolgáltatási elvárásokban, hibakategóriákban, elfogadási bizonyítékokban és szükség esetén közös változtatási naptárban. A szerződéses bizonyíték nélküli egyeztetések nem pótolják a meghatározatlan viselkedést.
Kezdje egyetlen fontos tranzakcióval, és kövesse végig az üzleti szándéktól mindkét szervezeten át, beleértve a bizonytalan választ és egy szabályváltoztatást is. Az így feltárt hiányok gyakran többet magyaráznak meg, mint az integrációs technológiák széles körű leltára.