如何才能做好数据中台的API运营？ by 傅一平

数据中台的建设第三年，我们开始推动数据中台的API开放，原因见《为什么是API而不是文件，对于数据中台的开放如此重要？by 傅一平》这篇文章，就是why，这篇文章再讲讲how，也就是如何做的，当然现在做的还很稚嫩和艰难，权当抛砖引玉。

1、业务驱动

数据团队的工作很多，虽然API服务开放很重要，但重要的并不一定紧急，不紧急的就没必要现在做，但正在发生的三个事情促使我们要做出一些改变，也就是业务的压力。

第一是对外变现规模日益扩大。

面对快速增加的客户，各条产品线需不停的申请数据开发资源满足需求，导致资源紧张，而且开发的模型质量很低，大量重复，没有什么沉淀价值。

结果就是，很多数据产品运营了几年渐成鸡肋，因为最核心的数据竞争力没了，毕竟数据产品是无法靠体验或运营来续命的。

第二是数据中台生态环境不好。

外人看我们的数据中台建得如火如荼，但实际却离产品很远，做的主要工作就是数据采集、数据开发和运维保障。

久疏战阵的数据中台模型大多退化，偶偶有一次产品方需要数据中台来提供模型支撑，但发现数据中台根本支撑不动，或者耗时很长，久而久之，产品方就失了耐心。

我在想，数据中台如果再没有一种强制的与业务协同的保障机制，数据中台就完了，跟20年前的数据仓库没啥区别。

第三是数据中台缺乏成就感。

数据中台成员要么做非常底层的模型工作，要么去做定制开发，相对商务和产品人员，获得感是不足的，即使考核倾斜也没啥用，因为很多人追求的是价值感。

自己去研读了很多公司的数据中台架构，包括阿里的OneService、史凯的公众号等等，最后得出结论：数据变现只要有了规模，API的开放和运营就不得不做，因为支撑不动。

2、组织保障

数据中台要建设好，运营至关重要，API运营职能放在哪个组织就很关键。

有一种选择是设立独立的中台运营组织，毕竟运营是非常专业的事情，但在大家对于中台的概念还没扯清的时候，设置独立的运营组织风险就很大，因为中台运营组织一旦独立，承上启下的工作会非常多，管理成本直线上升，比较保守的做法就是在现有的相关组织增加运营职能，让子弹先飞一会儿。

当时有三种选择，将API运营职能放在平台开发组，数仓模型组或是挖掘服务组。

平台研发组主要负责数据开发、治理、运维、开放等平台的建设和运营，数仓模型组主要负责基础模型、融合模型的建设和运营，挖掘服务组主要满足业务方提出的数据需求。

如果把API运营职能放在平台研发组，优势是API开放相关功能本身就是由该组负责开发的，建设的沟通成本会低很多，但劣势是离业务太远了。

数仓模型的运营失败告诉我们，API的运营组织必须具备在业务流程中强制卡位的能力，否则API就会做死。

因此唯一的选择就是挖掘服务组，其本来就直接面向业务提供数据支撑，进行API开放运营具有天然的优势。

围绕API运营我定出了三个组织的新职能：

挖掘服务组：负责API体系规划、API规范制定、API需求管理、API开发实现，API上架审核、API开放审核、API评估等

平台研发组：负责API服务的订阅，开放等功能的实现

数仓模型组：根据API服务的要求，持续优化仓库模型

挖掘服务组是API运营的中枢，其是API开放的第一推动力，其他组织基于专业能力做好API服务的支撑。

3、服务梳理

有了组织保障就可以干活了，第一件事就是要对游离在各类产品中的存量的API服务进行统一梳理，以下是一个示例。

基于梳理的结果，可以总结出当前API服务面临的五个挑战：

（1）服务能力透明度低：虽然现有服务数量较多，但由于分散在不同系统，没有形成统一服务开放目录，业务方和产品方对于服务的理解不够，导致调用量非常低，开放实现还是以文件为主

（2）服务开发冗余度高：当前服务均同业务需求紧耦合，以定制化开发实现为主，相似服务在多套系统承载，服务冗余度很高

（3）服务开通流程较长：现有服务开放流程是以需求管理的模式实现的，需求流转消耗时间长，服务开通平均周期1~2周，进一步降低了服务开放的可能性

（4）服务运行稳定性不足：各方产品实现服务的技术栈不同，服务资源的集约化水平不够，运维保障水平参差不齐

（5）服务运营缺少闭环：缺乏对于各类服务的常态化效果评估，无法进行迭代优化提升

4、服务目录

基于存量服务的梳理，需要设计出API服务目录体系，透明化是服务对外开放运营的基础，以下是一个服务目录的示例：

API服务与模型都属于可以开放的资产，数据交换目录和API服务目录构成了统一的数据资产目录，以下是一个示例。

5、流程控制

API的需求管理流程要增加运营组的审核环节，确保API服务发布的规范性，如下是一个流程示例：

API发布的时候填写的属性越丰富，可用性就越好，运营组审核的关键内容示例如下：

有一点要特别强调，API运营团队要在原有数据开放的流程环节进行控制，确保能用API实现的开放不采取文件的形式，这也是挖掘服务组的一个原生优势。

6、平台建设

我们打造了数据服务网关，用以收敛所有的服务，数据服务网关提供统一的数据目录，承载所有数据中台能力的发布和开放，包括数据服务目录、数据服务提供、数据服务保障、数据服务开发及数据服务运营等功能，如下图所示：

7、运营保障

关于API开放的认知、组织、体系、平台、流程都可以在短期内建立，但要让API开放能够形成生产力，还是要靠持续的运营。

运营的关键则在于数据驱动，即能从数据、业务、资源等维度对API服务进行常态化评估，形成从发现问题到解决问题的闭环，从而不断提升API服务的质量和规模，这也是API运营团队将面临的最大挑战。

治大国如烹小鲜，API开放只是数据中台的一个点，而数据中台也只是中台的一个点，但正是这个点，往往决定了数据中台的成败。

在我们建的平台到底是数据仓库还是数据中台的纠结中，也许API是唯一的救命稻草。

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！