一、中台简介
1.传统项目架构的痛点
(1)重复造轮子
各项目相对独立,许多项目在重复造轮子,让项目本身越来越臃肿,也使开发效率越来越低。
(2)前台和后台发展速度不同
-
前台:由各类前台系统组成的前台业务平台。每个前台系统都是一个用户触点,大多是企业最终用户直接使用的系统,是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。前台不仅仅是指前端,它还包含和前端配套的服务端。
-
后台:由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源(数据 + 计算),例如财务系统、产品系统、客户管理系统、仓库物流管理系统等,这类系统构成了企业的后台。
后台管理的往往是企业的关键核心数据,考虑到企业安全、审计、合规、法律等限制,这样的系统也往往⽆法被前台系统直接使用,或是受到各类限制⽆法快速变化,不能⽀持前台快速的业务创新需求。此时的前台和后台就像是两个不同转速的齿轮,前台由于要快速响应前端用户的需求,讲究的是快速迭代创新,所以要求转速越快越好;而后台由于面对的是相对稳定的企业核心后端资源,而且往往系统陈旧复杂,甚至还受到法律法规、审计等相关合规约束,一般是追求稳定至上,越稳定越好, 转速也自然是越慢越安全。
2.中台如何解决
为了解决上述痛点,提高开发效率而整合出的中间组织,为所有项目提供公共资源,这个中间组织就是“中台”。中台的架构思想不仅影响项目结构,也影响了研发团队的组织形式。
中台将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层,为前台减肥,恢复前台的响应力;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本;或者干脆直接对于后台进行中台化改造,通过配置化、自助化、白屏化等形式为后台加速,从而为前台提供更强大、更迅捷、更易用的支援。
3.中台本质
(1)企业级能力复用平台
①“企业级”
“企业级”定义了中台的范围(这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围,甚至可以是跨企业),它提供的是一套企业级的整体解决方案,解决小到企业、集团,大到生态圈的能力共享、联通和融合问题,中台一个企业只需要一个(至少包含多条业务线或服务多个前台产品(团队))。需要充分考虑未来架构规划对于战略的影响,回归到业务上,也和过去做系统完全不同,面对的将是企业的业务全貌,甚至是那些未来才会出现的,现在还不知道长什么样子的潜在的创新业务。
②“能力”
“能力”定义了中台的主要承载对象,能力的抽象解释了各种各样中台的存在;企业的能力可能包含多个维度,常见的例如计算能力,技术能力,业务能力,数据能力,AI能力,运营能力,研发能力……其中大部分的能力还可以继续细化和二次展开,从而形成一张多维度的企业能力网。可以说,中台就是企业所有可以被「多前台产品团队」复用能力的载体。这里有一个经常碰到的问题,就是对于某一家企业来讲,你说了有这么多种不同类型的能力,到底哪些能力才是我们企业需要的?哪些是值得中台化的?优先级又怎么划分?通过一系列Workshop,从业务、数据、技术等多个方面切入,通过一系列方法,结合企业愿景,市场定位和数字化现状,跨越多条业务线,试图将企业需要的能力和可复用的能力识别出来,并为落地做好规划和准备。
③“复用”
“复用”定义了中台的核心价值,传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上;只有能复用的能力才有意义做中台。
-
「复用」是中台更加关注的目标;
-
「可复用性」和「易复用性」是衡量中台建设好坏的重要指标;
-
「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。
而实现更好的复用,常常从两个方向做改进:
-
一方面将更高抽象(例如业务模式级别)的通用业务逻辑通过抽象后下沉到中台,这样前台就会更轻,学习成本和开发维护成本更低,越能更快的适应业务变化;缺点是,抽象级别越高,越难被复用,需要架构师对于各业务有深入的理解和非常强的抽象能力。
-
另一方面就是通过对于中台能力的SaaS化包装,减少前台团队发现中台能力和使用中台能力的阻力,甚至通过自助式(Self-Service)的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。
④“平台”
“平台”定义了中台的主要形式,区别于传统的应用系统拼凑的方式,通过对于更细粒度能