最近忙着给一个客户编制方案，主要是针对客户已经初具规模的信息化系统群，规划和建设了 业务中台和数据中台，以此而形成这个客户自己的企业中台。在交流和沟通的过程中，发现很多人（客户，竞争对手，甚至是自己人）对于中台的概念都存在比较明显的误区，特此简述一下。

       首先很多人认为了，我如果采用了微服务，比如什么Spring Cloud ，dubbo 框架来构建了自己的业务系统了，就可以称之为已经拥有了业务中台。理由很简单：你看，我所有的业务，不光是关键业务，而是所有业务，都下层到后面的服务，有这样的服务资源集合，难道不就是中台吗？对于数据中台也是同样，先上hadoop，把所有的数据库汇总，甚至再开发一个爬虫，去搞一些非结构化的数据，那么数据中台也形成了。

        按照我的理解，上面这些都不是中台，而是打着中台的幌子，做的其他的事，当然也有可能是承建人也没搞清楚什么中台，所以看什么热就套什么名字。中台的概念来自于阿里巴巴，最著名的中台事件应该是阿里在前两年提出的“大中台，小前台”的口号和概念。那么到底应该怎么解读中台呢？首先我们要理解中台不是一个产品，也不是一个技术，而是一个方法论。所以中台不是拘泥于具体形式的，既不能认为我引进了什么产品或技术就认为我已经有了中台了。那么这个方法论到底是解决一个什么问题了？我的理解是为了希望解决企业在信息化建设中能敏捷地，快速地，更少资源地构建一个业务应用这样一个愿景而提出的方法论。如果认同这个问题是中台提出的缘由，那么我们就可以得出符合中台概念的几个必要条件。

1，对于信息化建设一定需要能够沉淀信息化的资产。

2，对于基于中台的信息化建设必须快速。

3，对于基于中台的信息化建设必须足够降低门槛。

        基于上面这三个方面，我们可以引入相应的产品和系统建设，但有了这部分硬的东西，还只是实现了中台的基础。如果只是有了基础，而没有相应的组织保障和中台的文化保障，实际上中台也只是一个空壳子。因此在硬件的基础之上，必须同时针对组织架构和员工以及企业文化等进行相应的中台改造，只有这些软的东西的落地，才能形成一个真正有效的中台。

      当然每个企业软的东西都是不一样的，也不是一篇文章就能够解释清楚的，所以本文的落脚点还是关注硬的东西，也就是上面三点，应该有哪些具体的产品？

很久没有更新文章了，最近忙于给一个国企做顶规，所以工作很忙。

继续上面的话题，最近看过一篇文章，指出目前很多公司的敏捷开发其实都是错误的，因为很多的时候，只是强调了交付的敏捷，而忽略的了业务的敏捷，其实这个观点和中台的建设目的不谋而合，因为中台的诞生不仅仅只是为了交付的便捷，而是针对业务性敏捷蔡更加有意义。为什么这么说？下面我来例举个人经历的真实案例。

        某个二线城市，已经有了城市大脑的项目，而且该项目已经建设了好几年，而且这个城市大脑在业务归属上也属于该城市的数据局统管。这是业务背景之一。这两年笔者做为前期专家，接洽了该城市某一个业务局的业务系统，通过需求分析和趋势判断，发现该业务模块也需要有中台在背后支撑，那么在项目的论证阶段，就有两个观点。一个观点：城市已经建立了城市大脑项目，而且城市大脑下面已经有了相应的中台存在了，那么对于该委办局的业务中涉及到中台的部分，应该利用原有的系统行建设避免重复建设；而另一个观点是：业务应该由自己的独立中台，因为中台是服务于业务的，而不是业务为了中台，不能本末倒置，中台应该紧近业务方，而不是远远的独立于业务。

      本人的观点当时是第二个观点的支持者，为什么？其实就是前面论述的总结，中台不是为了中台而诞生的，还是为了业务，进一步明确就是为了业务的敏捷性而诞生的。如果脱离的业务，那么中台就是完全失去了其价值，起不到应有的作用。所以支撑业务的敏捷性就是中台最核心的价值。