应用研发解耦分析方法与实践

自2017年起，顺应金融科技发展潮流和内部数字化转型要求，工商银行启动智慧银行生态建设工程(ECOS)，实现信息系统的“代际”跃升，打造了金融与科技高度融合的全新生态体系。其间，工商银行构建企业级业务架构，并以此为指导建立了分层解耦的企业级IT架构，实现业务架构与IT架构的融合统一。与此同时，工商银行还创新构建了基于业务架构的管控机制和研发模式，例如，建立组件化研发机制，实现业务模型的高效传导，促进IT对业务的一致性承接，并大力推进板块化研发，实现架构布局与研发分工合理匹配。在此基础上，为持续完善研发分工体系，工商银行对研发解耦的分析方法与改进措施展开了深入探索。一、研发耦合概述与应对思路在信息科技领域，高内聚、低耦合是衡量IT系统设计优劣的重要标准之一，其核心目的即在于增强程序的可重用性和移植性。实际工作中，为满足不同的业务需求，一家企业的IT系统通常会涉及大量应用，且不同应用间还会通过服务调用、文件传递等方式进行信息交互，此类交互即为应用间的耦合。当用于交互的服务和文件发生变化时，往往还需要调用方同步进行修改，从而导致了研发层面的耦合。简而言之，应用间的耦合无法避免，否则可能会再次形成众多的信息孤岛，但通过合理的架构设计，可以在一定程度上减少耦合带来的影响。需要强调的是，应用间的耦合并不代表研发耦合，例如，如果应用对外服务设计足够灵活、具备前瞻性，而且在多数情况下可直接复用，就能够有效减少研发耦合。实践中，企业一般会选择对IT系统进行分层分组设计，同时建立应用层组模型来区分IT架构中的“稳态”和“敏态”，并对其实行差异化管理，以有效减少应用间耦合。基于这一方法，本文以银行业典型的IT应用架构层组模型(如图1所示)为基础展开了研发解耦分析。图1银行业典型的IT应用架构层组模型结合上述模型，工商银行在构建渠道、产品和基础服务时分别遵循了以下理念：一是在渠道建设方面，保持渠道和产品分离，并确保同一产品在不同渠道可得到一致的体验和服务。二是在产品建设方面，对不同类型产品按高内聚的原则进行分组，形成产品“板块”，且“板块”之间为松耦合关系。三是在基础服务建设方面，产品层各应用提供稳定的公共基础服务，并避免因修改导致上层应用出现大面积配合改造。此外，为进一步降低研发耦合，工商银行采用板块化分工方式，将产品根据相似性分为不同的板块，同一板块的研发分工尽量归属同一研发部门，从而避免同一业务部门与多个研发部沟通。二、研发耦合量化分析方法与实践现阶段，研发耦合与应用架构规划紧密相关，因此研发耦合分析需要与架构规划的原则和要求相结合。基于这一认知，笔者团队总结了一种面向研发耦合的量化分析方法，即通过数据可视化展现，直接研判当前存在的研发耦合热点，从而为问题分析和优化措施提供依据。具体而言，研发耦合分析流程主要包括评估指标制定、数据收集整理、数据可视化展现、问题分析挖掘、制定提升计划等五个步骤(如图2所示)。图2研发耦合分析流程1.评估指标制定研发耦合的最大影响在于跨团队的沟通和协调，因此指标选择上可以从跨团队的配合次数和配合工作量等方面进行衡量，其中团队级别越高，影响就越大。例如，工商银行软件开发中心在全国有7个研发部，研发分工遵循“板块化”的原则，研发耦合度最大的影响体现在跨研发部的沟通和配合。为此，笔者团队选择了跨研发部的需求作为评估指标，同时将配合工作量作为辅助指标。在需求管理上，工商银行一般将需求项作为基本管理单元(需求项指具有业务价值并能产生业务效果的，包含端到端完整业务场景的，最小范围可独立投产的需求)，但在实际执行中，也可以选择以研发项目为最小粒度进行评估。研发耦合指标不仅可以反映当前存在的研发耦合问题，也可以反映研发分工的合理性。2.数据收集整理为识别研发耦合，可以利用项目管理工具来收集各类信息，包括需求项的牵头应用、配合应用、配合工作量、各应用所属分组、牵头研发部等。同时，在收集过程中还需要对基础数据进行分析处理，以识别跨研发部门的需求项，而同一需求项也可能涉及多个应用和多个部门的研发耦合。对此，前期可以利用Excel等工具进行处理，后续可以考虑直接在系统中进行定制开发。3.数据可视化展现研发耦合是应用间耦合的外在表现，其本质是反映两个应用间的关联关系。因此，在展现时可以采用矩阵形式，统计内容则可以是研发耦合的需求项数量以及配合的工作量。以工商银行为例，由于应用数量较多，因此笔者团队在数据可视化阶段选择了分组方式，以期能更直观地体现耦合的热点区域。如图3所示，跨研发部耦合的需求项数量越多则颜色越深，从而有助于快速定位热点区域。图3数据可视化展现示例4.问题分析挖掘尽管数据可视化展示有助于快速发现研发耦合热点，但耦合的合理性以及解耦方法等还需要结合架构规划进一步分析确认。对此，笔者团队总结了如下经验规则：一是区分临时耦合与长期耦合。例如，部分应用在新建初期需要与其他应用对接，会产生较多的研发耦合，但该类耦合属于一次性工作，不具备长期性，因此不需要进行解耦分析。二是区分影响程度和范围。例如，研发耦合的最终影响会导致沟通成本与学习成本上升，而对于部分常规性的工作(如网上银行菜单统一发版等)，虽然需要跨研发部门配合，但工作量较少，对配合部门的研发影响也较为有限，因此可以考虑保持现状。此外，由于IT架构的差异，各家银行的研发耦合情况可能有所不同。以上述数据可视化展现为例，常见的研发耦合类型见表1。表1常见的研发耦合类型5.制定提升计划在明确研发解耦的策略后，可结合业务需求制定解耦版本计划。同时，对于分工调整的情况，因其可能涉及人员变化，所以应在充分评估投入产品效果的基础上，再最终制定提升计划。三、应用案例解析实践中，研发人员可以先从可视化图表入手总结耦合热点，之后再从横向和纵向上分别寻找耦合表现，从明细数据了解耦合的具体情况，最终分析该研发过程是否可以解耦。针对上述过程，笔者结合图3中的数据，分别从产品研发、渠道研发以及基础研发等角度展开了解耦分析，并尝试提出可行性建议。1.产品与渠道研发耦合尽管现实中产品与渠道的研发耦合较多，但如果该情况符合架构规划的预期，则属于合理耦合，对此，笔者团队选择通过渠道平台化等方式来优化研发分工。例如，工商银行通过在网上银行渠道推行平台化开发，各产品团队既负责产品业务逻辑开发，也负责网上银行前端界面的开发，从而基于该方法实现了产品与渠道的研发解耦。需要注意的是，该方法受特定技术和设备限制，通常难以做到100%的研发解耦。渠道应用平台化研发转变如图4所示。图4渠道应用平台化研发转变示意2.产品与产品研发耦合图3显示，信贷分组内部存在跨研发部耦合，说明同一分组下的应用分属于不同的研发部门，而通过进一步分析可以定位耦合的应用和相应的研发部门，并结合实际情况来调整应用研发分工实现研发解耦。从纵向上，产品组3几乎需要配合所有产品的修改，说明产品组3与多个产品分组产生研发耦合，同时服务也不够稳定。对此，通过进一步分析可以发现，该分组中的某应用具备公共服务属性，因此可以考虑将该应用或部分服务下沉至业务基础服务层，并逐步提升服务的通用性和灵活性，避免反复修改。3.产品与基础层研发耦合案例图3显示，技术组2牵头，多个产品与业务基础服务分组均受其影响需要配合修改，影响面非常广。为避免此类情况，技术基础服务的修改应尽量在应用内部封闭，以减少外部服务的变动;同时，如果确实需要修改，也应对修改周期进行合理规划，避免影响业务产品研发。综上，研发