这段视频在企业内部激起了不小的讨论，在当前的这个钱越来越难赚的行业背景下，数禾应该如何卷和熬成为了数禾人必须思考的问题， 聚焦到技术团队内部，呼应公司层的决策，也采取了一系列举措：建立BizDevops流程体系、引入DDD指导应用架构实践、建立研发效能度量体系；然而这些举措还是无法清晰回答“研发投入和系统完备度之间的关系”，例如：信贷核心系统做了这么久，为什么还是需要投入这么多研发资源 ？
2 如何解产研这道题？
我们虽然有研发效能度量，但是这套度量指标主要是针对BizDevops流程的多、快、好、省而制定的指标，能够反馈出来我们的研发资源投入情况，但是很难回答为什么需要投入这些研发资源；而要回答这个问题，就需要结合系统建设情况做关联分析。
在结合系统建设情况做关联分析的时候，我们又遇到了新的问题，我们每天都在说“应用、系统、领域、产品”，这些词到底是不是同一个意思？再基础性的概念问题都没有说清楚的时候，我们更加无法回答，资源投到哪里去了？
为了解决这一系列产研的问题，我们经过无数次的探讨，总结了一套思路，我们称之为“产品化体系建设”，本文主要是介绍产品化体系建设的三步主要是怎么做的，并且在文末给出了一个详细的产品梳理的案例。
产品化体系建设三步走
3 基于企业架构做要素拆解
3.1 什么是企业架构
企业架构是定义企业各个组成部分如何构建，企业各个组成部分之间的关系以及企业各个组成部分演变的原则和规定，主要包括：业务架构、数据架构、应用架构、技术架构。
企业架构是战略和数字化项目的桥梁，向上衔接战略规划，向下连接项目实施。“协调”与“对齐”是企业架构的重要特性和作用之一，纵向协调战略、规划、实施、运营各层级一致性。横向对齐业务、数据、应用与技术。
企业架构在企业中的位置
3.2 数禾企业架构框架（SEAF）
数禾企业架构框架（SEAF）：是一个符合数禾的企业现状的，参考了TOGAF和华为企业架构而形成的一套轻量化、可落地的企业架构方法。框架本身需要遵循下面的四条原则：
- 战略和业务价值驱动：一切从业务出发，以价值驱动，是架构设计的重要的原则和基础
- 符合数禾现状可落地：企业架构框架和产研流程紧密融合，让所有企业架构框架中的要素都在产研中被严格遵从
- 轻量化：概念简化，只保留工作中需要的要素，去除不必要的要素
- 产品化：以产品为中心打造4A架构体系，流程通过产品实现线上化、应用实现产品功能并归属于产品，产研流程以产品化开发模式，通过组合各个产品功能， 交付符合业务期望的解决方案。
3.3 数禾企业架构模型
企业架构模型：是对于架构核心概念要素的精确定义和描述，元模型构成了架构设计的“基本语言要素”，通过元模型及其关系的表达，就可以通过结构化的方式对于架构进行描述和展现，元模型是企业级架构框架的核心，是对于架构描述的“统一语言”。
3.3.1 数禾企业架构元模型
数禾企业架构元模型
3.3.2 数禾企业架构核心要素解释
企业架构核心要素
3.4 产出企业的产品地图
对公司已有的产品资产进行梳理，形成一个产品全景图基线，并且建立完善的产品生命周期管理体系，以提高产品成熟度为过程目标，最终实现三大目标：减少产研投入人力、提高产研质量、沉淀科技能力。
每一个产品的梳理都应该做到：梳理业务流程，识别业务对象、业务过程和使用的业务规则。首先实现对象、过程的系统化管理，记录业务对象的全量、全生命周期数据，记录业务活动的执行或操作轨迹，实现业务规则的结构化、配置化管理。然后进一步向业务流程自动化、业务决策智能化的方向发展。
金融科技企业产品地图
4 产品标准
产品标准是通过经验积累，将一个产品必备的能力组合形成一套用于指导产品如何变好的标准。但是并不是符合产品标准就一定是一个好产品， 产品标准是用于提高产品下限的，要做好产品，还需要产品经理不断探索，把产品做精做透。
产品标准框架
5 产品化运营体系
- 对标阿里的 “BIzDevops”方法，整理数禾的产研流程，和产品的生命周期匹配。
- 建立产品/应用架构资产库，沉淀架构资产，提高产研流程的运行效率。
- 建立以产品为中心的运营团队， 技术委员会为牵头组织， 每个产品任命对应的产品负责人和技术负责人。
- 建立产品标准和度量体系，指导产品建设，提高产品的成熟度。
产品运营体系
6 应用架构实践案例
本案例是以贷后催收业务为背景，从催收业务流程触发，逐步分析最后产出一套基于企业公共能力、满足催收业务场景的解决方案。
6.1 基于业务流程总结功能模块
1. 从业务流程中识别业务活动和业务对象
2. 基于业务活动和业务对象划分业务功能模块
核心业务功能模块
业务功能模块类型
- 核心模块：由主业务流程中的业务活动形成，如“催收数据处理”、“规则码分案”
- 支撑模块：支撑核心模块的对象管理模块，如用于支撑“坐席分案”的“坐席管理”，支撑非主业务流程的模块，如“账务处理”、“质检管理”
- 通用模块：各业务线都需要的功能模块，通常有比较标准的实现方案，如“系统管理”、“数据大盘”
6.2 梳理业务功能矩阵
从业务功能模块进一步分解到业务功能，可以参考以下方法：对于基于业务活动划分的功能模块，通常可以按照业务场景来划分功能点，如“分案”业务模块按照业务场景可以分为“规则码分案”、“坐席分案”等 对于基于业务对象划分的功能模块，通常包括一组相关对象的生命周期管理，如“通知管理”包括“短信模板配置”、“AI提醒模板配置”等。
业务功能矩阵
6.3 划分产品
将上一步梳理出来的业务功能各类到各个产品中。
产品业务功能矩阵
6.4 产出产品架构
产品架构由产品功能模块和产品功能组成。 面向特定业务领域的产品往往只出现在单一解决方案中，其产品架构形态也与业务功能矩阵比较类似。
产品架构
6.5 产品功能拆分到应用
产品架构中的每个产品功能都应该有明确的应用来承载。从产品架构到应用架构只是将产品功能划分到对应的应用。基于应用架构设计原则，结合技术架构标准，进一步拆分应用，形成最终版本的应用清单，输出最后的应用架构图。
应用架构
6.6 形成面向业务领域的解决方案
解决方案由产品+实施组成。 一套解决方案通常包含N个产品，在此基础上完成产品配置和集成的实施工作，从而实现特定领域内的业务能力。 产品所属领域划分：
- 核心域：实现核心业务功能，承载核心业务流程处理 支撑域：支撑核心业务功能，增强业务处理能力
- 通用域：业务属性较弱，在多个业务领域都可能需要通用能力，往往有比较标准的实现方式
- 数据域：业务实现数字化、智能化必不可少的功能领域
解决方案架构
7总结
架构管理是一个复杂的系统工程，只靠一套方法论和少数运动式的项目是无法达成目标的；要达到期望的目标既需要企业架构这样的方法论，从顶层做好规划，也需要敏捷开发这样的实践方法，创建MVP而不是追求完美，在实践过程中快速迭代。我们的应用架构管理实践之路才刚刚开始，路漫漫其修远兮，在实践的过程中自我迭代也是非常重要的， 只有自我认知跟得上，才是实践成功的最大保障。
