深入浅出之技术中台

在过去的一年里，「技术中台」成了技术圈内讨论的热门词汇，就连很多的小公司，也纷纷打出口号「要做自己的技术中台」，更有甚者更是提出了「不做技术中台就等着死吧」骇人说法。

那到底什么是「技术中台」，他的前世今生是什么样的？什么样的情况下才应该去做技术中台。

本文将一步一步的解释「技术中台」的概念是怎么被提出的，以及怎么应用的。

本文大约1500字，阅读需要10分钟

什么是「技术中台」？简单的说就:

将技术做到「通用性」与「复用性」

技术中台的最终目的:

降低成本，提升效率

并不是所有公司都适合去做一个技术中台，那什么情况下才应该演变出技术中台的概念呢？下面我将从三个场景进行剖析

场景一：

现公司20个项目，有15个项目组都用到第三方支付，每一个项目组都独立去维护一个第三方支付的代码，不仅是在做重复的工作，更重要的是不同的项目组中支付代码会有差异，甚至某些组因代码经手人员过多，导致代码难以维护。为减少做重复工作，保证体验的统一性，方便代码统一管理， 就需要一个专门的部门或人员维护第三方支付代码，把第三方支付内容抽象成一个中间件，供其他所有部门调用。

场景二：

公司有20个项目，每一个项目都独立维护自己的数据库，比如用户信息（登录），用户偏好（个人行为数据），购买数据（以往支付历史），以及更多价值更高的数据。此时各个项目组的数据库是单个的【信息孤岛】，难以打破多个项目的边界，让多个项目形成合力。集合多个数据源，让数据互通，需要一个专门的部门或人员维护公司基础数据库，把繁多的数据库抽象成一个中间件，供其他所有部门调用。

场景三：

公司多个项目，每个项目都需要运营人员，会导致人力成本上升；人员分布在不同项目组，其互相交流，交换意见变少，成长变慢；人员不集中，无法统一管理；某些项目暂停或成立新的项目组时，成员会出现增，删情况，不利于团队稳定。这时候为了降低成本，并且提升人员的专业性，方便相似职能人员互相调用，就需要成立一个专门运营部，把运营部门做成中间件，哪个组需要放到哪个组。

从上面的例子可以看出，演变出技术中台的重要的条件：

1.业务线多且复杂

2.组织结构垂直化，技术工具公共化

技术中台的核心是

大的技术工具仓库，里面放满了各式各样的技术工具，无论是哪个团队，都能快速找到自己的工具或人员，拿来就用就行了。

• 如何打造技术中台

专门找一帮技术大牛，作为技术工具的维护者，这群人不用贴近业务开发，每天的任务就是研究新的技术，并形成公共的文档，SDK，研究如何将多个项目的公共类进行抽象和标准化。研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。

• 技术中台的利弊

前面说到了，技术中台的最终目的是降本增效。显然，不同的技术公司的降本增效的方式肯定不同。并且维护一个技术中台会消耗一定的资源（人力，物力，时间等）

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

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

• 什么情况下适合做技术中台？

其实做不做技术中台全部都是根据自身情况而来。

当你是一家小公司，业务线清晰且少，那么你需要 “快速应对业务变化”，采用小步快跑，快速迭代的方式。这时候我们更多的精力应该放在如何应对外部的变化，满足客户的个性化需求。

此时强行上技术中台，不仅增加成本，更会拖慢整个开发进度。同时会因为中台工具被使用的次数过少而降低中台的积极性。

简单的例子。你是一个做垂直行业的CRM系统的公司，某一家公司要求你在客户信息中添加一个客户住址字段，并且这个字段只有这一家公司会用到。这时候小公司可以选择直接在代码中添加对应的字段，然后判断是否显示。10分钟就可以解决，不仅有效，而且快。满足了公司当前业务发展的需求

但这家公司慢慢成长，不再只是服务于某一个垂直行业，他合作的客户行业类别越来越多，这种个性化需求越来越多，代码中的判断越来越复杂，这时候你不得不去还以前的技术债。

那么你就会演变出一个专门的部门，研究怎么使用统一的技术方案，解决客户的个性化需求，CRM中的自定义字段应运而生。这时候运用这个技术是合理的，因为他也满足了公司当前的需要。并且为以后应对更大的挑战打下了基础。这时候使用一个技术中台去研究对应的技术合理且必须。

是否需要技术中台，视情况而定。不要一味追概念，不然到时候你发现你的技术中后台越发强大，但你的业务规模却在逐渐萎缩。可悲。

总结

技术圈从不缺少热点话题，现在人人都在讨论「技术中台」，明天就可能讨论「数据资产」，这个说能降本增效，那个是救命稻草，不亦乐乎。 企业的第一要务是发展，而不是追热点。

对于企业来说，符合企业当前发展需要，能帮助企业找到效率、质量与成本的平衡点才是真正的「技术中台」