购物网站的经营要素,网页设计与制作课程报告,版式设计作品集,什么是手机网站从 2015 年开始#xff0c;到 2019 年现在为止#xff0c;各大公司都在吹捧中台理念。 从 2015 年开始#xff0c;到 2019 年现在为止#xff0c;各大公司都在吹捧中台理念。 仿佛中台是业务复杂性的救世主#xff0c;是某些架构师和 PM 的新出路#xff0c;各种割韭菜的…从 2015 年开始到 2019 年现在为止各大公司都在吹捧中台理念。 从 2015 年开始到 2019 年现在为止各大公司都在吹捧中台理念。 仿佛中台是业务复杂性的救世主是某些架构师和 PM 的新出路各种割韭菜的讲中台的课程层出不穷。
当然吹牛逼的时候大家都是拣好的说苦逼的东西就只有内部人士知道。中台到底靠谱还是不靠谱只凭各路英雄的演讲内容那看起来是靠谱的。
先来看看这些公开的观点再以我(码农桃花源注资深研发工程师)的视角还原“中台”的真相。
手动贴上文章的目录 公开的观点
中台是什么
阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部包含了用户中心、商品中心、交易中心、评价中心等十几个中心而共享业务事业部正是“厚平台”的真实体现为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
钟华. 《企业 IT 架构转型之道阿里巴巴中台战略思想与架构实战》
中台实际上是通用业务的下沉企业在一个行业耕耘多年之后一般都会形成一些公用的业务而这些业务是可以像中间件那样进行下沉共享的。
再往前推一些也就是比较早期人们常说的偏业务的基础服务。在概念上并不是创新。
为什么要做中台
中台解决了什么问题?其实和把程序内的公用逻辑封装为 Library 差不多就是尽量避免重复造轮子。
一个轮子造 100 遍对部门是没有任何好处的。一个系统造 100 遍对企业自然是没什么帮助的。
早期的企业经常借鉴腾讯经验鼓励内部竞争。但内部竞争的度往往不好把握经常会出现“所有部门都在造差不多的系统”的现象。
中台从公司战略角度将这些行为进行了规范化公共的部分交给公共系统部门去做。
中台给企业带来的收益
①工程方面
就像上面提到的首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置并在公共服务上快速高效迭代出新的业务。
②数据方面
有了统一的用户、订单系统就不会再有各种恶心的数据打通问题不会有跨部门的数据墙。
有了统一的中台也就有了统一的数据规范。对于大数据相关的需求可以从相对唯一的数据出口进行业务迭代不需要为每一个部门进行定制开发浪费人力。
创新方面
这一项目也很好地诠释了之前所说的“点、线、面”的理论在“点”上根本感知不到的问题在“线”和“面”的平台上更容易发现这些问题的本质通过专业的技能解决这些问题为企业带来实实在在的业务价值这就是很好的创新!
钟华. 《企业 IT 架构转型之道阿里巴巴中台战略思想与架构实战》
有了公共的中台意味着有了相对全局的视角更能发现单点观察难以发现的问题。在更大的业务层面进行一定的创新。听着很有道理。 中台的真相
中台能解决问题么?是能解决的。中台能解决所有问题么?那显然是不能的。
就像微服务架构一样架构师吹牛的时候天花乱坠你做起来却发现这条路上全都是坑。
技术方面
公用业务下沉这个理念很朴素。所有程序员都知道我们公用的逻辑要进行封装、抽象变成 Library。
中台的本质其实就是把这种朴素的思想进行了一定程度的推广。(码农桃花源注新瓶装旧酒)
①难以应对 Cross cutting concern
根据中台进行系统拆分和部门调整之后还是会遇到 cross cutting concern什么是 cross cutting concern
The cross cutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.
有些需求难以避免地会影响整个流程中的所有系统。比如从技术范畴进行的一些改造(如为了完成 tracing所有系统增加 trace id并在 log 中默认携带)。
比如从业务范畴进行的 i18n 改造。(码农桃花源注i18n 是国际化的意思Internationalization 去掉头尾的 i 和 n 刚好还剩下 18 个字符程序员的智慧)
这些改造需求一般天生就是跨系统、跨组、跨部门的事情一带上“跨”的字眼就不好搞了。(码农桃花源注别人的地盘你能做主?)
举一个典型的例子某巨型互联网公司员工抱怨在当前的微服务和中台架构前提下做一个需求经常要改 20 个模块苦不堪言连上线顺序都不一定搞得清楚。
当这 20 个模块又是跨部门的时候就更难了。想要推动其他部门做一些短期看起来没啥收益的事太难了。
②稳定性和灵活性的矛盾
对于一个系统来说追求稳定性那么必然会在修改和升级上较为消极;追求灵活性那在功能迭代上一定会较为激进。
这两方面的矛盾本来就是难以调和的。追求其中之一在一定程度上就得放弃另一方面。
就像网友经常讲的不作死就不会死没有代码才是真正的稳定之道。Google 程序员在 GitHub 上发起的行为艺术项目noCode没有 code就没有 Bug。可谓弃疗的典范。
有很多中台系统被剥离之后因为用户众多一旦出现技术上的问题影响面巨大。
从我的实际观察来看中台部门的系统虽然初始立项的时候声势浩大但基本也没什么人关注这些公共系统的代码质量或者测试质量。
最终只不过是大家公用了一堆“垃圾”“垃圾”在转过几手之后后来的人基本就不太想对原来的代码进行修改了。
可能有人会讲你可以重构啊。嗯重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有!
在没有测试的情况下我们可以根据过往的系统需求文档和 PRD(码农桃花源注产品需求文档Product Requirements Document)来还原当时的业务场景并进行测试补充。
但你又发现中台的性质(大多偏技术项目基本没什么 PM 把关或者出文档)使其基本没有什么靠谱的、详尽的文档。写的复杂的中台连业务流程都理不清楚还想写测试别做梦了哦。
③中台与前台的模糊业务边界、距离
在实际实践时中台与 FT 的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态这些内容可能并不是用户服务本身关心的内容。
但往往需求也会提给用户服务这时候用户服务就只是进行字段存储而状态机变化则完全在外部。
如果对系统内的个别数据不进行管理那么有其他接入方接入时就无法解释清楚字段的含义和使用场景。
如果不接受这些不相干的数据接入那么前台流程系统可能会在自己内部重新建立自己的数据系统这部分系统又极有可能和中台有功能上的重叠。
如果想要把这些数据接管过来那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部这往往又会产生与中台与前台业务边界的冲突。
难以给出有效的边界就意味着无穷无尽的撕逼。这便是很多中台的两难我接不是不接也不是。
如果去问那些中台业务部门的系统开发负责人某些业务要不要你们来做连这些人自己都说不清楚。
人方面
如果要做中台那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门这一定会带来人员的调动。
从情感上来讲人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。
也有些公司在调整中进行粗暴的系统交接如果系统需要下沉那我直接从原来的维护团队手里夺过来交给中台部门来管理。
这一样会引起双方的反感
交接方这是我们加班加点辛辛苦苦开发出来的系统凭什么交给别人?奋斗了半年难道就是为了给别人摘桃子?被交接方这个系统原来的维护团队水平极低代码就是一堆“垃圾”他们不想搞了就随便扔给我们?凭什么啊?我们又不是接盘侠。
即使贵司运气好在系统交接过程中没有出现问题那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态这时候前台业务接入中台会比以往更加困难。
这种困难使前台业务的不满积累到一定程度之后会再次催生前台部门重新造一套新的自己的中台而部分或全部放弃原来的中台。这样原来的中台部门便会陷入尴尬的境地。
生存空间被挤压人也自然很难呆得下去各公司的中台部门人跑的比香港记者都快。
部门、公司、组织架构方面
①跨部门沟通障碍、跨部门目标差异
进行部门划分之后每个业务部门会有自己的一套目标体系。部门与部门的目标(KPI)一般是不相同的如果相同的话那也就没必要分多个部门了。
而部门与部门之间的目标在某种程度上甚至可能有冲突例如 A 部门 Feature Team 较多主要负责业务功能迭代需要更强的灵活性。
而 B 部门负责中台数据主要关心系统稳定性也就是前文提到的灵活性和稳定性的矛盾。
若此时出现 cross cutting concern两个部门需要在矛盾上取得一定程度的平衡这种平衡在个别情况下是不可得的。
例如在一段时间内中台部门的目标是提高某个商业指标让公司更赚钱/省钱。
这时候前台业务提来了新的需求这种需求是能使流程开发更加灵活的但与中台部门的 KPI 不在一个航道上。
中台部门显然要把需求排排优先级把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪不如自己实现了。
前台业务也有自己的理由“自闭环”嘛这词真是好用。
②公司利益分配
毫无疑问距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。
中台看起来是业务但又是公共业务既然是公共业务那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中中台的强大、便捷是重要原因。
这会导致什么问题呢?没有人愿意接手中台项目中台项目变成烫手的山芋。大佬无法在中台项目上获得红利小弟们没法在中台项目上获得利益。
中台功能确定以后只有出事故的时候大家才想起你来。稳定运行是应该的出事就是你的锅!
③利润中心?其实是成本中心
最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能转变为基于企业核心业务和数据进行运营的团队这个团队会更快、更好地支持业务发展的同时逐渐掌握企业最核心的业务和数据逐步培养出企业最稀缺的“既精通业务又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营到那个时候这个部门将成为企业最为宝贵的资产。
钟华. 《企业 IT 架构转型之道阿里巴巴中台战略思想与架构实战》
在大多数公司中台部门和基础架构一样会被当成是包袱而不是财富。可能有些人读到这里会不太爽。我们来看看科技公司是怎么看待员工的呢?
在 DDD(码农桃花源注领域驱动设计Domain Driven Design)相关的书里提到两个概念成本中心、利润中心。
技术对业务参与不强的情况下技术部门基本上都会被当作是成本中心。也就是老板要达成自己的目标必须不情不愿地花钱去养你们这些技术团队。
对应业务侧开发来说想要改变老板的这种看法需要让业务系统和业务人员之间进行强联动将一部分业务人员变成系统人员架构中的业务专家角色或者是研发人员自己变成一个业务领域专家就是有些人常说的你得跟老板穿一条裤子。
从这方面来讲大多公司的基础架构角色就比较尴尬。业务驱动的公司基础架构并不是其致胜要素。
所以不管你做的再好只要公司没有用技术赚钱那么这部分的支出就只能被当作单纯的成本。
当然了很多做基础的大佬也根本不在乎公司只是个练兵场练成了带小弟们跳槽就好。(码农桃花源注求带!)
中台也是一样的从业务一线剥离到后方之后。中台离业务的距离越来越远。公司高层渐渐看不到继续对中台进行投入的价值中台便渐渐变成了他们眼中纯粹的成本中心是公司财务的包袱而不是财富。 行业方面
中台建设一般要考虑公司的实际情况这样建设出来的系统可以应对一段时间内的公司业务变化。
然而公司的压力有时并不来自于自己的业务方向可能来自于行业内其他公司的模式挑战。
理论上来说只要一个公司的业务系统架构建设完成了便已经完成了一种架构上的 固化。
这时行业内如果有新的模式获得了成功公司肯定要进行跟进。但是新的模式一定意味着对原有系统、架构的挑战。
试想原来系统架构是针对线上交易设计的突然有一天O2O 模式被证明有利可图大多数公司都开始转向线下。
原有的流程、模式当然想要复用但是这时候复用的成本很可能比重新开发还要高。
眼睁睁看着竞争对手们甩掉包袱轻装上阵以更低的成本更短的时间攻城略地挤压自己的生存空间。
这时候怎么办呢?大多数公司给出的方案是成立新的业务部门在新趋势新阵地冲锋陷阵。
新部门肯定也要用到原来公司的老服务又碰到了我们的老问题跨部门合作。新部门的成功并不会让老部门多得到多少好处配合自然不会太积极。(码农桃花源注公司内部做事都是利益驱动)
如果新部门的尝试获得了初步成功得到了公司资源的倾斜获得了有效的人力资源补充。之后又会带来新一轮重复造轮子互相不合作互相撕逼的腥风血雨。
简直是一个轮回。
结语
经常有小伙伴说国内某公司中台非常好大家都在学。嗯我倒是想问问了如果真的做的好某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构和好几朵云?(码农桃花源注曹大真敢怼!)
作为一个技术人员在各种乌七八糟、花里胡哨的概念“轰炸”下应该能够保持理智不要被各种人带节奏。
