顶尖SaaS平台产品的技术架构剖析

最近读了某业内圈中大佬对企业服务管理领域顶尖的SaaS平台产品ServiceNow的详细剖析：《剖析ServiceNow | 中国企业软件公司如何做到年营收100亿美元，市值2000亿美元》，当看到ServiceNow最新的产品架构，让笔者想起了另外一个CRM领域顶尖公司SalesForce的产品架构，颇有一种“成功的产品都是相似的,失败的产品各有各的问题”的感觉（这里套用了托尔斯泰老爷子的名言“幸福的家庭都是相似的,不幸的家庭各有各的不幸”）。

（一）ServiceNow

    据业界报道：ServiceNow 的创始团队开始时，设想构建一个在企业内创建工作流的通用平台，他们开发了平台并进入市场，但最初由于价值主张模糊而难以获得吸引力。为了获得商业吸引力，他们围绕 IT 服务管理（ITSM）构建了第一个应用，利用了他们在该市场的深刻理解。后来，随着客户开始将ServiceNow的产品用于其最初范围之外的用途，公司重新引入了其最初的愿景，使企业能够创建满足其特定需求的定制化工作流。

    也就是说ServiceNow 从一开始的产品定义是个平台型产品，因为平台型产品过于抽象而离客户实际的业务场景太远，需要通过在平台上构建服务于某个具体业务场景的应用，来快速匹配到目标客户完成PMF，最后因为服务到更多的客户场景而重新回归到最初平台产品的愿景。这个“由技术平台，到构建核心场景应用，再到基于已有客户群衍生更多场景需求，最后再回归平台模式”的路径可以作为所有规划“技术型平台产品”的参考路径，在笔者亲身实践的一个制造数字化应用开发平台产品，也基于类似的路径思路成功跑通了商业模式。

    ServiceNow从产品架构上看，从下往上可以分为：核心技术能力引擎层，基于工作流的几个核心的应用产品层，以及最上层是将应用产品垂直化到某行业的解决方案层。

    其中最关键的是平台核心引擎层：通过这层实现整个产品体系基于单一架构、单一代码库和单一数据模型构建，在数据模型上可分层扩展：基于基础模型层之上扩展行业数据模型层。这种基础层面的统一架构在调整与扩展应用功能或者开发新应用时，需要更少的开发资源，很容易吸引更多的客户或者行业伙伴工程师在平台上开发更多出色的行业应用解决方案。    

    基于如此出色的平台化产品架构，ServiceNow已是一家真正的平台公司：拥有 4 款主要产品（ITSM、ITOM、客户服务和人力资源），构建成一个由 2900 个合作伙伴组成的庞大网络，这些合作伙伴转售和实施其平台，从而实现大规模可持续增长，目前年度经常性收入（ARR）超 100 亿美元。

（二）SalesForces

    SalesForce从产品架构上看，核心的是Force.com应用开发平台(aPaaS)，在aPaaS平台之上构建CRM等几款自有的核心应用产品，以及生态伙伴构建的三方应用产品。

    不难发现，无论是在产品的技术架构（整个应用体系也是基于平台的单一架构、单一代码库和单一数据模型来构建），还是产品的商业化成长路径，ServiceNow与SalesForce两家平台型产品公司都颇为类似，即产品体系是“一个平台+ 1-3个自建的核心应用产品+ N个不断增长的生态应用解决方案”，在商业打法上是基于1个核心场景应用产品作为尖刀攻破“利基市场”，积累一定客户规模后自然延伸到2-3个上下游场景形成交叉销售，并且同步基于平台的应用开发能力发展与构建实施/转售等合作类型的生态伙伴网络，最终实现大规模可持续性增长。

    关于SalesForce的产品架构的详细剖析，有兴趣的读者可以阅读笔者前期文章：

    SaaS洞察：SalesForce应用架构分析

（三）亲身实践

    笔者亲身实践了一个专门面向中小型企业生产制造场景的数字工厂aPaaS平台产品，最初是出于满足制造环节的数字化运营管理在不同行业不同工艺流程存在的较大的差异化需求，在产品架构上选择在平台层构建与提供核心的数据和流程建模引擎能力，然后将搭建制造数字化应用的最后一公里交给行业生态伙伴或者企业客户，即在平台核心引擎层之上构建基础应用模型和行业应用模型，实现基于平台生成的所有应用体系也是基于单一架构、单一代码库和单一数据模型构建，从而为行业伙伴高效快速开发与组合出色的应用解决方案提供强大技术能力支撑。

    在商业打法上与前面两家国外的产品前辈也基本类似，区别在于早期的1-3个主打的应用产品，选择绑定在目标行业具备相对较强行业经验的核心生态伙伴来联合共建，以及联合运营推广。

    关于此产品架构的详细剖析，有兴趣的读者可以阅读笔者前期文章：

    中小企业建设数字化工厂，选择集成还是重构？

（四）总结

    对于SaaS产品来说，一个好的平台化的产品架构能让它覆盖更多行业的客户，也能促使它“自我进化”的更快，生命周期走的更长远。这也是前些年SaaS产业圈里争论“SaaS公司要不要做PaaS”的重要原因之一，这几年在市场上能跑通并生存下来的SaaS公司，用结果也证明了虽然做PaaS层会给SaaS公司带来比较大的前期研发成本，但是做成了就能帮助SaaS产品构建一定的“技术护城河”，同时基于PaaS层框架的良好扩展与自我进化能力，能实现把更多行业定制化的功能需求从产品的“核心层”有效剥离，“上浮”到“业务数据/流程层”，在交付项目时基于产品核心层能力的业务建模与配置性工作来调整与扩展实现客户需求，而这些配置性工作可以发展与转移给做行业交付的集成商等类型的服务伙伴，从而能让SaaS公司更专注于产品本身核心能力的打磨，避免过多陷入“项目式”的交付工作，最终形成“SaaS产品公司+交付伙伴”的良性分工，各自做各自最擅长的事情，各赚各的钱，这个对于SaaS公司构建行业性生态网络和促进产品走向“平台化阶段”至关重要。

    战场上的战斗无法弥补战术的失败，战术无法纠正战略的失误，这是失败的本质。平台型产品的业务是否能取得成功最终需要依赖于市场客户买单，而最初的产品架构设计与商业路径规划则至关重要，容不得“糊弄”。