背景在最近的一个项目中，我有机会和团队一起完成了几个重要的工具选择。使正在构建的SaaS系统具备表单能力；使SaaS系统能够为运营商用户提供软电话功能；使不同角色的用户能够看到与自己相关的报告。在这几个选择过程中，有的在商业软件和商业软件之间选择，有的在商业软件和开源软件之间选择。回过头来看，每次评选的过程都不尽相同，但大致可以归纳为以下几个过程。为了方便读者理解下面的例子，对项目背景进行简单介绍。CD公司是一家为中小型家政服务企业提供ERP软件的公司，在行业内已有20多年的积累。目前，公司正在将老旧的基于C/S架构的传统ERP软件0转型为云端SaaS平台，通过20年行业最佳实践积累，不断为客户创造价值，吸引新的客户群体。清楚地定义问题在考虑其他因素之前，最重要的是清楚地了解问题本身。而在涉及工具选择等重大决策时，利益相关者希望采用的解决方案不仅能解决当前的问题，还能解决未来可能遇到的问题。那么如何在兼顾系统业务愿景的同时，确定需求的优先级就显得尤为重要。毕竟有人说过“定义明确的问题是解决了一半的问题”。这一步不是本文的重点，但会直接影响选择结果的正确性。在前面提到的报告的例子中。在与客户进行多轮访谈，分析竞争对手产品中的报表功能后，团队最终得出了一个共识需求——“客户希望为终端用户提供基于行业最佳实践的预定义报表功能，并能根据客户反馈提供简单的定制功能，允许用户从预设数据集中不同维度的业务数据中获得洞察力。”确定候选技术接下来您需要弄清楚如何获得备选方案的工具列表，那么该列表可以从哪里来？（1）来自客户客户通常有一些备选方案，这些备选方案可能是他们组织内已采用的技术，或者客户方技术人员懂的技术，这时候你只需要问客户，也有可能得到一些商业软件的官方支持，方便后续的研究工作。（2）从竞争对手那里，你可能有机会窥探竞争对手在该领域使用的技术。那么将该技术也列入列表可能是个好主意，特别是如果当前域是DDD中的通用域。（在DDD中，我们了解到通用领域是那些不需要有竞争优势的领域，所以与竞争对手打成平手是可以接受的）（3）每日积累如果你解决过（或参与解决过）类似的问题，那么您可能会了解一些相关技术。如果没有，别着急，类似的技术评选活动将是积累相关技术的绝佳机会。如果你想成为一名解决方案架构师，你可以在日常工作中使用5W1H不断积累各种工具和技术。在这里我将划线1H，因为成为一名架构师需要快速拓宽你的知识面并整合未知的未知数。将问题转化为已知的未知问题，丰富自己的工具箱。等到你需要更深入地挖掘。相信结合这些选项，您已经获得了进入下一步所需的工具列表。如果此时您还没有足够好的列表来开始研究，那么很可能该领域缺乏解决方案，团队可能最终需要自己发明轮子。在我们的报告工具示例中，客户组织在内部使用Tableau作为内部BI工具；团队之前已经接触过Jasperreport；该项目的云提供商AWSQuickSight提供了类似的BI功能；通过打听，我们了解了Redash；通过搜索，我们了解了Superset和Metabase。这时候，你可能已经准备好了各种纬度表，然后摩拳擦掌，准备开始对候选产品进行深入研究和比较。做出选择完成一个工具选择通常需要考虑的因素有很多，但大致可以分为：满足功能需求满足跨功能需求满足成本预算对齐虽然技术愿景只包括四个部分，但你想要快速分析一下做出决定并不容易。仅就跨功能需求而言，作者在《演进式架构》中列出了74条，并在其中添加了Evolvability（进化性）。综合考虑这些因素本身就是一个复杂的过程。从敏捷项目管理中我们了解到，当我们遇到问题时，首先要将其分解，然后想办法对其进行优先级排序，问题通常就会变得清晰起来。在我们的示例中，架构师根据影响程度或架构关注度对整理出的跨功能需求进行优先级排序，其中优先级较高的是：多租户、安全合规性、功能需求、互操作性（集成复杂性）、可扩展性、可维护性、技术愿景、收费模式、成本。然后我们根据信息获取和分析的难度做了一个简单的排名。例如，有些信息只能通过阅读少量文档或通过查询获得，有些信息需要阅读和分析大量文档才能判断候选工具之间的关系。优点和缺点。这样可以将研究工作缩小到一定范围，同时可以观察到研究活动会分布到下图中的四个象限。然后针对不同象限的因素，采取相应的策略进行研究。按照从最简单到最困难的顺序完成您的研究可以更有效地筛选替代方案。开源许可协议在选择报表工具的过程中，忽略了JasperReportServer的开源许可协议，导致选择过程重复，浪费了团队的精力。开源许可类型非常容易获取信息，无需过多分析即可得出结果，处于FastFail象限。如果能够准确识别出该象限内的因素，将大大提高选择效率。结合技术远景在进行工具选择时，需要结合组织的技术远景。比如我们希望系统的可移植性高，而不是锁定到某个云厂商，我们应该考虑是否是由于选择了我们的案例，我们最终选择了AmazonConnect作为客服电话集成方案，但是没有使用QuickSight作为报告/BI解决方案。同样是Amazon提供的服务，但是BI工具作为数据的下游，可能会导致在存储和数据管道技术上对AWS提供的其他服务有很大的依赖，使得未来可能的迁移更加困难，最终被锁定给供应商。电话系统作为客户接触点，通过API与后台系统解耦，更容易独立存在，供应商锁定风险更小。关于成本，这里不想过多展开，但涉及到商业软件的成本估算，通常需要客户大量介入。团队需要根据目前的总体规划，给出实施、整合和上线所需的资源分配和时间。工具提供商将提供实际价格以及后续维护和支持报价。如果是自建系统，需要对建设所需的软硬件成本和人力成本，以及后续的维护和支持成本进行粗略估算，为最终选型提供依据。写在最后工具选择是一个复杂的过程，需要大量的信息才能做出合适的选择。我们知道，任何技术决策都是权衡利弊的结果。记录最终选择的决策背景和利弊。即使以后发现这个选择不再合适，也可以清楚地追溯上一个决定的细节，为下一个决定提供更充分的依据。希望这篇文章能对你有所帮助，也希望世上没有选错工具。
