世界上的事物会发生变化，结构也会发生变化。由于企业架构规模庞大，必然包含许多导致其发生变化的因素。即使是精心细分的服务也很难保证不发生变化，更不用说包罗万象的架构了。架构设计并不是为了一味追求稳定性，甚至不是为了简单的复用目标。架构的首要任务是理清事物的内部结构，也就是更好地再现事物（从业务需求到技术实现，它本身就是一个表征的过程），同时也是通过清晰的结构来容纳变化。架构的关键功能之一是如何更好地接受变更，并对变更的范围和影响做出尽可能清晰的判断。这个判断除了架构师的能力之外，还可以依赖良好的架构资产。好的架构资产是提高架构师团队平均水平和复杂项目管理有效性的有效途径。
企业架构的设计本身就消耗大量资源，但又很容易被破坏。通过对整体架构的一点一滴的小违规，就会积累大量的偏差。架构资产相当于企业的能力图谱，如下图所示：
图1 基于企业级业务架构的企业能力图谱
运营需要军事地图，旅游需要旅游地图，企业架构、企业转型自然需要企业能力地图。只有有了地图，我们才能旅行。企业能力图可以识别企业从战略到业务流程再到IT实施的完整路径。然而，地图的准确性需要不断保持。需求永远在路上，系统也永远在变化。地图自然需要更新，而更新的最佳方式就是使用它并坚持使用企业级业务架构方法来分解新需求，没有比保持地图更新更好的方法了。企业级业务架构的详细构建方法可以参考作者的著作《企业级业务架构设计：方法论与实践》。本文重点讨论基于企业级业务架构现有架构资产的需求管理。
1、需求分析
需求管理是一个过程。在讨论管理之前，我们首先应该讨论如何应用架构资产进行分析。讨论完使用之后我们再讨论管理问题。
由于本文假设有架构资产，所以我们先创建一个业务范围不完整的虚拟银行业务架构，重点关注业务组件的展示。我们不会花太多时间讨论从价值链到业务组件的整个过程。我们假设一家银行有存款、贷款、理财、贸易金融等多项业务。其主要业务组成可能如下图所示：
图2 基于企业级业务架构的企业能力图谱
在这个不完整的银行中，假设目前有9个组件，其中4个位于领域层，负责存款、贷款、理财、贸易融资等业务处理； 5个位于公共层，负责统一客户信息管理，职责包括统一客户关系管理（一般包括客户政策、客户分配、集团客户关系维护等）、财务会计汇总账本生成总账、统一的风险管理和报告管理。其实说到公共层，很多读者可能会发现这个架构也有“中台”的味道。
请注意，这些是业务组件，而不是逻辑子系统。说到业务架构，不要轻易将当前很多技术方案中画出几个功能模块的“业务架构”与完整的企业级业务架构方法进行比较。业务组件是等效的。熟悉作者前面方法论介绍的读者就会知道，每个组件中聚集的数据都是密切相关的数据以及与这些数据密切相关的行为，是充分分析和企业级标准化处理的结果，而不是预先指定的内部功能模块是在清除系统边界后被裁剪掉的。
有了架构（当然线条很粗），我们就可以利用架构资产进行需求分析。我们可以用区块链来举例。区块链在金融领域的应用相当广泛。我们可以虚拟地讨论它。如果业务部门或者技术团队提出利用区块链技术搭建一个新的贸易融资平台。业务架构会如何看待这个问题？
首先，业务架构是从业务角度看问题，不受技术实现方式的直接影响。那么，区块链贸易融资平台首先要分析业务流程的变化。国内区块链一般都是联盟链。大多数平台都有会员资格认证。 CA证书有发证机构颁发的CA证书和国家CA证书。无论采用哪种方式，会员管理都是必要的流程之一。 。
不用说，客户信息的建立和维护一定有这个流程，而且一般来说，因为现阶段贸易金融的业务需求不会因为区块链而改变，所以客户信息管理流程也不会改变。业务处理程序也没有变化，例如信用证的处理。区块链平台一般提供业务数据的可信传输，并利用区块链的防篡改特性进行信息加固。采用区块链平台后，自动化处理能力可能会得到适度提升，但严格来说，自动化处理并没有完全改变操作流程。相反，操作员从人变成了计算机。如果业务建模有适当的抽象程度，那么，自动化处理对业务模型的改变并不是很明显，理论上RPA也是如此。
如果上述分析属实，那么主要的流程变化其实就在联盟管理上需求管理 软件，即会员的资质认证上。这部分可以归属于客户关系管理组件，可以用数据来表达为客户之间的联盟关系、联盟角色等，相应的业务处理流程，即新的任务，可以放在客户关系中管理组件。
那么区块链在哪里呢？事实上，你在业务架构中是看不到的。业务架构主要看业务是否发生变化，像区块链账本这样的东西就是技术实现的选择。也就是说，技术架构中会加入区块链平台，应用架构中会加入部署在区块链平台上的服务，而这些服务对应上面提到的业务功能。相当于业务架构理清之后，应用架构根据技术架构的变化来改变服务的位置。
那么如果区块链不体现在业务架构上，怎么能看到业务与技术的融合呢？如果想让业务方真正感受到变化需求管理 软件，那一定是区块链改变了商业形态。例如需要新增联盟管理。这个业务有充分的认识，但是其他流程的变化是否会那么明显。考验的是业务方和技术方利用区块链改善现有业务形态的能力，而新技术的应用最终是否简化了流程和架构，还是导致处理更加复杂，也可以通过比较来确定。其他新技术的应用也是如此。
通过这个虚拟分析过程，读者可以感受到业务架构如何分析需求，如何应对新技术，如何应用新技术来改善业务。由于篇幅和信息的限制，本文不会详细阐述详细的建模过程。
2.需求管理
说到管理，就是组织和流程的问题。首先，企业是否有专门的业务架构师团队或职位？如果是这样，业务架构师当然应该牵头建立企业的架构资产，然后依托架构资产进行业务需求的架构层面设计，并负责识别需求相关的需求。业务流程、数据实体、业务组件等架构元素提供业务架构解决方案，然后通过项目管理机制转化为项目任务执行。理想的工作方式是由笔者所倡导的业务架构师进驻业务部门来执行需求。管理方法如下：
图3 基于企业级业务架构的企业能力图谱
在此过程中，从组件到企业架构部分负责解决项目团队之间的架构差异，并由统一的企业架构管理团队负责最终决策。
架构资产的变更最好由业务架构师以统一的方式维护。如果建模层次比较深，细节比较多，也可以采用分层维护的方式。最细粒度的级别由组件项目团队划分或维护。产品人员负责。业务架构团队还必须定期对架构资产进行质量检查，确保资产更新的及时性和准确性。这部分可以作为项目团队评估的基础。
通过需求分析部分的介绍，读者也可以了解到为什么业务架构师进驻业务部门更为合适。这样他们可以更贴近前端，有更好的业务感受，了解业务人员需要什么、困惑什么，并在第一时间帮助他们。商界人士了解新技术的应用。业务架构师应在每个工作周期后在部门之间轮换，以保持其企业级视角并促进部门间协作。
所以对于没有业务架构师团队或者职位的公司来说，这样的公司在业务架构方面一般都没有架构资产，相当于从头开始建立上述的管理体系。培养业务架构师对于企业演进、数字化转型等任务是非常必要的。通过业务架构连接业务和技术，是实现业务和技术深度融合的第一步工作。需要培训的业务架构师的数量取决于公司的规模。对于人员较少的公司，除了少数专职架构师外，还可以考虑在业务部门和项目组中设立适当数量的兼职业务架构师。
3、提高开发效率
软件工程已经发展了近50年，企业架构的历史也有30多年。技术方作为技术服务商，一直在不断提升自己的开发效率。软件开发和设计流程取得了长足进步。然而，随着社会逐渐开始向数字化转型，软件需求规模只会越来越大，甚至可能出现爆发式增长。根据Gartner最新预测，未来五年新建应用数量将达到5亿之多，超过此前40年的总和。虽然这个数据很难验证，但数字社会最重要的生产工具就是软件，而数字银行的发展正如作者在新书《银行数字化转型》中描述的愿景一样，软件涵盖了一切，意味着更大规模的软件生产仍在等待技术人员，如何提高开发效率是重中之重。
现有的工程和架构理论基本上都是从技术层面来看待这个问题，而很少从业务层面来看待如何提高开发效率。数字化转型是整个社会的转型。这是一个新时代。新时代必然要求从业者的技能发生巨大变化，从农业耕作技能到工业机器控制技能再到信息时代的软件应用技能。数字时代，所有从业者都必须具备软件构建技能。当然，这并不是说他们必须了解编程级别的实现，而是说他们必须知道如何构建“乐高”式的软件，实现业务与技术的高效连接。
“乐高”式的软件已经讨论了很多年，但尚未看到很好的实施。低代码平台也是这方面的探索者。 “乐高”软件一直难以构建的关键原因，很可能是技术人员始终无法真正掌握“乐高”业务在业务人员心目中应该是什么样子。坦白说，我认为商界人士对于如何灵活运用还不是很清楚。 、快速组装的业务流程是怎样的？虽然业务人员会在ISO9000、6西格码等标准化管理流程中标准化流程，但很少有人尝试与技术人员一起用结构化思维去理解什么是所谓的柔性流程，更很少尝试对其进行升级。到企业层面。
如果读者一致认为数字时代的核心生产工具是软件，核心的生产方式也是通过软件来交付，那么业务人员就必须考虑提升自己的思维结构水平。否则，就很难真正实现“乐高”软件。也很难从根本上提高软件开发效率。这个原理可以类比经济学中的供给曲线和需求曲线的关系，如下图所示：
图4 软件开发绩效的供需曲线
在经济需求中，SS'代表供给曲线，DD'代表需求曲线。该理论的总体思想是供给曲线和需求曲线的交点是价格和数量的平衡点。供需总体平衡形成均衡价格E，也代表均衡水平。 。该理论的一个核心点是，仅靠移动供给或需求曲线的一侧很难实现均衡水平的良好改善。只有同时移动两条曲线才能大大提高均衡水平。
以此类推，我们可以将横轴上的数量替换为软件的输出，将纵轴调整为软件的质量。该曲线定义为供给能力曲线和需求能力曲线。在两者的交集处，我们可以将效率视为产出。和质量平衡。
遵循供需理论，我们将供给能力曲线S1S1'向S2S2'的移动视为工程方法的改进，即技术侧的努力。如果需求能力曲线不上升，单纯的技术改进无法很好地解决性能问题，甚至可能导致质量下降。这可能与大多数技术人员的直观感受不同。不过，从目前软件重构势头稳步增强的趋势来看，如果我们将“技术债”视为一种关于长期质量问题的观点，或许会更容易理解。
如果需求能力曲线同时从D1D1'移动到D2D2'，即需求能力曲线也上升，那么均衡点E3相对于E2和E1来说将会有很大的提高。从E2到E3，我们可以看作是商业思维的提升。
虽然上面的类比不是很准确，但相信读者能够理解，在数字化转型的过程中，我们强调的是业务与技术融合时应该做的一件事，那就是“刷新”业务上的思维模型方面，从而提高整体软件开发效率。如果数字化不是一个新时代，软件不是这个新时代的主要生产工具，我们就不必这样。但如果是这样的话，这几年我们一直在讨论的数字化员工的基本技能中，一定要有结构化思维能力，这是非常重要的一项。在形成这种能力的过程中，业务架构方法发挥了作用。带动作用不可忽视，它会逐渐成为一项基本能力训练。
提高软件开发效率任重而道远，架构之路也很漫长。业务架构更像是“前浪”般的火花，但未来的“后浪”可能越来越需要这个火花。
由拥有20年金融行业经验的资深架构师撰写，微软、亚马逊、阿里巴巴、百度、网易等13家知名企业架构师推荐，业务架构“知行合一”
关于作者：
付晓燕
高级企业级业务架构师，拥有超过19年金融行业经验，现就职于建信金融科技有限公司。2000年加入中国建设银行从事金融业务。 2012年调入建设银行总行成都发展中心。 2016年调入建设银行总行北京发展中心。 2018年，各中心全面转型，成立建信金融科技有限公司。
在从事金融业务的同时，多次作为核心业务人员参与业务系统开发工作，后转入技术开发部门，全职从事企业级业务架构设计多年。
工作期间，我认真学习软件流程、系统设计与分析、架构设计的理论知识，并与实践相结合，不断融合设计思想，逐步超越原有工作经验和指导理论的局限性，形成了对软件流程、系统设计与分析、架构设计等方面的理论知识。企业级业务架构。了解一般设计方法。
InfoQ中文网专栏作家，发表《中国与台湾之上》系列文章，累计阅读量超过10万。维护个人微信公众号：小谈研说，与各行业读者广泛交流，不断提高方法的通用性。
《银行数字化转型》
InfoQ明星专栏《中间平台之上》的作者是一位拥有20年银行经验的高级业务架构师。他从思维、目标、路径、技术等多个维度总结了银行数字化转型方法论。
如果您想申请加入技术问答读者群2，请回复公众号关键词：读者群
过去推荐的
技术问答
基于分布式设计、架构、系统思维，还讨论了与研发相关的各个方面，不仅限于代码、质量体系、研发管理。该帐户由经验丰富的司机技术团队维护。
