一文看懂技术中台、研发中台、移动中台建设全攻略( 三 ) _中台

数据中台提供了数据分析报表来响应运营，并在此基础上提供数据能力直接服务于业务。那能不能更进一步，提供诸如个性化服务等与智能相关的能力？答案是肯定的，通过AI中台就可实现。
AI中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题，通过AI能力平台化，降低对人员能力的要求。
与数据中台利用CPU级别的资源不同，AI中台需要扩展对GPU资源管理和整合能力，为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务，并最终为业务人员提供智能化的服务。
03 中台与前台的博弈中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同（见图3-13），会产生不同的中台建设路径。

文章插图
▲图3-13 中台对业务的参与度
一个极端理解是中台是工具，即将中台作为工具平台来建设。由于工具的通用能力强，抽象层度高，所以工具可适应各行各业的企业。如此，中台的研发人员可只专注技术相关的问题，而无须关注和了解企业本身的业务。
但是正由于工具无法深入业务场景，也不内含业务能力，导致中台不能沉淀业务，从而使中台开发人员与业务方沟通不顺畅，中台方无法直接为业务赋能。为了解这个问题，需要一个长期的业务理解和系统建设过程。
另一极端是中台完全为业务服务。中台方能快速理解业务需求，参与业务方的数据模型讨论、流程设计等，并将其变成系统实现。中台研发人员参与业务建设，符合中台为业务服务的目的，而且中台的能力也是通过业务沉淀下来的。
但是过分关注业务，过分与业务团队耦合，会受限于时间和团队的能力，不仅中台可能会没有考虑通用的业务能力，也会导致无法更专注于对中台技术的深入研究。
中台如果不从抽象度、适配性等角度出发，投入建设机制性的工作，很有可能局限于某单一业务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。
目前很多宣传中描述的数据中台走到了图3-13所示的最左侧：把数据建设的工具称为数据中台，或把数据治理、数据建模等工具宣称为数据中台（其实只是片面地在理解数据中台）。中台最主要的能力是提供业务方可重复使用的并与业务相关的能力。数据工具的能力太泛化，会导致与业务方的距离太远，从而不能很好地为业务方赋能。
从历史发展来看，一开始企业建设了一个前台应用A（如图3-14所示）。随着业务的发展，扩展到类似的业务，由于业务快速发展的需要，很有可能重新开发另一个前台应用B 。但随着应用B的建设，发现应用A和应用B的很多功能和能力是重复或相似的，因此考虑是不是可以通过建设公共的部分，避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。

文章插图
▲图3-14 中台与前台应用的关系
但是中台建设是一个新的命题，需要更强有力的团队，需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化，那么中台就只能满足部分前台业务的需求。
再者，如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能，由此可能发生本应由中台提供的能力却最终实现在业务应用中。中台越做越小，前台应用越做越大。这样一来，进一步压缩了中台的生存空间。
【一文看懂技术中台、研发中台、移动中台建设全攻略】因此，中台既需要满足业务的需求，但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性，便于业务方根据规范自主完成，减少沟通成本，提升效率。
“大中台，小前台”，并不意味着前台不重要。相反，建设大中台就是为了更好地服务于小前台。大中台要想发挥作用，体现出自己的价值，必须通过小前台的引导。因此，判断中台建设是否成功的指标应包括：前台有没有使用中台，前台从使用中台中获得了哪些好处，中台好不好用，愿不愿意继续使用中台。