接口管理不是一個新概念，在雲應用出現之前，就有接口管理問題，和混合場景相比，不同應用間的集成更爲常見。經典的問題包括：哪個工具是我的使用場景中的正確選擇？如何操作我的集成平臺？如何設計組織？以及如何保護、監控和控制集成？
本文鏈接：https://www.cnblogs.com/hhelibeb/p/17844094.html
集成工具的選擇
不同的集成需求使得必須使用不同的集成工具。在大多數情況下，特定的工具適用於特定的使用場景。當選擇一個用於跨系統流程集成的平臺，或者在需要實時傳輸大量數據的場景中，你需要考慮各個方面。畢竟，市場上有許多集成平臺。但是，哪些集成平臺最適合你的需求呢？平臺本身應該在你自己的數據中心內部運行，還是在雲上運行？包含哪些連接器，以及需要哪些連接器來滿足你特定的集成場景？應用使用什麼數據格式？
集成架構師，負責定義企業環境的集成策略，通常試圖找到最佳的方式來滿足各個開發團隊和項目的集成需求。對這些人來說，找到最適合當前和未來集成需求的集成技術非常關鍵。基於混合IT環境的轉型項目正在將數據集成和跨系統訪問變得越來越重要。無論是在本地系統還是雲系統中，應用程序環境的碎片化以及集成工具數量的碎片化都在增加。集成平臺的選擇是個複雜問題，因爲多個不同的集成平臺可能爲開發人員提供類似的功能，即使各個工具的主要目的並不同。例如，多種不同的集成工具中都支持模擬process flow。客戶的場景和需求決定了進行單純的系統集成還是更復雜的系統編排。集成的質量和效果取決於它如何滿足需求。
集成治理
集成治理決定了集成的規則，爲了在開發和運營接口中實現高質量標準化的程序，集成治理涉及集成相關的規則和方法。相關過程可能涉及到各種各樣的團隊和資源。
遺憾的是，需求可能沒有被清晰地定義或集中管理。在許多公司中，正在並行運行的各個項目的集成需求只在需要時傳遞給開發中的同事。各部門可能缺少專門的聯繫人，因此，需求被分散控制，沒有在集中治理體系下進行管理。由此產生的最壞結果是，需求被重複實施，並且不遵循清晰的開發指南。開發人員各自有自己喜歡的集成方法。有些人更喜歡OData服務；有的人更喜歡基於文件的消息傳遞。在IT中，通常缺乏與接口和技術以及如何和何時使用它們相關的行爲規則。最後需求實現了，但信息孤島也隨之形成。關於單個集成場景及其實施的特定知識可能只存在於被委託實施的開發者的頭腦中。許多公司輕視知識反饋和文檔記載，導致它們難以實現。
集成治理的核心目標是建立需求管理，引入指導實施需求的集成原則和模式，並確保對場景進行持久和清晰的文檔記載。
運維集成平臺
集成平臺的選擇確定後，下一步就是運維（Operations）。運維包括集成團隊在每個項目和日常業務中必須考慮的主題。集成平臺的日常業務運維涉及到確保和監控當前正在運行的運維（即，生產集成場景）以及未來的運維。除了確保有序的管理上線，包括對新集成場景的廣泛測試，運維也意味着適當的變更管理和運輸過程。當一個新項目開始時，必須持續進行接口測試。測試從第一次系統的技術連接開始，結束於從實施階段過渡到常規運維。
在測試管理中，必須將測試作爲實施的一部分記錄。測試包括以下內容：
- 開發者測試
- 進程和模塊測試
- 負載和性能測試
- 迴歸測試
根據接口的上下文和開發階段，這些測試會檢查集成的不同方面：
開發者測試通常發生在接口開發結束時或之前，並且只在較小的集成框架內進行測試。
進程和模塊測試通常在關鍵里程碑處進行。在這裏，整個（集成）進程也相應地進行了測試。
此外，也可以進行負載和性能測試，以檢查是否可以傳輸預期的消息量，或者是否會發生性能下降。
在進行了所有這些措施並且集成場景在生產中運行後，這些測試可能需要隨着時間的推移進行調整，無論是通過修復錯誤還是新的需求。在這個上下文中，常見的流行詞是迴歸測試。請注意，迴歸測試不是功能測試；它們只確保代碼庫的更改不會對現有功能產生負面影響。
所有接口經過成功測試後，必須將它們傳輸到生產。這種傳輸很少是一次性活動，因爲傳輸需要靈活地應對新的需求和更改。在業務需求、法律法規發生變化的情境下，能夠快速應對變更請求並考慮這些變更對現有系統和流程穩定性的影響非常重要。詳細的流程文檔和它們的依賴關係，以及相關支持IT系統的使用，可以在這個領域提供幫助。相關係統之一是SAP Solution Manager + SAP Change Request Management。它們允許你從頭到尾集中控制變更過程，使你能夠在SAP環境中管理變更和傳輸。需要注意的是，除了SAP Solution Manager覆蓋的SAP系統外，其他非SAP應用通常也會受到變更的影響，並且在傳輸和調整過程中也必須考慮。
在所有測試和傳輸完成後，必須監控定期的操作：需要澄清誰將分析正在運行的接口，是否可能委託服務提供商進行監控，或者是否可以由內部員工進行24/7的監控概念。除了誰負責監控的問題，還必須澄清必須通知哪些人羣，以及通知的及時性。那麼，接口依賴的響應時間是多少？監控的成本與收益的平衡也很重要，比如可能有些人認爲接口對公司至關重要，需要有持續的監控，但設備和系統並不一定是全天候運行的，有時甚至可以考慮人工監控。因此要綜合各種條件來考慮決策。
組織架構
除了以上描述的方面外，還有一個關鍵因素對集成質量的影響巨大：組織架構，它影響接口的實現和集成工具的使用。每個員工和團隊每天都面臨許多挑戰，這影響了各個團隊甚至各個部門之間的工作方式。挑戰包括：
- 技術和系統的進一步發展
例如，銷售過程通常只在形式上進行修改，而在集成領域，無論是技術還是架構方面的進一步發展都必須不斷審查。如果需要，應將新的發展納入自己的工作方法中，同時也要考慮到核心系統的持續演變。 - 專業部門的不同速度
如何支持敏捷的部門，同時還服務於經典的瀑布模型？並非每個組織都完全按照敏捷方法進行工作。例如，可能缺少的是敏捷方法在項目流程中的錨定，或者員工適應這種工作方式的適當心態。 - 在集成各方面之間的平衡行爲
集成是諮詢、開發、技術和架構問題以及掌握技術細節的混合體。當涉及到兩個不同的部門時，可能需要增加調解員和中間人。集成開發人員通常遠不止是純粹的實施者，在許多項目中，他們也充當業務和IT之間的鏈接。
那麼，如何克服這些挑戰呢？
從這些挑戰中可以識別出三個培訓領域：
- 經典的專業培訓。
- 不同項目管理方法（敏捷與瀑布）的知識。
- 以及與角色模型、方法和框架的經驗。
爲了掌握這一廣泛的範圍，集成團隊基本上應就以下問題達成一致：
- 團隊是否有專業角色互相補充，或者說，團隊更多的是一羣通才？
- 當團隊成員參與長期瀑布項目時，如何在團隊中滿足敏捷需求？
- 是否已經定義了從項目模式轉移到運營模式的知識轉移流程，並考慮到外部服務提供商？
- 集成團隊是否只提供服務，還是因爲主題而更深入地參與這些過程，扮演一個控制角色？
關於組織相關的內容，可能會在後文中進一步討論。