不做中台，那就等着死吗？！
在技术圈，每年总有那么一拨人，喜欢把 “某某岗位要不要写代码” 这样的话题拿出来讨论一番。
比如，前年的话题是CTO要不要写代码，去年的话题是架构师要不要写代码，今年的话题是技术总监要不要写代码……按这逻辑，明年的话题是不是要讨论工程师要不要写代码？
说实话，我并不喜欢讨论这类话题，因为每家公司的客观环境与人文价值观都不相同，聊这些，除了引发争吵，不会从中得到更多。
相比之下，我更愿意参与一些技术话题的讨论，因为大家面对的场景相似，采用的技术也相似，这样能更容易产生共鸣，更容易擦出 “爱” 的火花。
就在刚过去的半年里，「中台」成了技术圈内讨论的热门词汇，就连一些名不见经传的小公司，也都纷纷喊出了「要向中台转型！」的口号，甚至有人说「不做中台，那就等着死吧！」
如果我没有记错，「中台」思想源自于2015年，马云参观一个著名的游戏公司Supercell之后提出了这个概念，简言之就是“小前台、大中台”，随即阿里就成立中台事业群，并取得了很好的成效。随后，美团点评也开始走中台策略，腾讯在去年的组织架构调整中，也提出建设具有 “腾讯特色的技术中台”。
一、技术中台的作用是什么
要搞明白这点，你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系，以及他们各自扮演的角色与作用。
先来说说我们的「技术前台」。
「技术前台」，说白了就是为业务部门开发功能的技术团队，如果是ToC的业务，交付物必须贴近终端用户，如果是ToB的业务，交付物需要满足商家的需求。脑海中必须时刻牢记 “小步快跑，快速试错” 的理念，业务说啥，就是啥，业务要怎么做，你就怎么做。
另外，研发资源的投入基本和业务对等，业务需求多，人数增加，业务需求少，人数相应减少，而且团队组织也基本按功能线来划分。
image
运用的技术栈也相对单一，以Java语言为例，通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了，而其余的技术服务都将由「技术中台」提供。
image
「技术前台」的核心价值体现在对业务逻辑的理解与实现上，是技术向业务传递价值的阶梯。
我觉得在这点上，与线下销售团队的前台营销有一些类似。
再来说说我们的「技术中台」。
「技术中台」，说白了就是强调资源整合、能力沉淀的平台体系，当「技术前台」实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。
这怎么理解？
image
从这张图中可以看到，「技术中台」有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。
二、什么情况下有必要做技术中台
俗话说 “知己知彼，百战不殆”，在我看来，面对技术问题时，“知己” 比 “知彼” 更为重要。
在实施「技术中台」之前，我们是否要静下心来对自己进行 “灵魂拷问”？比如说，当前的时机是否已经成熟？或者怎么才叫成熟？
在我看来，要想做「技术中台」，客观环境需先满足两个前提：技术组织结构垂直化、业务线又多又复杂。
否则，「技术中台」的结果只会是两种：一场闹剧或者一笔赔钱的买卖。
1、技术组织结构垂直化
曾经有朋友说过，每家公司的组织结构演进都是一部心酸血泪史。我很费解，问为什么？
他说，因为这中间掺杂着太多的主观判断与情感纠葛。
比如，某员工认为公司管理混乱，组织架构来回调整，今天拆这个团队，明天合那个团队，纯属病急乱投医，高管都是些横行霸道，滥用资源的傻逼货，借机搞人，这公司，没救了。但高管们大呼冤枉，觉得组织架构调整的目的是为了提高产出和人效，如果你干得不爽可以离开，这种事情，本来就不可能让每个人都满意，既得利益者肯定大加赞赏，而失去利益者肯定狂喷不止，不用理会。
的确，这种 “自我革命式” 的调整，基本不可能一步到位，需要一个过程慢慢演化，而在这个过程里，自然会遭遇很多的阻力或质疑。
image
瞧瞧这结构，经典的职能分工模式，有什么问题吗？我不但说不出问题，甚至能找出一万个理由说明这种模式的好处。开发按业务线分开，测试与运维形成上下层关系，谁也不想管对方，两边的老大也是评级的，相安无事。
那什么情况下才会觉得这种模式有问题呢？
客观的说，职能分工模式更适合瀑布式开发模式。先谈需求，再谈工期，随后按部就班地往下做，但当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，你会发现开发出来的系统很难变更，至少很难快速变更。
于是，你把开发按系统功能进行重组，每个团队都围绕 “交付速度” 开展工作，但这样又遇到了两个新的问题：
-
多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA；
-
开发与测试、运维之间目标不一致（比如测试A君，开发要求你只做功能测试，快上线，但测试老大却要求你做非功能测试，保障质量，避免背锅……到底听谁的？），陷入永无休止的扯皮与争吵。
面对这两个新的问题，我们做出了调整：
-
成立平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护；
-
把质量管理部中的测试团队，与系统运维部中的应用运维团队，按照系统功能拆分至各开发团队，由原开发经理负责，形成各自独立的Feature Team。
image
到这个时候，虽然整个组织结构还未完全实现垂直化分工，但已基本能够达到 “快速试错，小步快跑” 的目标。
另外，这更像平台化的另一种雏形，就是逐渐把一些公共、底层的技术能力抽象出来，与业务逻辑分离，并形成各种接入式基础服务，同时可以为多个业务线提供服务。
也就是说，打造「技术中台」的前提是平台化，而平台化的先决条件是「组织结构垂直化，技术工具公共化」。
如果没有这样的前提，就失去了打造「技术中台」的立身之基。
2、业务线又多又复杂
曾经有朋友问我，技术的核心价值是什么？我的答案是 “改变世界”。
他说，别扯淡，好好说话。
他说，对业务驱动型的公司来说，技术的核心价值是 “降低成本，提升效率”，而单从架构设计的角度来看，想达成这项目标的两个手段是「通用性」与「复用性」。
现在想想，这句话可以完美的衔接到「技术中台」上去。
回顾几年前，我们的业务逻辑也曾非常单一，要么用你的银行卡买卖基金，要么用你的电子钱包买卖基金，方便，快捷。
image
渐渐地，随着业务创新业务增多，需要前后台系统定制开发，逻辑兼容难度增加。
image
在这样的局势下，为满足企业规模扩大和多样化经营对组织机构的要求，公司开始转向事业部制，按产品、地区或市场(顾客) 划分经营单位。
image
为了应对业务方的这次调整，我们开始将业务开发中的一些共享服务分离出来，成立了业务中台组（由于本文以技术中台为主，业务中台的内容将不进行展开说明），将可以复用的服务和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。
与「业务中台」相呼应，「技术中台」就像一个工具大仓库，里面放满了各式各样的技术工具，无论是哪个团队，哪个人，快速找到自己的工具，拿来就用就行了。
而维护工具的这群人，不用贴近业务开发，每天的任务就是研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。有了这么一群专职的人，就可以根据自身的情况，选择有限几个技术栈集中研究，限定业务组只使用这些工具，可保证选型的一致性。
如果你只有一条业务线，那就别搞「技术中台」了，把人凑在一堆，又省钱，又省力。
三、有了技术中台，是不是就能上天
理论上讲，当业务线变多且越来越复杂，前台与后台之间的“技术债”会随之变多，重复造轮子与沟通成本太高的现象会增多，通过技术中台可以一定程度上来解决这个问题。
这种理论看似完美，但在实际执行上却困难重重。
设想下，如果「技术中台」做得太多，资源投入就会很大，无法形成正向的利益传导，如果「技术中台」做得太少，又无法深入理解业务，导致适配方案落地性变差，渐渐失去价值。
这句话怎么理解？
十年前，我在某金融软件公司工作，随着客户数的增多，成本与效率/质量的矛盾日益凸显。
设想下，从一波人维护一套代码，渐渐变成一波人维护几套代码，这样一来，Bug增多，效率下降，抱怨也随之变多，再加上甲方挖人，最后人员离职，团队土崩瓦解，Game Over……
在这种情况下，一般公司会采取三种应对措施：
一对一服务 - 项目制：多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债；
一对多服务 - 标准化：一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别来某某标准来引导我，叫你咋做，你就咋做，不愿意？那您走，我找别人家做；
一对多服务 - 产品化：一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。
回想下，当年那些叱诧风云的软件公司，又有几家活下来了？以金融业为例，恒生算是在第二条路上走的比较成功的，而我们当年却死在了第三条路上。
在我看来，我们的「技术中台」就是一家 “乙方服务公司”，而我们的「技术前台」更像是一家 “甲方电商公司”。
不可否认，有了这家 “乙方服务公司” 之后，在面对大型项目及快速多变的业务时，技术的投入与主动权更强了，但由于理念、职责、节奏与使命不同，外加 “屁股决定脑袋” 的立场，前台与中台之间很容易引发矛盾。
从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。
一个追求效率，一个追求质量，这矛盾是天然存在的。
怎么理解？我来举个小例子说明下。
前台部门的A团队和B团队，由于业务需要同时向「技术中台」提出要接入缓存服务的需求，「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统，已在其他业务线运行多年，但由于A团队与B团队的技术债都各不相同，必须通过增加适配器才能完成接入，而此时人手又不够，按重要程度排序，只能先接A团队，但B团队也有需求，又等不及，怎么办呢？就先给他来个Redis接着玩玩吧，等A团队接好了再来接你的。
一个月后，等A团队接完了，找到B团队，这时痛点已不存在，团队的激情自然不高，毕竟没有收益，就不了了之了。
几个月后，安全团队提出要对Redis集群进行改密，由于A团队接入的是「技术中台」的缓存中间件产品，采用代理模式，并通过控制台操作，既方便，又快捷，找个晚上，5分钟内，全部搞定。
但B团队用的是直连Redis的模式，密码嵌入在SDK中，不仅在改密过程中需要前台与中台联动，而且还需要在改密后重启应用服务，这样一来，只有配合应用发布的周期才能干这件事。
最终，原本五分钟可以搞定的事，整整搞了三周才搞定，「技术中台」的运维同学更是陪熬了多次通宵，还因为人为疏忽引发了一次事故。
就在这件事过去的一年时间里，由于B团队系统的业务规模逐渐增大，Redis数量也逐渐增多，「技术中台」的运维成本与风险也随之上涨。
这期间，中台曾多次与前台交涉，希望能够通过适配的方式将B团队接入缓存中间件，但始终未能达成。
在「技术中台」看来，“你们只顾自己，不管别人，功劳你们拿，黑锅我们背？”
在「技术前台」看来，“你TM懂个屁！我们都快被业务逼疯了，你们不就多费点人工吗？多加点班会死吗？总扯一些理念干嘛？对你没收益的事，你干嘛？”
因为这样的分工模式，导致这种矛盾在工作中很多，而且似乎并没有更好的方法彻底解决。
有人说，要解决很简单，要么强压，要么加大投入，下下狠心就得了。
先来说说强压，似乎能够在短时间内达到目的，但纯属 “杀敌一千自损八百” 的招数，难道要业务研发团队停下手上的活，倾巢而出一起搞技术改造吗？更何况，前台承受的压力，是中后台团队无法想象的。
退一步说，抛开 “互相理解” 这个话题，强压的套路等同于 “攻城为上，攻心为下”，对今后的管理与团队氛围都会带来诸多的麻烦。
