文档

金融行业系统设计与咨询服务

更新时间:
一键部署

1.服务概述

1.1.服务说明

金融行业业务系统设计咨询服务是当金融企业进行业务模式创新,平台级系统上云,老旧业务系统上云时,为客户提供系统方案的咨询与设计服务,内容包含业务架构设计、应用架构设计、技术架构设计,及方案落地指导。该服务由阿里云新金融交付专家团队为客户提供业务系统的整体设计与实施路径规划,采用设计思维,微服务架构及平台化思想,合理和高效的结合阿里云产品和技术为业务带来价值,同时为完成快速平滑上云做准备,实现数字化转型的第一步。

业务系统设计咨询服务包含2项子服务,客户可以结合自身业务需求进行购买:

  • 基础咨询服务

针对单业务场景的系统,设计咨询服务包含以下内容: 单业务场景系统复杂度判断标准参考:系统支持的业务覆盖1类用户,3种以内的核心业务模式,涉及2个以内的业务部门,内外部集成系统不超过5个。

服务目录

服务简介

系统目标拆解

通过与项目核心干系人访谈及目标拆解工作坊对系统目标进行确认与拆解,作为后续设计与交付阶段可落地的方向性指导。

现状梳理与需求分析

通过一系列对不同角色(如业务部门,技术部门,管理团队,典型用户代表等)进行访谈以及结合技术与业务角色的工作坊讨论,充分理解当前现状,痛点与核心诉求,识别机会点。

业务方案设计/确认

参考最佳实践,通过设计思维,基于客户现状对上层业务方案进行设计。

开发规范对齐

参考客户已有技术规范,结合项目现状,产品选型等进行开发规范的设计及宣贯。

应用架构设计

基于业务方案进行应用架构设计,指导技术实现。基于领域设计思想,对系统进行战略及战术级别领域建模,指导微服务拆分。咨询阶段领域模型主要在L2层级。

微服务拆分

结合领域与技术实现进行微服务设计,划分边界。

技术架构设计

技术架构设计及基于客户偏好的产品选型建议,包含关键技术专题。

系统集成方案设计

集成地图设计,包含内外部集成场景及分场景的集成方案指导。

DevOps规范设计

对DevOps规范如配置管理,分支策略,效能度量等进行设计。

测试策略设计

设计指导交付过程中的分层测试策略

团队结构及协作模式建议

采取迭代式敏捷交付的思想,提出项目进入交付后的交付团队设置,各角色职责及协作模式建议。

方案交接

针对后续交付团队核心成员进行设计讲解与方案交接

  • 增补咨询服务

基于目标系统的业务复杂度,集成复杂度,组织复杂度等不同,具体工作量可能有所增加,可基于售前实际评估补充人天。

在基础服务覆盖的复杂度上每增加1类用户,或一种业务模式则需要补充一个增补包。

增补服务项同基础服务。

服务目录

服务简介

系统目标拆解

通过与项目核心干系人访谈及目标拆解工作坊对系统目标进行确认与拆解,作为后续设计与交付阶段可落地的方向性指导。

现状梳理与需求分析

通过一系列对不同角色(如业务部门,技术部门,管理团队,典型用户代表等)进行访谈以及结合技术与业务角色的工作坊讨论,充分理解当前现状,痛点与核心诉求,识别机会点。

业务方案设计/确认

参考最佳实践,通过设计思维,基于客户现状对上层业务方案进行设计。

开发规范对齐

参考客户已有技术规范,结合项目现状,产品选型等进行开发规范的设计及宣贯。

应用架构设计

基于业务方案进行应用架构设计,指导技术实现。基于领域设计思想,对系统进行战略及战术级别领域建模,指导微服务拆分。咨询阶段领域模型主要在L2层级。

微服务拆分

结合领域与技术实现进行微服务设计,划分边界。

技术架构设计

技术架构设计及基于客户偏好的产品选型建议,包含关键技术专题。

数据模型设计

针对关键业务域,对数据模型及数据架构进行设计。

系统集成方案设计

集成地图设计,包含内外部集成场景及分场景的集成方案指导。

DevOps规范设计

对DevOps规范如配置管理,分支策略,效能度量等进行设计。

测试策略设计

设计指导交付过程中的分层测试策略

团队结构及协作模式建议

采取迭代式敏捷交付的思想,提出项目进入交付后的交付团队设置,各角色职责及协作模式建议。

方案交接

针对后续交付团队核心成员进行设计讲解与方案交接

任何未在本SOW中定义的工作或方案均在本项目的范围之外。

2.服务范围

业务系统设计咨询服务内容如下:

  • 现状调研 - 以调研表,访谈及工作坊讨论等方式对业务现状,技术现状,当前团队数字化成熟度等进行评估。以PPT报告的形式产出评估结论。确定业务边界,集成现状,技术现状,目标系统设计的痛点,机会点等。

  • 目标拆解 - 通过访谈或工作坊方式,对齐项目目标,并对目标进行拆解,形成指导整体设计的规范。

  • 业务系统整体设计 - 采用设计思维对系统功能特性(feature)进行设计与验证,产出功能全景图及功能特性清单。

  • 应用架构设计 - 通过服务蓝图工作坊,事件风暴工作坊等方式进行领域模型设计,产出领域模型地图及微服务地图。

  • 技术架构设计 - 结合客户实际情况设计技术架构及部署架构,包含技术产品选型,包括网关,微服务框架,各类中间件,数据库,链路追踪等;以及部署阶段针对不同的容灾需求,可能会是集群、同城主备、同城双活、异地多活等部署架构。

  • 规范设计 - 结合客户整体实施规范,对本项目进行实施规范设计作为实施阶段参考。规范包含需求管理规范,代码规范,微服务治理规范,DevOps规范设计,测试策略,showcase规范等。

  • 交付团队结构设计及工作方式建议。

本服务不包含:

  • 业务系统高保真原型图。

  • 用户故事级别需求(概要设计及详细设计级别文档)。

  • 可运行的产品或代码级别交付。

  • 甲方不应限制服务方式,乙方按照项目需要通过现场或远程方式进行详细调研以及咨询方案设计,并产出最终结果。

  • 乙方不负责提供除阿里云官方文档、云上架构设计、系统方案设计之外的任何技术文档。

  • 乙方不负责甲方业务系统规划、架构设计、迁移、应用过程中的任何实施与维护责任。

  • 乙方不负责非阿里云平台以外(第三方软件、应用系统)问题处理、技术的支持和答疑工作。

  • 咨询与架构方案设计完成之后的应用交付实施、数据迁移实施等工作不在该基础服务包和增补服务包的服务范围之内。

  • 本服务不承诺提供任何范围外交付物,以服务周期为期限,服务时间到期则服务终止。

  • 乙方服务过程中不负责甲方应用的部署、应用代码的改造、数据代码改造、数据迁移等具体的实施工作。

  • 由甲方原因导致的进度不符合预期,乙方不承担延期责任。

3.前提条件

  • 客户应提前至少15个工作日申请该服务,以便于阿里云评估客户业务目标及时间计划可行,确认是否承接该服务申请。

  • 咨询过程中,客户需要提供足够的信息输入及相应角色参与调研及工作坊讨论。

  • 咨询过程中,客户需要参与阶段性方案验证,保证整体方案方向对齐。

  • 客户应及时向乙方提供所有需要的合理的文档、信息、数据、图表以及必要的系统权限、远程访问通道以使乙方可以提供服务。且所有这些资料将受到本协议项下的保密条款的约束。甲方同意向乙方已披露的或将要披露的所有信息是真实、准确并且不会产生误导。

  • 乙方将在正常业务时间,即星期一到星期五的正常业务时间,即北京时间上午 9:00 到下午 6:00(国家法定节假日除外)提供本项目的交付服务。

  • 双方在项目实施期间采用双方同意的通讯方式,由双方的项目经理负责传递本项目所需的书面信息,可选择的通讯方式包括:钉钉,互联网、FAX、电子邮件等。

  • 所有项目交付物为中文(简体),工作语言为中文。所有交付作品采用MicrosoftOffice(包括PPT,WORD,Excel,Visio)格式,并以电子拷贝方式提交。

  • 甲方与乙方应须按双方事先达成一致的工作计划、人员资源计划与系统确定的工作起止日期投入项目工作。如遇到甲方相关业务系统迭代延期上线,相关项目进度将会产生顺延,乙方对此不承担责任。

  • 如需引入第三方,甲乙双方应分别负责同各自第三方签订合同。乙方不对甲方的其他分包商或厂商(除乙方的分包商外)的行为负责、亦不对由其造成的延迟负责;甲方不对乙方的其他分包商或厂商(除甲方的分包商外)的行为负责、亦不对由其造成的延迟负责。

  • 任何一方均不对本合同项下的特殊、附带、或间接损害或后果性经济损害(包括利润或节省金额损失)负责,即便该方已被告知该等损害赔偿的可能性。

4.分工界面

4.1.客户与阿里云

  • 针对该服务期限内,双方商定并确认具体业务目标及范围。

  • 具体分工界面见下图

责任简称:R-Responsible执行人,A-Accountable负责人,C-Consulted征求意见人,I-Informed被告知人,S-Support负责配合“R”完成指标的工作

服务类型

阶段

任务名称

任务明细

客户

阿里云

业务系统设计咨询服务

现状调研

目标拆解

通过工作坊形式与项目核心成员对齐项目目标,将愿景与目标拆解以商业画布或精益价值树形式呈现

A/S/C/I

R/I

业务现状调研

通过访谈调研及服务蓝图工作坊等形式对当前业务模式,业务流程等进行梳理,识别系统设计层面痛点及机会点

A/S/C/I

R/I

技术现状调研

通过访谈调研及服务蓝图工作坊等形式对当前企业级整体数字化产品地图,目标系统技术架构现状,集成地图等进行梳理

A/S/C/I

R/I

方案设计

系统功能特性设计

围绕业务流程进行功能特性设计及验证

A/S/C/I

R/I

应用架构设计

通过组织事件风暴工作坊,识别领域事件,划分领域模型。通过业流程推演工作坊保证模型识别的相对合理性

A/S/C/I

R/I

技术架构设计

微服务架构设计

A/S/C/I

R/I

数据模型设计

针对关键业务域,对数据模型及数据架构进行设计

A/S/C/I

R/I

集成架构设计

识别内外部系统集成点,针对不同场景形成集成方案设计指导。对核心集成场景进行核心API设计

A/S/C/I

R/I

DevOps规范设计

结合当前DevOps现状,识别优化空间,在分支策略,自动化部署,持续集成等层面形成建议意见

A/S/C/I

R/I

测试规范设计

根据现状及实际资源情况设计测试策略,制定测试规范指导开发

A/S/C/I

R/I

方案交接

方案讲解

针对交付团队核心成员进行方案讲解

A/R/I

S/C/I

核心工作方法介绍

针对交付团队核心成员进行工作方法(如领域驱动设计,服务蓝图等)的课程培训。(课程为介绍为主的单次讲解)

A/R/I

S/C/I

4.1.1.客户

  • 客户指定一名具备合适技能和经验的项目经理作为与阿里云沟通的主要联系人,代表客户直接负责项目实施的计划、协调、监督与控制以及升级问题与风险,同时全权代表客户在本项目的各个方面做出决策。

  • 根据项目情况,由甲方项目经理协调各方资源参与调研及阶段性方案验证等关键活动。

  • 配合阿里云进行待改造系统现状调研,提供合理的文档、信息、数据、图表以及必要的系统权限、远程访问通道。

4.1.2.阿里云

  • 指派一名有经验的项目经理执行项目管理,并引入、管理乙方项目组人员,与甲方项目经理沟通。

  • 指派具备行业经验及相关项目经验的若干业务架构师及技术架构师,进行现状调研及方案设计。

  • 配合甲方完成方案交接与讲解。

4.1.3.完工标准

  • 系统设计方案设计完成并经过甲方确认

  • 产出交付物

5.服务SLA

  • 纯咨询服务,服务完工前,根据客户需要远程或现场提供服务。

  • 服务完工后不涉及运维相关事项,因此服务完工则视为服务结束。

6.服务流程

咨询服务流程

售前交流⟶官网下单⟶项目准备⟶现状调研⟶方案设计与验证⟶方案验收⟶项目验收

7.验收标准

7.1.验收分项清单

编号

交付阶段

交付明细

交付物

交付物类型

1

现状调研阶段

系统愿景与目标拆解

《商业画布》或《精益价值树》

文档

2

业务现状调研

《调研评估报告》

《As-Is服务蓝图》

3

技术现状调研

4

方案设计阶段

系统功能设计

《系统功能特性清单》

《系统功能全景图》

5

应用架构设计

《领域模型地图》

6

数据模型设计

《集成方案设计》

《微服务地图》

《核心数据模型》

《技术架构设计》

文档

技术架构设计

7

规范设计

《测试规范》

《微服务接口设计规范》

《微服务开发指南》

《代码规范》

《DevOps规范》

8

方案交接

方案讲解

9

工作方式介绍

7.2.验收标准

  • 乙方项目交付过程中提供业务系统咨询与设计服务,产出整体设计方案,并将关键信息记录在文档内,因此文档类交付成果应着重文档实质内容的验收,确认乙方提交内容符合双方在合同及SOW中约定的需求内容。

  • 若甲方业务流程要求在乙方提交交付成果前需进行各类内部评审,甲方应在约定的验收时点前推动并及时完成其内部所需评审和汇报。

  • 文档内容经过评审会,若需要修改,乙方修改后提请甲方进行验收,由甲方指定的代表进行签收确认。验收在公共云服务系统页面上点击验收确认按钮。

  • 系统设计方案符合合同中约定的需求描述。

7.3.验收计划

根据《7.1验收分项清单》所列示各阶段的交付内容与交付物,本项目将按照以下验收计划进行项目验收,甲方同意根据此验收计划对乙方的交付物进行验收。

金融行业业务系统咨询与设计服务验收计划

编号

验收里程碑

验收内容

验收完成标志

1

现状调研完成

《商业画布》或《精益价值树》《As-Is服务蓝图》《调研评估报告》

乙方完成交付物的提交且交付物满足合同中双方约定的需求范围和内容

2

业务系统功能设计完成

《功能全景图》

《功能特性清单》

乙方完成交付物的提交且交付物满足合同中双方约定的需求范围和内容

3

整体架构设计完成

《领域模型地图》

《微服务地图》

《系统架构设计》

《集成方案设计》

《微服务接口设计规范》

《微服务开发指南》

《代码规范》

《DevOps规范》

《测试规范》

乙方完成交付物的提交且交付物满足合同中双方约定的需求范围和内容

7.4.验收双方职责

  • 在乙方提交交付成果后,甲方将在5个工作日内验证该交付成果是否符合需求描述。如符合需求描述,甲方指定的代表应根据交付物类型按照《7.2 验收标准》约定的方式通知乙方通过验收,标志交付成果验收完成。如果超过5个工作日没有得到甲方的回复则该交付物视同甲方已审阅并通过验收。

  • 如在上述5个工作日内,甲方指定的代表书面通知乙方指出不符点(每一个不符合需求描述的方面称之为“不符点”),乙方应在10个工作日内针对不符点提出反馈,说明不符点的相应处理方式与修改的时间,与甲方就不符点的处理方式与时间达成协议。若不符点在不影响项目原定进度的情况下能够修改完成,乙方应按照约定再次提交修改后的交付成果,甲方应在5个工作日内验证该交付成果是否符合需求描述,并对此书面签字确认乙方通过验收。若甲方再次书面提出该交付成果依然存在不符点,则双方将在乙方收到该通知后3个工作日内进行讨论,双方针对如何处理不符点达成协议。

  • 若在乙方提交甲方交付成果后的5个工作日内,乙方未收到客户关于不符点的书面通知,则该交付物视同甲方已审阅并通过验收。

  • 甲方承诺将对乙方提交的任何工作成果以及待验收的交付物进行谨慎的评审,并对随后的生产实施负责。若该交付成果已经被甲方实际使用或用于与甲方业务有关的活动,该交付成果则被视为通过验收。

  • 交付成果验收通过或视为验收通过后,乙方根据本工作说明书提供的服务应视为已被验收和接受,同时乙方有关本工作说明书的义务应视为已履行。

  • 甲方原因导致未按照计划完成工作造成后续工作无法进行的,项目里程碑时间作相应顺延。

8.完成标志

实施结束并完成客户验收工作。

  • 本页导读 (0)