背景

在最近的項(xiàng)目上，我有機(jī)會(huì)和團(tuán)隊(duì)完成了幾次重要的工具選型。它們分別是在讓在建的SaaS 系統(tǒng)具備表單能力;讓該SaaS 系統(tǒng)能夠?yàn)榻泳€員用戶提供軟電話能力;讓用戶的不同角色能夠看到和自己相關(guān)的報(bào)表。在這幾次選型過程中，有些是在商業(yè)軟件和商業(yè)軟件之間做出選擇，有些是在商業(yè)軟件和開源軟件間做出選擇?；仡^看來，每次選擇的過程都不盡相同，但大致可以總結(jié)為以下幾個(gè)過程。

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

清晰定義問題

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

確定候選技術(shù)

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

(1) 從客戶那里來

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

(2) 從競爭對手那里來

可能你有機(jī)會(huì)可以窺探到競爭對手在該領(lǐng)域所使用的技術(shù)。那么不妨將該技術(shù)也放入列表中，特別是在當(dāng)前領(lǐng)域處于DDD中的通用域時(shí)。(在DDD中我們了解到，通用域是那些不需要具備競爭優(yōu)勢的領(lǐng)域，那么和競爭對手打個(gè)平手也是可以接受的)

(3) 日常的積累

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

如果你正開始嘗試解決方案架構(gòu)師，那么可以使用5W1H 在日常工作中不斷積累各類工具和技術(shù)，這里我將1H strikethrough，是因?yàn)槌蔀榧軜?gòu)師需要快速擴(kuò)寬自己的知識(shí)范圍，將未知的未知問題轉(zhuǎn)換為已知的未知問題，來豐富自己的工具箱。等到需要的時(shí)候再進(jìn)一步深入了解。

相信綜合這些選項(xiàng)你已經(jīng)獲得了可以進(jìn)入到下一步的工具清單。如果到這里你都還沒有一個(gè)足夠你開始調(diào)研的清單，那么很可能該領(lǐng)域的解決方案匱乏，團(tuán)隊(duì)可能最終會(huì)需要自己造輪子。

在我們報(bào)表工具的例子中，客戶組織內(nèi)部使用了Tableau作為內(nèi)部的BI工具;團(tuán)隊(duì)之前接觸過Jasperreport;項(xiàng)目的云供應(yīng)商AWS 上的QuickSight 提供了類似的BI 能力;通過詢問，我們了解到了Redash;通過搜索，我們了解到了Superset和 Metabase。

這個(gè)時(shí)候可能你已經(jīng)準(zhǔn)備好了各種緯度表，然后摩拳擦掌，準(zhǔn)備開始針對候選產(chǎn)品進(jìn)行深度調(diào)研和對比了。

做出選擇

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

• 滿足功能性需求
• 滿足跨功能性需求
• 滿足成本預(yù)算
• 對齊技術(shù)愿景

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

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

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

開源許可協(xié)議 在進(jìn)行報(bào)表工具選型的過程中，由于忽略了JasperReport Server的開源許可協(xié)議，導(dǎo)致了在選型過程中的反復(fù)和團(tuán)隊(duì)精力上的浪費(fèi)。而開源許可類型是非常容易獲得的信息，并且不需要過多的分析就能就可以獲得結(jié)果，它處于Fast Fail象限。如果可以準(zhǔn)確的識(shí)別出處于該象限中的因素將極大增加選型的效率。

結(jié)合技術(shù)愿景

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

關(guān)于成本

關(guān)于成本這里不想展開太多，但是當(dāng)涉及到商業(yè)軟件的成本的估算是通常需要客戶方的大量介入。團(tuán)隊(duì)則需要根據(jù)目前大致方案給出實(shí)施，集成和上線所需要的資源配置和時(shí)間。工具的提供方則會(huì)提供實(shí)際價(jià)格及后續(xù)的維護(hù)和支持的報(bào)價(jià)。如果是自建系統(tǒng)，則需要為建設(shè)所需的軟硬件和人力資源成本以及后續(xù)的維護(hù)及支持的成本給出大致的估算來為最終的選型提供依據(jù)。

寫在最后

工具選型是一個(gè)復(fù)雜的過程，需要綜合很多信息才能做出合適的選擇。我們知道任何技術(shù)決策都是權(quán)衡利弊的結(jié)果。將決策上下文和最終選擇的Cons & Pros記錄下來，即便將來發(fā)現(xiàn)這個(gè)選擇不再合適的時(shí)候，也能清楚的追溯到先前決策的細(xì)節(jié)，會(huì)為下一步?jīng)Q策提供更加充分的依據(jù)。希望本文能幫助到你，也希望天下沒有錯(cuò)誤的工具選型。