继本系列前一篇文章对中台架构作了整体性的介绍之后，本文我们将继续从组织架构的角度上展开对中台的介绍，这是中台建设中不得不谈论的话题，虽然在任何企业里这都是一个非常敏感的话题，但对中台建设来说，这一问题必须要思考清楚。另外，本文的后半部分，我们会冷静地分析一下中台所“不能”的地方，避免读者对中台产生错误的不切实际的理解与期望。本文核心观点援引自作者所著的《大数据平台架构与原型实现：数据中台建设实战》一书，全书对数据中台的理念、架构和具体实现做了详细论述。
3 中台的组织架构
组织架构无疑是一个重大而敏感的问题，但确实是在建设中台过程中不得不面对的，一家企业如果想要在中台化转型上取得成功，就必须直面这个问题。我们前面探讨烟囱式的生态系统和SOA 架构时提到的诸多问题和挑战都与组织分工、团队协作有关，这些问题的根源都是组织架构。在过去的烟囱式生态系统下，每一个应用系统都由一个专职的团队负责，团队的核心任务与首要KPI 是确保本系统持续稳定地运行，这使得每一个团队都必然地从本应用系统的立场和角度看待和思考问题。
然而企业的业务流程是一个有机的整体，这在客观上必然要求各个应用系统和运维团队紧密协作，这时候组织架构的问题就会显现出来。过去不管是点对点式的集成还是SOA 改造，当它们作为一个项目交付之后，随着时间的推移，在集成新系统时又会变得像以前一样举步维艰，究其原因是并没有一个长期有效的组织架构在持续地推动系统融合。
中台架构的提出对企业的组织架构产生了巨大的影响，有了与中台相适应的组织架构，企业才能很好地完成中台建设并从中受益。中台架构有一很鲜明的特点，那就是它彻底破除了应用系统的边界，从企业的全业务领域着手，切分出业务中心，每一个业务中心所支撑的不是一个孤立的应用系统，而是企业在该领域的全部核心业务，所以每一个业务中心都需要非常专业的团队来负责，团队必须对这部分业务非常了解，而且必须站在企业的全局去支撑和把控这一业务领域。
我们来看一下阿里巴巴共享业务事业部的故事。2003 年阿里巴巴首先成立了淘宝事业部，伴随着B2C 业务的兴起，2008 年从淘宝团队中拆分出了天猫事业部，但是这两大事业部依靠的都是淘宝的技术团队，这样带来的问题是技术团队会优先响应来自淘宝的业务需求，影响了天猫事业部的发展。另外一个问题也是很典型的，那就是这两个电商平台是完全独立的，都有各自的商品、交易、支付等功能模块，可见阿里巴巴也曾经走过烟囱架构的老路。
为了解决这个问题，阿里巴巴开始了第一次大胆的尝试，在2009 年成立了“共享业务事业部”，主要由淘宝的技术团队构成，但是这个事业部与淘宝和天猫两个事业部是平级的，这一架构调整的用意很明确，阿里巴巴希望通过共享业务事业部来梳理和沉淀两个电商平台的业务，抽离出公共的部分，避免重复建设。但事情的发展却出乎阿里巴巴的预料，由于淘宝和天猫作为核心业务部门，显然拥有更大的主导权，共享业务事业部发展缓慢。
这一状况的转变源自聚划算的出现，聚划算作为阿里巴巴的团购业务事业部，在成立之初拥有强大的引流能力，淘宝和天猫的产品一旦进入聚划算，销售额就会暴增，因此两大事业部都迫切地想要将自己的平台和聚划算对接。此时阿里巴巴做出了一个重要决定，其他业务平台如果要和聚划算平台对接，必须通过共享业务事业部，正是这一举措让共享业务事业部找到了发展的抓手，进而将自己提升到与其他业务事业部同等的公平位置上。
从阿里巴巴共享业务事业部的故事中我们可以看到，组织架构对于中台战略的有效实施至关重要，在整个组织架构中，企业需要仔细梳理和界定关键部门的职责及相关部门之间的关系。
中台事业部
由于中台的定位在于支持企业的共享业务，所以必须要由一个专职的实体部门对其负责，而不能是一个虚拟组织，这个部门必须要被赋予足够大的权限，过去分散于多个业务部门和系统运维团队的部分职责需要拆分并重组到中台部门，由中台统一管理和负责。
中台各业务中心
中台各业务中心的人员一般来自该中心对应的过去某个核心业务系统，如用户中心团队的骨干应该来自原CRM 系统，被划归到中台的个人和团队将面临一次内部转型，他们过去只对单一业务系统负责，而现在需要站在企业的全局来看待和梳理相关业务，这需要中台团队在广度上要能触达各个业务渠道的前端需求，同时要在深度上不断地挖掘和提炼共享业务，并最终落地到中台服务上。中台各个业务中心的职责划分必须清晰明确，特别是在一些关联性较强的业务领域上一定要做好切割，将各方的职责界定清楚。
中台与前台团队的关系
前台团队直接面向市场和终端用户，从这个角度来看前台团队扮演着中台用户的角色。一方面，前台团队经常会提出各种各样的需求，有些需求可以在团队内部消化，有些则需要中台团队的支持，这时候前台团队就会对中台团队产生依赖；另一方面，对于中台团队来说，也非常需要来自前台的业务“滋养”。因此两个团队应该维持紧密的合作关系，这对于能否成功建立中台架构是非常关键的，如果两个团队之间在合作上出现问题就会导致两种可能的后果：
- 如果前台团队强势，就会组织力量在自己可控的范围内实现自己的需求，导致一些本该出现在中台上的共享服务被放在了某个前端应用上，这在客观上弱化了中台的“威力”，同时会导致其他前台应用重复建设该功能，这是在“开倒车”；
- 如果前台团队弱势，就会放弃或推迟新的构想和尝试，这会让企业逐渐失去抓住市场机遇的能力。
4 中台不是“银弹”
前面花了大量的篇幅讨论了中台的各种优势，但是我们也必须理性客观地看待它，就像讨论以往出现过的任何新技术和新理论一样，我们可以看重或推崇它们的优势，但不能过分笃定或夸大它们的作用。中台是一种非常理想化的架构，当企业进化到这样先进的架构时自然可以借助中台创造巨大的业务价值。也可以反过来说，因为企业自身的组织和业务足够先进而催生了中台架构（从某种意义上来说这才是中台的真正由来），两者是相辅相成的。建设中台的难度是非常大的，其难度并不技术上，更多是在业务和组织架构上。
最近两年，中台的火爆让很多企业都跟风尝试，但真正成功的案例还不多，业界对中台的讨论也很激烈，有人认为中台可能仅仅是一种“乌托邦”，因为它过于理想化，在现实中缺乏生存的土壤，很多企业的现有组织形态与中台是不符甚至是对立的，这样的企业盲目上马中台项目必然是要失败的。这里我们不妨思考一下：为什么烟囱架构在企业中普遍存在？尽管我们在前面讨论了它的各种问题，但是至少有一点是烟囱架构的优势，那就是它的目标指向性极强，它是专门用于解决某一业务问题的，相应地，它背后的技术和业务团队的职责也是高度清晰的，这种目标指向性会驱使组织高效地运转，即使在不同的团队和环节上存在重复建设，在某些时候，付出这种代价也是值得的。
在这种视角下反观中台，我们会看到，业务中心在对业务的广度和深度上都有一个介入度的问题。从广度上看，不同业务部门、不同业务方向上的业务需求都可能全部或部分落地到中台上，而中台部门需要根据自身的情况来指定开发的优先级，这就决定了在中台建设过程中，并不是所有的业务请求都能得到及时的响应，业务端的体验会与之前烟囱架构有一定的落差；从深度上看，在垂直方向上的业务问题一部分是由前台应用处理掉的，另一部分是由中台解决的，这一点我们在前面讲如何进行前台和中台切分时也提到过，这会导致过去的单一业务问题由单一系统负责变成前台和中台两个参与方或团队负责，如果我们用目标指向性来度量这一状况，显然中台不如烟囱架构有优势，简单地说就是容易出现前台和中台之间的“扯皮”现象。
本文的讨论主要是提醒读者客观理性地看待中台架构，毕竟它还是相对新的一种思想，业界需要更多的时间去实践和检验，对于这个行业的从业者而言，我们应该保持一种积极的、谨慎乐观的态度看待它。不过相较于业务中台，本系列着重讨论的数据中台并没有这么多不确定的挑战，不管是理论还是实现技术都是比较明朗和确定的。
作者介绍
耿立超，架构师，14年IT系统开发和架构经验，对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验，热衷函数式编程。目前负责企业数据中台的架构设计和开发工作，对Hadoop/Spark 生态系统有深入和广泛的了解，参与过Hadoop商业发行版的开发，曾带领团队建设过数个完备的企业数据平台，个人技术博客：https://laurence.blog.csdn.net/ 作者著有《大数据平台架构与原型实现：数据中台建设实战》一书，该书已在京东和当当上线。