在當下複雜的現代IT 環境裡，企業極少會僅依仗單一供應商的產品。為了獲取最佳的功能，以及成本效益與靈活性，混合運用源自不同廠商的硬件、軟件和服務已然成為常態。然而，這引發了一個核心挑戰：怎樣使這些異構系統順利地“對話”並協作？多廠商互操作性解決方案正是為了攻克這一難題而產生，它涉及系統的整合效率，還有業務的連續性與最終的投資回報。
為什麼企業需要多廠商互操作性
單單依靠唯一的供應商會形成“供應商鎖定”，致使企業議價能力降低情形出現，升級路徑受到限制，並且很難採用行業內更為優質的創新技術；構建多個廠商的環境能夠促使供應商之間形成良性競爭狀況呈現，企業能夠基於擇優選擇進行組合，打造出更契合自身業務需求的定制化技術棧。
站在業務敏捷性的視角來看，具備良好的互操作性所代表的是，新功能或者新服務的上線時間被極大地縮短了。若核心系統能夠與不同供應商的最佳解決方案迅速進行集成，那麼企業便能夠更為快速地對市場變化作出響應，進而推出全新的數字化產品，如此一來便可在競爭當中搶占先行優勢。這可是維持企業長期競爭力的技術基礎所在。
如何評估不同供應商的兼容性
評估不可以簡簡單單就停流在供應商所宣揚的那個“支持開放標準”的口號方向上面。首先呢，需要去要求供應商給出詳細的API文檔，表示軟件開發工具包以及符合性測試報告。親自去做或者委託第三方來做概念驗證測試這件事情是非常關鍵重要的，特別是得去模擬處在真實業務場景狀況下的數據交換以及工作流銜接。
查看供應商的生態合作過往經歷，對於那種積極投身主流行業聯盟裡，且跟其他有名氣的廠商擁有成功聯合解決辦法實例的供應商而言，其產品的相互操作性常常更能讓人信賴，另外，要留意其技術支持的回應機制，有沒有設立專門的相互操作性支持團隊去處理跨廠商的各種問題。
多廠商互操作性有哪些主要挑戰
技術層面首要面臨的挑戰是，其中標準並非一致。雖說存在通用標準，不過不同之處在於廠商到實現階段時，常常會有各自的理解以及擴展，進而致使出現“方言”問題。而且數據模型的差異程度很大，同樣的業務實體於不同系統裡，可能會存在全然不同的字段定義以及格式，致使映射和轉換工作變得複雜，並且容易出現差錯。
在管理方面，與運營齊頭並發的挑戰顯著突出，當問題湧現出來的時候，極易出現供應商彼此之間相互推諉的狀況，故障定位存在困難，運維團隊要掌握多種技術棧，培訓成本以及技能要求頗高，除此之外，安全策略於不同平台之間的統一施行與審計同樣是一個重大難題，容易遺留下管理盲區。
實現互操作性常用哪些技術標準
於基礎設施層面而言，SNMP、/YANG模型堪稱網絡設備管理的根基所在， API以及在數據交換方面，已然成為現代應用集成的既定標準，它們依托HTTP協議得以存在，整體相對較為輕量，並且使用起來頗為容易，消息隊列像AMQP、MQTT則切實保障了異步通信的可靠性。
數據格式以及語義層面之中，XML跟JSON屬於主流的數據序列化格式，再進一步而言，類似OData這般的標准給出了統一的查詢以及數據操作方式，針對需要明確語義的領域，行業特定標準像HL7（醫療方面）、ACORD（保險方面）或者通用的語義網技術（例如RDF、OWL）能夠保證信息被準確理解。
如何選擇合適的多廠商解決方案
需從清晰的業務需求以及技術戰略著手進行選擇，要明確集成點的範圍，明確其性能要求，明確其安全性等級，還要明確未來的可擴展性需求，應優先考慮支持主流、成熟開放標準的解決方案，需避免採用某個廠商私有的、封閉的技術體系。
對於引入中立的集成平台或者中間件，像企業服務總線或者API管理平台，是有所建議的。它們能夠當作“翻譯官”以及“協調者”，從而降低點對點集成的複雜程度。在採購合同之中，互操作性要求、接口維護責任以及聯合技術支撐的具體條款，是應該明確寫進去的，以此通過法律形式保障自身權益。
未來互操作性技術發展趨勢是什麼
正推動互操作性朝著更微觀以及動態方向發展的，是雲原生和容器化技術。服務間通信借助邊車代理由服務網格統一展開管理，不同語言編寫、不同環境部署的服務得以實現無縫互聯。這為多廠商微服務的混合部署給予了強大支撐。
正在不斷發展的人工智能以及自動化運維，將會對互操作性管理產生深刻的影響，在很多方面帶來改變。其中，AIops工具能夠主動地去發現存在於跨系統之間的依賴關係，還能夠對因兼容性方面的問題而致使的性能瓶頸進行預測，甚至可以自動地生成適配的代碼或者配置。而區塊鏈技術呢，它為跨組織的可信數據交換提供了全新的思路，能夠確保在流轉過程當中是可以進行追溯的，並且是不可被篡改的。
開展實際推進多廠商環境整合的項目之際，您所碰到的最為棘手的互操作性究竟是哪一個層面的問題呢？是有關數據格式轉換方面的，是API版本管理這一領域的，還是故障排查以及權責界定這類情況的？歡迎於評論區去分享您的經歷與見解，要是覺著本文具備參考價值，請點贊並且分享給您的同事。
發佈留言