無法購買整合

無法購買整合

儘管有許多旨在簡化連接系統的工具，但您無法購買整合。

您可以購買程式語言。在 1974 年 CONTU 裁決後，支付編譯器費用變得普遍。比爾蓋茲著名的致業餘愛好者的公開信是呼籲社群為 Micro-Soft 的 Altair BASIC 解譯器付費的號角聲（他們在後來的幾年中刪除了連字號）。自由軟體基金會的 GCC 編譯器開啟了程式語言商品化的道路，但為開發人員工具留下了商業市場。例如，我很樂意使用 Java 編寫程式碼，現在可以免費取得，但我不會很興奮在 vi 或記事本中這樣做。

整合軟體產品（ESB、ETL 工具、API 平台和雲端整合服務）並非直接解決業務問題的產品。它們不屬於同一類別，例如詐欺偵測產品、分析產品或 CRM。它們是程式語言，與工具鏈和執行時間一起綑綁，以支援編譯程序。當您購買整合產品時，您同意使用商業程式語言建置整合本身。

整合工具幾乎總是低程式碼平台，這表示它們旨在透過提供圖形設計面板來簡化開發工作，您可以在其上拖放整合工作流程。原始碼通常儲存在執行時間可以詮釋的標記語言中。您可能會將一些工作流程拖放到面板上，但在底層，平台會將原始碼儲存為 JSON 或 XML，並嵌入一個執行時間，它知道如何將標記詮釋為實際機器碼，這與 Micro-Soft 早期的編譯器知道如何將 BASIC 碼轉換為 Altair 平台上的機器碼沒有什麼不同。例如，以下是 AWS 編排引擎 Step Functions 的「Hello, World」原始碼

圖 1：Step Functions 使用 JSON 和圖形設計面板來表示工作流程

許多整合工具，包括 AWS Step Functions，讓您可以使用圖形調色盤或直接使用標記語言進行程式設計。雖然調色盤通常是首選，原因對任何讀過 Charles Petzold 關於 CSAML 的著名愚人節玩笑的人來說顯而易見，但調色盤中設定整合步驟的複雜性意味著，實際上，有能力的開發人員會對底層標記語言本身具備一些熟悉度。實際上，圖形調色盤和標記語言之間存在雙向對應，因此更改其中一個可以立即反映在另一個中。如果我正確理解數學術語，這就是所謂的同構，因此我將產生的結構稱為「來源圖表同構」，其中調色盤和標記語言都代表原始碼，並且可以無縫地來回翻譯。這當然代表了以開發人員為中心的觀點；執行階段本身只關心標記語言。

這與大多數軟體程式設計大不相同，在軟體程式設計中，開發人員直接編輯原始碼，而沒有圖形調色盤，我將這種做法稱為「來源內態射」，不過如果您比較容易記住，也可以稱之為「正常」。當然，有些工具可以視覺化 Java 中的類別圖表，甚至可能讓您進行編輯，並反映在原始碼中，但 Java 開發人員的通常活動是在 IDE 中直接編輯 Java 原始碼。

提供圖形設計調色盤的優點在於它提供了一種組織思維的方式，一種用於整合問題的特定領域語言 (DSL)，讓您可以專注於將系統連接在一起的狹隘問題，而沒有多餘的複雜性。Java 可能更擅長解決一般用途的問題，但設計調色盤和宣告式標記語言的限制旨在更優雅地解決整合和工作流程問題，就像 Excel 函數讓您可以比撰寫自訂 Java 程式碼更優雅地解決預算編列問題一樣。同樣地，在許多情況下，我更喜歡 iPhone 上的計算器，而不是令人印象深刻的HP 50g 繪圖計算器，它支援逆波蘭表示法和科學計算。

圖 2：良好的 DSL 透過專注於核心問題來去除複雜性

當您購買整合工具時，您同意建置實際的整合。您購買的是一個承諾，即整合可以比使用通用語言更有效率、更簡單地解決。然後，架構師的工作歸結為了解在哪些情況下該承諾可能會成立，並避免將「購買」決策轉換為在這些情況之外使用工具以證明其投資報酬率的可以理解的誘惑。

有些整合 DSL 是問題空間的較簡單投影，例如我的 iPhone 計算器。其他確實是圖靈完備的，這表示在理論上，它們具有與通用語言相同的演算法能力。雖然正確，但對可計算性的學術討論未能說明軟體工程，而 一群 Google 員工 將其定義為「隨著時間推移的程式設計」。如果程式設計需要使用抽象，那麼隨著時間推移的程式設計表示在環境變化的情況下，在複雜的生態系統中演進這些抽象，並且需要積極考量團隊協議、品質實務和交付機制。我們將在稍後更詳細地探討如何隨著時間推移的程式設計問題影響整合，以及它們如何提供低程式碼整合工具的適當情境。不過，首先，我想挑戰整合的主要目標是將系統連接在一起的想法，因為我相信更廣泛的定義使我們能夠更好地分離生態系統中簡化抽象有助於程式設計的部分，以及隨著時間推移的程式設計問題的額外複雜性需要通用程式設計語言的部分，我將在稍後為此主張辯護。

將大部分精力投入建立乾淨的介面

對大多數人來說，「整合」一詞會產生將系統連接在一起、分享資料以保持系統同步的印象。我相信這種整合定義不足以滿足現代數位業務的需求，並且整合良好的真正目標是建立功能之間的乾淨介面。

當我們的主要焦點是連接系統時，我們可以透過衡量將新系統連接到現有技術環境的速度，來衡量我們的整合方法有多成功。在該環境中，系統成為主要的價值驅動力，而整合成為讓系統正常運作的必要之惡。相反地，當我們將主要焦點轉移到在數位功能上建立乾淨的介面時，我們會透過隨著時間增加數位敏捷性來衡量成功，而這些數位功能將成為主要的價值驅動力，甚至比系統本身更重要。在這種差異中有很多值得探討的地方，從強調介面而非實作開始。

簡化介面是建立成功產品和在複雜生態系統中擴展規模的關鍵要素之一。例如，我對我正在輸入的鍵盤底層的機電實作、輸入系統驅動程式或作業系統中斷，讓我在鍵盤上輸入的按鍵神奇地出現在螢幕上的方式，了解甚少。有人必須弄清楚這一切，更可能的是許多人，因為鍵盤、系統驅動程式、作業系統、監視器和應用程式都是獨立的「產品」，但我所需要擔心的，只是在正確的時間按下正確的按鍵，將我腦中的想法整合到螢幕上的文字中。

當然，這有一個有趣的推論：簡化介面的關鍵（無意中的雙關語）是接受更複雜的實作。

當我們想到面對市場的數位產品時，這句話並無爭議。Google 搜尋引擎在底層的技術複雜得難以想像，但即使是數位不精的使用者也能輕易使用。我們也接受它用於面對企業使用者的數位產品。對於導入 Salesforce 而感到興奮的銷售團隊肯定明白，雖然使用者介面可能比舊的 CRM 更符合他們的需求，但維護和進化產品本身需要大量的努力，這就是訂閱費用感覺合理的理由。然而，我們對整合的處理方式不同。直覺上，我們了解架構圖上的二維方塊可能隱藏著相當大的複雜性，但我們期望一維線條以某種方式有所不同。

（它們在一個方面有所不同。你可以購買方塊，但你不能購買線條，因為你不能購買整合。）

雖然我們過去一直圍繞著方塊（我們正在推出的數位產品）擬定專案計畫和成本，但線條是隱藏的，而且通常是組織技術負債的主要驅動力。它們就是導致事情現在比過去花費更長的時間的原因。

圖 3：我們會針對應用程式導入專案，但隨著時間推移，這些應用程式之間的線條會成為關鍵的成本驅動力

簡化該膠水程式碼肯定是一項崇高的努力，而且整合工具可以提供協助，但不能以建立乾淨的介面為代價。重要的是，介面容易使用的唯一有效評判者是實際使用者。Google 可以向我們索取更多資訊，以簡化其搜尋實作，例如地理、近期性和熱門資訊，但他們只提供一個單一的文字方塊來輸入搜尋，而且必須學習如何將這些因素套用至其演算法。API 設計（我廣泛定義為包含同步呼叫和非同步事件）也適用相同的考量。

乾淨的介面會隱藏實作細節，而且整合脈絡中的其中一個實作細節是程式語言的選擇。我尚未看過將重點放在所涉系統的程式語言的架構圖

圖 4：在架構圖中強調實作語言並不常見

然而，我已經看過太多針對整合進行這項工作的圖表變異。此類觀點強化了將整合視為將系統連接在一起的策略性理解，因為它強調連接工具鏈，而不是數位功能。

圖 5：在架構圖中顯示商業整合工具會將重點放在實作細節，而不是介面上，而且將整合視為策略性考量

我們的 API 使用者很樂意不關心另一個實作細節，那就是資料來自哪些系統。除了在 SAP 中工作的業務使用者和其周圍的 IT 人員之外，組織中沒有人應該關心 SAP 系統的怪癖。他們只關心如何取得客戶資料或如何建立訂單。值得另外提出此觀察結果，因為這是我在整合策略中看到最常被違反的原則之一，而且是將整合視為將系統連接在一起，而不是建立乾淨的介面來處理數位功能的隱含哲學的最有力指標之一。您不需要 SAP API，因為您的 API 使用者不關心 SAP，但您可能需要訂單管理 API。抽象化功能，而不是系統。

您的使用者不會停滯不前，而且良好的 API 常常會透過重複使用來增加價值。很容易將重複使用視為 API 的主要目標（我相信控制複雜性才是更重要的目標），但這仍然是一個有用的願景。滿足使用者不斷變化的需求表示要打破先前的假設，這是程式設計中隨著時間推移而出現的經典問題。延續我之前的比喻，鍵盤的工作是將使用者的想法無縫整合到螢幕上的文字中。作為一個母語為英語的人，我從未像母語為中文的人那樣，必須努力應付拼音轉寫，但有好幾年，我無謂地折磨自己，使用科爾馬克鍵盤配置輸入。由於我的實體鍵盤無法神奇地適應軟體配置，因此鍵盤上的字母與螢幕上顯示的字母之間存在阻抗不匹配。通常，這不成問題：作為一個（速度不快的）盲打者，我習慣於不看鍵盤。然而，這種阻抗不匹配讓學習過程變得痛苦不堪，因為我必須不斷查看 QWERTY 的螢幕對應，並在腦袋努力處理由此產生的混淆時，還要低頭查看按鍵。我敢肯定，市面上有背光鍵盤，可以根據鍵盤配置將字母投射到實體按鍵上。當然，這種改良介面的代價是更複雜的實作，而這種演進是程式設計中隨著時間推移而出現的問題。

無法隨著時間推移適應使用者的整合介面，或為了實作便利性而過於輕易地隨著底層系統而變更的介面，都是時點整合，實際上只是具有多層的多點對點整合。它們可能披著 API 的外衣，但每次將新的系統連線到資產中，並複製或濫用 API 來解決實作問題時，就會顯露出它們的本質。時點整合會增加系統間技術負債。

當然，您吱嘎作響的記錄系統會抵制任何將它們放入方框中的嘗試。ERP 專門設計為執行所有事情，因此嘗試將仍必須與 ERP 整合的新功能外化，將是一項挑戰。可能需要重要的架構技能來控制由此產生的整合複雜性，並將其隱藏在使用者面前，但替代方案是增加您的組織技術負債，在點對點或時點整合的義大利麵混亂中再加一團麵條。我所知道償還技術負債的唯一方法，就是堅持為您的使用者建立一個乾淨的介面，並建立必要的轉換、快取和編排，以連接到下游系統。如果您不這樣做，您就會迫使所有 API 使用者處理這種複雜性，而他們的脈絡會比您少得多。

我們需要顛覆思維模式，從思考如何使用我們的工具解決整合問題，轉而思考如何建立正確的介面以最大化敏捷性。

使用通用語言管理介面演進

許多商業整合工具宣傳它們擁有整合環境的能力，並在需要時呼叫一般用途語言。雖然我可以欣賞這種訊息背後的行銷手法，它促進產品滲透和鎖定，但作為架構指南，這完全是本末倒置。相反地，我們幾乎總是應該在一般用途語言中管理介面演進，至少有兩個原因：這樣我們可以更好地管理維護乾淨介面的複雜性，並且在做出策略整合決策時，我們可以避免我們工具心智模式的引力。

整合工具會從實作的角度「思考」

整合工具的建立，並持續蓬勃發展至今，是因為跨越 IT 系統範圍解鎖資料和功能的複雜性。例如，您實際的客戶主檔資料可能存在於 SAP 中，但客戶生命週期的早期部分存在於 Siebel CRM 中。IBM 大型主機系統仍為部分客戶處理核心帳單；其他客戶則使用 Oracle ERP。現在，企業希望用 Salesforce 取代 Siebel。引進新產品的業務團隊自然了解，花費一些時間才能正確設定組態以適應其銷售攝取流程，但他們最不希望聽到的就是漫長的 IT 時程，只為了理清系統之間的黏著劑。畢竟，這是 SaaS！

傳統上，這些漫長的時程是點對點整合的結果，而點對點整合不允許學習。系統之間的每條新連線都表示團隊必須重新學習如何連線、如何詮釋資料、如何在系統之間路由，等等。整合工具將問題分解成較小的部分，其中一些部分可以重複使用，特別是連線到系統的部分。看看我們稍早看過的 AWS Step Functions 調色盤中的一些可用動作

圖 6：AWS Step Functions 工作流程中的每個步驟都說明了一個實作問題

Step Functions 根據對某些 AWS 服務的某些動作來描述所有動作。您可以設定工作流程中的每個方塊來描述例如 DynamoDB 表格名稱，讓您專注於調色盤主部分的整體流程。雖然 Step Functions 是一個相對較新的整合工具，明顯偏向雲端原生 AWS 服務，但我所熟悉的整合工具都傾向於以類似的方式運作，專注於實作問題。應用程式整合的早期內部部署等效項是企業服務匯流排 (ESB)，它將系統連線作為可重複使用的元件從編排和路由中分離出來。您可以在 Mulesoft 的 ESB 的簡化檢視中看到這種分離，之所以這麼命名是因為它旨在移除整合的「苦差事」

圖 7：ESB 將連線與編排和路由分離

在 ESB 世界中有一些自然的錯誤開端，因為業界渴望在匯流排上擁有全企業的標準格式，但它們都共用匯流排輸入和輸出的適配器概念，也就是要整合的系統。在順利的情況下，您可以使用類似 BPEL 的語言描述您的整合，它可以提供圖形設計調色盤和原始碼圖示同構，因為它以 XML 描述流程。

產業已大幅拋棄 ESB，但您可以在現代 API 平台中看到它們的傳統。例如，看看 Mulesoft 的三層式 API 架構

圖 8：Mulesoft 的三層式架構維持連線與體驗和系統 API 的區隔

Mulesoft 販售 API 管理平台和用於建置 API 的低程式碼執行時期。您能且經常應該購買中間件基礎架構，而且完全有可能將 API 閘道與執行時期分離，代理至以通用程式語言建置的 API。如果您這麼做，就會產生一個問題：如果您在 Mulesoft 執行時期外部建置所有 API，您會使用 Mulesoft 的三層式架構嗎？

我相當喜歡體驗 API 的概念。這個名稱比微服務社群中流行的名稱 — 前端後端 — 較不專業術語化，儘管我比較喜歡「頻道 API」這個術語，因為它更明顯涵蓋更廣泛的考量。例如，在 B2B 場景中縮小核心 API 的存取顯然是頻道考量，比較不顯然是「體驗」或「前端」考量。無論名稱為何，提供最佳化的頻道特定 API 都是有價值的模式，這個模式允許頻道以不同於基礎功能的速度演進，並縮小攻擊者的攻擊面。

我比較不喜歡流程和系統 API 之間的規範性區隔，因為它們著重於實作而非介面：系統層著重於連線，而流程層著重於協調 [1]。我在上方重新繪製了他們簡化的 ESB 圖，以顯示連線系統的實作考量相似性難以忽視

圖 9：三層式架構強調實作細節，顯示其 ESB 傳統

像 Mulesoft 這樣的平台的價值主張的一部分 — 其 ESB 和 API 執行時期 — 在於內建連接器庫，可連接至 SAP 和 Salesforce 等系統，這些連接器可以在系統邊緣（特別是系統層）為您節省時間。三層式架構簡化這些連接器的使用，並將協調和彙總分開，以鼓勵重複使用它們。

在概念上，三層式架構用於限制設計 API，使其符合 Mulesoft 的 ESB 傳統。理論上，此架構允許跨層進行更多重複使用。實際上，您受到跨時間程式設計考量所限制，這些考量涉及將流程 API 演進至多個消費者。事實上，我見過許多根本不是 API 的 API，而是穿著 API 外衣的 ETL，其中系統層管理萃取、流程層管理轉換，而體驗層管理載入。這並不令人意外，因為整合工具會從實作的角度思考。

購買整合工具的吸引力在於它們讓連接系統的戰術考量變得更便宜，避免了客製化軟體常見的開銷和風險。不幸的是，當我們用這種方式界定問題空間時，我們已讓我們的工具替我們思考。

使用商業整合工具簡化實作考量

現在應該很清楚了，我對企業級整合工具授權深感懷疑，這並非批評特定工具本身，而是因為我相信授權代表了對整合價值的根本誤解。當然，工具供應商會反駁，但工具供應商自然而然地有增加滲透率和鎖定的目標。架構師的角色是確保您不讓供應商的產品策略成為您的架構策略，為工具建立適當的受限範圍。

透過此觀點，我看到商業整合 DSL 至少可以在兩個領域增加極大的價值。

簡化工作流程和連線性

僅僅因為實作是第二順位考量，並不表示加速實作沒有真正的價值，只要我們適當地將其置於簡化對底層功能存取的介面之後。毫不意外地，加速實作正是商業整合 DSL 的主要價值主張。

許多整合 DSL 都行銷為「擁有」整合環境，並在必要時呼叫一般用途語言。若要解決程式設計過時的問題，您需要反轉此控制，將實作中容易隨著時間演進的複雜部分，從不太可能隨著時間需要大幅變更的部分中抽象出來。

圖 10：若要管理程式設計過時的複雜性，請使用整合 DSL 簡化實作，而非擁有介面

我曾與之互動的一個團隊使用Camunda來管理微服務編排。與某些編排工具不同，您可以將 Camunda 作為 Java 函式庫與 Spring 和 Spring Boot 整合使用，讓您更容易使用傳統的 Java 軟體工程規範來管理一般用途程式設計語言中的介面演進，同時使用工作流程工具簡化某些實作面向（在本例中為開源，但商業工具也一樣好用）

類似地，那些系統連接器和適配器可以在提供一些實作提升方面大有幫助，而且可以抽象在一般用途程式設計語言中編寫的核心功能抽象之後。這類似於 Mulesoft 的系統 API 指南，即使您的最終 API 策略淡化系統，這也可能是不錯的實作建議。同樣地，圖形工作流程視覺化可以加速將一系列呼叫連接在一起，以進行多步驟流程中的簡單步驟，很像上面顯示的 AWS Step Functions 範例。

一般來說，我對於在整合 DSL 中新增許多轉換會持保留態度，或至少願意隨著時間推移，在 Java 等語言中重新實作這些轉換，因為那往往是許多程式設計複雜性隨著時間推移而存在的地方。轉換代表來源系統中的資料與消費系統預期的資料介面之間的緩衝區，因此會受到多方演化的壓力：記錄系統中的變更以及為消費者演化介面。同樣地，我會將任何效能最佳化或復原能力程式碼（例如快取）保留在通用語言中，因為它們隨著時間推移通常會變得相當複雜。

掌握 B2B 整合的長尾效應

在 B2B 情境中，通常需要在組織的圍牆外進行整合。如果你很幸運，你可以依賴乾淨的 API 進行此類整合，但運氣並非特別有回報的商業策略，你可能必須與 IT 能力較弱的小型企業進行整合。必須與像你的 B2B 合作夥伴一樣多樣化的系統進行整合，以及處理一些幾乎沒有 IT 能力的合作夥伴，這會帶來一項艱難的挑戰，我個人已在三個不同的產業中看到此挑戰不斷出現

• 透過經銷商進行交易的能源公司，以及簽約共享銷售資訊以管理自動化庫存補充
• 與第三方經銷商進行交易的重型機械零售商，但嘗試全球最佳化零件配送
• 與付款方進行交易的醫療保健服務公司，提供附加價值服務以偵測（例如）詐欺、浪費和濫用

即使那些 B2B 合作夥伴確實有適當的 IT 系統，其多樣性也可能令人不知所措，而且你可能沒有影響力要求他們撰寫整合至你的 API 合約。許多 B2B 合作夥伴也存在於傳統產業中，緩慢採用新的數位技術。FTP 檔案傳輸、大型主機系統的 EBCDIC 轉換和 EDI 仍然是你可能必須解決的問題。

緩慢變動的 IT 的優點在於，程式設計複雜性隨著時間推移而減弱。商業整合 DSL 的優點在於，其中許多可能確實有能力支援必要的整合模式和轉換。將轉換直接放入工具中與我上述的建議相矛盾，但由於 B2B 整合往往以律師和採購部門的速度進行，因此取捨更具吸引力。當然，你仍然需要一個專用的頻道 API，但整合 DSL 可以作為一個低成本的轉接器。

圖 11：將整合工具用作整合合作夥伴與共用頻道 API 之間的轉接器

要以通用程式語言處理整合的長尾問題，成本可能高得令人難以接受。如果問題不需要快速演進，那麼使用專門為快速解決問題而設計的工具，可能是經濟效益較佳的選擇。

將整合視為業務的策略

我常聽到有人用「我們不是軟體公司」這句話的變體，來為購買整合工具辯解。這種說法是可以理解的，用意是作為一項原則，用來釐清優先投資決策，以符合組織在市場上的整體價值。開發人員的勞動力是一項重大的投資，雖然有許多稱職的開發人員熟悉整合 DSL，但整體而言，此類開發人員的勞動力市場比更熟悉通用語言編碼的開發人員勞動力市場便宜。

我相信這個原則很符合「小氣鬼反而花更多錢」的說法。畢竟，我猜想你們也不是數學公司，但在一定規模下，你們依賴一些相當進階的數學技能。你們不會透過為財務團隊和統計學家購買功能較弱的計算器，並要求他們將整體問題分解成符合工具複雜度上限的方法，或將每個問題都變成適合你們工具的釘子，來解決這個問題。

當然，軟體是一種不同的野獸。撰寫軟體出了名的風險高且昂貴，許多組織非常害怕客製化軟體，以至於他們想盡辦法避免使用客製化軟體。購買圖形整合工具可以提供一種更簡單、更容易接近的客製化軟體形式。沒錯，架構圖上每個方塊之間的線條可能會變得更容易建立。然而，由於此類工具的複雜度上限，線條數量會爆炸性增加，這就像在架構上澆灌緩凝混凝土，會隨著時間增加架構技術負債。

幾年前，我與一家電信公司合作，該公司希望為其使用者提供購買新手機的自助電子商務功能。任何曾在這個產業工作過的人都知道這項工作涉及的挑戰：購買電信服務基本上比購買零售產品複雜，因為電信服務有一個生命週期。對於手機而言，此生命週期常見的客戶端抽象化是方案，其中詳細說明簡訊、資料和語音限制，以及國際電話的計費方式（這是一個極為複雜的實作，涉及法律和電信業者協議、海底電纜、整個深海電纜維修產業，以及防止電纜斷裂的國家防禦協議，所有這些都隱藏在電話號碼的乾淨介面背後）。

其實已經開發了一個 API，但它是為呼叫中心代理開發的，而不是電子商務網站。若要取得手機的可用方案，API 和基礎系統預期您會先建立一筆交易，以記錄呼叫中心代理的動作，這顯然是網站錯誤的抽象。我們能夠透過建立一筆假交易來解決此限制，只接收包含系統詳細資料的 XML 酬載

      <x:offerDetails>
        <id>2207891</id>
        <program>2205442</program>
        <filter>
          <typeCode>C</typeCode>
          <subTypeCode>E</subTypeCode>
          <contractTerm>24</contractTerm>
        </filter>
      </x:offerDetails>

與各個專家協調後，我們了解這些神奇數字和字母的意義，這些是基礎帳單系統中外洩的抽象，我們仍然需要再呼叫一次才能取得定價詳細資料。最後一次呼叫傳回超過 1,000 行的 XML，其中約有 100 行與我們的電子商務需求相關。

雖然一點都不容易，但我們與基礎 IT 組織合作，建立了一組新的 API，更清楚地呈現電子商務考量，而沒有所有額外的舊有複雜性，乾淨的介面將外洩的抽象轉換為有意義的功能，讓電子商務開發人員無需了解帳單系統機制。我們必須抽象舊有的複雜性，才能建立自助服務的未來。架構圖反映出思考問題的新方式，以數位功能思考，而不是基礎系統。我們不允許下游複雜性或實作程式語言在我們的電子商務團隊圖表中找到容身之處

圖 12：儘管下游複雜性顯著，我們確保核心功能有乾淨的介面，以改善電子商務敏捷性

當一切說完做完，這家電信公司在推出新 iPhone 時，是其國家中第一家擁有全自動自助服務體驗的公司，不僅擊敗了直接競爭對手，還擊敗了強大的 Apple 本身。

不論是傳聞還是事實，傑夫·貝佐斯著名的命令，即僅透過可外化的 API 進行通訊，可能是他們目前世界主宰的關鍵。此命令有深遠的影響，其中之一是將整合對話從思考系統轉換為思考功能，這在技術內部創造了巨大的組織敏捷性。另一個更具變革性的影響是透過簡化消費者介面，獨立於執行這些功能所需的專業知識，從內部作業（基礎架構配置、呼叫中心、履行）中產生收入流。這樣做會在他們的架構圖上建立新的方塊，這些方塊以前是線條，因為它們將複雜的流程具體化在使用者友善的可編程介面背後。

您的整合策略是組織敏捷性的關鍵架構組成部分。可以理解您希望將其外包給產品，類似於其他購買與建置的權衡取捨，以管理風險，但這種方法總是會導致整合被視為戰術考量。正如 Amazon 向我們展示的那樣，將整合對話重新定義為遠離連接系統，而朝向公開業務功能之間的自助服務介面，可以帶來顯著的商業價值。這樣做需要根據本文中探討的整合原則類型進行思考：

在 The Software Architect Elevator 中，Gregor Hohpe 描述了數位組織如何在「一階導數」中運作，這是數學怪咖表示他們將焦點從目前的數位足跡轉移到他們的變化率。我將超越 Gregor，並說一個良好的整合策略存在於二階導數中：您的整合策略，以及投資時間和金錢以簡化組織功能介面的能力，是組織加速的一個關鍵驅動力。它可能一開始會讓您稍微放慢速度，但隨著時間的推移，這些介面將成為您數位轉型的油門。

圖 13：建構數位加速需要關注程式設計時間考量，尤其是系統之間需要乾淨介面的需求

因此，請務必購買 CRM 和您的收益管理系統，以及呼叫中心的 ML 驅動情緒分析附加元件。購買您的 API 閘道和分析資料庫以及您的容器編排系統。向數位原生企業學習產品營運模式、內包方法和自主團隊結構。請記住，如果您繼續將整合視為需要克服的戰術麻煩，以便利用這些新系統，那麼這些系統都不會讓您在數位世界中具有競爭力。

您無法購買整合，但這沒關係；自行建置整合是值得投資的。畢竟，這可能是您投資組合中最具策略性的軟體。