加载中…再谈能力中台(200407）
(2020-04-07 08:13:48)
标签：
能力中台 |
分类： 产品规划 |
对于能力中台，更加精确点的说法应该是能力聚会网关和开放平台，即我们谈的能力中台并不是单纯的讲你自有的能力为了更好的上下游协同，通过API接口对外进行能力开放，而是谈的我们构建一个聚合平台，聚合当前已有的能力接口，在聚合的基础上提供更好的服务。
能力中台构建的核心内容
能力中台是一个多租户的PaaS服务平台，能力中台面对的是最终的开发商和合作伙伴，而不是面对具体的C端用户和消费者。简单来说，一个完整的能力中台应该包括如下内容：
1. 底层的API网关引擎，消息中间件
2. 能力和API接口的快速接入平台
3. 能力的快速浏览，订购，计费，计量平台
4. 能力的运维管理和监控平台
首先你底层需要有一个能力聚合网关，这个网关可以是传统比较重的ESB服务总线，也可以是当前比较主流推荐的轻量API网关引擎。这个网关需要实现对API接口的最基本的管理能力，也就是我们经常说的服务代理，日志，安全，流量控制等。
快速接入平台
其次是API接口的快速接入平台，要构建一个大的生态就是需要不断的接入API接口服务能力，但是实际上在我们构建能力开放平台的时候，这个快速接入平台并不是必须的，也并不是一定要完全做到自服务。为什么这样说？因为简单的快速接入往往就很难真正的对接入的服务进行聚合，归类和重构等各种处理。
能力中台不是对能力简单接入和聚合，而是体现在对能力的重构和整合。
我们拿机票订购服务接口来举例说明，在底层你可能会接入携程，去哪，也可能接入类似国航，南航等航空公司直连接口。但是你最终提供给消费者的仅仅是一个机票订购接口，这个接口需求很简单，就是在我们需要的时间区间，能够给我最低的折扣和价格。那么这个接口的价值就体现出来了。
或者简单来说，通过接口的整合，自动化的帮助客户完成了一系列的比价操作，给出最优方案。客户并不需要知道你底层究竟对接了多少接口，包括客户在调用的时候如何去路由，客户只需要知道你能够提供最低的价格，最优质的服务即可。
综合以上描述可以看到，在前期构建能力中台的时候，对于第1和第2件事往往并不太需要用户感知和参与，而是属于我们开发团队内部的问题。
第3点，构建一个能力消费门户
对于能力消费门户，我们看到实际上和传统的电商平台很类似，也存在用户，产品，订单，结算等关键动作。但是由于我们的服务就是产品，因此对于这类产品本身不存在库存和配送的概念。
对于用户这里不是最终的消费者，而是租户ID，对于能力中台只需要跟踪到租户ID
对于我们开放出来的API服务接口，即是我们对外的产品
对于订单动作就是对应我们的服务订购，对于订单生效则对应我们的服务自动开通和授权
对于结算则对应到我们的服务计费能力
简单来所能力中台的面向消费者的服务门户，本身也是一个SaaS应用，但是售卖的是PaaS层的服务能力。这个SaaS应用本身消费者是开发商和合作伙伴，而不是最终的C端消费者。是最终的开发商基于我们的能力中台来构建面向最终消费者的各种SaaS应用。
你聚合的能力越多，那么能力中台的价值也就越大。
在我们谈企业中台或传统企业数字化转型的时候，经常会谈到连接的重要性，首先你不要闭塞而是要开放，通过开放才能够形成连接，通过连接产生价值。
而简单的连接只能产生一般的价值，只有对连接进一步整合加工聚合才能够形成更大的价值。
第4点，运维管理和监控平台
在消费者订购和使用你的服务后，你必须提供相应的运维管理功能。这里面既包括了我们传统意义上的运维，包括资源的使用，服务的运行情况，运行并发和调用量，调用失败率等。同时也包括了我们在订购服务后本身的一下其他运行统计分析功能，包括订购目录，订单，计费和结算等各个维度的统计信息。
消费方最终应该是可以通过这个门户很方面的对常见的指标量进行查询和统计，当然你也可以将这些监控功能，统计分析功能做成API接口，开发给消费者免费使用。
能力中台的关键-还是能力的聚合和整合
能力中台不是简单的API接口服务能力的接入，也不是简单额聚合，而对对接入的接口服务分门别类的进行整理和整合，屏蔽底层多接口适配的复杂性，形成更加粗粒度的对外服务能力接口。
当我们再进一步根据业务领域，行业或面向的不同消费者群的时候，我们可以进一步对能力中台进行细分，比如我们原来谈到过的商旅能力中台，旅游能力中台，福利能力中台，教育服务能力中台等。这些能力中台通过聚合后可以产生更大的价值，为消费者提供更加精确的增值服务能力。
喜欢
0
赠金笔