Table of Contents
企业架构方法与实践
推荐语
- 架构设计之道在于针对 业务场景 给出优雅的解决方案
- 架构设计的过程是把静态的技术知识加以排列组合, 形成动态架构设计思维能力的过程
- 业务架构是战略、流程、组织等业务元素的 结构化表达
- 业务架构的首要责任在于实现业务与技术的深度融合, 打造能够让企业整体、尤其是 业务与技术之间进行的有效沟通
- 深刻认识到在大型企业的复杂业务体系中, 业务架构对企业信息化建设的巨大推动作用
- 业务架构需要充分描绘企业 现状 及企业 战略, 并使其具象化的
- 要求业务架构人员能深刻洞察企业业务及战略, 并能通过特定的方法对业务领域、业务流程、组织架构、数据等进行行之有效的 建模 和表征
- 业务架构是凌驾于技术架构之上的需求原动力, 可以说业务架构是商业价值交付的灵魂
- 所有的架构都是为了解决某种业务而诞生的
- 很多人忽视了 技术永远是为业务服务 的
- 学习业务架构方法, 才能真正学习到顶尖架构的精髓
- 基础架构相对更容易抽象, 从而更容易理解事物的本质
- 业务架构需要 解决各种形态的业务问题, 需要的是具备较强的业务背景和技术背景的复合人才
- 业务架构是连接企业战略和技术实现之间的桥梁
- 任何脱离业务的架构设计都是耍流氓
- 推动领域驱动设计时, 靠自下而上的革命是不够的
- 需要管理者从企业战略的角度认识到业务对于软件开发的重要性
- 需要 业务架构来提供一套可以实施和落地的方法论
前言
- 数字化浪潮
- 信息化、数字化, 实现业务与技术的深度融合
- 内容
- 业务架构的发展历程、作用、与 IT 架构的关系及业务模型的相关知识
- 战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法
- 业务架构方案制作、基于业务架构的实施、项目完成后的管理机制, 并比较了与敏捷开发的异同, 集中讨论了企业级项目的实施难度
- 进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率
- 对业务架构设计方法与当前热点—— "中台" 模式的一个比对
- 对方法论的深入探索和积极思考往往会让 "传统" 焕发新的 "生命力", 深度思考比追逐热点更重要
- 读者
- 管理者
- 在推动转型之前就有充分的认知
- 企业并非不善于设计 "战略" , 也并非不精通 "业务" , 而是不熟悉 "架构"
- 不清楚 如何将战略通过架构落实到业务和技术实现中
- 企业需要具备 "架构" 能力, 而这种能力应该由管理者带头, 从业务架构能力开始, 自上而下地建立起来
- 在推动转型之前就有充分的认知
- 项目经理、业务经理、技术经理
- 对企业级业务架构设计及落地的阐述有助于落地管理者 将方法论引入 其企业级项目工作中
- 寻找适合自身的方法论
- 需要各位深入思考其方法与自身行业的适配性
- 技术
- 实现 "业务人员" 的要求, 还是在实现 "业务" 的要求
- 从 "业务人员" 的众多要求中抽离出 "业务" 的要求
- 实现业务与技术的融合方面
- 技术人员自然是需要向业务侧多迈出一步
- 实现 "业务人员" 的要求, 还是在实现 "业务" 的要求
- 业务
- 忽略了对软件构建过程的关注, 正是这种忽略导致了在开发中出现大量 "冲突"
- 架构师
- 业务架构师并非一定要技术出身, 但是技术实力雄厚的人显然具有基础知识方面的优势
- 业务出身的业务架构师需要克服更多的技术障碍
- 管理者
业务架构
- 历史
- zachman 模型
- 按照 "5W1H" , 即 What (数据) 、Where (网络) 、Who (角色) 、 When (时间) 、Why (动机) 、How (功能) 6 个维度
- 结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统这 6 个层次
- TOGAF
- 强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统
- 基于架构 (或体系) 的集成, 而不是基于部件 (或组件) 的集成
- FEA
- 着眼于跨部门、跨机构提升业务效率, 解决重复建设、信息孤岛等问题
- zachman 模型
- 挑战
- 用的少
- 单体式或竖井式开发依然是企业更常采用的项目构建方法
- 这种开发基本上没有 横向视角, 所以无需强调业务架构, 通常的产品分析或者需求分析即足以满足其开发需要
- 难设计
- 业务架构对战略的分解、业务架构自身的整合与标准化, 到 IT 设计的过渡都存在不少陷阱
- 业务越复杂宽泛就越难驾驭
- 易偏离
- 由于客观因素可能会导致实施对业务架构的偏离
- 这种偏离如果没有得到及时纠正或架构调整, 那么累积久了就会造成业务架构的失真
- 难维护
- 维护架构的难度而心生放弃, 从而降低了对业务架构的评价
- 用的少
- 定义
- 以实现企业战略为目标, 面向复杂系统构建为使命, 构建 企业整体业务能力规划 并将其传导给技术实现端的结构化企业能力分析方法
- 业务架构与其他架构一样, 其 目的也是要降低复杂度
- 业务架构要想真正承担起这一职责, 还需要改进、简化业务架构设计的方法, 对业务人员更友好, 并且坚持使用业务架构方法做企业级需求管控
- 业务架构更突出的特点是影响参加过企业级业务架构设计工作的业务人员
- 他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变
- 面向业务人员, 以充当业务与技术之间的桥梁
- 业务架构与其他架构一样, 其 目的也是要降低复杂度
- 业务架构的 首要责任在于实现业务与技术的深度融合, 在于打造能够让企业整体, 尤其是业务与技术之间有效沟通的 "通用语言"
- 阿里提出的 "中台" 概念, 说到底也是一种业务架构设计结果, 是对企业能力的一种规划
- 阿里的实践代表的是 自下而上的积累 方式, 而业务架构设计通常是 自上而下的规划与演变
- 以实现企业战略为目标, 面向复杂系统构建为使命, 构建 企业整体业务能力规划 并将其传导给技术实现端的结构化企业能力分析方法
- 作用
- 业务架构的独特性在于帮助企业完成了深刻的 "数字化" 转型, 使企业通过信息技术将内部、业务与 IT 深刻地连接起来, 成为高效的 "数字化" 企业
- 转变思维方式, 架起一道跨越 "数字鸿沟" 的桥梁, 这就是业务架构的核心作用
- 通过建立业务架构, 业务和技术都能向对方的领域多迈出一步
- 如果 业务本身不能被很好地结构化、模块化, 那么技术人员也很难做出一个具有良好架构的系统
- 培养业务人员的逻辑思维、架构意识, 对于系统开发而言, 只有好处, 没有坏处, 要努力让业务 "懂" 技术
- 业务人员也能对技术的思维方式有所了解, 那将会对技术的合理应用乃至创新产生推动力
业务架构 与 IT 架构的关系
- 业务架构是大于 IT 架构范围的, 可以包含企业战略的非系统化部分, 是 企业业务的全景描述
- IT 架构则是用于企业信息化建设, 是企业战略的系统实现部分
- 业务架构是灵魂, IT 架构是容器
- 容器是灵魂的载体, 没有灵魂, 只有容器是没有生机的
- 所以, 技术人员需要关注业务和业务架构
- 业务架构是灵魂
- 可从企业战略出发按照企业战略设计业务及业务过程, 业务过程是需要业务能力支撑的
- 从战略到业务再到对业务能力的需要, 就形成了 支持企业战略实现的能力布局
- 可以将这个布局理解为业务架构, 它是企业为客户创造价值的设计过程
- IT 架构是容器
- 应用架构重点关注的是 功能布局
- 业务能力规划清楚之后, 向部署延伸一点就是应用架构
- 技术架构主要关注 分层结构
- 通过对业务特征、业务量等多种因素综合考虑分层的合理性和平台选型
- 业务架构人员应当了解本企业的技术架构及特点
- 数据架构中有一个重要的组成部分是 数据模型
- 数据模型与业务架构关系密切
- 安全架构
- 不再局限于传统的网络安全、信息安全等防护型工作, 需要体现出更多的 "规划" 特征
- 应用架构重点关注的是 功能布局
业务模型
- 模型是所研究的系统、过程、事物或概念的一种表达形式
- 可以是具象的, 如楼盘模型
- 表述的过程即可看作是建模的过程
- 表述还遵循了一定的语法规则
- 不同模型之间只是存在 建模视角 和 抽象程度 的差别
- 业务模型就是对业务的表达
- 对产品的设计、生产、销售、使用、售后管理过程的描述
- 包含所有参与方的目标、活动、角色、职责等
- 如果包含多条产品线, 每条产品线都有不同的业务过程, 而所涉及的参与方也会更多、更复杂
- 业务模型最主要描述的就是组织及其运作过程
- 对产品的设计、生产、销售、使用、售后管理过程的描述
建模方法
- ISO 9000 流程模型
- 对业务人员非常友好
- 表达能力比较单一, 对技术分析而言有所不足的问题
- BPMN 模型
- BPMN 的主要目标是为所有业务用户提供一些易于理解的符号, 支持流程的创建、分析和实现, 直到最终用户的管理和监控
- 开发 BPMN 的核心目标就是要构建从面向业务流程建模到面向 IT 执行语言的一座桥梁
- UML (统一建模语言)
- UML 对技术人员比较友好
- 但是其缺点也十分鲜明, 就是对业务人员非常不友好
- 功能模型
- 从用户的角度展示系统的功能, 包括用例图
- 对象模型
- 采用对象、属性、操作、关联等概念展示系统的结构和基础, 包括类图、对象图
- 动态模型
- 展现系统的内部行为, 包括序列图、活动图、状态图
- 业务架构的任务是搭建业务与技术之间的桥梁
- 作为业务架构在结构化表达方面不可或缺的工具
- 业务模型必须同时照顾业务与技术双方的感受
- UML 对技术人员比较友好
业务建模
- 架构相当于思想, 模型只是表达
- 模型质量尤其依赖建模者的经验, 是一个 "熟练工种" , 经验丰富很重要
- 两个原则
- 整体性原则
- 一定要将问题域 (或者说建模对象) 通盘 考虑清楚, 先有整体轮廓再考虑局部设计
- 合适性原则
- 模型中所包含的各个部分、各类元素要有机地结合在一起
- 放大需求、胡思乱想、生搬硬套, 只想进行 "理想" 的实现
- 漠视客观现实和循序渐进而导致设计结果的 "无用"
- 不能在生产环境中得到反馈, 那么建模者也会成为 "PPT 模型师"
- 整体性原则
- 模型思维
-
把握整体
- 要先抽出点时间, 考虑下事情的来龙去脉、前因后果, 这样才能控制好工作的度, 以免过犹不及
-
穿透现象
- 透过现象看本质, 注意事物内在联系、本质差别的能力
- 找到解决问题的最佳方案
概念 定义 举例 现象 直接观察和可感知得到 外貌, 声音, 行为举止 表象 与现象类似, 通常带有一定的偏见或误解 生活方式的刻板印象 本质 事物或现象内在的联系和特征, 是不能直接观察或感知的 物理研究物质相互作用的规律的学科, 化学研究物质的组成结构的学科, 生物研究生命起源演化等学科 -
保证落地
- 无论做出什么样的设计方案, 都会以落地实施为前提
- 落地靠的是经验、方法、能力, 而不完全是信心
-
业务架构设计
- 包括设计和实现两个不断交替上升的过程
- 设计过程
- 为从企业战略分析出发, 通过梳理企业目标, 发掘能力需求
- 企业自身业务与技术水平发展产生的 主动 能力需求
- 也可能是科技导致的业态变化、竞争压力产生的 被动 能力需求
- 再通过 价值链分析方式, 构建企业整体能力布局
- 在分析过程中, 将能力需求放入能力布局中, 并以此在业务层面落地战略、检验战略的可行性, 甚至调整战略
- 为从企业战略分析出发, 通过梳理企业目标, 发掘能力需求
- 落地过程
- 主要为通过业务架构驱动 IT 设计、协调实施过程
- 在实施中对业务架构进行基于实现的最终调整
- 确保业务架构与 IT 实现之间的一致性
- 优秀的业务架构实践
- 不能仅单纯地停留在业务分析层面, 也不能只满足于业务能力的组件化聚类
- 要时刻关注新技术、新业态的变化, 适时引入新理念、新方向, 使之具备与时俱进的能力
- 将 对新技术的理解 首先 通过业务架构设计引发业务变化, 用新技术理念推动业务模式演变, 再进行 IT 技术开发, 这才是理想的 "业务与技术融合"
- 设计过程
- 企业战略设计模型
- 愿景、使命和目标这 3 部分作为 "屋顶"
- 无法衡量的目标只能是个精神口号, 不能转化为行动
- 必须要 "量化" 出来, 成为可执行的目标
- 不落实到流程中的战略是无法被执行的
- "屋顶" 之下左侧是战略、右侧是战略能力
- 战略是为了完成上面提到的目标所需要采取的路线、方法
- 战略能力则是为了完成这一策略所需要的能力
- 下一层级
- 价值定位
- 企业为哪种类型的客户提供哪种类型的服务就是企业的价值定位
- 分解到各个领域
- 具体需要采取的工作和行动
- 价值定位
- 最下边的是收入和成本
- 上述行动成功后应当产生预期的收入
- 上述行动会带来合理的成本支出
- 收入与成本的差额就是收益了
- 即对上述战略的最终校验
- 愿景、使命和目标这 3 部分作为 "屋顶"
对标分析的问题
- 对标是为了通过对比与模仿, 引入优秀的发展经验
- 要先认清自己, 再了解别人
- 无异于照着别人的药方抓药给自己吃
- 全部学会并运行顺畅了, 再谈改良
- 光在 "别人家的事情" 上下功夫, 导致无效对标
- 甚至让对标分析 "带偏" 了自己
- 咨询项目启动时, 企业通常也是才真正开始思考自己的问题到底是什么
- 企业对自己的认知其实是有限的, 很多问题并没有深入挖掘根本原因和产生环境
- 只有真正的在内部无法攻克的问题才值得去对标
组织结构的影响
- 对组织结构的梳理, 在需求分析过程中也会经常遇到, 内容包括部门职能、部门关系、岗位等
- 康威定律
- 任意一个软件都能反映出制作它的团队的组织结构, 这是因为人们会以反映他们组织形式的方式工作
- 分散的团队可能采用分散的架构生成系统, 集中的团队更有可能采用单体的架构生成系统
- 两个凡是一个但是
- 凡是公用的部分, 应该 照顾到所有利益相关方的需求
- 凡是已实现的功能都应该对新的需求方开放并支持 必要的扩展, 这是企业级设计应该追求的目标
- 但是, 一旦系统的设计边界跨越了单个部门的职能范围时, 都会出现部门利益问题, 无非是企业规模、文化差异造成的协调难度的差别
- 部门利益是部门需求的天然边界
- 各部门在参与到企业级谈判中时, 都是首先要满足自己所在部门的业务诉求
- 业务架构的设计者, 拿出来的方案最好是以一种更有效的方式来满足所有相关方的需求, 而不是单纯做抽象、归并
- 部门利益是做企业级的最大障碍, 跨越这个障碍是对业务架构师设计能力的最高挑战
- 在项目组间搭建起企业级架构协作网络
- 提升架构 决策效率, 才能使得企业级架构不至成为 "瓶颈"
业务架构的设计过程
- 业务架构强调的是 整体性 , 需要有 横向视角 通观整个企业的生产过程
- 直接开始进行业务流程分析, 那就走上了竖井式开发的老路
- 展开垂直的业务分析之前, 必须先确立 一个统一的分析框架 作为 观察 各个业务线的统一方法
- 将企业需要的 业务能力 进行分类汇集, 从而产生合理的业务架构
价值链分析
- 波特价值链模型
- 边际
- 企业基础设施
- 财务
- 采购
- 人力资源管理
- 产研
- 企业基础设施
- 利润
- 销售
- 售后
- 边际
- 引入价值链分析主要是为企业横向审视自身的业务能力提供分析框架
- 价值链主要包括基本活动和支持性活动
- 基本活动是指主要生产过程
- 支持性活动指对基本活动起辅助作用及维持企业基本运转的各类活动
- 可以将支持性活动整合后并入到基本活动中, 形成只有一个维度的价值链
- 可以是个性化的活动
- 只需符合企业的特点, 覆盖其价值创造过程
- 价值链主要包括基本活动和支持性活动
划分业务领域
- 搭建好价值链这一 横轴 之后, 就可以基于价值链的各个环节分析多个 竖轴
- 业务领域其实是企业确定以某类产品服务某类客户的一个业务范围
- 为实现这一价值定位, 企业在整个价值链上的 各种业务活动的有机结合
- 业务领域的划分取决于企业的战略和价值定位, 也就是打算为哪种类型的客户提供哪种类型的服务或产品
- 一个业务领域实际上就是由一组业务活动构成的, 业务活动中的角色和任务
- 业务活动中的角色和任务, 体现了所有参与到价值创造过程中的组织单元的分工协作关系
-
划分领域 其实包含了两种方式, 从客户出发和从产品出发
- 从客户出发, 很多产品会有交叉；而从产品出发, 则会避免这一问题
- 产品指的是是同类产品的集合, 比如存款、贷款、托管、资管、投行等
- 而不是活期存款、定期存款、通知存款这种更细的产品维度
分析业务流程
- 首先要知道整个公司是怎么运转的
- 然后思考怎么让公司更高效的运转
- 将一个业务领域中的 所有业务处理过程 按照价值链约定的范围进行分解
- 形成每一个价值链环节中的一个或者多个 工作流
- 整个企业必须统一 采用一种语法标准 , 否则将会无法进行企业级 整合
- 形成每一个价值链环节中的一个或者多个 工作流
- BPMN 语法
- 一个工作流在 BPMN 语法中称为一个 活动 , 每个活动都可能会有多个不同的角色共同参与
- 工作流的分析重点在任务上
- 每个角色在活动中承担的 职责 称为 任务
- 任务在后续的设计中对功能、业务组件内部结构的影响比较大
- 活动之间是可以靠 事件 串接起来的
- 业务架构设计是从企业战略开始的, 分析到业务领域这一层级时, 要将战略分析过程中梳理出的能力需求落实到工作流中
- 业务领域内的活动是否能够有力地支持战略的实现
- 业务领域内的活动是否能够有力地支持战略的实现, 是否能够有效地服务客户, 是否能够有效地应对行业竞争, 也就是先进性的衡量
- 流程建模
- 需要不断地练习、摸索, 自己总结套路
企业级数据模型
- 流程模型分析了行为, 数据模型分析数据
- 业务架构的重点在于生产阶段的管控, 而非建模阶段
- 生产阶段要通过数据管控平台或工具对数据字典进行严格管理
- 未进入数据字典的数据项, 将无法生成企业唯一的数据项 ID, 无法在设计时被使用, 从而达到 "严防死守" 一般的控制
- 首先要对业务数据进行全面建模, 再对生产进行严格管理, 并对历史数据进行处理
- ER 实体关系图
- 按照对业务对象的划分, 将数据属性按照实体聚类, 并描述实体间的关系
- 指导程序设计和数据库设计
- 构建企业级数据模型时, 就需要横向分析所有业务领域的 ER 图
- FSDM
- IBM 的一个企业级数据模型, 囊括了银行约 80%的业务数据
- 将数据分为九大类, 分别是关系人、合约、条件、产品、地点、分类、业务方向、事件、资源项目
- 这个框架可以将数据实体、数据属性进行归类, 形成统一的企业级逻辑模型
- FSDM
行为和数据的结合
- 流程模型表达的是 "处理" , 数据模型表达的是 "输入" 和 "输出"
- 数据模型和流程模型的组合, 可以清楚地描述出
- 什么样的 场景 (事件_) 或条件下
- 由谁 ( 组织 / 角色) 将会触发一组业务活动
- 业务活动需要的 输入 (实体_) 有哪些
- 业务流程处理的 业务规则 是什么样子的
- 规则可以由不同的 任务 进行 编排
- 经过业务流程的处理后 输出 (实体_) 有哪些
- 一个业务领域是由一组活动构成的, 而这些活动又是分布在价值链的不同环节中
- 数据模型包含 主题域 这个层级, 即将关系较近的数据实体聚合成一个分类
- 比如按照产品划分主题时, FSDM 中的产品分类下就可以建立一个 "存款" 主题域
- 将存款业务相关的数据实体放入其中, 并使用 ER 图的方式进行表达
- 比如按照产品划分主题时, FSDM 中的产品分类下就可以建立一个 "存款" 主题域
- 数据模型包含 主题域 这个层级, 即将关系较近的数据实体聚合成一个分类
- 在软件设计上, 通常会考虑将关系较近的数据实体聚合在一起, 按照行为接近数据的原则, 再将相应的功能聚合成一个组件
- 从业务模型的角度来看, 就是按照主题域 划分边界 , 将与主题域内实体相关的任务聚在一起构成 业务组件
- 数据生成职责的唯一性, 数据应该只有一个唯一的可信数据源, 并负责该数据的生命周期
- 针对数据的操作 ( 修改/ 新增/ 删除) 聚合在一起形成组件
- 读基于性能考虑, 引入值对象或 CQRS 架构
- 这些原则将在一定程度上影响任务 边界 的划分
- 因为在任务中要表达对不同主题域数据实体的写操作
- 实践过程中这里需要具体问题具体分析了
- 应该将任务切分开来呢?
- 还是直接复用其他组件中已有的对该数据实体的写操作
业务架构的整体逻辑关系
- 业务架构的设计包括
- 价值链
- 构建企业能力统一视图的 "横向" 结构
- 业务领域
- 构建企业能力统一视图的 "纵向" 结构
- 业务流程如何通过组合实现领域级的业务目标
- 业务流程 (即活动、任务、角色)
- 业务流程由业务活动组成
- 由不同角色分别完成若干任务
- 这些任务之间遵循一定的 业务规则
- 任务执行过程中其必然与业务数据发生联系
- 由不同角色分别完成若干任务
- 业务流程由业务活动组成
- 业务数据
- 数据主题域将关系紧密的数据进行聚类
- 与数据关系紧密的行为 (也就是任务聚类)
- 业务组件
- 包含行为和数据的业务组件, 组件代表了企业的某一类业务能力
- 价值链
- 业务能力复用
- 在设计及后续迭代过程中多注意对任务的企业级分析和对组件能力的开放共享
- 避免因组件能力与主要应用部门间的关系产生对其他应用的自然壁垒
- 数据在组件间是可以根据需要自由流动的
- 这种流动也是建立在企业级数据模型对数据的统一定义的基础上的
- 封闭变化, 开放调用
- 对 任务边界 进行长期的企业级打磨, 最终会使组件能力的内聚性增强, 职责更集约
- 在设计及后续迭代过程中多注意对任务的企业级分析和对组件能力的开放共享
业务架构设计的难点
- 企业级业务模型的建设离不开标准化过程, 做企业级模型需要横向对比分析企业的所有业务领域
- 以期在设计上实现 "以更少支持更多"
- 同时实现快速的灵活响应和减少重复开发这两个目标
- 业务架构设计所面临的最大难点——标准化工作
- 业务架构模型的标准化包括
- 数据标准化
- 企业级数据模型要保证数据 实体和属性的唯一性
- 重复的概念会造成数据的 "同义不同名"
- 通过与 流程模型 的配合, 从语义层面逐一澄清了
- 企业级数据模型要保证数据 实体和属性的唯一性
- 任务标准化
- 语义对接
- 识别任务需要使用的数据实体
- 从语义方面去理解流程和数据的关系
- 要通过语义分析判断任务、数据实体的颗粒度是否合适
- 分析重复的业务动作
- 通过企业级数据模型去除重复的数据概念之后, 任务与实体之间的写操作对应关系, 可以清晰地发现重复的操作
- 标准化的建模判断
- 找到重复动作之后就需要做出建模的决策, 是分开建模还是将所有对客户信息进行写操作的部分集中到一起建模
- 可以将各业务领域中与之相关的任务或者涉及该操作的任务中的客户信息部分全部抽离出来集中起来组成一个组件
- 语义对接
- 数据标准化
避免 "过度整合"
- 业务上自然是要重新审视、理清业务流程，搞清楚具体差异
- 数据上则要重新检视数据实体划分的颗粒度是否正确
- 是否因为包含的属性太多而导致内聚性不够
- 流程模型与数据模型之间的语义互查是进行合理标准化的关键，同时这也是一个反复锤炼的过程
融合
- 业务人员与技术人员融合得越好，就越能产生高质量的模型和系统
- 依靠高质量的建模输入
- 既要包括完善的业务资料, 更需要有丰富经验的业务人员
- 不合理的设计一旦传导到开发上，就将产生高昂的纠错成本
- 这种标准化也是识别中台通用能力的基础
- 在技术人员与业务人员的不断融合、反复的标准化与去重过程中沉淀下来的
案例
- 价值链侧重于划定业务环节，并分析环节所包含的业务能力