某大厂提出中台概念之后,所有人似乎都很兴奋,似乎找到了一剂包治百病的良药。大厂在讲,客户在讲,竞争对手在讲。不讲中台,不上中台似乎企业就活不下去了。一时间风起云涌,百家争鸣,什么数据中台、业务中台、技术中台、组织中台、 AI 中台,甚至财务中台都炒的火热。但经过一段轰轰烈烈时间之后,随着众多中台项目暴露出越来越多的问题,似乎中台也不行了。大厂也承认自家中台化仍在探索中,也才完成百分之三四十。也有很多人把中台问题归结为组织问题。其实我们觉得“中台”概念忽悠了很多人。在没有真正想清楚之前就想比猫画虎实施中台,失败是必然的。中台到底是什么?让我们来深入洞察一下。
芬兰游戏公司 SuperCell 能以几个人的小团队在短短的几周内开发出一款新游戏,得益于把游戏开发过程中公共通用的素材、组件和算法等实现了服用和共享,然后马老师受启发提出了中台的概念。因此中台的本质是复用和共享。
从系统集成到企业服务总线到微服务架构,我们一直都在讨论复用和共享。企业服务总线可以看作是中台的萌芽,通过总线层服务实现各系统集成。但企业服务总线重在集成,是加层,导致系统之间的共享越来越复杂,性能往往难以满足需求。微服务架构的提出,简化了系统之间的关系,但微服务意在重构,它不是在原来的系统上封装一层接口,而是需要以微服务架构重构业务系统,是减层,在实现复用和共享的同时,提升性能和对业务的响应能力。正因为复用和共享的方式有很多种,所以中台的实现也存在多种可能。
中台建设的目的就是把一些可以复用的组件、数据、系统、能力实现重构共享,减少重复建设和投入,提升对业务的响应能力,这才是中台的本质。如果认识不到中台的本质,就无的放矢,就无从下手。很多人提那么多中台概念,其实是并没有理解何为中台。技术的发展是一脉相承的,不会凭空蹦出来。但不同的技术解决的问题是一样的,因此洞察到中台的本质,也就知道了为什么需要中台。共享的目的是为了减少重复、敏捷响应,这是建设中台的内驱力。
企业是否有市场压力去响应快速变化的业务需求是企业是否需要中台的内驱力。如果企业业务并没有要求适应市场快速的变化,则上中台可能得不偿失。不是所有企业都需要中台,也不是大企业才需要中台。 SuperCell 公司并不大,但他们有这样的需求。无论大象和蚂蚁,只要有资源共享的需求,有需要响应快速变化的需求,都可以规划中台、建设中台。如果企业成长到一定的程度,再去规划实施中台,其成本和代价是极其高昂的。就象某大厂,虽然经过这么多年的努力,其效果也并不令人满意。
某大厂中台的构建是因为有太多部门、太多的系统、太多的数据、太多的人员需要协调,这大大影响了对业务的敏捷响应能力,所以需要打破数据、系统、部门等之间的隔离,融合基础设施资源、数据、业务、人员等,提供统一的标准化服务,提升敏捷响应能力。
企业信息系统建设这么多年,基本上都是单体系统建设,通过不同方式的集成实现了部分复用和共享能力,但在如今大数据、云计算、人工智能应用大行其道的时代,已经无法满足数字化转型的要求。而中台化,通过抽取、沉淀、复用企业可共享能力,实现企业快速数字化转型目标,具备敏捷响应能力,更好的为客户提供服务和产品,以在数字化时代立于不败之地。
实施中台的目标是为了企业能够在数字化时代活下去并且能够活的更好,所以我们鼓吹数字化转型。数字化转型不是一朝一夕之功,中台的建设也不是一个项目就能完成。茅台等众多企业做中台遇到问题就在于没有想清楚拿中台做什么,有点人云亦云被忽悠。
我们曾经提出了 OneID 、 OneDataSource 、 OneService 、 OneWorld 的中台建设思路, OneID 通过唯一 id 将企业内的数据进行整合,提供高质量数据。 OneDataSource 是在数据整合治理的基础上实现唯一可信数据来源。 OneService 实现企业内服务的共享和重用,封装中后台逻辑。 OneService 是构建企业中台的基础,但往往要基于 OneID 和 OneDataSource 。 OneWorld 通过 OpenAPI 的方式实现和合作伙伴的互连互通,也就是要标准化,驱动企业数字化转型。中台的建设比较好的方式是采用微服务架构,实现平台融合。一个企业内不再是一个个单体平台,也不再纠结于相互之间的整合和集成,而是使所有这些平台都平滑融合在一起,形成一个整体,对内提供统一的服务接口 Service API ,对外提供统一的开放接口 OpenAPI ,构建起企业生存和发展的生态环境,相互依存,相互促进,共同发展。
我们说微服务意在重构!采用微服务架构实现企业内公共能力的复用和共享,往往需要对现有系统进行改造。在这个过程中,副产品是去 ERP 等系统,因为要服务化往往需要利用微服务架构重构业务系统。以前我们做 ESB 是为了集成各个系统,微服务就不能简单的在原有系统上封装,那样无法实现数据层的整合,通过微服务架构实现系统重构才能真正实现共享和复用。
ERP 、 CRM 等单体系统严重阻碍着企业数据和基础能力的复用和共享。传统大软件厂商提供的 ERP 、 CRM 等系统有各自的标准,集成共享扩展困难,阻碍着企业的数字化转型敏捷响应能力,因此在逐步沉淀、构建可复用可共享中台能力过程中,需要逐步替换掉传统的 ERP 、 CRM 等系统。
中台不是空中楼阁,不可能凭空出现,它需要基础平台的支撑。平台支撑中台,平台是中台落地的基础,是支撑中台构建、运行、运营的基础设施、工具、组件和组织。
我们说平台是技术概念,中台是业务概念,这就很好理解平台和中台的区别,也能很好的理解平台支撑中台的概念。中台并不是一个系统或者一个平台,它可能由很多个系统或者平台来共同构成。企业内可以复用和共享的能力可能来自于不同的系统或组件,它们可能由统一的标准化服务来提供,运行在企业内融合的各个平台之上,共同构成了企业具备敏捷响应能力的服务中台能力。因此我们一直强调“服务中台”而不是什么“业务中台”或“数据中台”什么的。每家业务不一样,数据不一样,因此每家的中台可能也是不一样的,你无法从一家公司拷贝一个完整的中台到另一家公司,但支撑中台的平台可以。比如基础的统一认证平台、集中权限平台、日志平台、监控平台、数据治理平台、云管平台、 PaaS 平台等等;或者中台的一些服务也可以,比如消息服务、知识图谱服务、 AI 算法服务、图形图像服务等等;但客户服务、产品服务等可能就会有很大不同。这些不同的服务通过场景化组合,可以敏捷的构建企业业务应用,敏捷响应业务需求,这就体现出了服务中台的价值。
平台支撑中台,通过平台分层融合来共同实现企业内各种系统、资源、数据、流程、人员的融合,以标准化的服务形式提供,共同组成企业服务中台。
我们为什么一直强调说“服务中台”,而不是什么技术中台、业务中台、 AI 中台、数据中台什么的,因为中台的核心不是技术,也不是业务,更不是一个 AI ,中台的核心是可复用可共享的标准化服务,更要使这些服务成为一个整体。我们说标准化,是需要遵循一定的协议规范的,就象人与人之间的交流通过语言,语言就是协议规范,可以是中文、英文、日文等等。只有协议一致才能相互理解,否则就需要翻译,比如加个协议转换适配器实现协议翻译。
规划建设中台就是要把企业内可复用可共享的组件、服务提取出来,采用微服务的架构重构服务,为企业内各个部门、各个团队提供统一的标准化服务,包括但不限于数据服务、基础设施资源服务、基础公共组件服务、平台服务、业务服务等等,这些服务运行于企业内的各种平台之上,敏捷的为企业内不同应用场景提供支持。通过场景化组合而不是定制化开发快速的满足业务变化的需求,满足客户要求,为客户带来利益,在数字化时代留住客户并赢得更多客户,这才是建设中台的价值。
人才和数据是企业的核心资产,数字化时代中台的价值是为了更好的融合数据,更高效地使用数据,数据融合是中台实施的第一步。
很多人单独提数据中台,有一定的道理,因为中台实施的第一步是数据融合,提供数据服务。先有数据才不至于巧妇难为无米之炊。数据,相对独立,因此数据中台的概念大行其道。但数据始终是为业务服务的,每家企业的数据是不一样的,使用数据的方式方法也是不一样的,所以数据中台也不可能完全一致。
数据融合的第一步是主数据,如果不谈主数据而去实施数据中台,很可能会陷入一团乱麻。主数据是骨架,支撑着整个数据体系,也是微服务拆分的重要依据。企业内各种数据系统需要根据企业业务主数据进行模型重构和融合,在此基础上构建数据服务,支撑业务服务和应用。这个过程涉及到繁琐的数据治理工作,因此我们也提到,数据治理做的好,微服务就可能做的好,数据治理做不好,微服务一定做不好。
中台实施的第一步是数据融合,关键在主数据,核心在数据治理,支撑在数据平台。
可以关注作者个人微信公众号:抛砖引玉之道至简
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论0 条评论