app的网站域名,做的图怎么上传到网站,百度网页怎么设置青少年模式,永久免费网站申请注册从公众号转载#xff0c;关注微信公众号掌握更多技术动态 --------------------------------------------------------------- 一、中台简介 1.传统项目架构的痛点 (1)重复造轮子 各项目相对独立#xff0c;许多项目在重复造轮子#xff0c;让项目本身越来越臃肿#xf…从公众号转载关注微信公众号掌握更多技术动态 --------------------------------------------------------------- 一、中台简介 1.传统项目架构的痛点 (1)重复造轮子 各项目相对独立许多项目在重复造轮子让项目本身越来越臃肿也使开发效率越来越低。 (2)前台和后台发展速度不同 前台由各类前台系统组成的前台业务平台。每个前台系统都是一个用户触点大多是企业最终用户直接使用的系统是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。前台不仅仅是指前端它还包含和前端配套的服务端。 后台由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源数据 计算例如财务系统、产品系统、客户管理系统、仓库物流管理系统等这类系统构成了企业的后台。 后台管理的往往是企业的关键核心数据考虑到企业安全、审计、合规、法律等限制这样的系统也往往⽆法被前台系统直接使用或是受到各类限制⽆法快速变化不能⽀持前台快速的业务创新需求。此时的前台和后台就像是两个不同转速的齿轮前台由于要快速响应前端用户的需求讲究的是快速迭代创新所以要求转速越快越好而后台由于面对的是相对稳定的企业核心后端资源而且往往系统陈旧复杂甚至还受到法律法规、审计等相关合规约束一般是追求稳定至上越稳定越好 转速也自然是越慢越安全。 2.中台如何解决 为了解决上述痛点提高开发效率而整合出的中间组织为所有项目提供公共资源这个中间组织就是“中台”。中台的架构思想不仅影响项目结构也影响了研发团队的组织形式。 中台将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层为前台减肥恢复前台的响应力又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层赋予这些业务能力更强的灵活度和更低的变更成本或者干脆直接对于后台进行中台化改造通过配置化、自助化、白屏化等形式为后台加速从而为前台提供更强大、更迅捷、更易用的支援。 3.中台本质 (1)企业级能力复用平台 ①“企业级” “企业级”定义了中台的范围(这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围甚至可以是跨企业)它提供的是一套企业级的整体解决方案解决小到企业、集团大到生态圈的能力共享、联通和融合问题中台一个企业只需要一个(至少包含多条业务线或服务多个前台产品团队)。需要充分考虑未来架构规划对于战略的影响回归到业务上也和过去做系统完全不同面对的将是企业的业务全貌甚至是那些未来才会出现的现在还不知道长什么样子的潜在的创新业务。 ②“能力” “能力”定义了中台的主要承载对象能力的抽象解释了各种各样中台的存在企业的能力可能包含多个维度常见的例如计算能力技术能力业务能力数据能力AI能力运营能力研发能力……其中大部分的能力还可以继续细化和二次展开从而形成一张多维度的企业能力网。可以说中台就是企业所有可以被「多前台产品团队」复用能力的载体。这里有一个经常碰到的问题就是对于某一家企业来讲你说了有这么多种不同类型的能力到底哪些能力才是我们企业需要的哪些是值得中台化的优先级又怎么划分通过一系列Workshop从业务、数据、技术等多个方面切入通过一系列方法结合企业愿景市场定位和数字化现状跨越多条业务线试图将企业需要的能力和可复用的能力识别出来并为落地做好规划和准备。 ③“复用” “复用”定义了中台的核心价值传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注中台的提出和兴起让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上只有能复用的能力才有意义做中台。 「复用」是中台更加关注的目标 「可复用性」和「易复用性」是衡量中台建设好坏的重要指标 「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。 而实现更好的复用常常从两个方向做改进 一方面将更高抽象例如业务模式级别的通用业务逻辑通过抽象后下沉到中台这样前台就会更轻学习成本和开发维护成本更低越能更快的适应业务变化缺点是抽象级别越高越难被复用需要架构师对于各业务有深入的理解和非常强的抽象能力。 另一方面就是通过对于中台能力的SaaS化包装减少前台团队发现中台能力和使用中台能力的阻力甚至通过自助式Self-Service的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。 ④“平台” “平台”定义了中台的主要形式区别于传统的应用系统拼凑的方式通过对于更细粒度能力的识别与平台化沉淀实现企业能力的柔性复用更好地支撑前台业务。 中台首先体现的是一种企业级的能力​ 有了完善的中台就可以通过有限而比较固定的基础业务来满足无限而快速变化的上层业务场景了。从业务角度来看中台收敛了业务场景统一了业务规则从系统角度看中台相当 于操作系统对外提供标准接口屏蔽了底层系统的复杂性从数据角度看中台收敛了数据比如使用同一套订单数据模型让所有渠道的订单使用相同的订单模型所有订单数据 落到同一个订单库。 做中台建设的时候一定是跳出单条业务线、站在企业整体视角来审视业务全景寻找可复用的能力进行沉淀从而希望通过能力的复用一方面消除数据孤岛、业务孤岛一方面支撑企业级规模化创新助力企业变革孕育生态。虽然中台的建设过程虽然可以自下而上以点及面。但驱动力一定是自上而下的从全局视角出发的并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门例如CIO级别领导或是企业的战略规划部门因为只有这些横跨多条业务线的角色和组织才会经常去反思与推动企业级的能力复用问题。 (2)明确中台作用 ①做之前需要明确做中台的目标解决什么问题 你的规模大到足够消化中台吗 中台能给你带来什么商业价值 中台既不是一套软件也不是一套服务器而是一种理念、一套方法论。第三方公司的销售为了拿下客户也会夸大中台的效果。云徙前技术骨干周宏告诉 36 氪他发现销售去客户那讲 PPT 的时候“什么都承诺什么东西都有”造成一种中台能“包治百病”的感觉。这就造成了一个极为吊诡的现象一时间大家都在说中台似乎什么都可以往“中台”里装。有业务中台、数据中台、技术中台、安全中台、AI中台……从来没有一个“风口”像中台这样说不清、道不明。 ②中台实际作用 以用户为中心的持续规模化创新是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段并不是⽬标本身。 中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾提供⼀个中间层来适配前台与后台的配速问题沉淀能⼒打通并顺滑链接前台需求与后台资源帮助企业不断提升用户响应⼒。 4.中台和平台的区别 中台是支持多个前台业务且具备业务属性的共性能力组织平台是支持多个前台或中台业务且不具备业务属性的共性能力。 比如数据存放在Hadoop可以称为大数据平台中台使得数据不再是各前端业务独立管理而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合 中台还是平台与所在的业务环境相关。同样的能力对A业务来说可能具备业务属性从而是中台但对B业务来说没有业务属性从而是平台。比如说IDC建设和运维对AWS来说可谓至关重要的业务中台而对绝大多数企业来说只能说是平台。PaaS平台对SaaS厂商来说是业务中台但对绝大多数企业来说也只能说是平台。 所以不具备业务属性的能力即便是共性的即便有一个专职的部门在做即便对业务非常重要也不能称之为中台而还是应该称之为平台。因此应该说所有中台都是业务中台没有别的类型的中台。数据中台、搜索中台、内容中台、零售中台等等都是特定形式的业务中台也还是业务中台。 二、中台的使用 1.中台的分类 (1)业务中台 把各项目的共同业务进行下沉整合成通用的服务。业务中台需要具体承载支撑业务开展的必要业务元素封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。 (2)技术中台 避免重复造轮子提供通用的底层框架、引擎、中间件。「技术中台」有点像编程时的适配层起到承上启下的作用将整个公司的技术能力与业务能力分离并以产品化方式向前台提供技术赋能形成强力支撑。 (3)数据中台 抽象数据能力的共性形成通用数据服务能力为各个项目进行数据分析和采集。 从后台及业务中台将数据流入完成海量数据的存储、计算、产品化包装过程构成企业的核心数据能力。比如海量数据进行采集、计算、存储、加工的一系列技术集合包括数据模型、算法服务、数据产品、数据管理等等和企业的业务有较强的关联性是企业独有的且能服用的。 数据中台通过对于业务数据的二次加工并反馈回业务中台为业务进行数据和智能方面的赋能。 (4)算法中台 为各项目提供算法能力 (5)研发中台 软件开发是一项工程涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”从而助力创新性应用的快速开发迭代也是我们看到的很多企业正在做的事情我们可以管这种关注与开发效能管理的平台叫做研发中台。如果说技术中台为前台应用提供了基础设施重用的能力那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。 2.适用场景 从0到1阶段没有必要搭建中台首要目的是生存市场价值验证野蛮生长最适合 从1到N阶段适合搭建中台价值已被认可项目复杂度不是特别高搭建中台为后续快速迭代试错做准备 从N到N1阶段搭建中台势在必行企业规模大产品、服务、部分错综复杂。为了长期发展搭建中台避免以后越来越难以维护 什么情况下别做中台业务还没成型、没有相近的多个业务、人员能力不足——如果一个企业奔着中台做中台就是死。 3.如何实现前中后台的协同 企业级能力往往是前中后台协同作战能力的体现。如果把业务中台比作陆军、火箭军和空军等专业军种的话它主要发挥战术专业能力。前台就是作战部队它需要根据前线的战场需求对业务中台的能力进行调度实现能力融合和效率最大化。而数据中台就是信息情报中心和联合作战总指挥部它能够汇集各种数据、完成分析制定战略和战术计划。后台就是后勤部队提供技术支持。 前台主要面向客户以及终端销售者实现营销推广以及交易转化中台主要面向运营人员完成运营支撑后台主要面向后台管理人员实现流程审核、内部管理以及后勤支撑比如采购、人力、财务和 OA 等系统。 (1)前台 传统企业的早期系统有不少是基于业务领域或组织架构来建设的每个系统都有自己的前端相互独立用户操作是竖井式需要登录多个系统才能完成完整的业务流程。 中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案以实现各不同中台前端操作、流程和界面的联通、融合。不管后端有多少个中台前端用户感受到的就是只有一个前台。 在前台设计中我们可以借鉴微前端的设计思想在企业内不仅实现前端解耦和复用还可以根据核心链路和业务流程通过对微前端页面的动态组合和流程编排实现前台业务的融合。前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中实现前端页面、流程和功能复用。 (2)中台 传统企业的核心业务大多是基于集中式架构开发的而单体系统存在扩展性和弹性伸缩能力差的问题因此无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过 ETL 工具抽取数据实现数据建模、统计和报表分析功能但由于数据时效和融合能力不够再加上传统数据类应用本来就不是为前端而生的因此难以快速响应前端一线业务。业务中台的建设可采用领域驱动设计方法通过领域建模将可复用的公共能力从各个单体剥离沉淀并组合采用微服务架构模式建设成为可共享的通用能力中台。同样的我们可以将核心能力用微服务架构模式建设成为可面向不同渠道和场景的可复用的核心能力中台。 业务中台向前台、第三方和其它中台提供 API 服务实现通用能力和核心能力的复用。 在将传统集中式单体按业务职责和能力细分为微服务建设中台的过程中会产生越来越多的独立部署的微服务。这样做虽然提升了应用弹性和高可用能力但由于微服务的物理隔离原来一些系统内的调用会变成跨微服务调用再加上前后端分离微服务拆分会导致数据进一步分离增加企业级应用集成的难度。如果没有合适的设计和指导思想处理不好前台、中台和后台的关系将会进一步加剧前台流程和数据的孤岛化、碎片化。 数据中台的主要目标是打通数据孤岛实现业务融合和创新包括三大主要职能 一是完成企业全域数据的采集与存储实现各不同业务类别中台数据的汇总和集中管理。 二是按照标准的数据规范或数据模型将数据按照不同主题域或场景进行加工和处理形成面向不同主题和场景的数据应用比如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。 三是建立业务需求驱动的数据体系基于各个维度的数据深度萃取数据价值支持业务和商业模式的创新。 相应的数据中台的建设就可分为三步走 第一步实现各中台业务数据的汇集解决数据孤岛和初级数据共享问题。 第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。 第三步萃取数据价值支持业务创新加速从数据转换为业务价值的过程。 数据中台不仅限于分析型场景也适用于交易型场景。它可以建立在数据仓库或数据平台之上将数据服务化之后提供给业务系统。基于数据库日志捕获的技术使数据的时效性大大提升这样就可以为交易型场景提供很好的支撑。综上数据中台主要完成数据的融合和加工萃取数据业务价值支持业务创新对外提供数据共享服务。 (3)后台 那对于后台为了实现内部的管理要求很多人习惯性将这些管理要求嵌入到核心业务流程中。而一般来说这类内控管理需求对权限、管控规则和流程等要求都比较高但是大部分管理人员只是参与了某个局部业务环节的审核。这类复杂的管理需求会凭空增加不同渠道应用前台界面和核心流程的融合难度以及软件开发的复杂度。 在设计流程审核和管理类功能的时候可以考虑按角色或岗位进行功能聚合将复杂的管理需求从通用的核心业务链路中剥离参考小程序的建设模式通过特定程序入口嵌入前台 APP 或应用中。 管理需求从前台核心业务链路剥离后前台应用将具有更好的通用性它可以更加容易地实现各渠道前台界面和流程的融合。一个前台应用或 APP 可以无差别地同时面向外部互联网用户和内部业务人员从而促进传统渠道与互联网渠道应用前台的融合。 三、中台建设方法论 1.产品化思维建设中台 (1)现有组织架构的困局 无论是以传统行业为代表的直线职能型组织还是以互联网为代表的事业部产品型组织亦或是各种组合变种例如最常见的矩阵组织结构我们发现在中台建设的演进过程中都会或多或少陷入到同样的问题。 所以问题不在于企业原本是哪类的组织结构问题在于中台团队本身的定位。 在两种组织结构的推演中因为Shared Servie共享服务中心的组织概念历史悠久深入人心。所以大多默认会将中台团队一开始就定位成一个内部的共享职能团队。 中台团队被定位成一个共享职能团队中台团队与前台团队之间的关系是服务和被服务的关系这才是问题的关键。 因为中台是一个共享服务团队与前台是服务与被服务的关系。那自然前台出钱中台团队为其提供服务就是天经地义的事情正所谓“拿人钱财替人消灾”。 这时候就会出现两种情况 一种情况是因为中台建设的复杂性和长期性导致短期无法满足前台团队的短期业务需求业务方不满觉得花了钱没有得到相应的服务中台团队责因为背负着业务的持续施压无法按照自己的节奏推进中台建设痛苦不堪矛盾产生。我管这种矛盾叫做短期战术目标与长期战略目标的矛盾。 一种情况是中台团队迫于压力极力满足前台的需求。但因为中台的企业级性质中台团队需要同时面对多个不同的前台业务、前台团队。因为每一个前台团队都是“金主、客户、甲方”在中台团队眼中地位是一样的都是需要极力满足需求的。而因为前台团队“花了钱”为了能获取更多的中台资源使用权自然都会给中台团队提出各种各样的需求来争取到更多的中台资源导致中台团队的需求短时间剧增但因为毕竟中台的资源有限所以自然而然会出现之前反复提到的需求剧增、排期、冲突等问题矛盾产生。我管这种矛盾叫做多前台由于中台资源竞争所产生的矛盾。 (2)产品化中台建设 如果中台是一个产品则意味着 中台作为产品需要有自己的愿景定位不一定需要满足所有前台客户的需求这同样也意味着前台可以选择不使用中台的某些能力而选择自建。 中台作为产品需要有自己清晰的用户定位和用户划分前台作为中台的用户不再是平等的VIP前台用户的需求要优于免费前台用户的诉求通过产品上常见的用户划分来解决需求膨胀、排期、优先级和冲突问题。 中台作为一个产品需要想方设法体现自身的价值真正为前台客户解决实际问题并关注前台用户体验通过营销和售前等手段获取前台客户通过清晰的用户定位和产品力吸引前台客户让其主动选择采购中台产品。 产品的建设初期不一定启动资金直接从业务上切分可能需要类似于天使投资的企业战略投资进行初始孵化减少中台前期建设的业务交付压力甚至作为企业的战略级产品需要一些内部保护和孵化但仍需要快速验证其价值获取客户实现自负盈亏。 产品的建设过程可以借鉴精益创业思路需要尽快体现其商业价值如果一定时期内无法获取相应的前台用户前台不用或是其他考核指标不达标则需要进行中台建设止损类似于创业失败。 甚至在特殊情况下允许同一类型的中台产品存在合理的内部竞争同时对两个相似的中台产品进行孵化使用类似于内部赛马的机制解决内部服务差异性带来的内部产品垄断和定价困难问题。 中台产品为了用户留存需要对于前台客户提供产品级SLA提供客户运营客户售后服务保持产品平滑更新关注用户满意度实现客户留存与转化。 2.中台建设前必须想清楚的问题 (1)中台建设的愿景是什么 中台就像一个产品一样需要一个明确的愿景要让所有人能够清晰明确地知道中台建设对于企业对于业务的价值从而可以一起始终向着同一个方向持续前进。如果愿景缺失那就会很容易在中台建设过程中迷失自己的方向失去定力。(明确建中台是为了解决的问题对于企业和业务的价值)。 愿景帮助了解自己中台建设的目标帮助判断哪些事情是符合中台建设愿景的作为中台团队我们需要去考虑。在这之外更重要的是帮我们判断哪些事情不是中台要去做的为中台做减法这点在中台的建设过程中其实更加重要。 所以在建设中台前第一个要问自己的就是建设中台愿景是什么而且更重要的是这个愿景是需要所有的角色上到企业管理层下到每一位中台的相关人员都要明确并达成一致的。 (2)中台的用户和客户是谁 中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系必然在中台的建设过程中就会四面碰壁陷入“干系人旋涡”之中面临多方面的阻力陷入一个非常被动的局面。 所以在中台建设之前最好先搞清楚中台如果作为一款产品它的用户是谁客户又是谁用户和客户是一个群体么除了用户和客户还有哪些干系方他们对于中台都有什么期望这些期望又是否一致呢 中台因为其所处的特殊位置干系方往往纷繁复杂。在保持自己方向的前提下找到各方利益的结合点(比如某一条业务线更关注短期的战术目标)是一件非常困难且有必要的事情。否则在建设过程中就会受到各方的阻力产生摩擦导致中台很难推进落地。需要找到企业管理层与业务线关注点的结合点也就是长期战略价值和短期战术价值的结合点。推动者职级一定要高 但反过来讲中台也不应该只是极力去满足各方的诉求中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划要能做到听得进别人的话但是还要明确自己的目标走自己的路。而自己的目标就是来源于上面提到的中台建设愿景而中台的愿景也往往来源于企业的战略需要。 中台建设虽然需要兼顾各方的利益但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。 (3)中台的钱由谁出 对于企业内部可能代表的就是人和资源。所以这个问题还可以引申到中台的人从哪来从前台团队借调么还是重新招聘新组建呢一个中台建设往往会持续很长的时间那这些人的成本又由谁来承担呢如果说中台是为前台业务赋能的是不是就应该从前台各业务的预算中划分出一部分作为中台的建设预算呢 市面上的中台建设如果从投资结构来讲基本上可以分为两种类型即“众筹模式”和“投融资模式”。当然我们还能看到这两种类型的混合模式。 众筹模式从业务前台集资有钱的捧个钱场没钱的碰个人场能出预算的出预算能出人的出人来组建中台团队然后再反过来服务于前台业务团队 投融资模式(推荐)中台建设的前期从 0 到 1由企业本身的战略储备资源投资建设。经过一定时间的建设期比如 6个月然后逐渐找适合的前台业务进行试点接入如果效果好的话再推广到更多的前台业务团队。当服务稳定之后对前台也产生了稳定的价值之后再逐渐从前台收取一定的资源可以是人也可以是其他资源既所谓的收回投资并实现盈利。这里的盈利只是个比喻可能是满足了企业管理层对于企业战略目标的需求。 内部抽调是重要来源人员大都既懂业务又得懂技术团队内部最好有一个沟通和协调能力较强的人员这个人是中台团队对外沟通的桥梁不同企业叫法不同比如阿里最为核心的角色是业务架构师但可以简单理解为中台的产品经理。 (4)中台的目标如何验证 目前业界有一些中台的考核标准我们可以作为参考例如阿里巴巴的中台考核就是设计成40% 稳定性 25% 业务创新 20% 服务接入量 15% 客户满意度。 具体到一家企业某个中台的验证指标设计这是一个复杂过程而且往往还会不断演进需要结合上面提到的中台愿景、投资模式、干系人利益点以及其他相关因素来综合设计。 3.D4 模型 第一个阶段是Discovery帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT资产盘点全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌帮助我们做出最正确的判断。 第二个阶段是Define帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析一起来收敛推导基于中台的企业架构设计。并基于多维度的打分形成具体的实施路径规划说白了就是先做什么后做什么。这里需要注意一点此时收敛的是仍是企业架构层面像业务中台、数据中台这种级别的产品可能只是实施路径中的一个项目在这个阶段也可以回答那个我们关心的问题我们到底需不需要中台需要哪些中台 第三个阶段是Design帮助我们针对实施路径中的某一个产品例如业务中台做详细的设计包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等这个过程就是一个标准的产品设计过程只不过在中台项目中大多是针对中台类的产品而已。 第四个阶段就是Delivery这个时候我们就可以针对一个设计好的中台开始具体的交付过程我们采用的是敏捷结合精益软件开发的方式用快速迭代和基于反馈的调整最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题并且注重架构的治理与守护减少实现与设计的偏离。 四、业务中台落地 1. PD D4 的前两部分 Discovery 和 Define 合起来就是一个在企业级先发散再收敛的过程。对这个过程有一个称呼叫作Portfolio Discovery简称为 PD。实际实施时PD 是一个 48 周的头脑风暴工作坊。 对于中台的整体规划也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题。 我需要花多少钱在数字化建设上 这些钱该怎么花怎么分配要新增哪些系统是购买还是自研要干掉哪些系统优化 哪些系统继续维护哪些系统保持哪些系统不变 要不要建个中台 中台这种解决方案到底适合不适合企业仍然是需要调研和判断的。所以如果我们一开始就把中台作为一个确定的既定方向难免会限制住我们的视野有可能会错过比中台更好、更简单、更有效的解决方案或是过早地进行过度设计在根本不需要中台的场景下大张旗鼓地开展中台建设劳民伤财。 那企业到底要不要划分出一部分钱和资源来做中台建设对公司来讲添加中台这样一个新的架构层次有什么价值什么时候做最好优先级怎么样这也正是 PD 所主要关注和需要回答的问题。 而为了避免拍脑袋的情况出现Discovery 作为 PD 的前半程主要目的就是做充分的发散和调研也就是利用各种工具和手段帮助我们充分了解行业趋势、竞争对手的情况、公司的战略分解以及自下而上的现状调研等信息和环境为下一个阶段 Define 的收敛也就是对于企业新的业务架构、应用架构、技术架构甚至是组织架构的设计提供充分的信息支撑和依据。 2.企业战略分解及现状调研 (1)由外到内行业与竞争对手分析 所谓知己知彼百战不殆在详细了解自身之前我们有必要先将视野放开一些看看行业的大趋势与竞争对手都在做些什么。 “点 - 线 - 面 - 体”的理论。 点中台本身只是一个点那它可能只是一家企业发展到一定阶段的产物不是开始也肯定不是结束。 线从一家企业的发展过程这条主线上来看待中台这件事情来看这个点。它从哪里来为什么会出现又将向哪儿去甚至思考中台的下一个阶段会是什么会被什么替代 面同一个行业中的其他线也就是同一行业中的其他企业在做什么战略都是什么数字化建设的重点又是什么有没有同时在做中台建设建设的目标又是什么效果怎么样但这里要注意的是分析不一定就代表要直接借鉴人家都在建中台我们就要建中台。 体从其他的行业其他的面上来学习。如果其他面上有好的概念或是方法我们可以借鉴过来帮助自己的企业在自己的行业里取得先机。中台这个概念起始于互联网行业目前就正在被各个行业参考和借鉴。 业界已经有了很多非常成熟的方法可以直接使用例如常见的五力模型SWOT商业模式画布竞争对手产品线分析竞争态势分析矩阵等。 (2)自上而下企业战略分解 愿景是到达一定时间希望企业可以变成的样子或是达到的目标 依据战略平衡三角形在企业的愿景和目标已经确定的情况下 企业战略就可以简化理解成结合企业自身的能力与其所处的环境到底需要采取什么样的举措才能实现企业预定的愿景和目标呢 而企业战略分解就可以简化理解成结合企业各部门自身的能力与其所处的环境到底需要采取什么样的举措才能实现企业预定的愿景和目标呢 对于企业战略的分解业界也有很多工具和实践例如 BMGovernance设计的企业战略分析模型等。但为了应对变化越来越快的市场环境在 PD 中我们使用的是精益价值树Lean Value Tree的工具来帮助做战略愿景的分解的。 精益价值树是一种以价值成效为导向用于分析和沟通业务愿景、战略与投资的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐因此采用一种逐层分解的树形结构如下示意图 (3)自下而上现状调研与分析 如果把企业战略分解理解成从企业愿景自上而下的分析推导过程那是不是直接按照推导出的举措具体实施就可以了呢往往还是不够的因为每家企业经过长时间在市场中的搏杀能生存并发展到现在都会出现各种各样的问题和限制。如果脱离现状无视这些问题与限制就肯定会面临非常大的阻力与风险。 所以不但要自上而下地做企业战略的分解以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题收集汇总痛点另一方面又要求我们能跳出过去的限制重新从业务出发从用户出发去重新探索基于新技术、新架构下的一些新的可能性。 这里常用的工具和实践也很多例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。 充分且多维度的现状调研与分析不但能让我们对于业务、应用、技术、数据、组织现状也就是企业架构现状有一个全面清晰的认识还可以通过访谈与调研补充时间线上的上下文包括过去发生了什么为什么现状是这样子的未来大家希望是什么样的为什么 不过这里有一个问题需要关注那就是梳理的范围和深度。不要忘了我们此时做的是企业级的架构梳理宽度和范围可能会远远超过我们的想象。如果深度控制不好会发现转了半天还是在一个小的领域和业务线原地打转。所以面对这种问题和风险建议: 先完成自上而下的企业战略分解再开展自下而上的现状调研。因为做完战略分解我们已经对于公司的行业、业务、愿景、战略已经有了一些了解再开展调研的时候就会有个全局的把控对于粒度和深度都更容易拿捏。 做好充分的准备能够提前通过阅读资料和小范围调研完成的内容就提前完成。 制定详细的计划可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够可以用两天的时间梳理一条业务线的业务架构这样梳理就可以深入一些。但如果只有半天则粒度可以适当放粗先保证有一个全局业务视图。 建议刚开始做的时候可以粒度粗一些不要过早陷入细节不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解也是最见功夫的地方。在判断不好的时候可以先粗一些如果最后还有时间也可以再做一轮调研向下再展开一层。 这样的现状调研工作对于一个中型的有四五条不同业务线的企业我们实际实施大概需要24 周左右的时间当然还要视客户而定。完成调研工作后我们就对企业各方面的现状有了一个比较全面的了解并且也收集到了每条业务线大量的痛点和问题这样就有了对未来架构的展望。 3.企业数字化全景规划 (1)中台复用的能力类型 业务数据、业务功能、业务流程以及通用的技术能力 (2)使用DDD识别复用能力 中台本质上是领域的子域它可能是核心域也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域将通用的公共能力沉淀为中台对外提供通用共享服务。 使用领域驱动设计结合事件风暴这两个工具通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析识别出关键聚合再通过跨业务线的问题域叠加投影找出大家共同关注的问题空间和聚合从而继续扩展来做共性场景和能力识别。 ①中台建设要聚焦领域模型 中台需要站在全企业的高度考虑能力的共享和复用。中台设计时需要建立中台内所有限界上下文的领域模型DDD 建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界微服务划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型最终影响到微服务的拆分和项目落地。因此在中台设计中首先要聚焦领域模型将它放在核心位置。 ②项目级微服务与中台微服务 项目级微服务可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用这样前端就可以直接访问自己的微服务了。 企业级中台微服务企业级的业务流程往往是多个中台微服务一起协作完成的企业级中台微服务的集成不能像项目级微服务一样在某一个微服务内完成跨微服务的服务组合和编排。可以在中台微服务之上增加一层它的主要职能就是处理跨中台微服务的服务组合和编排以及微服务之间的协调它还可以完成前端不同渠道应用的适配。 4.中台的规划与设计 (1)确定中台产品愿景 中台的愿景作为所有问题的出发点需要足够简单明确才能做到像一个指南针一样成为我们中台建设过程中指引方向的工具也才能做到“遇事不决看愿景”。 (2)确定业务梳理范围 是不是所有的业务线都要梳理是不是端到端的所有阶段都要梳理业务梳理要到什么样的粒度这些都是经常面对的问题。 从业务线上来看就不一定所有的业务线都需要梳理。将关联紧密的业务梳理到一起长期独立发展的与其它业务线关联不大的不应梳理到一起。 (3)细粒度业务梳理 一般大家的做法都是基于现有的流程或系统对现有业务的流程进行梳理例如在电子商务领域大家经常提到的四流具体指的是信息流、商流、资金流、物流的梳理工作使用的工具也大多是流程图这种非常成熟的工具。 但是这种基于已有流程的梳理有时候会有一些限制简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢就是对于一些长期且成熟的业务现有的业务方式可能并不是一个最好的方式而是由于长时间发展以及和过去的各种周边限制以及 IT 限制妥协的产物。 这种回到问题域本身回到问题的原点基于用户需求在当前的业务及技术条件下重新设计解决方案的思维方法可以避开上面提到的业务债陷阱也多用于创新型业务的设计过程而这种思维方式也大量参考和借鉴了设计思维的方法。 所以和基于现状的传统业务流程梳理不同我们在业务梳理过程中大量地采用了基于设计思维结合用户体验地图User Journey Map和服务蓝图Service Map的方式。回到业务本身从问题域出发以用户为中心进行用户体验设计和业务服务蓝图的梳理。 通过范围内的业务架构梳理再结合最后的跨场景通用能力的分析我们就可以对关注领域的业务全貌有了一定深入的了解并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求我们是通过用户故事User Story的方式描述的。 (4)确定 MVP (1)运营前置制定迭代计划及接入计划 对于中台可能就是中台产品推广、前台用户接入计划以及接入后的运营支持。如果中台建设的中后期才开始考虑这些问题往往就有些晚了。 而且很多情况下前台是不会停下来等中台建设完等接入后再开始自己的业务演进所以往往都是前中台并行。所以提前考量运营计划尤其是接入计划尽量使用合理的接入计划来规避一些风险对于中台产品的建设也非常关键。 (2)度量前置定义验证指标 市面上最常见到的产品度量指标分为了四个大类也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开都能找到很多的常用度量指标。 而对于中台来讲与市场和用户之间还隔着一层前台所以在度量上就不如直接接触用户的前台系统这么清晰。但是中台是为前台业务赋能的又不能脱离开业务单纯只在技术上做一些度量例如接口稳定性和接口数量等这样也不符合中台对于业务支撑赋能的定位和价值。 所以一般在考虑中台的度量指标的时候还是把战略价值和业务价值作为出发点开始拆解和推导并且按照干系人关注点的不同用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下虽然维度和视角不同我们要保证所有指标体现的中台建设目标必须是一个。 而具体到实施方法因为每一个中台产品都是不一样的所以很难给一个标准的答案。在实操过程中建议你多换位思考多问几个“怎么How”。相信你比较熟悉 5Why 分析法这里可以稍微改一下用5How来驱动验证指标的设计。 那我怎么判断中台建设的成果如果回答是看对于新业务的赋能 那我怎么验证对于新业务的赋能效果如果回答是看新业务的上线速度 那我怎么验证新业务的上线速度如果回答是看新业务从立项到上线的时间 那我怎么验证…… 5.中台的建设与接入 中台所处的特殊位置对产品界定要求和对建模的难度都比其他终端产品的复杂度要高一个级别所以我们建议采用精益的产品研发流程保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程保证中台建设是一个持续演进和被业务驱动的过程。 (1)精益产品研发流程 这里叫精益产品研发流程主要是面对中台建设过程中的不确定性引入精益思想来实现价值的定义和快速流动及度量再结合敏捷开发实践让整个软件开发过程轻量、迅速、敏捷、价值驱动。 精益思想之所以流行关键在于其定义了一套完整的思想框架而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中我们也建议引入精益思想结合到软件的开发过程中小批量快速开发产品快速引入度量基于测量的数据快速对于之前的需求假设进行验证和认知并基于此做快速的调整。 敏捷关注的是价值确定的情况下如何通过小步快跑的迭代方式按节奏交付价值而精益关注的则是在价值并不确定的情况下如何用最小成本快速定位到真正价值点。 由于中台建设的复杂度非常高所以将精益思想结合敏捷思想应用到中台的建设和开发过程再配合后边马上会谈到的中台运营机制的建立可以让我们更好地应对中台建设过程中的各种问题例如最经典的中台边界界定问题。 (2)中台的运营、治理与演进 除了中台的建设过程同样不能忽视的就是对于中台建设过程中的持续治理及演进以及真正接入了前台之后对于中台的运营管理。如果没有运营管理则会在建设过程中产生很多困难和问题 ①中台产品的用户划分 中台作为一个公共服务部门一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限且有自己的愿景不可能无条件地满足所有前台用户的诉求往往就会陷入疲于应对的状态对前台的响应和服务质量也会急速降低。 怎么办呢问题的根本在于虽然我们说中台是企业级能力复用平台但我们经常会忽略的一点就是如果我们采用产品化的思维来构建中台那中台中所沉淀的能力并不是产品的全部还需要再加上 NFR非功能性需求或是我们常说 SLAService-Level Agreement服务等级协议才是产品因为不同的前台用户之间不只是对于中台产品的功能本身有着不同的诉求同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子比如核心业务对于中台的 SLA 稳定性的要求可能是 5 个 9性能是 5 毫秒而一个新的创新型应用可能还没有用户就不需要有这么高的要求。 ②Offering Capability SLA/NFR 对于前台用户基于需要的能力和 NFR/SLA 做用户划分。 最常见的就是三层用户划分机制。通过对于前台用户的分层我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源人或钱甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺 举个例子 当我们开始中台建设时可以只找到一个或是两个种子用户作为 Tier1 级别的用户来服务。对于这个种子用户的需求作为最高优先级的需求来对待并建立例行的沟通机制和服务响应机制。因为此时的服务还处于初建时期还不是特别的成熟所以可以采用“免费”的方式动用企业的战略资源来进行建设。这样对于前台用户来讲资源是免费的而且是一对一式服务自然也会乐意配合到中台的建设过程中。 当中台建设到一定阶段之后对于种子用户的服务已经接近稳定有了一定的能力沉淀也能释放出一定的资源了就可以利用释放出来的资源开始为 Tier3 层的用户构建自助服务控制台Self-Service Console并着手构建中台产品的运营团队制定 Tier3 层的NFR/SLA。在很多互联网企业这个过程常常由于做出来的自助服务控制台比较粗糙看起来也像是对于平台服务的增强和可用性优化和治理的过程大多数就是一个白屏幕加一些的配置选项所以常被称为“平台的白屏化”。 当中台的自助服务控制台创建完成Tier3 层次的 SLA 也构建完成后我们就可以重新签订 SLA将之前的 Tier1 用户迁移到 Tier3 层次即完成之前种子用户从定制化服务到自助式服务的迁移过程从而释放出更多的资源用于接入新的前台用户。 如果由于种种原因无法一步到位实现服务的完全自助化还可以通过构建 Tier2 层的SLA也可以通过重新签订 SLA将之前的 Tier1 用户迁移到 Tier2 层次通过“自助VIP 服务”的方式保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。 此时我们就已经有了三层的用户划分机制可以在企业内更大范围地发布 Tier3 的自助式服务通过这种方式实现更多用户的接入。同时因为已经释放出一些中台的资源就可以继续选取下一个关键的种子用户一般是关键业务作为新的 Tier1 级用户开始第二轮中台建设的推进。 6.落地中台 渠道 应用 渠道 应用层这是整个系统的对外部分包括了各个应用的前端如 App、小程序、公 众号等等这些是需要定制的部分。同时在对外部分我们还会提供 Open API供上下 游企业调用。 应用平台 应用平台是各个具体应用的母体它包含了各个应用的服务端比如小程序服务端、App 服务端等等这些服务端会针对具体场景做流程编排和信息的聚合。服务端和前端之间还有一个网关网关实现前后端隔离具体负责外部访问的安全验证和监 控以及内外部请求的路由和消息格式转换。 业务中台 业务中台是中台架构的核心它包括一系列的通用基础服务以及它上面的通用聚合服务和 下面的技术平台这个在前面已经详细介绍过了我就不赘述了。 后台 后台包括两部分第一部分是适配插件用于连接商户内部系统和中台基础服务比如在 中台的商品服务和后台 ERP 之间同步商品数据在中台的会员服务和后台 CRM 之间同步 会员信息。一般针对每个内部系统都有一个适配插件它起到了类似硬件驱动程序的作 用这个一般是定制化的。第二部分是企业内部系统这个是企业的 IT 基础设施业务最 终会在这里落地。 ​ 五、使用DDD规划和设计中台 1.DDD、中台和微服务的协作 DDD 有两把利器那就是它的战略设计和战术设计方法。 中台更多偏向业务模型形成过程是业务领域不断细分的过程过程中会将同类通用的业务能力进行聚合和业务重构再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。 在中台完成领域建模后就需要通过微服务来完成系统建设。此时DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说中台和微服务正是 DDD 实战的最佳场景。 中台是微服务的升级。在微服务架构下搭建的是一个个离散的服务如商品服务、订单服务等等。而在中台里这些微服务升级为了商品中心、订单中心每个中心更强调体系化包括更好的业务通 用能力更好的系统运营能力如监控、稳定性、性能的强化更好的业务运营能力比 如商品中心自带配套的商品管理后台。每个服务中心都围绕核心业务自成体系成为一个微内核这些微内核形成一个有机整 体共同构成了基础业务平台也就是中台。松散的微服务 - 共享服务体系 - 中台这 是微服务架构向中台架构的演进过程。 (1)DDD、中台和微服务的协作模式 更多的企业还是会聚焦在传统企业中台建设的模式也就是将通用能力与核心能力全部中台化以满足不同渠道核心业务能力的复用。 可以将需要共享的公共能力进行领域建模建设可共享的通用中台。除此之外还会将核心能力进行领域建模建设面向不同渠道的可复用的核心中台。而这里的通用中台和核心中台都属于业务中台的范畴。 DDD 的子域分为核心域、通用域和支撑域。划分这几个子域的主要目的是为了确定战略资源的投入一般来说战略投入的重点是核心域因此后面就可以暂时不严格区分支撑域和通用域了。领域、中台以及微服务虽然属于不同层面的东西但还是可以将他们分解对照整理出来它们之间的关系。下面这张图从 DDD 领域建模和中台建设这两个不同的视角对同一个企业的业务架构进行分析。 如果将企业内整个业务域作为一个问题域的话企业内的所有业务就是一个领域。在进行领域细分时从 DDD 视角来看子域可分为核心域、通用域和支撑域。从中台建设的视角来看业务域细分后的业务中台可分为核心中台和通用中台。从领域功能属性和重要性对照来看通用中台对应 DDD 的通用域和支撑域核心中台对应 DDD 的核心域。从领域的功能范围来看子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系我们就可以用 DDD 来进行中台业务建模了。 这里还是以保险领域为例。保险域的业务中台分为两类第一类是提供保险核心业务能力的核心中台比如营销、承保和理赔等业务第二类是支撑核心业务流程完成保险全流程的通用中台比如订单、支付、客户和用户等。根据 DDD 首先要建立通用语言的原则在将 DDD 的方法引入中台设计时我们要先建立中台和 DDD 的通用语言。这里的子域与中台是一致的那我们就可以将子域统一为中台。 中台通过事件风暴可以进一步细分最终完成业务领域建模。中台业务领域的功能不同限界上下文的数量和大小就会不一样领域模型也会不一样。 当完成业务建模后就可以采用 DDD 战术设计设计出聚合、实体、领域事件、领域服务以及应用服务等领域对象再利用分层架构模型完成微服务的设计。这就是 DDD、中台和微服务在应用过程中的协作模式。 (2)中台如何建模 中台业务抽象的过程就是业务建模的过程对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程中台业务建模的过程 第一步按照业务流程通常适用于核心域或者功能属性、集合通常适用于通用域或支撑域将业务域细分为多个中台再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力通用中台要站在企业高度考虑共享和复用能力。 第二步选取中台根据用例、业务场景或用户旅程完成事件风暴找出实体、聚合和限界上下文。依次进行领域分解建立领域模型。由于不同中台独立建模某些领域对象或功能可能会重复出现在其它领域模型中也有可能本该是同一个聚合的领域对象或功能却分散在其它的中台里这样会导致领域模型不完整或者业务不内聚。这里先不要着急这一步我们只需要初步确定主领域模型就可以了在第三步中我们还会提炼并重组这些领域对象。 第三步以主领域模型为基础扫描其它中台领域模型检查并确定是否存在重复或者需要重组的领域对象、功能提炼并重构主领域模型完成最终的领域模型设计。 第四步选择其它主领域模型重复第三步直到所有主领域模型完成比对和重构。 第五步基于领域模型完成微服务设计完成系统落地。 如果还是以保险领域为例的话完成领域建模后里面的数据就可以填上了。以通用中台的用户、客户和订单三个中台来做示例。客户中台提炼出了两个领域模型客户信息和客户视图模型。用户中台提炼出了三个领域模型用户管理、登录认证和权限模型。订单中台提炼出了订单模型。 2.用DDD重构中台业务模型 以保险行业的互联网电商和传统核心应用来做个对比分析。下面这张图这两者在业务功能上会有很多相似和差异这种相似和差异主要体现在四个方面。 核心能力的重复建设。由于销售同质保险产品二者在核心业务流程和功能上必然相似因此在核心业务能力上存在功能重叠是不可避免的。传统保险核心应用有报价、投保、核保和出单功能同样在互联网电商平台也有。这就是核心能力的重复建设。 通用能力的重复建设。传统核心应用的通用平台大而全通常会比较重。而互联网电商平台离不开这些通用能力的支撑但为了保持敏捷性一般会自己建设缩小版的通用功能比如用户、客户等。这是通用能力的重复建设。 业务职能的分离建设。有一类业务功能在互联网电商平台中建设了一部分在传统核心应用中也建设了一部分二者功能不重叠而且还互补组合在一起是一个完整的业务职能。比如缴费功能互联网电商平台主要面向个人客户于是采用了支付宝和微信支付的方式。而传统核心应用主要是柜台操作仍在采用移动 POS 机的缴费方式。二者都是缴费为了保证业务模型的完整性在构建中台业务模型时我们可以考虑将这两部分模型重组为一个完整的业务模型。 互联网电商平台和传统核心功能前后完全独立建设。传统核心应用主要面向柜台不需要互联网电商平台的在线客户、话务、订单和购物车等功能。而互联网电商平台主要面向个人客户它不需要后端比较重的再保、佣金、打印等功能。在构建中台业务模型时对这种情况应区别对待将面向后端业务管理的应用沉淀到后台将前端能力构建为面向互联网渠道的通用中台比如订单等。 可以用 DDD 领域建模的方法来构建中台业务模型。有两种建模策略自顶向下和自底向上的策略。 (1)自顶向下的策略 这种策略是先做顶层设计从最高领域逐级分解为中台分别建立领域模型根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设或旧系统推倒重建的情况。 由于这种策略不必受限于现有系统可以用 DDD 领域逐级分解的领域建模方法。从下面这张图可以看出它的主要步骤第一步是将领域分解为子域子域可以分为核心域、通用域和支撑域第二步是对子域建模划分领域边界建立领域模型和限界上下文第三步则是根据限界上下文进行微服务设计。 (2)自底向上的策略 这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模然后对齐业务域找出具有同类或相似业务功能的领域模型对比分析领域模型的差异重组领域对象重构领域模型。这个过程会沉淀公共和复用的业务能力会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。 以互联网电商和传统核心应用的几个典型业务域为例采用自底向上的策略来构建中台业务模型主要分为这样三个步骤。 第一步锁定系统所在业务域构建领域模型。 锁定系统所在的业务域采用事件风暴找出领域对象构建聚合划分限界上下文建立领域模型。下面这张图选取了传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域共计五个业务域来完成领域建模。 可以看到传统核心共构建了八个领域模型。其中用户域构建了用户认证和权限两个领域模型客户域构建了个人和团体两个领域模型传统收付构建了 POS 刷卡领域模型承保域构建了定报价、投保和保单管理三个领域模型。 互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。 在这些领域模型的清单里可以看到二者之间有很多名称相似的领域模型。深入分析后会发现这些名称相似的领域模型存在业务能力重复或者业务职能分散比如移动支付和传统支付的问题。那在构建中台业务模型时就需要重点关注它们将这些不同领域模型中重复的业务能力沉淀到中台业务模型中将分散的领域模型整合到统一的中台业务模型中对外提供统一的共享的中台服务。 第二步对齐业务域构建中台业务模型。 下面这张图可以看到右侧的传统核心领域模型明显多于左侧的互联网电商可以得出一个初步的结论传统核心面向企业内大部分应用大而全领域模型相对完备而互联网电商面向单一渠道领域模型相对单一。 这个结论也指明了一个方向首先可以将传统核心的领域模型作为主领域模型将互联网电商领域模型作为辅助模型来构建中台业务模型。然后再将互联网电商中重复的能力沉淀到传统核心的领域模型中只保留自己的个性能力比如订单。中台业务建模时既要关注领域模型的完备性也要关注不同渠道敏捷响应市场的要求。 有了上述这样一个思路就可以开始构建中台业务模型了。从互联网电商和传统核心的领域模型中归纳并分离出能覆盖两个域的所有业务子域。通过分析找到了用户、客户、承保、收付和订单五个业务域它们是可以用于领域模型对比分析的基准域。 下面以客户为例客户中台业务模型的构建过程。 互联网电商客户主要面向个人客户除了有个人客户信息管理功能外基于营销目的它还有客户积分功能因此它的领域模型有个人和积分两个聚合。 而传统核心客户除了支持个人客户外还有单位和组织机构等团体客户它有个人和团体两个领域模型。其中个人领域模型中除了个人客户信息管理功能外还有个人客户的评级、重复客户的归并和客户的统一视图等功能因此它的领域模型有个人、视图、评级和归并四个聚合。 构建多业务域的中台业务模型的过程就是找出同一业务域内所有同类业务的领域模型对比分析域内领域模型和聚合的差异和共同点打破原有的模型完成新的中台业务模型重组或归并的过程。 将互联网电商和传统核心的领域模型分解后找到了五个与个人客户领域相关的聚合包括个人、积分、评级、归并和视图。这五个聚合原来分别分散在互联网电商和传统核心的领域模型中需要打破原有的领域模型进行功能沉淀和聚合的重组重新找出这些聚合的限界上下文重构领域模型。 最终个人客户的领域模型重构为个人、归并和视图三个聚合重构为个人领域模型客户信息管理评级和积分两个聚合重构为评级积分领域模型面向个人客户。到这里就完成了个人客户领域模型的构建了。 还有团队客户领域模型其实团体客户很简单。由于它只在传统核心中出现将它在传统核心中的领域模型直接拿过来用就行了。 至此就完成了客户中台业务模型的构建了客户中台构建了个人、团体和评级积分三个领域模型。 通过客户中台业务模型的构建你是否 get 到构建中台业务模型的要点了呢总结成一 句话就是“分域建模型找准基准域划定上下文聚合重归类。” 第三步中台归类根据领域模型设计微服务。 完成中台业务建模后就有了下面这张图。可以看到总共构建了多少个中台中台下面有哪些领域模型哪些中台是通用中台哪些中台是核心中台中台的基本信息等等都一目了然。根据中台下的领域模型就可以设计微服务了。