备选架构评审避免过度设计：PM Suite案例

设计概念架构时，架构师脑中经常存在”为什么要这样设计？有没有其他设计方式？”这类问题——项目研发的早期阶段，不考虑任何可能的备选架构是危险、武断的，可能造成未来”架构大改”的巨大代价。为了更清晰地评审和对比多个备选概念架构方案，可以借助《概念架构设计备选方案评审表》这类工具，从”设计描述”的若干子项到”评审结论”，让对比过程一目了然。这个原则在PM Suite贯穿案例中有具体演示：面对”要设计一个组织级项目管理平台”这个任务，团队摆出了三个备选架构——备选架构1，一刀切采用B/S架构，简单便宜；备选架构2，C/S+B/S混合架构，照顾不同功能的特点；备选架构3，效仿IBM ALM基于Jazz平台搞多系统集成的”更先进”做法。如果直接选”最牛”的备选架构3，会怎样？团队专门分析了IBM ALM的概念架构，结论是：针对PM Suite的现实需求，照搬IBM ALM的概念架构属于”过度设计”——IBM ALM面对的是多个已有自主产品的整合场景，这和PM Suite自身作为单一产品、逐步孵化集成能力的现实处境并不匹配，直接照搬会引入远超实际需要的复杂度。这个案例揭示的教训和第8章”小系统与大系统的架构分水岭”呼应：备选架构对比评审的价值，不只在于挑出”技术上最先进”的那个选项，而在于能识别出哪个选项和自身真实的关键需求最匹配——对软件企业而言，这种系统性对比能避免”管他三七二十一就这么设计啦”造成的偏差，尽早确定合理的架构选型（而不是后期被动修改），还有利于统一团队上下对架构方案的认识；对个人设计能力培养而言，对比备选设计、评审设计优缺点，本身就是一种能拓宽思路、洞察设计”所以然”的训练方式。