如来说：世界，即非世界，是名世界 - 《金刚经》
另一方面，也可以这么看，互联网企业一些概念的提炼抽象，让传统行业在把业务搬上互联网的过程中有了明确的思考框架和方法论。“中台”这个概念最大的存在价值，就是充当“指导思想”让传统企业有方法的采用一些技术架构和一些平台去建立“中间层”，形成从Web 2.0时代以来的互联网前台“店面”到本世纪初乃至上世纪90年代的历史遗留核心系统之间的价值链路的平滑过渡。
从技术上看，对于传统行业的企业而言，从信息化向数字化过渡的进程中，需要
- 解决“属于不同世代的异构技术系统与互联网入口连接”的问题
- 解决“信息化时代形成的信息孤岛、烟囱”问题
- 解决“经营管理与展业获客线上化”问题。
先把“台”字去掉 – 从中间层说起
在计算机世界，中间层就如一顿烧烤 - 没有什么事儿是一层间接不能解决的。如果有，那就是两层。
从中间层演变成中间“平台” – 就是这么朴素自然、顺理成章
2013年，是所谓互联网金融的元年，券商也开启“电商”、“互金”的线上展业之路。此时的集中交易系统，首次面临互联网链路上的并发要求、可用性、安全性挑战。以前的柜台系统，交易时间外停机，周末和交易所联调测试，维稳思维主导下，外部接入系统都不能随便直连。可是券商一旦开启互联网业务，那就是24x7打开门做生意：
- 高可用性问题出现。客户在非交易时间无法通过互联网柜台查询自己的持仓和账单、在周末居然看到自己账户被临时测试数据弄的面目全非而误以为出现系统问题等等，都是完全可能发生又完全不可以接受的，分分钟引起投诉，如何保障客户服务24x7可用？
- 高响应与高并发问题出现。电商部开始通过互联网销售爆款理财产品，并以秒杀方式进行促销，经常导致计算资源请求的突发性高峰。传统交易系统性能以交易委托笔数和并发交易事务数量的执行为衡量，却不适合响应海量用户在线交互频繁的、“会话型”（session）高并发请求。如何支持良好的用户体验、弹性响应海量用户访问、支持用户会话的高并发？
- 信息安全问题出现。只要在互联网上开了一个口子，你会发现自己的核心业务系统与互联网之间就会形成链路，无论是多么的间接。如何做好信息隔离和保护？
2015年，日益丰富的互联网业务的高度敏捷诉求与传统后台系统的维稳导向已经产生矛盾，朴素自然顺理成章的，出于对日益复杂的中间层的可运维性、可监控性的担心，我们考虑到了DevOps（距该概念诞生的8年后）。利用已经研究了两年的对容器化技术的知识积累，这一年我们落地了基于容器与容器编排技术（K8S、Rancher）构建的PaaS，现在中间层不再仅仅是一堆没有标准规范的服务，而是一个支持不可变基础设施（Immutable Infrastructure）、容器编排、数字化指标监控、服务治理，配备先进工具链的平台化中间层。
所以，回溯一下这个“朴素自然顺理成章”的过程，它是这样的：
- 我们要在互联网上开门做生意了。可是我们的技术系统是异构的（相对于互联网的分布式架构），是Web 1.0时代甚至是Client/Server时代的产物。怎么办？引入一个间接层，封装一下、转接一下，对接互联网吧
- 互联网上的业务越来越多，尤其是移动互联网出现、开启数字化时代，这间接层越搞越复杂，变成一大坨了。怎么办？需要建立规范、需要服务治理。这时候微服务、容器化技术应运而生，正好拿来用一用
- 可是光有微服务、容器化也不行啊，这些都是底层技术，它怎么解决数字化业务带来的敏捷化诉求、怎么解决信息孤岛问题实现横向连通呢？这个时候，我们就需要一个真正的技术平台，它能解决开发、测试、交付、上线一体化问题，才能有希望“敏捷”起来。此外还需要建立API管理机制、数据标准，让构建在平台上的新服务不会形成信息孤岛。DevOps来了
- 技术平台有了，逐渐发现它不仅仅是一个技术连接方案，它还需要让业务人员而不仅仅是技术人员介入。开始的时候，是让非技术人员在平台上设置业务参数，然后是让业务岗位在平台上设置互联网业务规则 – 这已经是在进行一些运营性质的工作，再发展下去是让经营管理者实时在线查看数据和调整运营策略… 越来越多的运营工具出行在平台上供业务部门使用，这个时候技术平台已经成为一个技术载体，在它的基础上承载了各种岗位角色的协作
何谓之“台”？
什么是平台？平台就是你搭戏台，让别人唱戏，再引来观众看戏。你或者向戏班收舞台租赁费或票房分成，或者向观众收门票，或者你牛的话两边收费。
优雅的技术平台，把“契约式设计”（Design by contract）、“松散耦合”的原则运用到极致，不仅分离出平台的稳定内核和插件化周边生态，更有甚者把内核本身实现成平台的第一个插件。平台本身只是一堆契约、协议、接口、框架，它貌似没有实际业务价值和运行能力，它是“空”的；但是平台又是抽象、提炼了各式其色的业务功能的共性与精髓，它又是“有”的。佛说：平台，即非平台，是名平台。“空有不二”！
技术平台的特点是：
- I don’t call you. You call me – 作为平台，我不会去调用你的接口，而是提供钩子（hook）、回调（callback）、事件订阅机制让你作为第三方进行调用。金融机构的平台是业务逻辑自洽的、边界清晰的，而IT则是平台提供者而不是系统集成商，应该在对业务抽象的基础上制定接口，实现“外挂”（谁实现则是另一个问题，也不见得需要一些所谓强势开发商软件商的配合）。而传统的系统集成思维缺乏对平台化的认识
- 插件化、生态化 – 微信和它的小程序、苹果手机和它的应用商店，就是典型的平台和插件关系，以及大量插件形成的开发生态、商业生态。这种插件化、生态化思路，同样适用于企业软件系统，就看你的技术架构是否设计得当
- 多种角色的参与：平台设计者与维护者、插件提供者、应用开发者、用户
- 建立在技术平台基础上（平台型的业务过去并不依赖于系统，没有技术支持的平台型业务模式一向存在，可是现在没有技术平台支撑的业务平台已经越来越难以想象）
- 连接多边、促进交互和交易，例如Uber，司机和乘客就是平台的利益双边。平台通过巧妙、合理的策略，通过同边网络效应、跨边网络效应，促使平台的“滚雪球”
“中台”概念的最大价值是作为方法论
“中台”这个概念，对促进本来不熟悉互联网技术生态的一些行业和机构主动去采用分布式、云原生、平台化的解决方案实现间接层、中间层，还是挺有价值的，作为指导思想也好、方法论也好、参考案例也好，能起到正面的启迪作用。虽然中台应该是自然而然产生的，不是削覆就履、也不是按图索骥拿着概念去凑架构凑方案，但是稍微刻意的“中间层平台化”的意识也值得称道。
中台，即非中台，是名中台
作为技术人的自我反省，我们经常追求一个技术或者技术方法论而忘记了它的目的，正如高僧为我们指明了月亮的位置而我们只执着于那根指着月亮的手指…
技术中台、业务中台、数据中台、AI中台… - 这些都是浮云而已。平台，不过是一堆的规范、标准、框架、规则、最佳实践，它本身没有做什么最具体的事情；可是它是对业务的抽象与精炼，是资源的匹配、交易的撮合、生态的连接，它又促成了一切。
中台 – “不忘初心、牢记使命”
云山雾罩之下，中台的“初心”，不过是用间接层解决一些不同历史时期的异构技术的连接问题，然后在这些间接层越来越复杂、越来越厚、越来越重要的时候，如何通过框架、规范、治理手段、工具链去把它们管理好，并且在互联网的倒逼之下，它必须与时俱进的支持云计算、支持敏捷，因为它是“稳态”世界异构系统对接“敏态”世界的转换器。
不敏捷、非云原生的方案，都不是真正的中台。
中台也不仅仅是一堆无人干预的中间件技术，它逐渐成为一个自动化半自动化、人为介入、多人协作的环境，越来越多的业务员工甚至外部客户发现自己通过各种工具在中台上展开日常工作，于是中台不再仅仅是技术解决方案，它承载了新的岗位与人员，甚至有应运而生的运营部门。它成为了企业数字化的枢纽 – 但在此之前它首先对组织结构、经营管理的转型产生了诉求。
- 组织：业务涉及到的人或者组织，每一项业务应该由多个人、多个角色来完成
- 目标：做某项业务的目的和价值，换言之，为什么做这项业务，做好这项业务要达到的目标是什么。
- 过程：过程就是业务过程，一项业务由多个过程组成
