就算有了企业级业务架构，也还是会经历〞一脑门子官司”的企业级转型过程。经过多年的实践，有时笔者也会自问，企业级这么费力的事情、真的物有所值吗？
1.一本难算的账
单纯从经济角度来看，所谓降低开发成本，是一个常被挂在嘴边、但却不一定完全是依靠企业级去解决的问题。技术每隔五到八年差不多就换代了，节省的成本就算能计算出来又可以节省几年呢？此外，还得扣除转型成本，目前，国内大多数企业在投入产出方面都难以做到高度精细化的管理，尤其是对于此类影响深远的项目的核算，因此，管理基础本身都不支持算这笔账。单纯从技术角度来看，所谓系统互联互通、数据共享，其实这个问题可以通过对关键问题的企业级处理来解决的，比如数据标准化加数据仓库。所谓灵活响应、快速上线，则更多的是开发方式、DevOps等关注的内容。毕竟领域之所以为领域，还是因为领域之间存在差别，可以因功能共享而提升的反应速度是有上限的，信息共享的价值可能更大。
2.无形的核心价值
不惜血本去做企业级开发，其实最重要的是转变企业文化，打破部门边界，让企业融为一体，让业务与技术也融为一体。这种一体化带来的内部变化、清晰分 工和高效协作才是最有价值的，是末來长期竞争力的关键，也是打造”数宇化”企业的基础。衡量企业级项目成功的标志不是一个系统是否实现，若文化没有转变、思维没有转变，则是不会真地诞生这样一个系统的，即便交给企业一个这样的系统，也会被改回去。做企业级，难点不在于技术，企业级真正解決的是业务问题、组织问题、思想问题，是超越技术之上的建立一个什么样的企业的问题。企业级业务系统是给具备此类文化的企业使用的配套工具，也是为不具备此类文化的企业提供的一个转型过程，至于结果，则要由时间、感受和市场去检验，而非标准来检验。正是为了实现这种价值，才需要企业级业务架构设计这类分析问题、解决问题的方法。因为一般的需求分析、系统设计方法，包括DDD方法，大多数都只是面向领域级甚至产品级，而能实现战略分析的方法与实现的衔接通常又不够理想，同时基于模型的企业级业务架构设计方法所关注的正是从战略到落地的〞一气呵成”。
建立转型后的长期应用机制
业务架构是推动业务与技术深度融合的重要方法，之前也曾讲到过，其目的是要在各种场合尽可能地推广模型的使用和模型的思维方式，以促进” 通用语言” 的建立。为了能够长期维持” 通用语言”，业务架构还有一项很重要的工作内容，那就是使用既有架构去管理新需求，建立企业级业务架构的长期应用机制。
项目结束了该怎么办？
1 别做“一锤子买卖”
企业级转型，或者称为中台，都不是“一锤子买卖”，并不是项目上线后就万事大吉了。按照”熵增” 理论，没有良好的维护，再好的架构也会慢慢崩坏，更何况架构自身也必须与时俱进。任何领先都是暂时的，尤其是在技术方面。企业级业务架构建立之后，必须坚持使用这个架构去管理新的需求，随着业务和技术的发展，需要不断调整架构，以保持架构常用常新。那什么样的机制才是合适的呢？
做企业级转型时，为了保证项目的顺利进行，企业可以选择按照项目管理的套路构建临时管理机构，安排各业务部门的领导、骨干组成临时性的跨部门项目管理组织，为业务架构、应用架构、技术架构、数据架构、安全架构都设立专职团队，形成企业级架构管理。除了进行最初的企业级规划之外，由于项目周期可能时间较长，因此在旧系统改造的基础上还要不断叠加新需求的处理，架构团队自然也要承担基于已经建好的业务模型进行新需求整合与分配的职责。项目开展期问，这样的临时机制是没有问题的，而且，有跨部门的项目管理组织做后盾，就算少不了磕磕绊绊，也还是可以很好地执行下去的。那么项目结束之后呢？显然各业务部门不能总是将精力花在这些项目协调和管理工作上，而跨部门的项目管理组织，即便形式上可以固化，也很难长期维持其热情和效率。所以，看似可以简单继承的项目管理机制，实际上很难直接继承下去。
2.关于建立长效机制的分析
那么，又该如何解决这个问题呢？我们先从模型工具、架构仲裁和具体设计三个角度来分析一下。
（1） 模型工具
完成企业级转型的项目之后，如果业务模型构建合理，质量过关，则意味着企业有了一张从业务直通技术的“作战地图”。而新需求大部分都是对已有流程和功能的改良，这些改良可以〞按图素骥”，找到模型中需要做的变更；少部分需求是全新的，需要增加流程和功能，这也就意味着要增加模型内容。这样的模型应用逻辑，简单而直接，始终保持着企业级理念，从工具的角度来看，继续使用业务模型管理新需求也是没有问题的。
（2） 架构仲裁
前面分析过，业务架构不宜过于中心化，但是作为争端的解決机制，终归还是要有个仲裁者。所以，保留一个适当规模的企业级架构决策团队（除了业务架构、应用架构之外，还可以根据企业自身需要酌情考虑是否包括技术架构、数据架构或安全架构等）作为整体架构的指导者和仲裁者也是很有益的。但很显然的是，这个团队不可能太大，也不会直接去处理各领域具体的架构设计，否则工作效率会有问题。
(3） 具体设计
这就需要探讨大多数业务架构设计人员在企业级转型项目结束之后的工作机制问题了。业务架构不同于需求分析，所以，不能简单地将业务架构人员分散到项目或者组件开发团队中去，因为时间久了，会淡化业务架构人员的企业级视角。笔者认为最合适的方式是回归初心，让业务架构人员进入业务条线工作，继续承担推动业务与技术融合的职能，尤其是承担起引导业务人员合理运用技术手段解决业务问题、持续贯彻业务架构理念的职责，去填补〞数字鸿沟”。
促进深度融合的需求管理机制
需求管理是很多传统企业不太重视的管理环节。企业级项目结束之后，企业级业务架构设计人员应当充分接触业务部门，把握住需求的最前端，从源头开始维护、推广企业级设计，不断加强业务与技术的深度融合，这是企业级项目结束时，后继管理机制的关键。我们就来探讨一下具体的做法。
1.什么是深度融合
很多人都在强调深度融合，但什么才是真正的深度融合呢？笔者认为，融合首先是人的融合。深度融合并不是聘请若千技术大牛或者仰仗领头科技公司开展若干看起来“高端大气上档次”的项目，而是让业务人员和科技人员能够坐到一起充分交流、沟通，多了解对方的想法，互相碰撞和渗透思想。如果要用技术术语来打比方的话，就是改变过去按部就班地接需求“ 面向过程”地开发项目，实现具有深入理解的“ 面向对象”“面向服务”的开发。这就要求技术人员必须向前迈出一大步，参与到业务中去，而业务架构人员非常适合担任这个〞 先锋”。企业级转型项目在实施过程中往往会培养出一定数量的业务架构设计人员（企业也可以有意识地借助企业级项目培养一批这样的人员)，在项目结束后将其分散派驻到业务部门，但是人员管理不归属于业务部门，这样做可以保持其工作的独立性。在日常工作中与业务人员广泛交流，不断提升业务人员对企业级理念、技术实现、技术趋势的理解，激发业务人员更大的想象空间和跨部门协作的动力，使需求在交流中“ 自然”产生，也可以减轻过去业务人员〞 冥思苦想” 新需求的痛苦，让双方在工作起步时就能交融在一起。读者可能会觉得，这是否会需要许多技术人员？确实是需要不少，不过，目前很多大型企业在研究转型战略时都将提高技术人员占比列入了规划之中。在笔者看来，如果不提升技术人员的比重，只谈数宇化转型则无异于〞 雾里看花、水中望月”。试想，一个企业使用了一大堆“不知其所以然”的工具，真的能摇身一变成为”数字领袖”吗？提升技术人员比重的长远用意，不仅是要加强技术掌控力、提高自主研发率，而是要通过技术人员的增加带动更深入的交流，从而帮助业务人员实现数字化思维的转型，这才是业务与技术深度融合的目标。
2.业务架构师的工作模式
业务架构师非常适合作为与业务人员接触的“技术第一人”，在工作中，业务架构师可以及时调动需求分析人员、产品经理、开发人员提早参加到需求的形成过程中，将需求管理直接转变为业务规划，这才是各方都希望实现的融合与快速反应。业务架构师基本的工作组织形式如图所示。
业务架构师分散驻扎在各个业务部门，需求产生时即采用模型工具与业务人员共同讨论，我们可以根据需要，要求组件开发团队的需求分析人员、产品经理或者开发人员提前介入分析；需求成型后即进入实施过程，业务架构师可以代表业务人员进入项目组（在长期驻扎业务部门的情况下，业务架构师即便不能完全代替业务人员，也可以减少开发过程中对业务人员的需求量)，与开发团队共同工作一段时间；项目组若出现业务架构师不能处理好的协调问题时，则会提交给企业架构进行沟通，必要的时候还会进行仲栽。
这种机制的正常运行，一是要保证业务架构师的数量，不能每个部门一个，那样做是做不过来也做不到位的，而是要有多个，要有〞替补”；二是要保证业务架构师能够每隔两年左右进行部门间的轮岗一次，业务人员不能轻易调换部门，但是业务架构师则要保持一定的流动性，以促进企业级理念的生长，架构师要有替补也是为了加强轮换能力。业务架构师与企业架构之间要有定期的集体性工作交流，以增强业务架构师对企业级的把握和企业架构对业务前端的理解。在工作过程中要时刻注意使用模型工具分解需求，通过模型工具把控企业级设计。
3.千里之堤溃于蚁穴
“ 打江山容易，坐江山难”，做企业级项目无论过程有多痛苦，下定决心克服困难都是能坚持过去的。然而企业级理念的长期保持和应用则是更为因难的事情，需求管理机制对非科技类企业而言，很难成为企业的工作重心。尽管企业的科技意识已经得到普遍提高，然而，恰怡是这样一项非重心工作，却是检验企业级理念应用、保持和维护机制的关键。说得严重点儿就是
企业级项目的建成其实就是其崩坏的开始
而崩坏就是由一个个看似微不足道的需求分配过程形成的，也就是所谓的〞 千里之堤溃于蚁穴”。即便是中台模式也不是一次建成就可以“万年长青” 的，也需要进行长期维护。那么，希望学习中台模式的企业是否已经对维护这个模式的长期性有了充分的思想准备呢？ 考虑过以一个什么样的机制去管理需求、维护中台架构吗？这个机制只靠技术人员就可以处理好吗？实现了中台就能达到快速响应、达到业务与技术深度融合了吗？尽管很多传统企业都在努力转型，但是技术人员仍然只是〞少数派”，比不得那些互联网企业，动辄技术人员占比超过50%-60%。对于这些互联网企业，技术也是业务，但也时常能够听到这些企业的技术人员抱怨业务与技术之间的互不理解，那就更不用说传统企业了。如果不从企业级业务架构入手、不从顶层设计入手，将业务整体拉入到开发机制当中，那作为“少数派’的技术人员又如何能够持久规范得了一个中台呢？
