小系统与大系统的架构分水岭：拿来主义的危险

领域相同、但规模不同的软件系统，架构应该相同还是不同？每个领域都有”领导者”产品，其他厂商是否应该直接照搬领导者的产品架构？架构师小李设计”项目管理系统”时的困惑很有代表性：要不要支持集成？如何支持集成？他面前摆着三种候选架构——架构1，不支持集成的纯B/S Web应用；架构2，针对要集成的每个外部系统分别做定制开发（集成开发工作量随集成系统数量增加而增加）；架构3，模仿IBM Jazz平台，自建一个集成平台，通过平台间接集成、把集成开发工作量降到最低。这三种架构孰优孰劣，答案完全取决于关键需求，而关键需求又完全取决于”这是个什么样的系统”这个前提——书中通过三种场景对比揭示了这一点。场景一，小型PMIS（项目型ISV背景）：公司以做项目为主，项目规模不大，此时首先要确定的是”这个系统是部门级、企业级还是集团级应用”“需求范围是什么”“要做哪些需求的权衡取舍”，梳理出的关键需求会明显偏”轻量”。场景二，大型PM Suite（产品型ISV背景）：公司要把项目管理系统做成产品对外销售（对应书中反复使用的PM Suite贯穿案例），梳理出的关键需求会显著不同，集成、二次开发这类需求的权重会大幅提高。场景三，多个自主产品组成的ALM方案（如IBM ALM产品线）：面对的是横跨多个已有自主产品的整合场景，关键需求的构成又完全是另一番景象，集成平台化的架构（如架构3）在这种场景下才真正具备合理性。小李完成这套”对比式”分析后得出的结论是：架构设计只有合适，没有最好；无视条件差异照抄架构，是危险的——领导者产品的架构之所以那样设计，是因为它面对的关键需求是那样的，把这套架构原样搬到关键需求完全不同的系统上，等于是在用别人的答案去解别人的题，而不是自己的题。

结构图：

flowchart TD
    A["同一领域：项目管理系统"] --> B["场景1：小型PMIS\n（项目型ISV背景）"]
    A --> C["场景2：大型PM Suite\n（产品型ISV背景）"]
    A --> D["场景3：多自主产品ALM方案\n（如IBM）"]
    B -->|"关键需求偏轻量\n范围/权衡取舍为主"| E["架构1：不支持集成的\n纯B/S应用可能已够用"]
    C -->|"关键需求侧重集成/二次开发"| F["架构2：针对性定制集成开发"]
    D -->|"关键需求侧重多产品整合"| G["架构3：自建集成平台\n（类IBM Jazz）"]