中台概念出现之前，在信息化模式上，前端为支撑业务的应用端，后端为各个应用系统，为前端用户，如：客户、供应商、伙伴、社会，提供服务，但随着市场、用户需求、业务的多变性，底层僵硬的应用无法及时提供支撑。

企业需要一个强大的中间层为高频多变的业务提供支撑，为不同的受众用户提供多端访问渠道，基于此类需求“中台”概念出现，接着开始对企业客户、中间件厂商、数据平台厂商、甚至传统应用软件厂商都有较大的概念冲击。

恰逢此时，微服务技术和架构、容器化的生态、Devops概念和工具处于大发展的阶段，最后基于“大中台、小前台”的信息化建设模式开始流行。

二、银行数据架构体系

数据架构层面通过数据分类、分层部署等手段，从非功能性视角将数据合理布局。通过整体架构管控和设计，支持业务操作类和管理分析类应用（系统），满足业务发展及IT转型对数据的需求，架构的扩展性和适应性能够提升数据分析应用的及时性、灵活性和准确性。

那实际情况下各个银行的数据架构体系会有所不同，根据各行的业务发展、客户数据量、交易数据量、功能需求等会有不同的演变路径以及发展方向。

一般国有银行、股份制银行等全国性的银行业务较复杂，数据量也较多，数据架构也因此进化较快。常见的数据架构分区如下图所示：

三、零售行业中台架构

这是一张混合了技术和业务的中台逻辑架构示意图，前台应用部分我们将零售和消费品行业需要对接消费者的若干应用系统一一列举了出来，但是在中台架构下它们已经和传统的“应用系统”有了很大的差别，变得非常“轻量”。

前台跟着界面走，天生就稳定不了，总是有五花八门的数据请求，这是必然的事情。

后台应该主要负责数据存储，把不同形式和规模的数据以合适的方式整理好，大数据倒腾起来动静太大，要求有一定的稳定性。

如果前台的请求都要求后台直接做，那后台管的事就太多了。

后台是被许多前台共享的，如果直接向前台提供灵活数据服务，还可能导致各个前台之间的耦合程度变高，维护成本立即陡增。

同样的，把这些数据处理放在前台也不合适，一方面不太安全，另一方面，前台团队也是忙着让界面如何更好看使用更流畅，没太多工夫琢磨数据的事情。这样一个后台架构就能够相对平衡这一矛盾。

下面是实现实时数据中台的一种逻辑架构，方便你去理解，其实最关键的是实时模型那一层

我用下面这张图来概括中台发展的三个阶段，最终我们发现，对于那些已经有 ERP 系统的企业来讲，中台的建设本质就是利用微服务架构构建开放业务平台来替换闭源单体架构的 ERP 系统的过程。

中台是一种架构理念和方法。任何一种架构的方法，其本质不外乎，利用分、合、打散、重组等技术手段，对系统进行有序化重构，以达到减少系统“熵”的过程，使系统得以不断进化。

通过阿里云平台将技术中台进行部署，对集团内共享业务单元提供支撑，并最终对前台各业务线提供服务化能力输出。

如果仅仅是把所有的东西打包在一个“大后台”并不能真正解决IT的痛点，因为毕竟它是一个IT系统。IT系统要考虑的东西除了业务功能，更重要和更有价值的地方在于：

2007~2012年是“集成模式”概念被抛出率最高的年代，它有一个名字叫“SOA”，SOA就是那个时代的“全渠道中台”

数据中台的核心职责是高效地赋能数据前台为业务提供价值。要想理解数据中台先要理解数据前台，上文说到的搜索、推荐、BI 报表、数据大屏等都属于数据前台。

不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）