赞
踩
在过去的一年里,「技术中台」成了技术圈内讨论的热门词汇,就连很多的小公司,也纷纷打出口号「要做自己的技术中台」,更有甚者更是提出了「不做技术中台就等着死吧」骇人说法。
那到底什么是「技术中台」,他的前世今生是什么样的?什么样的情况下才应该去做技术中台。
本文将一步一步的解释「技术中台」的概念是怎么被提出的,以及怎么应用的。
本文大约1500字,阅读需要10分钟
什么是「技术中台」?简单的说就:
将技术做到「通用性」与「复用性」
技术中台的最终目的:
降低成本,提升效率
并不是所有公司都适合去做一个技术中台,那什么情况下才应该演变出技术中台的概念呢?下面我将从三个场景进行剖析
场景一:
现公司20个项目,有15个项目组都用到第三方支付,每一个项目组都独立去维护一个第三方支付的代码,不仅是在做重复的工作,更重要的是不同的项目组中支付代码会有差异,甚至某些组因代码经手人员过多,导致代码难以维护。为减少做重复工作,保证体验的统一性,方便代码统一管理, 就需要一个专门的部门或人员维护第三方支付代码,把第三方支付内容抽象成一个中间件,供其他所有部门调用。
场景二:
公司有20个项目,每一个项目都独立维护自己的数据库,比如用户信息(登录),用户偏好(个人行为数据),购买数据(以往支付历史),以及更多价值更高的数据。此时各个项目组的数据库是单个的【信息孤岛】,难以打破多个项目的边界,让多个项目形成合力。集合多个数据源,让数据互通,需要一个专门的部门或人员维护公司基础数据库,把繁多的数据库抽象成一个中间件,供其他所有部门调用。
场景三:
公司多个项目,每个项目都需要运营人员,会导致人力成本上升;人员分布在不同项目组,其互相交流,交换意见变少,成长变慢;人员不集中,无法统一管理;某些项目暂停或成立新的项目组时,成员会出现增,删情况,不利于团队稳定。这时候为了降低成本,并且提升人员的专业性,方便相似职能人员互相调用,就需要成立一个专门运营部,把运营部门做成中间件,哪个组需要放到哪个组。
从上面的例子可以看出,演变出技术中台的重要的条件:
1.业务线多且复杂
2.组织结构垂直化,技术工具公共化
技术中台的核心是
大的技术工具仓库,里面放满了各式各样的技术工具,无论是哪个团队,都能快速找到自己的工具或人员,拿来就用就行了。
专门找一帮技术大牛,作为技术工具的维护者,这群人不用贴近业务开发,每天的任务就是研究新的技术,并形成公共的文档,SDK,研究如何将多个项目的公共类进行抽象和标准化。研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。
前面说到了,技术中台的最终目的是降本增效。显然,不同的技术公司的降本增效的方式肯定不同。并且维护一个技术中台会消耗一定的资源(人力,物力,时间等)
如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导;
如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。
其实做不做技术中台全部都是根据自身情况而来。
当你是一家小公司,业务线清晰且少,那么你需要 “快速应对业务变化”,采用小步快跑,快速迭代的方式。这时候我们更多的精力应该放在如何应对外部的变化,满足客户的个性化需求。
此时强行上技术中台,不仅增加成本,更会拖慢整个开发进度。同时会因为中台工具被使用的次数过少而降低中台的积极性。
简单的例子。你是一个做垂直行业的CRM系统的公司,某一家公司要求你在客户信息中添加一个客户住址字段,并且这个字段只有这一家公司会用到。这时候小公司可以选择直接在代码中添加对应的字段,然后判断是否显示。10分钟就可以解决,不仅有效,而且快。满足了公司当前业务发展的需求
但这家公司慢慢成长,不再只是服务于某一个垂直行业,他合作的客户行业类别越来越多,这种个性化需求越来越多,代码中的判断越来越复杂,这时候你不得不去还以前的技术债。
那么你就会演变出一个专门的部门,研究怎么使用统一的技术方案,解决客户的个性化需求,CRM中的自定义字段应运而生。这时候运用这个技术是合理的,因为他也满足了公司当前的需要。并且为以后应对更大的挑战打下了基础。这时候使用一个技术中台去研究对应的技术合理且必须。
是否需要技术中台,视情况而定。不要一味追概念,不然到时候你发现你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。可悲。
总结
技术圈从不缺少热点话题,现在人人都在讨论「技术中台」,明天就可能讨论「数据资产」,这个说能降本增效,那个是救命稻草,不亦乐乎。 企业的第一要务是发展,而不是追热点。
对于企业来说,符合企业当前发展需要,能帮助企业找到效率、质量与成本的平衡点才是真正的「技术中台」
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。