数据中台成为电子商务行业技术圈里面的热议话题，从中引发争论的还有技术中台、业务中台等，今天本文重点谈论的是技术中台系统架构。因为中台模式太过热门了，连一些小型的电商平台公司也想要“蹭下热度”搭建技术中台来提升技术组织架构水平，实现所谓的“小前台，大中台”模式。可惜中台系统不是适用所有的电子商务平台，今天我们就来好好议一议。

一、对于电子商务平台企业，技术中台系统有什么作用？

先搞清楚技术中台系统的作用，先要清楚技术前台、技术中台与技术后台之间的关系，以及他们各自扮演的角色与作用。

1、技术前台

说白了就是为业务部门开发功能的技术团队，如果是ToC的业务，交付物必须贴近终端用户，如果是ToB的业务，交付物需要满足商家的需求。另外，研发资源的投入基本和业务对等，业务需求多，人数增加，业务需求少，人数相应减少，而且团队组织也基本按功能线来划分。

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

技术前台核心价值体现在对业务逻辑的理解与实现上，是技术向业务传递价值的阶梯，与线下销售团队的前台营销有一些类似。

2、技术中台

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

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

二、什么样的电子商务平台企业适合做技术中台系统架构？

电子商务系统公司要想做技术中台系统，客观环境需先满足两个前提：技术组织结构垂直化、业务线又多又复杂，否则技术中台系统的结果只会是两种：一场闹剧或者一笔赔钱的买卖。

前提1：技术中台系统组织结构垂直化

技术中台系统结构是经典的职能分工模式，技术中台架构开发按业务线分开，测试与运维形成上下层关系。客观的说，职能分工模式更适合瀑布式开发模式。先谈需求，再谈工期，随后按部就班地往下做，但当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能，做一个新系统的时候，会发现开发出来的技术系统很难变更，至少很难快速变更。

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

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

2、开发与测试、运维之间目标不一致（比如测试A君，开发要求只做功能测试，快上线，但测试老大却要求做非功能测试，保障质量，陷入永无休止的争吵）。

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

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

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

虽然整个组织结构还未完全实现垂直化分工，但已基本能够达到 “快速试错，小步快跑” 的目标。另外，这更像平台化的另一种雏形，就是逐渐把一些公共、底层的技术能力抽象出来，与业务逻辑分离，并形成各种接入式基础服务，同时可以为多个业务线提供服务。

也就是说，打造技术中台系统的前提是平台化，而平台化的先决条件是「组织结构垂直化，技术工具公共化」，如果没有这样的前提，就失去了打造技术中台系统的立身之基。

前提2：电子商务系统企业的业务线多且复杂

技术系统的核心价值是什么？对业务驱动型的公司来说，技术系统的核心价值是 “降低成本，提升效率”，而单从架构设计的角度来看，想达成这项目标的两个手段是「通用性」与「复用性」，这句话可以完美的衔接到技术中台系统上去。回顾几年前，电子商务平台企业的业务逻辑也曾非常单一，要么用银行卡买卖基金，要么用电子钱包买卖基金，方便，快捷。

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

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

为了帮助电子商务网站企业及时应对业务方的调整，大数据自动化营销平台【乐融沃】公司提出的技术中台系统解决方案：建议开始将技术中台业务开发中的一些共享服务分离出来，成立了业务中台组（由于本文以技术中台为主，业务中台的内容将不进行展开说明），将可以复用的服务和代码，交由这几个组开发出服务来，给业务组使用，这样数据模型会统一，业务开发的时候，首先先看看有哪些现成的服务可以使用，不用全部从零开发，也会提高开发效率。

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

而维护工具的这群人，不用贴近业务开发，每天的任务就是研究如何使用这些工具，如何调优，遇到问题如何Debug，形成知识积累。有了这么一群专职的人，就可以根据自身的情况，选择有限几个技术栈集中研究，限定业务组只使用这些工具，可保证选型的一致性。如果电子商务平台公司只有一条业务线，那就别搞技术中台系统了，把人力、资源、资金凑在一块干活，才更省钱更省力。

三、电子商务平台公司业务线复杂，是否需要搭建技术中台系统？

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

这种理论看似完美，但在实际执行上却困难重重。设想下，如果技术中台做得太多，资源投入就会很大，无法形成正向的利益传导，如果技术中台做得太少，又无法深入理解业务，导致适配方案落地性变差，渐渐失去价值。

技术中台系统好比就是一家 “乙方服务公司”，而技术前台更像是一家 “甲方电商公司”。

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

从职责角度来说，前台是 “快速应对业务变化”，中台是 “稳定高效提供服务”。一个追求效率，一个追求质量，这矛盾是天然存在的。

来举个小例子说明下：

前台部门的A团队和B团队，由于业务需要同时向技术中台系统提出要接入缓存服务的需求，技术中台的中间件产品线中有一套基于Proxy的自研分布式缓存系统，已在其他业务线运行多年，但由于A团队与B团队的技术债都各不相同，必须通过增加适配器才能完成接入，而此时人手又不够，按重要程度排序，只能先接A团队，但B团队也有需求，又等不及，怎么办呢？就先给他来个Redis接着玩玩吧，等A团队接好了再来接你的。

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

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

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

最终五分钟可以搞定的事，整整搞了三周才搞定。经过一年时间里，由于B团队系统的业务规模逐渐增大，Redis数量也逐渐增多，技术中台系统的运维成本与风险也随之上涨。这期间，中台曾多次与前台交涉，希望能够通过适配的方式将A团队接入缓存中间件，但始终未能达成。

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

最后是电子商务网站公司的技术中后台越发强大，但电子商务网站公司的业务规模却在逐渐萎缩。在互联网时代，技术圈似乎从来不缺少热议话题，对于电子商务平台企业来说，关键是能帮助用户找到效率、质量与成本的平衡点，或许才算是一个合格的技术中台系统，想要了解更多数据中台系统、技术中台系统、业务中台系统搭建解决方案，详情请咨询电子商务网站开发【乐融沃】公司！

<本文由数商云•云朵匠原创，商业转载请联系作者获得授权，非商业转载请标明：数商云原创>

作者：云朵匠 | 乐融沃(微信ID：shushangyun_com)

【乐融沃www.apprh.com】专注为企业提供电商大数据商城网站建设服务，长期为大中型企业打造数据化、商业化、智能化的大数据解决方案，为传统企业搭建一站式大数据自动化营销平台闭环体系，实现商城系统大数据互通、全链融合，综合提升平台运营效率与平台收益。