1.借助软件产品线工程方法，实现大规模重用
对于金融企业来说大部分的软件需求并不是全新的，而是已有系统需求的变体，传统的软件研发通常只关注某一具体应用领域，不断地重复开发该领域已有软件的变体，这些变体之间通常存在着大量的相似性，这为系统化和大规模软件重用奠定了基础。金融企业需要采用产品化思维，通过平台来进行重用和扩展，支撑大规模软件重用研发。产品线工程方法就是进行大规模复用的一种方法。
2.金融企业数字化中台建设关键是实现可变性管理
金融企业数字化中台建设的核心是重用，中台的建设可借鉴软件产品线工程方法实现大规模的软件重用、保证高质量的新产品开发。软件产品线的关键问题是如何进行可变性管理，并基于可变性管理实现软件核心资产的复用，因此金融企业数字化中台建设关键也是实现可变性管理。
3.实现可变性管理需要将领域工程和应用工程分离
可变性管理是对产品线范围内的通用资产和可变资产进行管理，并将可变性建模的成果透出给应用，用于应用的个性化业务的配置。建立企业级可重用能力将是金融企业数字化中台建设的主要手段，企业级可重用能力的建设可借助软件产品线工程中重用的指导思想，依托可变性管理方法，将数字化中台分为领域工程与应用工程来实现软件大规模重用的开发。领域工程是开发以重用，基于领域工程将建设可重用的共享服务中心，提供通用的业务流程和服务，并提供可变的业务定制点，用于应用工程系统化的、一致的软件重用。领域工程职责是定义主题数据并根据主题数据切分共享服务中心，实施标准化、端到端业务流程，并发布应用工程可复用的业务组件。应用工程是使用重用来开发，应用工程从领域工程的共享服务中心中获得可复用的流程和服务，使用其中可变的业务定制点，实现特定业务需求的个性化实现，从而构建出个性化的前台业务应用。应用工程职责是在利用领域工程提供的标准化、端到端流程，细化分析差异需求，通过个性化的可变点实现，完成个性化业务定制。
金融企业建立产品线时应先由产品经理制定详细的“业务方案”，“业务方案”是一个全方位的产品规划，包含目标客户、核心价值、解决方案、渠道、合作方、考核指标、竞争分析、收入分析和成本分析等。从业务的构成看，银行的业务方案可分解为客户交互（渠道）、金融产品服务、产品营销、产品运营、风险控制等部分，当一个业务方案提出后，需要明确业务在哪些渠道完成，本渠道如何交互，跨渠道如何协作；业务由哪些产品提供，这些产品需要哪些个性化要求；该业务通过何种营销手段触达客户；渠道接受客户请求后，企业内部所需的运营流程如何；该业务有哪些风险控制因素，如何控制风险。
编制系统需求时需要由中台架构人员根据重用的指导思想、依托可变性管理方法，将需求拆分为领域需求和应用需求，并梳理领域需求中可重用的能力，决定是否需要领域工程研发新的组件。
领域工程研发过程分为领域需求、领域设计、领域开发等，最终交付可重用资产，并通过“可变管理”将“通用资产”（指在业务中台建设过程中具有普遍应用价值的通用流程、服务、组件或工具类等）和“可变资产”（指在业务中台建设过程中在时间、空间、角色、业务、技术等方面存在个性化差异的扩展主题）透出共享服务给“应用工程”，而应用工程在应用需求梳理、应用设计和应用开发时复用领域工程的通用资产，同时部分复用可变资产，然后通过个性业务定制，发布应用服务。
“业务需求” 是对业务目标、业务流程、业务实体类型和决策过程的业务模型的分析描述。业务需求需要描述清楚业务目标、业务办理的流程、业务办理的条件等。在需求阶段，我们需要充分分解领域业务目标和应用业务目标，抽象可重用的业务流程和定制化的业务流程，透出共享服务，复用可变资产，建立领域需求与应用需求在需求层面的沟通体系。
在设计阶段，我们需要全面阐述业务中台建设的“体系结构”。“体系结构”是通过特定结构组合起来的 IT 系统架构，可以分解为业务架构、数据架构、应用架构、技术架构、部署架构，和技术中台对应的是技术架构，技术架构又可以分解为应用集成架构、应用技术架构和基础设施架构等。
“组件”是用来复用的，从功能的角度可以分为业务组件和技术组件，业务中台中提供的主要是业务组件，技术组件是从技术角度看的复用，我们可以分为基础设施（服务器、存储、网络等）、基础软件（数据库、操作系统等）、集成组件（门户、企业服务总线、文件传输等完成应用间集成功能的软件）、其他技术组件等。
在研发过程中需要解决的核心问题是领域工程和应用工程的业务需求沟通、体系结构的设计和交付可重用的组件，为了更好地借助领域工程和应用工程分离实现可变性管理，研发过程中也需要借助一些成熟的研发方法，包括需求的结构化描述方法、参考“4+1”视图和四色原型法进行体系结构设计、软件持续交付的方法与规范、行为驱动的软件测试方法，以及业务可变性分析的方法等。
结构化描述业务需求：
举个简单的交易前检查的例子：
V1.0 ：必须是登录的用户才可以进行交易；必须是未惩罚、未冻结的用户才可以进行交易；
V1.1：海外登录的用户IP不能是“XX.XX.XX.XX”；
V2.0：金额大于1000元需要短信验证码确认，单日限额10000元；V2.1：短信验证金额、单笔限额、单日限额可以由用户调整……；V2.5：转账给曾经转账用户小于2000元无需短信认证……；
V3.0：购买行内理财产品仅需输入密码确认；购买三方理财产品需要短信验证……；
V4.0：久眠户交易必须增加实名认证和生物识别，且金额大于500元需要审批。需求分析是软件工程中的一个关键过程，也是一个复杂的过程。
需求的管理与各个应用的特征密切相关，同时还涉及非功能性需求及其与功能性需求的错综复杂的关系。需求需要方方面面的人员参与，业务部门是需求的发出者，需求分析人员是需求的接受者，开发人员是需求的执行者，只有三方人员对需求的理解达成一致才能开发出成功的软件产品。但这三种人员由于背景知识不同、擅长的领域不同，通常不能完整、正确地了解对方领域的知识，再加上沟通的不充分，最终导致需求理解存在偏差。
4+1视图：
一个软件的架构要涵盖的内容非常多，很难一蹴而就，因此多采用分而治之的办法从不同视角分别设计。目前软件架构设计常用模型就是视图模型，可以从多个角度描述一个复杂的软件系统，分而治之下一个架构视图是从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，所以我们建议4+1视图的方式：
1. 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。
2. 开发视图：描述软件在开发环境下的静态组织。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系，比如逻辑层一般会映射到多个程序包等。
3. 运行视图：描述系统的并发和同步方面的设计。运行视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题，和开发视图相比，运行视图比较关注的正是这些运行时单元的交互问题。
4. 部署视图：描述软件如何映射到硬件，反映系统在分布方面的设计。部署视图关注目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器上，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。和运行视图相比，部署视图重视目标程序的静态位置问题，是综合考虑软件系统和整个IT系统相互影响的架构视图。
运用“4+1”视图方法可以针对不同需求进行架构设计，“4+1”视图模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西。系统工程师先从部署视图，然后从运行视图靠近体系结构；最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。
“4+1”视图可以全面阐述中台建设的体系结构，运用“逻辑视图”讲述中台分解方式、模块层次关系、依赖关系；运用“运行视图”讲述应用系统内外的运行期交互模式，柔性价值等；运用“部署视图”讲述中台进程在机器上的安装部署，并和网络等配合满足软件系统的可靠性、可伸缩等要求。运用“开发视图”讲述开发视角的组织管理形式、技术框架支撑等。运用“关键过程”讲述业务中台的研发交付机制。
四色原型：
四色原型是领域模型的一种原型，领域中的任何模型及其关系都可以抽象为“四色原型”。四色原型可以用这句话进行描述：某个人（Party）的角色（PartyRole）在某个地点（Place）的角色（PlaceRole）用某个东西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）。
（1）时刻-时间段原型（Moment-Interval Archetype）：表示在某个时刻或某一段时间内发生的某个活动。使用粉红色表示，简写为MI。
（2）参与方-地点-物品原型（Part-Place-Thing Archetype）：表示参与某个活动的人或物，地点则是活动的发生地。使用绿色表示。简写为PPT。
（3）描述原型（Description Archetype）：表示对PPT的本质描述。它不是PPT的分类！Description是从PPT抽象出来的不变的共性的属性的集合。使用蓝色表示，简写为DESC。
（4）角色原型（Role Archetype）：角色就是我们平时所理解的“身份”。使用黄色表示，简写为Role。
四色建模是建立在UML基础之上的一种新型建模方式，在建模过程中需要按照四个步骤来完成业务领域的建模工作：
分析业务流程，确认流程中的关键名词，抽象出业务实体；
从用例入手，找出其中的红色；
找出其中的相关元素；
细化每一个类的方法和属性。
这四种类型不仅规定了各种类的属性和方法，而且也蕴含了不同原型间的典型交互方式。通过彩色编码不仅有利于开发组中各种人员的沟通，而且还可以加深开发人员对领域问题的理解，从而保证开发可以按照分析阶段的领域模型正确地进行开发。
采用中台架构后，各业务系统将从原来一个巨石型系统发展为大量的服务，服务可以独立部署与发布，降低了系统耦合度，水平扩展能力得到显著提高，但也带来交付与运维复杂度增加的问题。中台建设需要建立持续交付的方法与规范，将需求、设计、开发、交付、运维的过程协同与配合，用于促进应用开发、技术运营和质量保障各职能之间的沟通、协作与整合，通过优化开发（DEV）、测试（QA）、运维（OPS）的流程，使开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
首先需要建立敏捷的项目管理方法。敏捷的项目管理方法以需求进化为核心，采用迭代、循序渐进的方法进行软件研发管理。项目不再采用瀑布式的模式，而是被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。分布式应用让应用、服务、数据、感知都可以独立发布、部署、运行，可以把一个大的业务系统项目分为多个相互联系但可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。支撑平台支持这种敏捷的项目管理方法，帮助业务系统研发团队管理需求与设计，建立需求、设计与开发、测试的关联，分配任务并跟踪进度，有效整理与跟踪出现的问题，对团队行为进行记录，通过看板方式可视化团队活动，提高各业务系统项目的项目管理水平。
其次要建立持续集成能力。持续集成可帮助业务系统的研发团队经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，支撑平台联接统一的代码库，调用研发人员编写的编译脚本、自动化测试用例进行自动构建与自动测试，通常每次代码递交后都会在持续集成服务器上触发一次构建，可以在模拟生产环境中自动测试。研发人员需要保证每次构建都要100%通过，每次构建都可以生成可发布的产品。持续集成有利于检查缺陷，了解软件的健康状况，减少了代码编译、数据库集成、测试、审查、部署及反馈中的重复劳动，同时对功能完成度和缺陷率等项目的状态自动产生有效的报告，提高了软件研发的质量。
最后要实现一键式部署与持续交付。业务系统开发过程中，往往存在多个环境，包括开发环境、测试环境、预发环境、性能测试环境、生产环境，研发人员需要将代码、配置、类库等部署到多个环境中，遇到问题需要回退到前一个状态，手工操作是一个非常繁琐的过程，通常研发人员会编写部署脚本进行一些自动化的操作，但是这些脚本又缺少规范与管理，无法成为统一、一致的行为。通过支撑平台，研发人员可以自定义部署过程，实现一键部署、一键供应、一键创建新环境，环境的创建可以通过一条命令或一键点击的方式创建，减轻运维人员的负担，避免错误，缩短业务系统上线的周期。一键式部署让持续交付成为可能，通过更频繁的自动化部署，业务系统新上线的功能可以尽可能快地呈现在用户面前，并能在一定的时间内从用户处获得尽可能多的反馈，根据反馈更快速地对新业务功能进行调整，从而加快业务系统交付的速度，适应业务变化。
传统软件研发模式的问题在于业务人员把业务需求描述给软件需求分析人员之后，软件需求分析人员按照自己的理解编写软件需求规格说明书，然后研发人员根据软件需求规格说明进行软件架构设计和编写软件代码，最后测试人员根据软件需求规格说明书编写测试案例进行测试。由业务需求到软件编码，再到软件测试的过程中，不同角色和不同人员在不同时段对软件开发所需的信息进行处理，这中间有太多可能的机会丢失、弄错甚至直接忽视业务人员的原始需求。软件研发的众多环节中，只需一个环节出错，软件研发团队就很难按时交付出符合业务人员要求的软件产品。
行为驱动开发（Behavior Driven Development，BDD）是一种敏捷软件开发的方法，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。应用在自动化测试中也可称为行为驱动测试。BDD借鉴了敏捷和精益实践，让敏捷研发团队尽可能理解产品经理或业务人员的产品需求，并在软件研发过程中及时反馈和演示软件产品的研发状态，让产品经理或业务人员根据获得的产品研发信息及时对软件产品特性进行调整。BDD帮助敏捷研发团队把精力集中在识别、理解和构建跟业务目标有关的产品特性上面，并让敏捷研发团队能够确保识别出的产品特性被正确设计和实现出来。
产品经理（业务人员）通过具体的用户故事使用场景来告诉软件需求分析人员他（她）想要什么样的软件产品。使用软件产品的使用场景来描述软件需求，可以尽可能地避免相关人员错误理解软件需求或增加自己的主观想象的需求。
软件需求分析人员（BA）和研发团队（研发人员、测试人员）一起对产品经理（业务人员）的用户故事进行分析，并梳理出具体的软件产品使用场景举例，这些场景举例使用结构化的关键字自然语言进行描述，例如中文、英文等。
研发团队使用BDD工具把用户故事场景文件转化为可执行的自动化测试代码，研发人员运行自动化测试用例来验证开发出来的软件产品是否符合用户故事场景的验收要求。
测试人员可以根据自动化测试结果开展手工测试和探索性测试。
产品经理（业务人员）可以实时查看软件研发团队的自动化测试结果和BDD工具生成的测试报告，确保软件实现符合产品经理（业务人员）的软件期望。
BDD并不是一种软件研发方法，也不是用来替代Scrum、XP、看板等现有的敏捷理论和方法，而是把现有的工作方法融合起来，让软件研发团队更加高效地工作，从而减轻因软件产品计划延误或功能缺失带来的压力。
雷达型阶段模型中，BAPO评估模型覆盖了软件工程的业务支撑、架构支撑、软件过程、组织保障四个维度，每个维度有五个级别，可以全面、科学地对软件产品或产品线的研发能力进行指导和评估，同时CMMI模型主要用于对软件过程改善和软件过程评估，对软件开发流程中的需求开发阶段有较好的参考价值。
在金融企业中台建设中，我们认为存在四个相互依赖的中台开发问题，即：业务支撑：如何从中台产品中获利；架构支撑：构建中台的技术手段；软件过程：中台开发中的流程、角色、职责和关系；组织保障：角色和职责到组织结构的实际映射。这四个问题互相关联，一个维度的变化会引起其他维度的变化。业务支撑是最有影响力的因素，必须优先考虑；架构支撑反映中台软件结构和规则中的业务问题；软件过程构建由架构支撑确定的中台产品；最后，通过组织保障执行软件过程。
为确保评估的准确性，我们结合自身在金融企业信息化建设多年的经验，综合分析后选择的国际先进BAPO评估模型是最符合金融企业中台建设的评估模型，该模型提供了一个基于软件工程成果的过程能力阶梯式进化的框架，可基于BAPO模型对金融企业中台建设进行全面且深入的评估。