企业业务架构的需求管理与软件开发的供求曲线

世事唯有变化不变，架构亦如此。企业架构因其庞大的体量，必然蕴含众多引致其变化的因素，即便是一个被仔细切分过的服务也很难保证自己不会变化，何况包罗万象的架构。架构设计并不是为了一味的追求稳定，甚至不是为了单纯以复用为目标，架构首要任务是澄清事物的内部结构，这即是为了更好地再现事物（从业务需求到技术实现，本身就是一个再现的过程），也是为了通过一个清晰的结构接纳变化。架构的关键职能之一就是如何更好地接纳变化，对变化的范围和影响作出尽可能清晰的判断，而这个判断除了架构师的能力外，还可以依靠良好的架构资产，良好的架构资产是提高架构师团队平均水平和复杂工程管理效能的有效方式。

企业架构的设计本身需要消耗较大的资源，而破坏却很容易，通过一个一个需求对整体架构的些小违犯，就会积累出大量的偏离。架构资产相当于企业的能力地图，如下图所示：

图1 基于企业级业务架构的企业能力地图

作战需要军事地图，旅游需要旅游地图，做企业架构、企业转型自然也需要企业能力地图，有了地图才好走路。企业能力地图可以标识企业从战略到业务流程到IT实现的完整路径，但是地图的准确性是需要不断维持的，需求总在路上，系统一直在变化，地图自然需要更新，而更新最好的方式莫过于使用，坚持用企业级业务架构方法分解新需求，从而保持对地图的更新。关于企业级业务架构的详细构建方法，请参看笔者《企业级业务架构设计：方法论与实践》一书，本文集中讨论基于企业级业务架构已有的架构资产进行需求管理。

一、需求分析

需求管理是一个过程，在讨论管理之前，还是先讨论下如何应用架构资产进行分析，讨论过用法再讨论管理问题。

既然本文已经假设了具备架构资产，那么就先虚拟一个业务范围不是很完整的银行业务架构，并集中在对业务组件的展示上，不再花费过多笔墨从价值链一路讨论到业务组件了。我们假定一个具有存款、贷款、理财、贸易融资等几项业务的银行，其主要业务组件可能如下图所示：

图2 基于企业级业务架构的企业能力地图

在这个不完整的银行中，假定暂有9个组件，4个位于领域层，分别负责存款、贷款、理财、贸易融资方面的业务处理；5个位于公共层，分别负责统一的客户信息管理、统一的客户关系管理（一般包括客户政策、客户分配、集团客户关系维护等）、汇总分类账进而产生总账的财务会计、统一的风险管理和报表管理等职责。其实一提公共层，很多读者可能就会发现，这个架构是不是也有些“中台”的味道。

请注意，这里是业务组件，不是逻辑子系统，提到业务架构，也不要轻易把目前很多技术方案中画了几个功能模块的“业务架构”与通过完整的企业级业务架构方法得出的业务组件等同。熟悉笔者之前方法论介绍的读者会知道，每个组件中聚类的是关系相近的数据以及和这些数据关系相近的行为，是经过充分的分析和企业级标准化处理之后的结果，而非在预先指定了系统边界后切出来的内部功能模块。

有了架构（当然线条很粗）就可以应用架构资产进行需求分析，我们可以用下区块链的例子，区块链在金融领域的应用还是比较广泛的，我们可以虚拟讨论下，如果业务部门或者技术团队提出要用区块链技术构建新的贸易融资平台，那么业务架构会怎么看这个问题？

首先，业务架构是从业务角度出发看问题，而不会直接受技术实现方式的干扰。那么，区块链的贸易融资平台就要先分析业务流程有哪些变化。国内区块链一般是联盟链的方式，多数平台对成员资质都有认证，既有发行机构CA证书的，也有采用国家CA证书的，无论用那种方式，成员管理都是其必要流程之一。

客户信息的建立与维护自不必说，这个流程必然有，而且总体来讲，因为贸易融资的业务要求现阶段并不会因为区块链改变，所以客户信息管理流程也不会有什么变化。同样不变的还有业务处理流程，比如信用证的处理过程，区块链平台一般是提供了业务资料的可信传输，利用了区块链的防篡改属性进行信息加固。采用区块链平台之后也许自动化处理能力可以适度提升，但自动化处理严格来说并没有彻底改变操作环节，而是操作者从人变成了计算机，如果业务建模具备适当的抽象度的话，那么，自动化处理对业务模型的改变并不是十分明显，RPA理论上也是如此。

如果上述分析成立的话，那么，主要的流程变化其实在联盟管理上，也就是成员的资质认证，这部分可以归属于客户关系管理组件，在数据上可以表现为客户间的联盟关系、联盟角色等，相应的业务处理过程，也就是新增的任务，可以放在客户关系管理组件中。

那么区块链在哪里呢？业务架构上其实看不到的，业务架构主要看业务是否变化了，而区块链账本这些东西属于技术实现上的选择，也就是说，技术架构上会增加区块链平台，应用架构上会增加在区块链平台上部署的服务，而这些服务对应的是上述提到的业务功能。相当于在业务架构梳理清楚后，应用架构根据技术架构的变动改变了服务的位置。

那么区块链不在业务架构上体现，怎么看得到业务与技术的融合呢？如果想让业务侧真的感受到变化，那一定是区块链改变了业务形态。比如需要新增加的联盟管理，这个业务有充分的感知，但是其他流程的变化是否会有如此明显，考验的就是业务和技术双方结合运用区块链改善现有业务形态的能力了，而新技术的应用最终是简化了流程和架构，还是导致了更复杂的处理，也可以通过对比得出。对其他新技术的应用也是如此。

通过这个虚拟的分析过程，读者可以感受到业务架构是如何分析需求、如何处理新技术的，而新技术如何应用才可能为业务带来改善。本文因篇幅和信息的限制，不再展开详细的建模过程。

二、需求管理

谈到管理就是组织和流程的问题了。首先，企业是否有专门的业务架构师团队或者岗位，如果有的话，当然应该由业务架构师们牵头建立企业的架构资产，然后依托架构资产进行业务需求的架构层级设计，负责识别需求相关的业务流程、数据实体、业务组件等架构元素，给出业务架构解决方案，再通过项目管理机制转化为项目任务执行，理想的工作方式是笔者之前一直主张的业务架构师派驻到业务部门中进行需求管理的方式，示意图如下：

图3 基于企业级业务架构的企业能力地图

在这个流程中，从组件到企业架构这部分是负责解决项目团队间的架构分歧的，由统一的企业架构管理团队负责最终决定。

架构资产的变动最好由业务架构师统一维护，如果建模层次较深，细节较多，也可以采取分层级维护的方式，颗粒度最细一级的由组件项目团队中的需分或产品人员负责。业务架构团队也必须定期进行架构资产的质量检查，以确保资产更新的及时性和准确性，可以将这部分列为对项目团队的考核依据。

通过需求分析那部分的介绍，读者也可以理解为什么业务架构师派驻在业务部门更合适，这样可以离前端更近，有更好的业务感觉，第一时间了解业务人员需要什么、困惑什么，帮助业务人员了解新技术的应用。业务架构师每工作一段时间后应该在部门间进行轮换，以保持其企业级视角，并推动部门间的协作。

那么对于没有业务架构师团队或者岗位的企业，这样的企业一般也没有业务架构方面的架构资产，相当于要从头建立上述管理体制。培养业务架构师对企业进化、数字化转型等工作而言非常必要，通过业务架构将业务和技术衔接起来，是实现业务与技术深度融合的起步性工作。培养多少业务架构师则要看企业的规模，人少的企业，除了少数专职的架构师外，也可以考虑在业务部门、项目团队中建立适当数量的兼职业务架构师。

三、提升开发效能

软件工程发展至今接近50年了，企业架构的历程也有30多年，技术侧作为技术服务供给方一直在持续提升自己的开发效能，软件开发和设计工艺取得了长足的进步，但是，随着社会逐步开始向数字化转型，软件需求的规模只会越来越大，甚至出现爆炸性增长。据Gartner最新预测，未来五年新构建的应用数量可达5亿之多，超过之前40年的总和，尽管很难考证这一数据，但数字化社会最主要的生产工具莫过于软件，数字化银行的愿景如笔者在新书《银行数字化转型》中所描述，软件覆盖一切，这就意味着更大规模的软件生产还在等待着技术人员，如何提升开发效能是重中之重。

已有的工程和架构理论基本上都是站在技术侧看待这个问题，而很少从业务侧看待如何提升开发效能。数字化转型是整个社会的转型，是一个新的时代，新的时代必然要求从业者的技能发生很大变化，从农业的农耕技能到工业的机器操控技能到信息时代的软件应用技能，那么数字化时代，所有从业者必须具备的就是软件构建技能，当然，这不意味着必须懂编程级的实现，而是懂得如何构筑“乐高”式软件，来实现业务与技术的高效衔接。

“乐高”式软件的探讨已有多年，但是迟迟未见良好的实现，低代码平台也是这方面的探索者。“乐高”式软件一直比较难于构建的关键原因很可能是技术人员一直无法真正把握业务人员心目中的“乐高”式业务该是什么样，坦白的讲，我觉得业务人员也不是很清楚可以灵活、快速地组装的业务流程到底是什么样。业务人员尽管会在ISO9000、六西格玛等标准化管理过程中进行流程的标准化，但是很少有与技术人员尝试共同用结构化的思维一起理解所谓灵活的流程到底是什么，更少有将这种尝试上升到企业级层面。

如果读者认可数字化时代的核心生产工具是软件，核心生产方式也是通过软件送达服务，那么，业务人员提升思维结构化水平就是必须要考虑的事情，不然，“乐高”式软件很难真正实现，软件开发效能也很难获得根本性提升。这个道理可以用经济学中供求曲线的关系来类比，如下图所示：

图4 软件开发效能中的供求曲线

经济需中用SS’代表供给曲线，DD’代表需求曲线，该理论的大意是供给曲线和需求曲线的交汇点就是价格与数量的平衡点，供求总体平衡，形成均衡价格E，也代表均衡水平。该理论的一个核心点是，单靠供给或需求曲线一方的移动，均衡水平很难获得良好的提升，两条曲线同时移动才能获得均衡水平的较大提升。

类比中，我们可以将横轴的数量替换成软件的产量，而纵轴调整为软件的质量，将曲线定义为供给能力曲线和需求能力曲线，二者的交汇点，我们可以视为效能在产量和质量上的平衡点。

沿用供求理论，我们将供给能力曲线S1S1’向S2S2’的移动视为工程方法的提升，也就是以技术侧为主的努力，那么在需求能力曲线没有上升的情况下，单纯的技术改善并不能很好地解决效能问题，甚至可能造成质量下降，这也许与多数技术人员的直观感觉不同，但是从现在软件重构势头稳增不减的趋势看，如果我们把“技术债务”也视为一项远期质量问题，可能会更容易理解这个观点。

如果需求能力曲线同步从D1D1’向D2D2’移动，即需求能力曲线也上升，那么，均衡点E3相比E2和E1，都会是一个很大的提高。从E2到E3这部分，我们可以视为业务思维的提升。

上述类比尽管不是很精确，但是相信读者能够理解在数字化转型过程中，我们强调业务和技术融合时该做的一件事是什么，那就是“刷新”业务侧的思维模式，从而在整体上提升软件开发效能。如果数字化不是一个新时代，软件不是这个新时代最主要的生产工具，我们大可不必如此。但如果是，我们这几年一直在讨论的数字化员工的基本技能中，就必须要有结构化思维能力这非常重要的一项，而在这一能力的形成过程中，业务架构方法起到的推动作用不可忽视，它将逐渐成为一项基本能力训练。

软件开发效能提升任重道远，架构之路也很漫长，业务架构更像一团“前浪”般的星星之火，但是，未来的“后浪”们可能越来越需要这团星星之火。