*天参加了公司的中台服务规划会议，会议中评委提到了中台与SaaS的关系，沿着这个方向，我从产品和中台关系的角度对中台进行了一些思考，可能不准确。

只有产品是在SaaS生态的模式中被生产和使用的情况下，中台的价值才能更为凸显，分析如下：

我们公司是生产软件产品的，我们的关注点是产品本身（我称之为产品的静态期）。

*网（其他一些大型企业）是使用软件产品做信息化建设的，关注软件实施之后的使用（我称之为产品的动态期）。

中台的概念从这两个不同的产品状态视角去解读，可以对我们中台的规划和落地提供一些思路。

1）站在静态期的角度，中台是微服务的一个分类，在产品研发阶段，方便挑选而已。

我们公司建设很多后台微服务，中台微服务，形成某个阶段一个全的微服务池；

在现有的产品生产模式下，我们的产品事业部，从这个微服务池中挑选出个别的后台服务+个别的中台服务+自身的服务组合研发出新的产品；

我们交付的产品就是一组的微服务，是微服务池里的一个子集；

我们卖产品给客户，卖的就是这个子集，这个微服务子集永远只会被产品自身消费，等于说在产品被研发出来卖给客户之后，中台之于产品的意义就不明显；

从这个意义上讲，中台仅仅只是产品被拆分成微服务架构之后，对微服务的一个逻辑划分而已；

中台本质上还是微服务拆分的问题——我们先定了中台这个分类，然后找哪些微服务应该被划到这个分类里，如果没有，就把它们造出来。

2）站在动态期的角度，中台是通用业务能力的全集，是在产品运行期，被多方消费。

比如*网，它的整个信息化系统运作起来，所有池里面微服务全都是运行态，时刻提供服务被不同的业务消费；

这个运行起来的信息化系统，由一系列的微服务提供完整的能力集，形成一个“活”着的生态系统；

此刻的产品是围绕这个生态，组合这些线上的微服务进行生产和开发的，从而实现产品创新，解决新的业务问题；

我们面向*网的产品将变成自己的微服务+*网提供的中台微服务和后台微服务这种形态；

从这个意义上讲，中台不仅仅只是微服务的一个逻辑划分，更是一系列能直接在线上使用的微服务；

中台体现为抽象了各类业务通用能力并提供在线服务，被不同的应用系统/产品消费，隐含了一个企业内部SaaS生态的模式；

核心的问题是我们的产品如何使用这些中台服务进而融入这个SaaS生态——我们将产品在逻辑上划分出中台有利于平滑融入到*网的信息化生态。

3）我们卖产品给客户（单独购买产品的行业外客户），客户可能会关心是不是微服务架构，但不会关心这个产品是不是有个中台，中台在客户那里体现不出价值。

换句话说，除非我们连中台也卖，否则我们的中台服务可能大部分都停留在静态期，除了被自身的产品使用外没有其他的消费者。

一个静态的服务还能称之为服务吗？我们只是把组件变成了服务的形式而已，并用时髦的中台这一个概念做了归类。

4）*网能自然而然的去构建中台服务，并体现中台的价值，是因为国网经过多年的发展其信息化已经在内部产生了类似SaaS生态模式的雏形，在这种模式下可以把所有能直接面向终端产品且具有业务共性的服务（自建+厂商承建）统一管理起来，在生态内以线上的方式开放出去，直接面向内部和生态伙伴，方便使用。

5）中台的价值在于帮助企业在SaaS生态的模式下更好的支撑业务创新和产品研发。

如果我们自身的产品是SaaS模式的，那么建设中台价值就会凸显出来——中台的建设有利于支撑公司产品往SaaS方向的发展——运行期获取用户真实行为数据勾勒用户画像，认识和理解用户，找到痛点，利用中台灵活的组合能力和共性服务能力实现产品和业务创新——这是线下模式无法做到的。

而在非SaaS模式下，无论有无中台，只要微服务拆分合理——由前线服务人员和需求人员去获取用户需求，再将用户需求转成产品功能需求，然后从微服务池中挑选微服务加上一些新研发的微服务，一样能很好的支撑业务创新和产品研发。

6)总言之，建设中台的几个价值：

1>微服务很多，做个前、中、后的层次划分，方便管理和使用；

2> 以中台建设为切入点，推进产品的微服务改造工作；

3> 将产品在逻辑上划分出中台有利于平滑融入到*网的信息化生态；

4> 有利于支撑公司产品往SaaS方向的发展；

5> 具备帮助大型企业构建内部SaaS生态模式的能力；

后两者才是中台更大的舞台。