业务架构是推动业务与技术深度融合的重要方法，之前的文章中也提到，要在各种场合尽可能推广模型的使用和模型思维方式，以促进“统一语言”的建立，那么，业务架构还有一项很重要的工作就是使用既有的架构去管理新的需求，这是业务架构的长期应用机制问题。

项目结束了怎么办？

企业级转型，或者搞中台，都不是“一锤子买卖”，不是项目上线，搞个庆功仪式就万事大吉了。按照熵增理论，没有良好的维护，再好的架构也会慢慢崩坏，何况架构还得与时俱进。任何领先都是暂时的，尤其是在技术方面。

企业级业务架构建立之后，必须坚持用这个架构去管理新的需求，随着业务和技术的发展不断调整架构，以保持架构常用常新。那什么样的机制合适呢？

做企业级转型时，为了项目的顺利进行，大部分企业都会选择按照项目管理的套路构建临时管理机构，比如笔者原来所在单位，就是安排各部门领导、骨干组成临时的跨部门项目管理组织，为业务架构、应用架构、技术架构、数据架构、安全架构都设立专职团队，形成企业级架构管理。除进行最初的企业级规划外，由于项目周期长达数年，在旧系统改造的基础上还要不断叠加新需求，架构团队也会承担基于已经建好的业务模型进行新需求整合与分配的职责。项目期间，这样的临时机制没问题，而且，有跨部门的项目管理组织做后盾，虽然少不了磕磕绊绊，但还是走得下去。项目结束之后呢？显然各部门不能总是把精力花在这些项目协调和管理工作上，而跨部门的项目管理组织即便形式上可以固化，也难以长期维持其热情和效率。所以，看似可以简单继承的项目管理机制，实际上很难直接继承下去。

如何解决这个问题呢？我们从模型工具、高阶管理和具体执行三个角度看一下。

模型工具。完成企业级转型项目后，如果业务模型构建的合理，质量过关，就意味着企业有了一张从业务直通技术的“作战地图”，而新需求大部分都是对已有流程和功能的改良，这些改良可以“按图索骥”，找到模型中需要做的变更；少部分需求是全新的，需要增加流程和功能，也就意味着模型内容要增加，这样的模型应用逻辑，简单而直接，始终保持着企业级理念，从工具角度看，继续使用模型是没有问题的。

高阶管理。前边我们说过，业务架构不宜过于中心化，但是作为争端的解决机制，终归还是要有个仲裁者，所以，保留一个适当规模的企业级架构决策团队（包括业务架构、应用架构、技术架构、数据架构、安全架构）作为整体架构的指导者和仲裁者也是有必要的，但显然，这个团队是不可能太大的，否则工作效率会有问题。

具体执行。这就是探讨项目结束后，企业级架构决策团队以外的业务架构人员工作方法的问题了。业务架构不同于需求分析，所以，不能简单把业务架构人员分散到项目或者组件管理团队中去，因为时间久了，会淡化业务架构人员的企业级视角。以我个人的经历来讲，我觉得最合适的方式是回归“初心”，让业务架构人员进入业务条线工作，继续承担推动业务与技术融合的职能，尤其是承担起向业务人员普及技术应用方式的职责，去填补“数字鸿沟”。

深度融合该怎么搞？

现在大家都常说要实现业务与技术的深度融合，但是怎么做呢？所有业务线上化、大力提高科技战略地位？个人认为，融合首先是人的融合。深度融合不是找几个技术大牛或者请些头部科技公司做几个“亮瞎眼”、不明觉厉的项目，而是业务人员和科技人员能够坐到一起充分交流、沟通，多了解对方的想法，互相碰撞和渗透，改变过去按部就班地接需求、搞项目的“面向过程”的开发，实现具有互相理解的“面向对象”、“面向服务”的开发。这就要求技术人员必须向前一大步，参与到业务中去，而业务架构人员非常适合担任这个“先锋”。利用企业级转型过程，培养大量业务架构人员，再分散到业务部门，但是人员管理不归属业务部门，以保持工作的独立性。在日常工作中与业务人员广泛交流，不断提升业务人员对企业级理念、技术实现、技术趋势的理解，激发业务人员更大的想象空间和跨部门协作的动力，使需求在交流中“自然”产生，也可以减轻过去业务人员“冥思苦想”新需求的痛苦，让双方在工作起步时就交融在一起。大家可能会觉得，这得需要多少技术人员？是需要不少，不过，目前很多大企业在研究转型战略时都把提高技术人员占比列入了计划中，在我个人看来，如果不提升技术人员比重，谈数字化转型无异于“雾里看花”，试想，一个企业用了一大堆“不知其所以然”的工具，真的能摇身一变成了“数字领袖”吗？提升技术人员比重的长远用意，也不仅是加强技术掌控力、提高自主研发率，而是要通过人员的增加带动更深入的交流，从而帮助业务人员实现数字化思维的转型，这才是业务与技术深度融合的目标。业务架构师非常适合作为与业务人员接触的“技术第一人”，在工作中，还可以及时调动需求分析、产品经理、技术人员提早参加到需求形成过程中，将需求管理直接转变为业务规划，这才是大家都希望实现的融合与快速反应。基本的工作组织形式可以如下：

业务架构师分散驻扎在各个业务部门，需求产生时即采用模型工具与业务人员共同讨论，可以根据需要要求组件开发团队的需求分析人员、产品经理或者开发人员提前介入分析；需求成型后即进入实施过程，业务架构师可以代表业务人员进入项目组（在长期驻扎业务部门的情况下，业务架构师即便不能完全代替业务人员，也可以减少对业务人员的需要量），与开发团队共同工作一段时间；项目组产生业务架构师不能“摆平”的协调问题时，提交给企业架构进行沟通，必要的时候进行仲裁。这种机制下，一是要保证业务架构师的数量，不能每个部门一个，那样是做不过来也做不到位的，要有“替补”；二是要保证业务架构师每隔一至两年左右进行部门间的轮岗，业务人员不能轻易换部门，但是业务架构师则要保持一定的流动性，以促进企业级理念的生长，架构师要有替补也是为了加强轮换能力。业务架构师与企业架构之间要有定期的工作交流，以增强业务架构师对企业级的把握和企业架构对业务前端的理解。在工作过程中时刻注意使用模型工具分解需求，通过模型工具把控企业级设计。

“打江山容易，坐江山难”，做企业级项目无论过程多痛苦，咬咬牙也是能坚持过去的，但是企业级理念的长期保持和应用则是更为困难的事情，需求管理机制对非科技类企业而言，很难说是企业的工作重心，尽管大家科技意识已经普遍提高。然而，恰恰这么一个非重心工作，却是检验企业级理念应用、保持和维护机制的关键，说的严重点儿，企业级项目的建成其实就是其崩坏的开始，而崩坏就是由一个一个看似微不足道的需求形成的，“千里之堤溃于蚁穴”。

再说说想学中台的同学们，你们的企业考虑过以一个什么样的机制去管理需求、维护中台架构吗？这件事只靠技术同学就可以搞定吗？实现了中台就达到了快速响应、达到了业务与技术深度融合吗？很多传统企业尽管在努力转型，但是技术人员仍然是“少数派”，比不得那些互联网企业，动辄技术人员占比超过50-60%，对于这些互联网企业，技术也是业务，但也时常听到这些企业的技术人员抱怨业务与技术之间的互不理解，那就更不用说传统企业了，如果不从企业级业务架构入手、不从战略入手，把业务整体拉入到开发机制当中，那作为“少数派”的技术同学又如何能规范得了一个“中台”呢？

相关文章：
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素
 中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路
 中台之上（五）：业务架构和中台的难点，都是需要反复锤炼出标准模型
 中台之上（六）：如何为一个商业银行设计业务架构？
中台之上（七）：不神秘但很麻烦的业务架构落地过程
 中台之上（八）：企业级业务架构的实现需要不断沟通和调整

作者介绍：付晓岩，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。

创作场景

中台之上（九）：如何基于企业级业务架构管理业务需求？