背景
在最近的项目上，我有机会和团队完成了几次重要的工具选型。它们分别是在让在建的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记录下来，即便将来发现这个选择不再合适的时候，也能清楚的追溯到先前决策的细节，会为下一步决策提供更加充分的依据。希望本文能帮助到你，也希望天下没有错误的工具选型。
