基于模型的设计与协调
前面讲过了模型转化为方案和基于模型的沟通，自然就到了基于模型和业务架构进行的企业级 IT 系统开发，相信到这一讲很多人都会有所期待，毕竟从业务到模型只是一个复杂的“预备过程”，开发才是大家关注的重头戏，然而，我不得不以自己六年的企业级项目经验告诉大家，这里既没有什么神秘，也不该有什么神秘。可能让你失望了，但这是事实。为什么很多企业，甚至包括科技企业在内，业务转型或企业级方面做得不理想，其实是因为一个很简单的问题——脱节。一开始把企业级或业务转型搞得“高大上”，请咨询顾问、搞战略项目，但是往往停留在企业高层，缺少向执行层面的贯穿，当然也就更谈不到传导到开发，甚至搞战略时技术人员都很少参与。
搞企业级或者业务转型，实际上是个“全民工程”，不能只做顶层设计，必须逐级分解；不能只是业务自己想转型，而是必须拉上技术人员一起研究。转型不是搞一套新需求，而是要实实在在落地的。而基于模型的企业级业务架构设计方法正是关注战略到落地的“一气呵成”。
基于模型的设计
模型驱动开发（MDD）并不是新鲜事物，搞开发的人，尤其是科班出身的开发人员，上学时可能就知道 MDD 了，特别是 UML 这类耳熟能详的需求分析方法；企业架构也有 30 多年历史了，就算只以 TOGAF 为起点，业务架构也有 20 多年历史。虽然业务架构这几年提的人越来越多，并且大家着手的落地实践也日益增多，不再觉得业务架构，特别是企业级业务架构只是“画大饼”，但是，它只是在以往的工程方法之上累积发展起来的，所以，它更多的是对使用者决心和意志有较高要求，而非有什么点石成金的神奇方法。所有的企业级业务架构都是在痛苦的摸索、怀疑甚至反复中，靠着“革命乐观主义”精神和持之以恒的努力，迭代演化出来的，无论最初的设计看起来多出色、多惊艳，终归也要随着时代发展更迭，何况大部分的企业级业务架构设计最多只能算是给出了一个可以被多数人接受的演化起点而已。
基于业务模型进行项目设计在具体方法上可以根据自身企业的特点和习惯去决定实施工艺，但是其过程本质上是对业务模型的细化。业务模型为了设计企业级业务架构，必然对活动、任务进行适当的抽象，甚至减少一些工作细节，这样的模型可以让项目实施团队了解其标准化的核心，以及功能复用方面的设计思路，但是在具体开发中，实施团队是要了解到细节需求的，这与建模过程有一些矛盾之处。对建模而言，需要了解一定的细节，细节有助于判断抽象的正确性和合理性，但是，建好的模型中却不能表达太多的细节，过多的细节会让抽象的表达变得混乱，而且，以后我们还会讲到，过多的细节也会让模型的应用过程笨拙，使维护变得不可能。所以，到了设计阶段就必须对模型表达的工作流再细化，这也是为什么说业务架构的建模不能替代需求分析的原因。设计阶段的细化允许对原有的工作流进行拆分重构，但是有一个前提，就是新产生的元素必须基于旧元素，并且标明继承关系，这样才能保证设计的连续性。比如，之前虚拟案例中“获取新客户”、“维护老客户”、“存款”这三个活动，在实际设计中，如果存款部分和客户管理部分按照组件边界划分了项目组，存款项目组负责合约管理组件和账户管理组件，客户项目组负责客户管理组件，这种情况下，需求分析或者开发人员可能更愿意用一个较长流程来表示应用视角，这样可以更好地描述两个项目组提供的功能如何在具体的存款业务场景中衔接，而重构后的流程很可能如下图：
现实场景中，对公客户经理录入客户信息时很可能对方还只是潜在客户或者客户并没有马上进行开户操作，而是隔了一段时间之后才开户，这时客户信息可能需要更新。如果是客户经理首先了解到需要变更客户信息，则会走上边泳道中流程；如果客户直接去了柜台，柜员则会首先检查客户信息，这时发现需要更新，则可以走下边泳道这个过程，更新之后再开立账户。图中也可以发现，原本没有“检查客户信息”这个任务，在最初的建模过程中，它是可以写在开立账户这个任务中的，但是在细化流程阶段，则可以考虑是不是将其独立出来。这个取决于整体的架构判断，如果其他流程中也涉及这种拆分，确实可以调整企业级业务架构模型，如果不涉及或者很少领域涉及，也可以将其标记为“开立账户”任务的衍生。这种细化可能产生新的数据需求，设计新的数据实体，或者在原有的数据实体下产生根据某种维度细分的子实体。
之后就是根据细化了的、已经达到需求分析标准的业务模型，进行大家已经比较习惯的项目开发，设计用例、设计功能或者服务、分组开发、测试上线。但是企业级项目很重要的一点是要建立各阶段工作之间明确的衔接关系，尤其是设计元素之间的联系，最好能建立“战略 - 战略能力 - 需求 - 活动与任务 - 细化活动与任务 - 用例 - 交易或服务”这样明确的关联关系，形成一个完整的、分层级的企业能力地图，当然，这需要工具的支持。其参考逻辑关系如下：
企业能力视图不能仅局限于业务侧或者到组件层级，而是应该延伸到最终的实现，业务与技术的深度融合是今后企业发展的大趋势，业务就是技术，技术也是业务，企业未来的作战地图必须是基于业务技术一体化的视图，而非分裂的视角。
基于业务架构的协调
“检查客户信息”这个任务的增加，还引出了企业级项目中很常见的另一项工作——跨项目协调。业务模型最初设计时将任务归类给了各个组件，每个组件都包含了一定数量的任务和数据，从而构成了自己的边界，这个边界可以演化成各个子项目的边界。假定根据业务模型，企业内部已经完成了第一次“争吵”，所有项目的边界在下达项目计划给项目组时，已经暂时接受了，那么，在进行需求分析产生的这个“检查客户信息”任务应该归谁呢？从流程图中，似乎挺明显，它读取客户信息数据做判断，生成判断结果，按照数据聚类的话，应该归负责客户管理组件的项目组实施，尤其是在多个领域都涉及这种拆分时，它的“企业级”属性看起来比较明显。但如果涉及的领域很少呢？比如只有存款领域用它，虽然图中做了简化，数据实体没有增加，但在实际需求中，如果要求它不但生成屏显的判断结果，还记录判断结果并生成推送信息给客户经理呢？如果这个推送信息又被视为运营和销售两个部门间的沟通呢？数据会增加，而这些数据的归属似乎也是模棱两可的。不但任务的“企业级”属性模糊了，连数据归属都有点儿模糊。如果我们再引入一些常见的影响因素，比如，项目组的预算管理比较严格、项目组都面临工期问题、新加任务识别的较晚等等，在这些因素的作用下，项目组对于这些调整是很不愿意接受的，毕竟，企业级项目的一大特点就是，功能谁都能做，谁做了也都可以实现企业级复用，为什么就非得拍给我？这就是对基于模型的企业级架构协调工作的考验，一方面考验模型本身的质量，而更重要的是考验人和制度。人指的当然是业务架构师自身的设计和协调能力，架构师提出的调整方案是否具有足够的说服力；制度指的就是整个企业给企业级项目或者企业级转型提供的配套管理措施是否到位，项目组对企业级管控的执行是否给力。文中的案例是虚拟的，但在实际工作中，大家难免会遇到类似情况，如果这类问题解决的不好，组件间的不规则“边缘”会越来越多，而企业级项目协调难度之大，甚至会令一些项目组望而却步，为了赶工，宁愿多干活儿、少开会，产生一些连架构层都不清楚的“违章建筑”，最终形成一个到处都有“兔子洞”的企业级。
基于模型的企业级业务架构对解决上述问题有多大帮助呢？个人的经验认为，最大的帮助在于大家可以用同一种“语言”进行“吵架”，在进行项目协调的过程中，业务模型会很自然地吸引“火力”，它是项目设计的源头，向上追溯一定会追溯到模型这里，使大家不再只是“公说公有理，婆说婆有理”，为最终达成一致结论提供了有益的标靶。而模型也是一种很好的、结构化的结论记录形式，比起“一纸文书”的会议纪要或者发个内部电邮更容易让项目组理解和执行。
可能也有人会觉得，形成一个至高无上的强力架构不是更简单吗？但是，从实际工作角度来看，一是模型很难一开始就做到十分完善，很难达到可以照做不问的程度；二是，做企业级不是为了造就新的技术官僚，是为了打破部门边界、提升企业能力，所以让架构自己过于中心化了，反倒不是一个很好的选择。从这里引申开去，做企业级项目的成功标志，我个人认为不是项目上线，而是业务能力被全面地固定在机构中并且能够可视化，让大家都能在一个框架下朝着一个目标努力，不再过分依赖个人，无论是业务还是技术人员，这才是企业级的真谛。
从设计的角度再说说中台，中台其实也不过是个规划和迭代的结果，如果抛开规模导致的技术复杂度来看，只要坚持企业级的方向或者合理的领域规划，经过业务设计和沉降过程，产生中台规划只是个必然结果，每个企业都能找到属于自己特点的中台，而这个“寻找”的过程对企业而言胜过“中台”这个结果本身。从企业级的视角出发，你也许能够找到比中台模式更适合你的组件化结构，而不必沉迷于中台这个概念。
实施中产生的架构调整
前面已经多次提到了业务架构设计是个迭代的过程，会有不断的反复和调整，站在旁观者或者事后回头看的角度，这是挺容易理解的，但是在执行过程中，却是一个需要慎重考虑且非常“烦人”的事情。如果把你摆在业务架构师的位置上，花了好大精力，动用了不少的人力、物力，几经周折汇报，过五关斩六将地完成了业务架构设计，任务发到了项目组，然后没过多久，以各类合理不合理的理由被提出种种调整，这当然是件很让人掉头发的事情，作为企业级项目，这些调整往往涉及的不是一个项目组，而是一条绳上拴着好几只“蚂蚱”，企业级架构管控经常在做些“按下葫芦浮起瓢”的操作。每每出现这种情况，上上下下都会想为什么架构不能直接把事情拍了（当然很多时候还是站在自己立场上想，为什么不按我说的拍）？业务架构师自己也会觉得，我说的很在理，我是最站在企业级立场的，为什么不干脆让我直接说了算？其实业务架构师，如果具有较大权力确实有助于贯彻整体架构，中心化毕竟是一种高效的执行结构，但是中心化的决策方式其实不符合建设企业级项目的目标，上一讲最后我提到，理想的企业级项目，实现之后应该达到不对个人的依赖，而过于强势的架构师自然会导致这种依赖的产生，所以，无论是从职业的角度还是企业级项目目标的角度，架构师都必须接受、鼓励、坦然应对这种调整要求，当然，这不是要求架构师允许无限制的浪费精力和项目时间，而是首先坚持“以理服人”，再要求对架构设计的贯彻，讨论是让所有项目人员深入理解企业级的过程，这个过程必须，也只能允许反复和挑战。基于实施情况进行调整，对业务架构和模型都是有益的，没有此类反馈的模型，十之八九是没有被真正使用的模型。
应该做的调整
既然允许调整，又不能无限浪费时间，那我们就来梳理下应当调整的情况：
- 原有架构设计中的疏漏。这一点是架构师们不愿意看到，出现疏漏证明了原有工作的缺失，不过， “知漏就改还是好同志”，别给自己找什么借口，坦然承认，补充设计，调整架构方案，越是虚怀若谷，越是赢得尊重。项目都是有周期的，每个环节都必须有一定的时限，除了首次做企业级转型之外，业务架构设计是非常重要却又不能被分配太多时间的环节，想想对项目的“敏捷”要求，如果让业务架构师自己慢条斯理地搞起细致的业务架构设计，相信所有人都会疯掉。那么，业务架构师就必须在尽可能短的时间内给出覆盖度尽可能完整的架构方案，这是对业务架构师的考验。但是，平心而论，时间越短、信息越少，就越可能出现疏漏，在细化阶段发现问题就很正常，自然调整就好，各方都不必苛求。
- 出现了更好的设计。上一讲的虚拟案例中就提供了改良的可能性，“检查客户信息”这个任务独立出来，可能会给整个企业级设计带来一定的改善，方便其他业务领域实现同类需求，这样的改良就可以回补到模型中，由此带来的架构调整是有益的。
- 对现实妥协的等价方案。架构设计经常不是只有一个可行方案，人们常说，架构师就是在手里永远准备两套方案，并随时准备抛弃其中一套。我个人也经历过这样的事情，原本设计时有两个方案可以选择，在为 C 领域做业务架构设计时，A 领域和 B 领域都有可以采用的会计引擎实现能力，A 领域的业务性质与 C 领域更为接近，于是做架构设计时选择了 A 领域，但是实际推进项目时，负责 A 领域的项目组由于客观条件限制，无法按时实现，只好再转到 B 领域，两个方案基本等价，但是架构和模型上必须要做一定的调整，这是现实条件制约的。对了，不要问我为什么两个领域都会有类似的会计引擎实现能力，这是另一种现实。
- 架构设计错误。与第一点不同，这是实实在在的错误，是架构师们一直竭力避免的情况，这对架构设计和架构师自身能力的可靠性都是直接的挑战，对此，架构师应当做的就不仅是调整了，更重要的是深入了解错误原因，总结经验，反省和提升自我，由此，也看出经验在架构师综合素质中的重要性，好的架构师都是时间和项目铸就的。但是，如果一个架构师经常出现此类问题，就必须考虑对其进行调整了，或是到项目组重新锻炼，或是不再让其担任架构职责。如果是整个架构师团队经常出现此类问题，那就很可能是工作机制的原因，是不是架构师没有机会深入参与到项目过程中去了解项目实际情况？是不是上一讲提到的“违章建筑”太多，导致架构已经失灵？总之，集体问题与个体问题不同，需要区别对待。
不应该做的调整
以上是几种应当做的调整，还有些情况则不应当调整，大致如下：
- 明显违反既有规则的调整。比如客户统一视图这类需求，这是典型的跨领域需求，但是又具有一定的领域特性，因为金融行业中客户可能同时在多个领域发生业务，但是每个业务条线从自己领域出发，应用客户视图时不一定要看所有内容，这就相当于在一个统一的数据基础上分领域定制，这样的需求其实由客户管理组件实现，或者由专门负责数据仓库、数据主题的项目组实现都可以，因为客户管理组件掌握客户基本信息但未必掌握业务数据，大型企业中，通常会考虑以数据仓库的方式归集各组件形成的数据，因此，无论是哪个项目组实现，本质上都是通过数据仓库加工。但是，分工一旦形成，就不要再随意调整，如果既定是由客户管理组件做，特别是客户管理组件已经实现一部分时，就不能允许客户管理组件再以各种理由推脱后续需求，把其他需求交给做数据加工的项目组去做，这样会导致架构的混乱，导致决策原则的不一致，不要轻易推翻已经成为事实的判断原则，要通过事实建立共识。
- 不必要的重复造轮子。这样例子相信在大家都常见到，一般的重复造轮子我们不谈了，反对的理由大家也都清楚。还有一类重复造轮子则可能是“企业级”给“逼”出来的，这么说有点奇怪，有点给企业级“泼脏水”的嫌疑，但是实际工作中确实会遇到，特别是在企业级转型过程中。企业级项目最大的难度其实是实施过程中的跨项目协调，这时各种利益冲突都会在某种诱导条件下爆发出来，背后的原因即可能是错综复杂的，涉及到遗留系统难以拆解、缺乏关键业务人员、第三方不配合、技术不过关等非常客观甚至是由来已久的因素；也可能是简单到令人无奈的，就是给不想干找一堆理由，这些令人心力交瘁的协调工作，也可能会“逼”得大家宁可重复造轮子，也不愿通过协调解决问题。这种情况，架构管控上也要坚决制止，因为转型之路虽艰难，但是开倒车会导致更大的艰难，会让之前的努力都付之流水。
经过多年的企业级实践，有时我也会问自己，企业级这么费劲儿的事情，真的物有所值吗？坦白地告诉你，无法计算。所谓降低开发成本，这个是常挂在嘴边，但不一定是企业级要去解决的核心问题，技术五到八年差不多就换代了，节省的成本就算能算出来可以挺几年？你还得扣除转型成本。所谓系统互联互通、数据共享，其实这个是通过对关键问题的企业级处理，也就是点上的企业级就可以解决，比如数据标准化加数据仓库。所谓灵活响应、快速上线，这个更多是开发方式、Devops 等关注的内容，毕竟领域之所以为领域，还是因为领域之间有差别，可以因共享而提升的反应速度可能是有限的。所以，企业级价值在哪里？我个人认为，花费这么大力气搞企业级最重要的是转变企业文化，打破部门边界，让企业融为一体，让业务与技术融为一体，这种一体化带来的企业内部的变化，带来的高效协作才是最有价值的，是企业未来长期竞争力的基础。衡量企业级项目成功的标志并非单指一个系统的实现，文化没有转变、思维没有转变，是不会真的诞生这样一个系统的，即便交给企业一个这样的系统，也可能会被改回去。做企业级，难点不在技术，企业级真正解决的是业务问题、组织问题、思想问题，是超越技术之上的建立一个什么样的企业的问题。企业级业务系统是给具备此类文化的企业使用的配套工具，也是给不具备此类文化的企业提供的一个转型过程，至于结果，要由时间、感受和市场去检验，而非标准。
不同的系统也会反映不同的企业文化，这点如同之前对阿里中台背后的分析，希望朋友们能够多去思考和观察你所能接触到的系统和使用这些系统的企业。
