企业级业务架构设计（3） 落地篇

企业级业务架构设计

落地篇

从项目管理的角度来看，时间是项目的最大敌人。但从系统实现的角度来看，时间又能解决一切问题，包括企业整体对方法的理解和“通用语言”的形成。除了架构人员自身的不懈努力之外，时间也是你可以依靠的“盟友”。

从业务模型到业务方案

业务架构不等于需求分析

业务架构设计并不是为了停留在纸上，而是为了实践，为了推动开发，尤其是面向复杂系统的企业级开发。

这个架构虽然分析得有条有理，却并没有精细到可以直接出IT设计方案的程度。也就是说，它只能明确企业级架构，而不足以替代具体的需求分析。

企业级业务架构是一种规划，它要求IT设计继承这套结构，继续向下分解为IT设计元素。企业级业务架构是一座桥，业务通过这座桥以更加结构化、逻辑化的方式进入到软件过程当中。

业务架构方案制作

业务架构落地过程的第一步，即将模型转化成业务架构设计方案。将模型转化为方案的过程实际上是一个导读和解释的过程，方案主要包含3个部分的文档：企业级架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述。

• 整体描述：单独作为整体进行介绍的内容，

主要包含：企业愿景、使命、目标介绍，外部干系人介绍，企业战略介绍，企业战略能力介绍，企业价值链介绍，全部业务领域的整体介绍，全部业务组件的整体介绍，全部数据主题域的整体介绍，企业整体组织结构的介绍

业务架构师非常适合作为与业务人员接触的“技术第一人”，在工作中，业务架构师可以及时调动需求分析人员、产品经理、开发人员提早参加到需求的形成过程中，将需求管理直接转变为业务规划，这才是各方都希望实现的融合与快速反应。此外还要保证业务架构师的替补和轮岗机制。

企业级理念的长期保持和应用则是更为困难的事情，需求管理机制对非科技类企业而言，很难成为企业的工作重心。

在互联网企业中时常能够听到这些企业的技术人员抱怨业务与技术之间的互不理解，那就更不用说传统企业了，所以要重视业务架构师的培养，从企业级业务架构入手、从顶层设计入手。

小团队应对之道

大型企业之所以有必要对文档制作提出较高的要求，也是“熵增”理论客观作用的结果。规模变大容易导致无序的大幅度增加，为了对抗无序，自然需要消耗更多的能量，文档就是消耗能量以抵抗“熵增”的一种方式。

“敏捷”组织方式优先的小企业来说，它们一定会觉得这样的文档处理过程太过繁琐，“消费”不起，这是很现实的问题。。这种情况下，重要的已经不再是文档了，而是“通用语言”的形成，即所有相关方共同形成的对模型一致的解读能力。

在具有一致解读能力的基础上，由于不用考虑规模导致的复杂度，因此也就可以专心于效率的提升，降低对文档的要求。但是，业务建模过程最好要有合适的工具做支持，除了提升协同效率之外，也可以方便对架构设计的快速查询。(感觉又有了活文档的用武之地)

充分解释架构方案

业务架构方案做好之后，不能指望IT设计可以自然产生，还需要业务架构人员去做充分的解释来保证架构方案的传导。

建模过程并不能代替对架构方案的解释，建模过程并非项目所有的人都参加了，如果建模完成之后，没有业务架构设计人员到项目中去以模型沟通需求、以模型宣讲企业级理念，那么模型的传导是极可能会出现“信号衰减”的。

架构设计人员的缺位可能会导致方案失效，如果需求提出方和实施团队一起对模型理解不一致或者对模型中某些地方解释不清时，由于工期、成本限制，那么可能双方会直接协商需求的解决方案。而这时的沟通结果与最初的建模很可能会存在差异，毕竟任何一个问题的解决方法都可能包含很多种。

建模的业务架构人员跟进各个项目组的概设过程或者敏捷过程，最好是能实地跟进。

努力打造通用语言

为了提高业务架构方案的传导效率，必须努力将业务模型打造成“通用语言”。
首先要培养合格的业务架构师队伍：

• 坚持选用具有足够能力的人员，补足业务或技术短板
• 坚持长期培养，好的业务架构师要对业务、模型、开发都具备深入的了解和足够的知识储备，需要长期积累
• 坚持让其跟进项目而非只做架构设计，只有跟进项目才知道模型的实际效果，才能对其进行迭代修正

其次要加强项目外的宣讲，用业务模型去解释业务，使各条线的员工对整体的企业架构都能有所了解，对模型化、结构化的思维方式能有所了解。

业务方案实施过程

从业务到模型再到方案只是一个复杂的“预备过程”，开发才是读者关注的重头戏。

业务架构与IT架构之间是灵魂与容器的关系，后者承载着前者。业务架构是将业务能力经过企业级规划后传导给IT端，并不会限制IT的实现方式，事实上是IT需要适配业务架构的规划。

因此，基于企业级业务架构的实施过程，其实是IT细化企业级业务架构设计，并基于企业级业务架构进行实施协调与管控的软件过程。

基于业务架构设计

• 1 细化业务架构模型：其过程在本质上是对业务架构模型的继承与细化
• 2 处理新发现：可能会产生新的数据需求，设计新的数据实体
• 3 进行IT化设计，但要建立一体化视图

应建立“战略–战略能力–需求–活动与任务–细化活动与任务–用例–交易或服务”这样明确的关联关系，形成一个完整的、分层级的企业能力视图

企业能力视图不能仅局限于业务侧或者仅到组件层级，而是应该延伸到最终的实现，业务与技术的深度融合是今后企业发展的大趋势。业务就是技术，技术也是业务，企业未来的作战地图必须是基于业务技术一体化的视图，而非分裂的视角。

• 4 业务架构桥梁作用：IT实现取决于企业自身的开发习惯与特点

纷乱复杂的业务“理想”经过“业务架构桥”的梳理，将展现出其企业级规划的“秩序”，从而使IT设计更接近于业务的核心诉求和内在逻辑，而不受业务表象牵引。

基于业务架构的协调

新发现往往会带来麻烦，新识别出来的任务到底归属哪个领域，会带来谁做了也都可以实现企业级复用，为什么就非得指定给某一个团队来做？

如果项目组的预算管理比较严格、项目组面临着工期问题、新加任务识别得较晚等，在这些因素的作用下，项目组对于这些调整很可能是不愿意接受的。

这是对企业级架构协调工作的考验。一方面是考验架构模型本身的质量，而更重要的则是考验人和制度。

业务架构的解决之道莫过于各方可以使用同一种“语言”进行协商。

企业级不是为了造就新的技术官僚，而是为了打破部门边界、提升企业能力，所以让架构自己过于中心化了，反倒不是一个很好的选择。

处理架构调整的原则

Q：为什么不能允许简单的指定架构？

作为企业级项目，架构调整所涉及的往往不是一个项目团队。
业务架构师如果具有较大的权力，确实有助于贯彻整体架构，中心化毕竟是一种高效的执行结构。

但是高度中心化的决策方式其实不符合建设企业级项目的目标，理想的企业级项目，实现之后应该达到不对任何人依赖，而过于强势的架构师自然会导致这种依赖的产生，所以，必须接受、鼓励、坦然应对这种调整要求。

Q：什么样的架构调整可以接受？

• 原有架构设计中存在疏漏
• 出现了更好的设计
• 对现实妥协的等价方案
• 架构设计错误

Q：什么样的架构调整不该接受？

• 明显违反既有规则的调整
• 不必要的重复轮子

企业级物有所值吗？

• 一本难算的账：技术迭代快，投入产出做不到高度精细化管理，很难算清楚；因功能共享而提升的反应速度是有上限的，信息共享的价值可能更大

• 无形的核心价值：其实最重要的是转变企业文化，打破部门边界，让企业融为一体；企业级真正解决的是业务问题、组织问题、思想问题，是超越技术之上的建立一个什么样的企业的问题

建立长期应用机制

为了能够长期维持“通用语言”，业务架构还有一项很重要的工作内容，那就是使用既有架构去管理新需求，建立企业级业务架构的长期应用机制。

项目结束后

别做一锤子买卖，按照“熵增”理论，没有良好的维护，再好的架构也会慢慢崩坏，更何况架构自身也必须与时俱进。

企业级业务架构建立之后，必须坚持使用这个架构去管理新的需求，随着业务和技术的发展，需要不断调整架构，以保持架构常用常新。

从三个方面来建立长效机制：

• 1 模型工具：继续使用业务模型管理新需求
• 2 架构仲裁：保留一个适当规模的企业级架构决策团队做指导者与仲裁者
• 3 具体设计：让业务架构人员进入业务线工作，继续承担推动业务与技术融合的职能

需求管理机制

让业务人员和科技人员能够坐到一起充分交流、沟通，多了解对方的想法，互相碰撞和渗透思想。
改变过去按部就班地接需求、“面向过程”地开发项目，实现具有深入理解的“面向对象”、“面向服务”的开发。

如果不提升技术人员的比重，只谈数字化转型则无异于“雾里看花、水中望月”。让这些人员参与到与业务人员广泛交流中去。

一个企业使用了一大堆“不知其所以然”的工具，真的能摇身一变成为“数字领袖”吗？提升技术人员比重的长远用意，不仅是要加强技术掌控力、提高自主研发率，而是要通过技术人员的增加带动更深入的交流，从而帮助业务人员实现数字化思维的转型，这才是业务与技术深度融合的目标。

业务架构师非常适合作为与业务人员接触的“技术第一人”，在工作中，业务架构师可以及时调动需求分析人员、产品经理、开发人员提早参加到需求的形成过程中，将需求管理直接转变为业务规划，这才是各方都希望实现的融合与快速反应。此外还要保证业务架构师的替补和轮岗机制。

企业级理念的长期保持和应用则是更为困难的事情，需求管理机制对非科技类企业而言，很难成为企业的工作重心。

在互联网企业中时常能够听到这些企业的技术人员抱怨业务与技术之间的互不理解，那就更不用说传统企业了，所以要重视业务架构师的培养，从企业级业务架构入手、从顶层设计入手。

和敏捷关系

与正宗敏捷对比

• 工作的软件优于详尽的文档：敏捷开发并非不需要文档，而是不需要那么详尽的文档；

敏捷开发也还是要求有一份恰当的概括性文档作为项目的总体目标，而不是什么都没有就直接往前冲。所以，要想消除与敏捷开发之间的“矛盾”，业务模型这套方法自身也必须具备一定的简洁性。首次企业级转型肯定不适合采用这种方式。敏捷不应是不顾一切的敏捷，更不是牺牲企业级架构一致性的敏捷，否则敏捷项目就成了为短期利益而有意忽视长期影响的盲目行为。

• 个体和互动优于流程和工具：敏捷开发的速度来自于节省不必要的步骤和提高协作的效率，

所以“个体和互动”才“优于流程和工具”，注重面对面的直接交流，以减少分歧。这就要求业务架构师必须参加敏捷项目，在项目中快速完成架构分析，把控项目引起的架构调整，而不能在项目之外等着按“流程”来操作。

• 客户合作优于合同谈判：冲突较少
• 响应变化优于遵循计划：冲突较少

与非正宗敏捷对比

非正宗的敏捷指的是不按套路出牌的“特事特办”。这种方式会对企业整体的架构管理带来一定的破坏性，除非生死攸关，最好不要经常特事特办。

尽可能地在企业“搏命”之后，回归正途，以避免架构遭到破坏。

对于不具备上述价值的“特事特办”，架构师应该从业务架构的角度申明其立场，给出认真详尽的分析意见，这是架构师自身的职业操守，而能否容忍架构师的意见则是企业文化的真实体现了。

且行且珍惜

无论是否建立了敏捷开发体制，也总是有项目必须要尽快上线。大型企业中，企业级体制建立不易，打破却很容易，不要为了“快”而牺牲企业级业务架构。

管理大企业的开发工作就像指挥大兵团作战一样，既要有担当主力、稳扎稳打的方阵部队，也要有处理特殊任务的游骑兵，多兵种之间的有序协作是克敌制胜的关键。

这种有序协作离不开有序的架构管理，通过业务架构方法、应用业务模型驱动开发本身与敏捷并不矛盾。

敏捷可以是、也应该是一个有序架构体系下的敏捷，而不是“叫嚣乎东西、隳突乎南北”的乱闯，Shortcut is the fastest way to get last（捷径是迷路的最快方法）。

企业级业务架构设计希望实现的是企业整体联动、文化转型，而不是仅仅建立一套系统。
达不到敏捷标准的往往不单纯是工具，而是人和人所在的环境。

企业级五难

捷径难寻

DDD不认为企业级真的可以通过自顶向下的规划来产生，而只能是自底向上的生长。因为确实很多行业听上去是一类，但是其实是个大杂烩，真的需要一个领域一个领域的去做研究。

企业级建设的难度与企业所在行业的特点有直接关系，没有一个通用的企业级业务模型可以随便套用。

银行不能直接套用阿里集团的业务架构，阿里集团也不能直接套用银行的业务架构。甚至在同一个行业内，企业与企业之间内部特点的差别，也会决定企业级建设路径和结果的不同。

所以没有可以简单复制的模式帮你快速切换到企业级。别人的经验，无论成败，对你而言都只能是个借鉴，自己的路只能自己摸索前进。但是实践中若能依靠做过企业级实现的科技公司或者开发团队作为“老司机”带带路还是会有很大帮助的。

文化难建

企业级在大多数情况下不只是个技术问题，如果是一个业务种类繁多、部门庞杂、等级森严的传统企业，那么建立企业级不啻于一场“内战”，一场对部门边界、协同关系的重新界定。

如果真的是下定了决心要做企业级，那么对于一个传统企业而言，要改造的东西实在是太多了。然而引入新方法、新思维产生的冲击也需要大量的时间去消化，这将是一个彻头彻尾的大转身。

在这个过程中，业务上需要做的调整不亚于技术上要做的调整，而对于企业文化的调整则尤为重要。现代管理学之父彼得·德鲁克曾说过这样一句名言：“文化能将战略当午餐吃掉。

预期难控

做项目有一项很重要的事情就是管理好用户的预期，企业级建设更是如此。因为要耗费大量的人力和物力，所以，企业级项目在启动之前，各方往往会对此寄予厚望，将蓝图描绘得太过美好，期望多年的夙愿可以“毕其功于一役”。

但是建设周期的漫长、建设过程的曲折，以及中间不断对现实做出的妥协，会让很多美好的“理想”大打折扣，或者由于项目的进度原因而一拖再拖，这也会让实现过程和最终结果都看起来并没有当初设想的那么美好。

需要事先管理好企业的预期，不要为企业级项目戴上太多不该戴的“高帽”，而忽视了真正该戴的“高帽”——完成一次企业文化的建设，实现整体转型。如果这个目标没有实现，那才是真正该失望的，不要只用系统去检验企业级。

转型项目成功与否，只需要观察企业中各级领导、员工的行为习惯是较之以前是否发生了变化。如果行为已经符合转型前的预期了，那么转型项目也可以算是成功了，不必非将系统的好坏当成目标本身。

因为转型的目标也许无法一次性达成，但是如果员工的行为习惯已经朝向预期发展，那么系统目标的实现也许只是需要更多的时间而已。

权责难定

一件事情要能够做好，其前提就是做事的人应权责匹配，无论是临时事项还是长期事项，否则，成功就是侥幸而不可复制的。

架构定位的困难在于：若权力太小，则不足以维护企业级，企业级甚至会随着时间的流逝而“名存实亡”；若权力过大，则又会发展成新的部门化组织，一旦开始以架构“卫道士”自居，就会导致对架构创新的阻碍。

企业级建设实际上是要让这些习惯了业务管理的企业去正视技术，定位好自身的科技基因，思考数字化转型后的企业管理结构，技术在企业中的定位到底是什么？工具？主业？是脑还是手？而对技术人员中很重要的一股力量——架构师（包括各类专业的架构师）如何进行合理的定位，就成了对企业的一个大的考验。

在传统企业中，架构师通常只会被当成技术类专家来看待。不少企业只有技术部门的行政管理者，而根本没有所谓的“架构师”岗位，培养了很多“项目经理”，但缺少对“架构师”有意识的培养。这也导致了很多良好的项目实践经验无法转化成方法论层级的知识，如果发生人员流失，那么知识也就“随风而逝”了。

传统企业必须关注架构师的重要性，他们是数字化转型的关键力量，而好的架构师能够帮助企业实现合理的整体规划。他们虽不是管理者，却拥有基于项目实践积累的管理经验，他们并非仅仅是技术专家，而是实现企业整体战略不可或缺的力量。

长志难立

水会自然流向阻力最小的地方。所以，企业级的放弃和崩坏，未必是将架构组织撤销、机制停掉这类激烈的动作，而是各种“畏难情绪”“客观原因”导致的缓慢的无序，是由一个个需求的分配、落地的偏离堆积而来的，这一点与减肥、戒烟的失败是类似的。在这方面，“破窗效应”的作用也很明显。

企业级维护工作很难与个体、局部的利益有明确的结合，很多时候需要依靠员工自觉去维护企业级。这方面除了所谓的制度、机制之外，还会绕回到战略和文化的问题上，即人们常说的如何打造一个“伟大的企业”。

随着国家开放程度的不断提高，民营领域创新能力的不断提升，大型传统企业已经进入了被动的数字化转型之中，是否能迎难而上、顺利走通企业级转型这条举步维艰之路呢？“未来已来，你爱来不来”！

快速设计案例

案例背景

某企业与某互联网公司合作进行的实物贵金属产品在线销售的业务。受市场形势所迫，该项目必须快马加鞭，紧急施工，特事特办。

需求产生时，该企业正在企业级转型期间，但已经完成了企业整体战略设计、高阶能力需求分解，实现了企业级的业务架构设计和业务模型建设，并已应用模型驱动企业级开发了数年时间，工具使用已经比较熟练。

在转型项目期间，该企业平均每年都有几十个大型项目同时开展。所有业务需求都要经过业务架构分析，出具业务架构方案，再落实到具体项目组，可以说，企业级分析是项目的先导和开发任务分工的依据。

业务部门为配合快速开发，已经连夜写出了业务需求。需求共计15页，将近9000字，涉及11个大的需求项，需要业务架构师马上根据需求文档形成业务架构方案，以推动快速立项、快速进入开发阶段。

需求的主要内容包括：为客户建立虚拟账户，用于记录客户买卖交易、持仓等；支持使用该互联网公司的黄金发送红包（黄金份额）；红包的账务性处理、红包资金的支付结算及划转；支持黄金实物兑换；支持黄金转赠；销售数据提取、报表统计、实物提取配送数据交互以及相应的核算规则等。

架构方案

该企业的业务模型中包含了大量的业务组件和领域级业务应用。其中，该需求所属的业务领域就包含十余个应用，涉及多个核心组件及公共类支持组件。

经过分析整理，项目组最终理出了“签约”“产品查询”“交易（含红包）”“对账”“结算费用”这几个主要的工作流程，涉及7个现有业务组件。经判断，现有业务模型基本支持该需求的实现，部分任务需要增加业务规则，但无须进行大的改动。

互联网黄金在线销售业务架构关系图如下:

• 1 签约：客户向互联网公司提出建立购买企业的实物贵金属产品的合约申请，互联网公司将相关信息及客户在互联网公司的PID（客户在互联网公司的身份标识）传到企业。由于一个客户可能存在多个PID，因此需要分别为其建立账户。该过程的处理，由企业新增的渠道负责信息传输，“客户管理组件”负责识别是否应为企业新增客户，并记录客户在互联网公司的PID信息，与企业的客户信息进行关联；××交易组件则负责为每个PID建立单独的交易合约和账户。考虑到未来可能与该互联网公司有更多的产品合作，因此，PID应该作为企业级信息进行管理，以方便各组件的查询并保持唯一性。
• 2 产品查询：产品信息“产品管理组件”负责提供产品查询，需要由“价格管理组件”提供报价查询
• 3 交易：交易涉及贵金属买卖和对红包转账的支持，由“非实物交易管理组件”负责账户金交易、资金归集转账，“实物交易管理组件”负责实物金交易，“营运管理组件”负责库存和配送管理，核算则由“会计组件”完成。这些业务都有现有业务活动和任务可以支持
• 4 对账清算和手续费扣除：这两项都由“非实物交易管理组件”基于交易记录发起，清算结果和扣收都是通过互联网公司在企业的资金账户和企业内部账户之间转账完成，也有基础的业务活动可以支持
• 5 报表：都是基于该组件的交易记录而生成的，因此可以由该组件负责提供支持

实际操作中，上述方案从阅读需求到完成设计，再到向领导请示汇报，发出结果，总共花费了四个多小时。因为时间紧急，所以出具的方案也比较简要，事后需要及时将部分“微调”的信息补充到业务模型中，以保持模型与实施的一致。

案例小结

• 对原有业务架构和模型的充分复用
• 模型化的业务架构工具对企业级需求分析的加速作用
• 业务架构师必须非常熟悉项目情况
• 业务架构对提高项目的效率发挥更大作用

最初建立企业级业务模型一定会是一个漫长的过程。因为需要处理大量的标准化整合，同时还可能会触动一些深刻的利益关系。

一旦完成了这个过程，建立了企业级业务架构，就可以向敏捷过程看齐。这种具有有企业级参照的敏捷过程，要好于没有“篱笆”的快速开发，具有清晰的边界总是开发人员所愿意看到的。

看似“笨重”的业务模型方法，其实提供了一个“扎实”的下盘，如同练武术一样，若没有扎实的马步，又怎么能够“飞檐走壁”呢？