架构C本文是全系列中第4 / 7篇：白话中台系列
前两天无意中看到了一篇文章 阿里的中台战略其实是个伪命题 ，看完很有启发，所以写篇读后感，说说自己的思考：
当人们谈论中台的时候，都是从自己的视角。
我见过CIO的视角，互联网产品经理的视角，中台开发人员的视角，每个角色看待中台的视角都不同。
但就像我在 白话中台战略-3：中台的定义 里提到的，中台是“企业级”的，自然也就是一个企业层面的架构问题（包含了业务，架构与组织），本质上也是一个EA（Enterprise Architecture）的问题，但从EA视角（也是我自己的原生视角）出发看中台的文章比较少，这篇算是一篇。
传统EA讲的就是架构方法，常用的包括TOGAFZeMACH。也就是我们熟悉常见的“几大架构”（业务架构，应用架构，技术架构，数据架构，组织架构……），各大咨询公司的企业战略规划咨询也都差不多使用类似的方法，中台无非是在企业架构规划中加入了平台的因素而已。
第一次看这篇文章的时候，觉得作者并没有完全理解中台，人家阿里明明讲的是“大中台，小前台”，怎么文章中又说阿里是“大前台、小中台、无后台”呢？第三张图（图3集团性企业业务架构与阿里巴巴业务架构对比）也不对，哪有按照用户触点-供应链-生产来划分前中后台的呢（不是应该按照抽象来划分么？）。
又看了两遍之后，方恍然大悟，不但觉得作者说的也没有错，反而很受启发性。顺带还解决了自己的一些疑问，比如为什么传统企业就是理解不了互联网企业业务中台的概念？
思考之后觉得，问题就出现在这“业务”二字上！（再一次印证了DDD统一语言的重要性）。
在传统的EA体系里，“业务”是有明确的含义的，就是文中图2所描述的业务架构，本文中对于中台的描述也都是在传统EA框架的“业务架构”下描述的。
怎么理解业务架构呢？你可以把整个社会想象成一家大的企业，那简单讲业务无非就是生产各种产品或服务（业务后台），然后通过供应链（业务中台），最终通过用户交互界面（业务前台）送达客户手中。
前者就是常说的供给侧，后者就是消费侧。
我们常说的“业务梳理”，也是在梳理类似的端到端流程。从这个角度就可以理解为什么作者说阿里在业务架构上是个“大前台、小中台、无后台”了，因为阿里确实重点不是产品的生产制造和供应链，只是在不断创（抢）造（占）各种各样的前台场景，或者说大部分互联网企业都是类似的，都是在消费互联网这波浪潮里抢占用户的前台场景（流量）而已。
而我们常说的“业务中台”，其实更多指的只是IT架构中的应用架构中的应用中台（图 2企业信息化架构体系对比）。
好，搞清楚了业务架构与IT架构的中台概念，对我们有什么用呢？用处可大了！
之前互联网企业看不懂传统企业（所以就冠了个“传统”，予以区分，本文仍使用，但不带感情色彩，只为了区分），传统企业学不会互联网企业。
互联网企业经常说中台各种好处，而且做起来感觉思路也非常清晰（无非就是……无非就是……），但是为什么传统企业怎么也搞不清中台该怎么搞呢？是不是这就是“传统”与“新兴”的实力差距呢？答案是否定的。
问题就出在“业务架构”的差异上。
在EA的体系里，应用架构不能脱离业务架构，必须由业务架构驱动，业务架构决定了应用架构（也就是我们常挂在嘴边的：业务驱动）。应用架构可以学，但前提是业务架构基本相同的前提下，但互联网企业和传统企业的业务架构是截然不同的，两种类型的企业在整个社会这个大的“业务架构”上处于不同的节点，解决的是不同的问题，按照作者说的甚至是互补的，业务架构不同，自然应用架构就不能直接照搬，照搬就会出问题。
在“业务架构”（注意是业务架构）上，互联网企业往往面对的问题是各种各样的类似的不同场景的前台（消费侧）问题，所以互联网要解决的更多是基于自己的业务模式快速创新应用场景（抢地盘）的问题。典型的像阿里要出淘宝，天猫，飞猪，背后的业务模式都是卖东西；滴滴要做出租车，专车，顺风车，豪华车，背后的业务模式也都是运东西。而业务中台作为业务模式能力复用的“锤子”，自然适合这些“钉子”。
但是回到传统企业，尤其是大型集团型，主要关注的问题不像（或还不到）互联网企业是业务“横向”的快速扩张，更多还是在供应链、生产制造这类偏供给侧的整合拉通上。追求的也还是全链路全周期的管理和打通，对比与互联网的“横向”业务扩展，传统大型集团企业更讲究“纵向”的业务打通。
所以经常会出现这种现象，一家企业看互联网建业务中台，自己也要建业务中台，结果我们梳理来梳理去，就一条主要业务线，却异常的复杂，这种情况下怎么建业务中台？或是再深一步想，希望通过建设业务中台来解决什么问题？往往客户的回答都是业务梳理，数据打通，业务联动，你看还是纵向上的打通。
这就能解释为什么互联网企业做的业务中台都更多承载了“业务模式”，而传统企业做业务中台更多承载的就是“数据”而已（形式虽然都是一个个微服务）。因为一个强调横向业务模式的复用，一个强调的是纵向数据的打通和复用，本质上还是当前阶段的“业务架构”不同。
所以业务中台的建设不能脱离开企业的业务，不能脱离开要解决的问题，要先从业务架构的梳理开始，从痛点出发，不要一头扎进IT架构里，没搞清楚业务就直接照搬别人家的“业务中台”，结果往往会非常的痛苦。
