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