技术前台、技术中台、技术后台之间的关联与作用

技术中台的作用是什么？

要搞明白这点，你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系，以及他们各自扮演的角色与作用。

先来说说我们的「技术前台」。

技术前台

「技术前台」，说白了就是为业务部门开发功能的技术团队。

如果是ToC的业务，交付物必须贴近终端用户，如果是ToB的业务，交付物需要满足商家的需求。

脑海中必须时刻牢记 “小步快跑，快速试错” 的理念，业务说啥，就是啥，业务要怎么做，你就怎么做。

另外，研发资源的投入基本和业务对等，业务需求多，人数增加，业务需求少，人数相应减少，而且团队组织也基本按功能线来划分。

运用的技术栈也相对单一，以Java语言为例，通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了，而其余的技术服务都将由「技术中台」提供。

「技术前台」的核心价值体现在对业务逻辑的理解与实现上，是技术向业务传递价值的阶梯。

我觉得在这点上，与线下销售团队的前台营销有一些类似。

技术中台

再来说说我们的「技术中台」。

「技术中台」，说白了就是强调资源整合、能力沉淀的平台体系，当「技术前台」实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。

这怎么理解？

从这张图中可以看到，「技术中台」有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。

在什么情况下，才有必要做技术中台？

俗话说 “知己知彼，百战不殆”，在我看来，面对技术问题时，“知己” 比 “知彼” 更为重要。

在实施「技术中台」之前，我们是否要静下心来对自己进行 “灵魂拷问”？比如说，当前的时机是否已经成熟？或者怎么才叫成熟？

在我看来，要想做「技术中台」，客观环境需先满足两个前提：技术组织结构垂直化、业务线又多又复杂。

否则，「技术中台」的结果只会是两种：一场闹剧 或者 一笔赔钱的买卖。

| 前提1：技术组织结构垂直化

曾经有朋友说过，每家公司的组织结构演进都是一部心酸血泪史。我很费解，问为什么？

他说，因为这中间掺杂着太多的主观判断与情感纠葛。

比如，某员工认为公司管理混乱，组织架构来回调整，今天拆这个团队，明天合那个团队，纯属病急乱投医，高管都是些横行霸道，滥用资源的傻逼货，借机搞人，这公司，没救了。

但高管们大呼冤枉，觉得组织架构调整的目的是为了提高产出和人效，如果你干得不爽可以离开，这种事情，本来就不可能让每个人都满意，既得利益者肯定大加赞赏，而失去利益者肯定狂喷不止，不用理会。

的确，这种 “自我革命式” 的调整，基本不可能一步到位，需要一个过程慢慢演化，而在这个过程里，自然会遭遇很多的阻力或质疑。

瞧瞧这结构，经典的职能分工模式，有什么问题吗？

我不但说不出问题，甚至能找出一万个理由说明这种模式的好处。开发按业务线分开，测试与运维形成上下层关系，谁也不想管对方，两边的老大也是评级的，相安无事。

那什么情况下才会觉得这种模式有问题呢？

客观的说，职能分工模式更适合瀑布式开发模式。先谈需求，再谈工期，随后按部就班地往下做

但当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，你会发现开发出来的系统很难变更，至少很难快速变更。

于是，你把开发按系统功能进行重组，每个团队都围绕 “交付速度” 开展工作，但这样又遇到了两个新的问题：

• 多种多样的中间件，每个团队独立选型中间件，没有统一的维护，没有统一的知识积累，无法统一保障SLA。

• 开发与测试、运维之间目标不一致（比如测试A君，开发要求你只做功能测试，快上线，但测试老大却要求你做非功能测试，保障质量，避免背锅……到底听谁的？），陷入永无休止的扯皮与争吵。

面对这两个新的问题，我们做出了调整：

• 成立平台架构组，负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。

• 把质量管理部中的测试团队，与系统运维部中的应用运维团队，按照系统功能拆分至各开发团队，由原开发经理负责，形成各自独立的Feature Team。

到这个时候，虽然整个组织结构还未完全实现垂直化分工，但已基本能够达到 “快速试错，小步快跑” 的目标。

另外，这更像平台化的另一种雏形，就是逐渐把一些公共、底层的技术能力抽象出来，与业务逻辑分离，并形成各种接入式基础服务，同时可以为多个业务线提供服务。

也就是说，打造「技术中台」的前提是平台化，而平台化的先决条件是「组织结构垂直化，技术工具公共化」。

如果没有这样的前提，就失去了打造「技术中台」的立身之基。

| 前提2：业务线又多又复杂

曾经有朋友问我，技术的核心价值是什么？我的答案是 “改变世界”。

他说，别扯淡，好好说话。

他说，对业务驱动型的公司来说，技术的核心价值是 “降低成本，提升效率”，而单从架构设计的角度来看，想达成这项目标的两个手段是「通用性」与「复用性」。

现在想想，这句话可以完美的衔接到「技术中台」上去。

回顾几年前，我们的业务逻辑也曾非常单一，要么用你的银行卡买卖基金，要么用你的电子钱包买卖基金，方便，快捷。

渐渐地，随着业务创新业务增多，需要前后台系统定制开发，逻辑兼容难度增加。

在这样的局势下，为满足企业规模扩大和多样化经营对组织机构的要求，公司开始转向事业部制，按产品、地区或市场(顾客) 划分经营单位。

为了应对业务方的这次调整，我们开始将业务开发中的一些共享服务分离出来，成立了业务中台组（由于本文以技术中台为主，业务中台的内容将不进行展开说明）

将可以复用的服务和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。

与「业务中台」相呼应，「技术中台」就像一个工具大仓库，里面放满了各式各样的技术工具，无论是哪个团队，哪个人，快速找到自己的工具，拿来就用就行了。

而维护工具的这群人，不用贴近业务开发，每天的任务就是研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。

有了这么一群专职的人，就可以根据自身的情况，选择有限几个技术栈集中研究，限定业务组只使用这些工具，可保证选型的一致性。

如果你只有一条业务线，那就别搞「技术中台」了，把人凑在一堆，又省钱，又省力。

有了技术中台，是不是就能上天？

理论上讲，当业务线变多且越来越复杂，前台与后台之间的“技术债”会随之变多，重复造轮子与沟通成本太高的现象会增多，通过技术中台可以一定程度上来解决这个问题。

这种理论看似完美，但在实际执行上却困难重重。

设想下，如果「技术中台」做得太多，资源投入就会很大，无法形成正向的利益传导；

如果「技术中台」做得太少，又无法深入理解业务，导致适配方案落地性变差，渐渐失去价值。

这句话怎么理解？

十年前，我在某金融软件公司工作，随着客户数的增多，成本与效率/质量的矛盾日益凸显。

设想下，从一波人维护一套代码，渐渐变成一波人维护几套代码，这样一来，Bug增多，效率下降，抱怨也随之变多，再加上甲方挖人，最后人员离职，团队土崩瓦解，Game Over……

在这种情况下，一般公司会采取三种应对措施：

1. 一对一服务 - 项目制：多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债。

2. 一对多服务 - 标准化：一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别来某某标准来引导我，叫你咋做，你就咋做，不愿意？那您走，我找别人家做。

3. 一对多服务 - 产品化：一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。

回想下，当年那些叱诧风云的软件公司，又有几家活下来了？以金融业为例，恒生算是在第二条路上走的比较成功的，而我们当年却死在了第三条路上。

在我看来，我们的「技术中台」就是一家 “乙方服务公司”，而我们的「技术前台」更像是一家 “甲方电商公司”。

不可否认，有了这家 “乙方服务公司” 之后，在面对大型项目及快速多变的业务时，技术的投入与主动权更强了，但由于理念、职责、节奏与使命不同，外加 “屁股决定脑袋” 的立场，前台与中台之间很容易引发矛盾。

从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。

一个追求效率，一个追求质量，这矛盾是天然存在的。

怎么理解？我来举个小例子说明下。

前台部门的A团队和B团队，由于业务需要同时向「技术中台」提出要接入缓存服务的需求

「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统，已在其他业务线运行多年，但由于A团队与B团队的技术债都各不相同，必须通过增加适配器才能完成接入

而此时人手又不够，按重要程度排序，只能先接A团队，但B团队也有需求，又等不及，怎么办呢？就先给他来个Redis接着玩玩吧，等A团队接好了再来接你的。

一个月后，等A团队接完了，找到B团队，这时痛点已不存在，团队的激情自然不高，毕竟没有收益，就不了了之了。

几个月后，安全团队提出要对Redis集群进行改密，由于A团队接入的是「技术中台」的缓存中间件产品，采用代理模式，并通过控制台操作，既方便，又快捷，找个晚上，5分钟内，全部搞定。

但B团队用的是直连Redis的模式，密码嵌入在SDK中，不仅在改密过程中需要前台与中台联动，而且还需要在改密后重启应用服务，这样一来，只有配合应用发布的周期才能干这件事。

最终，原本五分钟可以搞定的事，整整搞了三周才搞定，「技术中台」的运维同学更是陪熬了多次通宵，还因为人为疏忽引发了一次事故。

就在这件事过去的一年时间里，由于B团队系统的业务规模逐渐增大，Redis数量也逐渐增多，「技术中台」的运维成本与风险也随之上涨。

这期间，中台曾多次与前台交涉，希望能够通过适配的方式将A团队接入缓存中间件，但始终未能达成。

在「技术中台」看来，“你们只顾自己，不管别人，功劳你们拿，黑锅我们背？”

在「技术前台」看来，“你TM懂个屁！我们都快被业务逼疯了，你们不就多费点人工吗？多加点班会死吗？总扯一些理念干嘛？对你没收益的事，你干嘛？”

因为这样的分工模式，导致这种矛盾在工作中很多，而且似乎并没有更好的方法彻底解决。

有人说，要解决很简单，要么强压，要么加大投入，下下狠心就得了。

先来说说强压，似乎能够在短时间内达到目的，但纯属 “杀敌一千自损八百” 的招数，难道要业务研发团队停下手上的活，倾巢而出一起搞技术改造吗？更何况，前台承受的压力，是中后台团队无法想象的。

退一步说，抛开 “互相理解” 这个话题，强压的套路等同于 “攻城为上，攻心为下”，对今后的管理与团队氛围都会带来诸多的麻烦。

再来说说加大投入，看看我上面提到的 “死在路上的软件公司们”，还想加大中后台的投入吗？

如果你不是大厂，还是算了吧。

那句话怎么说来着？最悲惨的结局是，你的技术中后台越发强大，但你的业务规模却在逐渐萎缩。

可悲，可叹。

总结

在互联网时代，技术圈似乎从来不缺少热议话题，但有质量，有深度，且能解决实际问题的却少之又少。

现在人人都在讨论「中台」，今天「产品中台」，明天「数据中台」，这个说能提高效率，那个说能排除万难，聊得不亦乐乎。

对于企业来说，话题热不热并不重点，方案牛不牛逼也不重要，关键是能帮助用户找到效率、质量与成本的平衡点，或许才算是一个合格的「技术中台」。

分类: 其他