下载掌阅APP，畅读海量书库
立即打开
随着金融企业软件应用领域逐步扩大，科技部门需要交付的软件产品数量将呈现出指数级增长。面对不断增长的软件产品规模，如何灵活定制软件缩短新业态软件产品的上市时间？如何提高软件产品的质量、交付稳定可靠的产品以降低核心系统风险？如何降低软件开发、维护的成本让知识工作者创造更大的价值？这些都是科技部门必须解决的问题，如图3-2-1所示。
图3-2-1 金融企业科技部门要解决的问题
对于金融企业来说大部分的软件需求并不是全新的，而是已有系统需求的变体，传统的软件研发通常只关注某一具体应用领域，不断地重复开发该领域已有软件的变体，这些变体之间通常存在着大量的相似性，这为系统化和大规模软件重用奠定了基础。金融企业需要采用产品化思维，通过平台来进行重用和扩展，支撑大规模软件重用研发。产品线工程方法就是进行大规模复用的一种方法。
软件产品线起源于20世纪70年代对程序族的研究，80年代中期开始使用软件产品线开发系统，90年代中期出现了对软件产品线正式的理论研究，进入21世纪软件产品线的研究已成为软件工程领域的热门，借助于软件工程中软件重用和软件架构的理论基础，软件产品线成为一种非常专业的软件开发组织的方法。
软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集合，这个特征集合能满足选定的市场或任务领域的特定需求，这些系统遵循一个预先描述的方式，它们是在一个公共的核心资源基础上开发的。软件产品线工程是基于软件产品线理论进行规模化软件开发的方法，主要包括领域工程、应用系统工程和产品线管理三个方面，领域工程是其中的核心部分，它是领域核心资产（包括领域模型、领域体系结构、领域构件等）的生产阶段；应用系统工程面向特定应用需求，在领域核心资产的基础上，面向特定应用需求实现应用系统的定制和开发；而产品线管理则从技术和组织两个方面为软件产品线的建立和长期发展提供管理支持。
金融企业数字化中台建设的核心是重用，中台的建设可借鉴软件产品线工程方法实现大规模的软件重用、保证高质量的新产品开发。软件产品线的关键问题是如何进行可变性管理，并基于可变性管理实现软件核心资产的复用，因此金融企业数字化中台建设关键也是实现可变性管理，如图3-2-2所示。
图3-2-2 可变性管理
可变性管理是重用最重要的手段。传统SOA的服务化也是解决重用问题的，但SOA架构下的服务强调互联互通的标准化，并没有为服务的可变化能力进行标准化定义。为了适应不同的情况，服务往往有下面几种方式：一是多版本方式，不同版本对应不同的业务，实际上每个版本就是不同的服务，我们不建议这种多版本方式管理服务，还不如做成一个新服务来维护；二是利用不同的输入参数标识需求特征，在实现中利用不同的代码分支（例如面向对象的多态方式）实现，这种模式是一个常见模式，但这种方式对小粒度重用是有效的，大粒度重用时就会造成输入输出定义复杂，难以使用；三是通过内部配置的方式生成可执行的代码，这种方式已经接近重用的最佳方式，缺点是如何进行配置，能够支持哪些变化，外界是不可知的。因此，数字化中台建设重点是需要将重用能力所支持的可变性标准化出来，可变性建模是可变性管理的关键技术，可实现产品家族成员的共性和可变性的描述。
可变性管理是对产品线范围内的通用资产和可变资产进行管理，并将可变性建模的成果透出给应用，用于应用的个性化业务的配置。建立企业级可重用能力将是金融企业数字化中台建设的主要手段，企业级可重用能力的建设可借助软件产品线工程中重用的指导思想，依托可变性管理方法，将数字化中台分为领域工程与应用工程来实现软件大规模重用的开发。
领域工程是开发以重用，基于领域工程将建设可重用的共享服务中心，提供通用的业务流程和服务，并提供可变的业务定制点，用于应用工程系统化的、一致的软件重用。领域工程职责是定义主题数据并根据主题数据切分共享服务中心，实施标准化、端到端业务流程，并发布应用工程可复用的业务组件。领域工程和应用工程分离示意图如图3-2-3所示。
图3-2-3 领域工程和应用工程分离示意图
应用工程是使用重用来开发，应用工程从领域工程的共享服务中心中获得可复用的流程和服务，使用其中可变的业务定制点，实现特定业务需求的个性化实现，从而构建出个性化的前台业务应用。应用工程职责是在利用领域工程提供的标准化、端到端流程，细化分析差异需求，通过个性化的可变点实现，完成个性化业务定制。研发过程如图3-2-4所示。
图3-2-4 研发过程
金融企业建立产品线时应先由产品经理制定详细的“业务方案”，“业务方案”是一个全方位的产品规划，包含目标客户、核心价值、解决方案、渠道、合作方、考核指标、竞争分析、收入分析和成本分析等。从业务的构成看，银行的业务方案可分解为客户交互（渠道）、金融产品服务、产品营销、产品运营、风险控制等部分，当一个业务方案提出后，需要明确业务在哪些渠道完成，本渠道如何交互，跨渠道如何协作；业务由哪些产品提供，这些产品需要哪些个性化要求；该业务通过何种营销手段触达客户；渠道接受客户请求后，企业内部所需的运营流程如何；该业务有哪些风险控制因素，如何控制风险。
编制系统需求时需要由中台架构人员根据重用的指导思想、依托可变性管理方法，将需求拆分为领域需求和应用需求，并梳理领域需求中可重用的能力，决定是否需要领域工程研发新的组件。
领域工程研发过程分为领域需求、领域设计、领域开发等，最终交付可重用资产，并通过“可变管理”将“通用资产”（指在业务中台建设过程中具有普遍应用价值的通用流程、服务、组件或工具类等）和“可变资产”（指在业务中台建设过程中在时间、空间、角色、业务、技术等方面存在个性化差异的扩展主题）透出共享服务给“应用工程”，而应用工程在应用需求梳理、应用设计和应用开发时复用领域工程的通用资产，同时部分复用可变资产，然后通过个性业务定制，发布应用服务。
“业务需求”是对业务目标、业务流程、业务实体类型和决策过程的业务模型的分析描述。业务需求需要描述清楚业务目标、业务办理的流程、业务办理的条件等。在需求阶段，我们需要充分分解领域业务目标和应用业务目标，抽象可重用的业务流程和定制化的业务流程，透出共享服务，复用可变资产，建立领域需求与应用需求在需求层面的沟通体系。
在设计阶段，我们需要全面阐述业务中台建设的“体系结构”。“体系结构”是通过特定结构组合起来的IT系统架构，可以分解为业务架构、数据架构、应用架构、技术架构、部署架构，和技术中台对应的是技术架构，技术架构又可以分解为应用集成架构、应用技术架构和基础设施架构等。
“组件”是用来复用的，从功能的角度可以分为业务组件和技术组件，业务中台中提供的主要是业务组件，技术组件是从技术角度看的复用，我们可以分为基础设施（服务器、存储、网络等）、基础软件（数据库、操作系统等）、集成组件（门户、企业服务总线、文件传输等完成应用间集成功能的软件）、其他技术组件等。