一、引言
现在，中台这个概念比较火。比如阿里首先提出了中台的概念，把信息系统的一些通用的模块，系统，统一到一起，并对组织进行了相对应的调整，形成中台，支持阿里的各大业务板块。很多大大小小的公司，包括it公司，制造业公司，也提出了自己的中台战略。似乎现在不提中台，就跟不上时代的步伐，就会错过下一个风口似的。
那到底什么是中台，他解决什么问题，它在企业的it架构中，处于什么位置，和传统的前台、后台的关系；
在这个概念大潮中，我们可以做什么？
二、中台解决的问题
为了能把这个概念高清楚，我们缩小下范围，仅局限于IT架构中的中台，而不考虑技术中台，组织中台。这些中台我们有机会再讲。
我们先来看中台要解决的问题。我没有认真思考我所在的公司在业务应用层面，哪些问题需要用“中台”来解决，因为我们公司的系统很多单一，也很简单。
通过查资料，有几个我比较认同的问题：
（1）已有的系统比较分散，不同的服务，不同的能力，分散在不同的“后台系统”中。而前台需要将这些数据，能力整合起来，一并展示给最终用户。存在整合难度。现状是，用户不得不登录多个系统，查询所要的数据，或者使用不同的功能，已达成自己的目的，完成自己的工作。
（2）前台系统面向最终用户，消费者，二最终用户和消费者的需求是多变的，而适应这些多变的系统，现在的后台系统已经不能满足要求，除了第一个原因之外，还一个经常被提到的原因是：后台系统求稳，无法适应前台的多变，需要一个中介，一个转换器进行适配，这个适配器就是总台。
（虽然我把这个理由放在里， 但是我没有非常透彻地理解这个问题，因为没有深刻的体会。只是从宏观上、很高的抽象层面上觉得有一定的道理）
所以，我比较认同第一个问题。第一个问题很容易理解，确实需要采取一定的方法来解决。
三、中台做什么
但是采取什么方法来解决这个问题呢？我理解，方法就是对这些服务进一步包装整合，形成一些it资产，这些it资产的集合，我理解为中台，将这些IT资产按照功能，业务范围分成几块，每块就可以称之为xx能力中心。
其实从技术上讲，我认为这中台的地位和传统的后台没有什么区别。但是既然要把这个概念抽象出来，说出来给大家伙儿听，概念先行，总要给出个概念，下个定义，这样才比较利于沟通交流。
再一个IT界中一个解决问题的很重要的手段就是分层，分层是大事化小，分而治之的方法论。系统太复杂了，分层简化，双方不匹配了， 加个适配层。要解决这个问题，也可以用分层这个方法，那么这个层，既然分层，总要有个高低前后，前台第一层，后台在后边，这新抽象的一层放在前台和后台中间，给他个名字，叫在中台，容易让人理解， 前中后。这样把层次图画出来，也挺好看。
所以我把中台，理解为服务管理中心。包括服务包装，服务注册和发现，服务调度，负载均衡，服务编排，服务监控等等。也称为能力中心。
（1）服务包装是什么意思？
前面提到，要解决的第一个问题是，服务能力分散的问题，不标准的问题。所谓不标准，就是调用的协议多样，有的采用 websevice，有的 restful，有的rpc，有的通过数据库直连，有的是ftp等等。因此有必要，统一成同一种协议，或者少数几种协议，并规范参数格式，参数类型，做好参数类型转换，和返回数据的格式转换。这就是服务包装的内涵。
（2）服务编排呢？
中台最终是给前台服务的，通过服务调用的方式，接收前台的指令，执行后台的业务逻辑，并将结果返回给前台。前面有说过，前台需求多变，中台如何满足多变的需求呢，就要有服务编排的能力，换句话说，一个服务满足不了前台的一次调用需求，那就把多个服务组合起来给前台用。比如一个服务提供供应商的应收，一个服务提供供应商的应付。要拿到供应商的这俩个数据，一个选择是调用两次，再一个选择是，把这两个服务以适当的方式组合起来，前台一次调用就ok了。将服务组合起来的过程和方法，就是服务编排。服务编排要处理什么？统一协议，参数转换和映射，参数格式化，返回数据合并和格式化。甚至复杂一点的，还要处理事务，增加加工逻辑。其他的服务注册和发现，负载均衡，监控等等，是服务管理的标准功能，目前市面上很多开源的服务管理平台，都具备这些功能。
三、前中后台的关系
（1）中台和前台的关系
前面也提到了，前台服务于终端用户。终端用户可以是消费者，内部的业务人员，第三方系统。前台一般通过一定的额格式展示数据，提供ui，输入数据，向中台发出服务请求。中台接收请求后，调用后台进行运算，并将结果反馈个前台。因此中台服务于前台，是前后台的连接器。
（2）中台和后台的关系
中台往前服务于前台，往后呢？
在典型的三层架构中，前台是ui，中间层（那是不称为中台）是业务逻辑，第三层是数据存储层。如果按照现在中台的概念进来后，这里的中间层应该是后台了，中台是在前台ui 和中间层之间加了一层。根据这个说法讲，后台是传统的业务系统的后台，比如erp的后台，crm的后台，wms的后台，中台接收前台的服务请求后，经过复杂均衡，参数转换等一些列处理后，调用这些传统应用的后台程序（这些后台程序可能也会使用服务的方式对外提供），也有可能是直接方位后台数据库（第四层），这样，传统应用的后台程序和数据库系统，都称之为后台。
在这种结构中，传统应用的后台程序，有2个角色，一个是还是给自己的前台提供服务，比如sap后台程序会sap gui 提供调用，另一个是为“中台”提供服务调用（假设公司的it架构，通过中台对其服务进行了整合和包装）。这样sap系统既是中台，也是后台。我觉得这就是中台和传统应用的关系。
（3）前台
说外了中台和后台，我们在聊聊前台。
上面说了额，sap gui 也是前台系统，因为他的用户就是企业诶不的业务人员，他提供了标准的ui，让用户录入数据，发出请求，并最终以一定的格式将后台返回的数据展示给用户。这是传统的后台，他仅仅局限于单一的系统，处理单一系统的数据。
一旦引入中台并实施后，前台就不是传统的小前台了，而是“大前台”，大一方面是他可以通过中台系统，请求多个后台系统的服务，拿到多个后台系统的数据，再一个是，通过流程整合功能，将零散在多个传统系统的业务，活动，集成到一个大的业务流程中，将多个系统协同起来。这样，从企业宏观来看，就不分什么系统了，财务系统，合同系统，报下系统等等，对终端用户来看，就是个门户，portal。要做什么事情，只要登录到这个门户就可以了，门户根据配置，用户岗位，权限，展示不同的内容，不同的界面。在一个前台上操作，所引起的服务请求，通过中台，分发到不同的业务系统中，最终汇集到同一个屏幕上，同一个门户上。这就打破了传统新的信息孤岛，数据孤岛。这是提出中台的概念的终极目标。
四、结语
从以上分析，我认为，中台不是新的事务，中台的事情，我们一直在做，只不过是分散在不同的业务系统中在做，没有继承起来，统一管理起来而已。
以上纯从技术上分析，中台并不是什么新鲜的东西，是还是那么多事，只是个名字而已。当然为了迎合或者配合市场或者客户提出的大中台战略，我们当然可以提中台概念。以上是我对中台的认识，同时回答了以上的几个问题。