为什么微服务化、数据仓库都不是中台.docx

为什么微服务化.数据仓库都不是中台？导读：企业在多年的信息化进程中，基于特定应用场景，引入或建设了解决定特 定业务领域问题的多套垂直的IT系统或套件。这些单体系统或套件间的业务能力 和数据不互通、不共享，形成了一个个系统烟囱和数据孤岛。企业这种业务及数据的烟囱式IT架构，正是中台进化的原点。中台经历过业界的 大力推广与布道，已为一些信息化比拟完善的企业带来红利。但是有些企业在演进的分叉口徘徊，由于种种原因，它们建设的所谓"中台"仅 解决了短期在性能、扩展等技术架构上的问题，如单体服务微服务化、数据资产 数仓化。在这里，我们需要明确一下，这些都不是中台。01微服务化不是中台以传统的思维来套用微服务,很有可能只是将原先彼此隔离的各单体业务系统通过微服 务的方式强行集成在一起，如图1所示。这种方式不是基于领域，而是从一个系统的粒 度层次来建设微服务。比方订单管理系缴OMS法注会员和订单，客户关系管理CRM ） 同样涉及会员和订单，而供应链管理（SCM ）那么涉及用户和订单。API网关图1多个烟囱应用微服务化可见，按此方式所建设的中台的各组成局部仍旧是互相交叉重叠的，数据还是重复 且不一致的，并不能表达中台是能力共享平台的核心理念。因此，只将原有单体业 务系统进行微服务封装，套上一个微服务的壳，连微服务都不算，更不能说是中台了。还有一些企业选择针对某个业务系统局限在此业务系统范围内进行微服务做见图2 ), 比方将OMS拆分为用户、会员、订单等，将CRM拆分为会员、订单、积分等。OMSCRMCRMAPI网关微服务集群用户 会员 订单SCM微服务集群会员 订单 积分WMSAPI网关API网关微服务集群用户 采购 销售微服务集群用户 仓库 出入库API网关图2单个烟囱应用微服务化从单个应用领域来看,这没什么问题。虽然使用微服务的技术架构解决了性能问题、水 平扩展问题等，能充分发挥微服务的优势，但从企业全局来看，数据还是没有打通，有 多套用户、多个会员系统、多份订单数据等，烟囱型系统仍然存在，因此这也不是中台， 不是正确的开展方向。中台是在将应用以微服务纵向拆分的基础上，加上横向切分，X各共享能力与上层应用分 开，形成可复用的共享服务层，从而促进业务和数据在各应用间的交叉共享，大大减少 重复建设和重复投资，这也造就了中台的共享理念"吏中台远远超出微服务的范畴。02数据仓库不是中台 企业对数据资产越来越重视，数据分析、数据运营被提上日程，而数据仓库规范与技术 也日臻成熟，于是企业开始以经营分析为主要目的建设自己的数据仓库。在建设的过程 中，企业会自底向上梳理业务板块，将各业务板块的数据分门别类，并按照数据仓库的 规范进行建设。而在中台尤其是数据中台的演进过程中，有些企业着眼于数据资产的集合，使用维度建 模的方法论从业务过程中抽象出通用维度与度量，组成数据模型，从而为决策分析提供 通用的数据分析能力，以满足企业数据报表分析的场景。这些企业将这种数据模型称为 "数据中台"。然而这并不是数据中台的全部。相比数据仓库，数据中台更加强调数据业务化，以服务 业务的视角去规划企业的数据资产，以运营的视角去管理数据资产，以实时、智能的数 据应用去服务业务。让数据用起来，不仅服务于企业数据分析，还主动迎合业务，梳理 需要数据赋能的业务场景形成业务闭环。综上所述，数据仓库只是解决了如何看数据的问题，而数据中台那么进行了更全面的规划 与建设，利用大数据和AI的特性解决业务洞察、精准决策、应用智能等一系列问题。-END -