侧边栏壁纸
博主头像
为了吃方便面博主等级

行动起来,活在当下

  • 累计撰写 12 篇文章
  • 累计创建 11 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录

传统企业中台的建设策略

Administrator
2023-03-21 / 0 评论 / 0 点赞 / 64 阅读 / 1961 字

与传统企业不同,拥有流量入口的超大型互联企业是互联网生态圈的创造者,而传统企业只是生态圈种群中的个体,除了需要做好原有的传统渠道业务外,还需要融入互联网生态圈,其商业模式、个体能力,以及与其他个体共生的能力决定了它的发展潜力。

相对互联网企业而言,传统企业的渠道应用更加多样化,有面向内部人员的门店类应用、面向外部用户的互联网电商以及移动App类应用。这些应用面向的用户和场景可能不同,但其功能与产品同质化严重,基本涵盖了企业的核心业务能力。此外,传统企业也会将部分核心应用的页面或API服务能力开放给生态圈第三方,实现业务的优势互补,相互借力发展。

为了适应不同业务和渠道的发展,过去很多企业的做法是开发很多相互独立的应用或App。但由于IT系统建设初期并没有企业级的整体规划,平台之间融合不好,直接影响了用户体验,归根结底是用户并不想安装那么多App。

为了提升用户体验,实现统一运营,很多企业开始缩减App的数量,在一个App中集成企业内的所有能力,联通前台所有的核心业务链路。

由于传统企业的商业模式和IT系统建设发展的历程与互联网企业不是完全一样的,因此传统企业的中台建设策略与阿里中台战略也会有所差异,中台需要共享的内容也不太一样。但是传统企业的中台建设策略与阿里的中台建设策略基本相同,都需要从业务中台和数据中台这种双中台的模式开始建设,如图所示。

image

我们来分析一下企业中台的能力建设过程。企业中台业务能力建设一般会经历“分”和“合”两个过程。通过将企业可复用的能力沉淀,形成多个不同业务领域职责单一的中台领域模型,然后对这些不同类型的中台业务能力进行组合和编排,形成企业级业务能力,从而在企业领域模型的“稳”和商业模式与业务流程的“变”中找到最佳平衡。

“分”的主要目标是通过业务领域边界划分和微服务拆分,建立稳定的、单一职能的领域模型,让业务和应用具有更强的扩展和复用能力。但分不是目的,而是手段,是根据单一职责原则实现业务能力的复用和高内聚。分的过程主要发生在业务中台,在完成业务领域和微服务拆分后,降低了应用建设的复杂度,使业务和应用具有更强的扩展能力和稳定性。

在完成业务能力拆分后,我们还需要对这些拆分后的、稳定的、可复用的核心领域能力进行组合、编排和融合,形成企业级能力,从而灵活快速地适配外部业务和流程以及商业模式的变化,这是“合”的过程。

“合”包括业务融合和数据融合。业务融合主要作用在前台,实现企业不同业务板块能力的联通、组装和整合,实现企业级业务流程的融合,提供一致的前台用户体验。而数据融合则主要作用在数据中台,实现企业不同业务板块数据的汇集、集成、智能分析和商业模式创新等,为企业前台业务提供统一的智能化数据服务。

在进行业务领域划分和中台设计时,由于渠道多样化,传统企业不仅要将通用能力中台化,以实现通用能力的沉淀、共享和复用(这里的通用能力对应DDD的通用子域或支撑子域),还需要将核心能力中台化,以满足不同渠道的核心业务能力共享和复用的需求,避免传统核心和移动互联等不同渠道应用之间出现“后端双核心、前端两张皮”的问题(这里的核心能力对应DDD的核心子域)。

上述这些都属于业务中台的范畴,需要我们解决核心业务链路的联通和不同渠道服务复用的问题。

注意
“后端双核心、前端两张皮”主要是指IT重复建设的问题。
对于相同的核心业务领域,传统核心应用和移动互联应用分别采用不同的技术栈重复建设,出现传统应用和移动互联应用两个核心。而两者在前端技术栈和展现方式又完全不同,无法复用。

除此之外,我们还需要解决微服务拆分后的数据孤岛、数据融合和业务创新等问题,这就属于数据中台的范畴了,尤其是当我们采用分布式微服务架构以后,就更应该关注微服务拆分后的数据融合和共享问题了。

综上,在中台设计和规划时,我们需要整体考虑企业内前台、中台以及后台应用的协同,实现不同渠道应用的前端页面、流程和服务的共享,还有核心业务链路的联通以及前台流程和数据的融合、共享,以支持前台一线业务和商业模式创新。

摘录来自《中台架构与实现:基于DDD和微服务》

0

评论区