背景

在最近的項目上，我有機會和團隊完成了幾次重要的工具選型。它們分別是在讓在建的SaaS 系統具備表單能力;讓該SaaS 系統能夠為接線員用戶提供軟電話能力;讓用戶的不同角色能夠看到和自己相關的報表。在這幾次選型過程中，有些是在商業軟件和商業軟件之間做出選擇，有些是在商業軟件和開源軟件間做出選擇。回頭看來，每次選擇的過程都不盡相同，但大致可以總結為以下幾個過程。

為了方便讀者理解后面的例子，簡單介紹一下項目背景。CD公司是一家為中小型家政服務公司提供ERP軟件的公司，在行業內已經積累了20多年。目前該公司正在將其老舊的基于C/S 架構的傳統ERP軟件0改造為云上SaaS 平臺來持續為客戶創造價值，并通過其20年積累的行業最佳實踐來吸引新的客戶群體。

清晰定義問題

在考慮其他因素之前，最重要的是清晰地理解問題本身。而且當涉及到工具選型這類重大決策時，干系人都期望所采用的方案能解決的不僅是當前的問題，還需要能解決將來可能會遇到的問題。那么如何確定需求的優先級的同時兼顧系統的業務愿景就特別重要。畢竟有人說過 “A Problem Well-Defined is a Problem Half-Solved”。這一步不是本文的重點，但是會直接影響到選型結果的正確性。在前面提到的報表的例子中。團隊在和客戶進行了多輪訪談并對競爭對手產品中報表功能的分析后，最終獲得了理解一致的需求 —— “客戶希望根據行業最佳實踐為最終用戶提供預定義的報表功能，并能隨著客戶反饋提供簡單的自定義功能，讓用戶可以在預設的數據集內通過不同的維度從其業務數據中獲得洞見。”

確定候選技術

接下來你需要想方設法獲得一個備選方案的工具清單，那么清單能從哪來呢?

(1) 從客戶那里來

客戶通常會有一些備選方案，可能是已經在其組織內部被采用的技術，或者是客戶方的技術人員所了解的技術。這時你只需要詢問客戶即可，你很可能還可以獲得一些商用軟件的官方支持，這將為后面的調研工作提供便利。

(2) 從競爭對手那里來

可能你有機會可以窺探到競爭對手在該領域所使用的技術。那么不妨將該技術也放入列表中，特別是在當前領域處于DDD中的通用域時。(在DDD中我們了解到，通用域是那些不需要具備競爭優勢的領域，那么和競爭對手打個平手也是可以接受的)

(3) 日常的積累

如果你曾經解決過(或參與解決過)類似問題，那么可能會了解一些相關技術。如果沒有，也不用急，類似的技術選型活動將會是積累相關技術的絕佳機會。

如果你正開始嘗試解決方案架構師，那么可以使用5W1H 在日常工作中不斷積累各類工具和技術，這里我將1H strikethrough，是因為成為架構師需要快速擴寬自己的知識范圍，將未知的未知問題轉換為已知的未知問題，來豐富自己的工具箱。等到需要的時候再進一步深入了解。

相信綜合這些選項你已經獲得了可以進入到下一步的工具清單。如果到這里你都還沒有一個足夠你開始調研的清單，那么很可能該領域的解決方案匱乏，團隊可能最終會需要自己造輪子。

在我們報表工具的例子中，客戶組織內部使用了Tableau作為內部的BI工具;團隊之前接觸過Jasperreport;項目的云供應商AWS 上的QuickSight 提供了類似的BI 能力;通過詢問，我們了解到了Redash;通過搜索，我們了解到了Superset和 Metabase。

這個時候可能你已經準備好了各種緯度表，然后摩拳擦掌，準備開始針對候選產品進行深度調研和對比了。

做出選擇

通常完成一個工具選型需要考慮的因素很多，但大致可以分為：

• 滿足功能性需求
• 滿足跨功能性需求
• 滿足成本預算
• 對齊技術愿景

雖然只包含著四個部分，但是想要通過分析快速做出決策并不簡單，就單單從跨功能性需求而言，在《演進式架構》中作者就列舉了74項，并還向其中增加了Evolvability (可演進性)。綜合這些考量本身就是一個復雜的過程。

從敏捷項目管理中，我們學到遇到問題時要首先將其分解，再想方法排個優先級，問題通常就能變得清晰。在我們的例子中，架構師將整理出的跨功能需求按照其影響程度或架構的關注程度進行了優先級排序，其中處于較高優先級的有：多租戶，安全合規，功能性需求，互操作性(集成復雜度)，伸縮性，可維護性，技術愿景，收費模式，成本。接著我們再通過信息獲取和分析的難易程度進行了簡單的排列，例如，有些信息只需要閱讀少量文檔或者通過問詢便可得到，有些信息需要閱讀大量文檔并進行分析才能判斷候選工具間的優劣。這樣就能讓調研工作縮小到一定范圍，同時可以觀察到調研活動會分布到下圖的四個象限中。

那么針對不同象限中的因素遍可以采取對應的策略進行調研了。按照從易到難的順序完成調研工作可以更有效地篩選備選方案。

開源許可協議 在進行報表工具選型的過程中，由于忽略了JasperReport Server的開源許可協議，導致了在選型過程中的反復和團隊精力上的浪費。而開源許可類型是非常容易獲得的信息，并且不需要過多的分析就能就可以獲得結果，它處于Fast Fail象限。如果可以準確的識別出處于該象限中的因素將極大增加選型的效率。

結合技術愿景

在作出工具選型時需要結合組織的技術愿景，例如，如果我們希望系統可以具有高度的移植性，可以不被鎖定到某個云廠商，那么在技術選型時應該考慮是否由于選擇某項技術而增加對云廠商的依賴，在我們的例子中，最終我們選擇了Amazon Connect 作為客服電話集成方案，但是并沒有采用QuickSight作為報表/BI 方案。同是Amazon所提供的服務，但是BI工具作為數據的下游，可能會導致在存儲和數據管道技術上大量依賴于AWS提供的其他服務，使將來可能的遷移更加困難，最終鎖定到供應商。而電話系統作為客戶觸點，則更容易通過API的方式和后臺系統解耦而獨立存在，供應商鎖定的風險更小。

關于成本

關于成本這里不想展開太多，但是當涉及到商業軟件的成本的估算是通常需要客戶方的大量介入。團隊則需要根據目前大致方案給出實施，集成和上線所需要的資源配置和時間。工具的提供方則會提供實際價格及后續的維護和支持的報價。如果是自建系統，則需要為建設所需的軟硬件和人力資源成本以及后續的維護及支持的成本給出大致的估算來為最終的選型提供依據。

寫在最后

工具選型是一個復雜的過程，需要綜合很多信息才能做出合適的選擇。我們知道任何技術決策都是權衡利弊的結果。將決策上下文和最終選擇的Cons & Pros記錄下來，即便將來發現這個選擇不再合適的時候，也能清楚的追溯到先前決策的細節，會為下一步決策提供更加充分的依據。希望本文能幫助到你，也希望天下沒有錯誤的工具選型。