私藏干货分享：关于企业架构中如何进行平台化

备注：这一篇是来自在自己写的书某些章节删减，在这里并不对文章中所涉及到内容深入展开。  

一、企业架构

企业信息架构这个词已经存在很多年， 从 1987 年的 Zachman Framework 开始到现在大概有 30 多年了。

企业架构（Enterprise Architecture），简称 EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案，更确切的说，是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。

 

企业架构从概念上来讲分为四个部分：

业务架构 、应用架构、信息架构、数据架构、IT 架构：

• 业务架构
  ，企业的业务层面建模、也就是从领域模型的建模，是一切业务产品应用系统起点。主要包含的内容产品流程图、组织结构图、数据流程图等层面的非常全面的分析与认知，是来进行业务模型的设计与实现的。

• 应用架构
  ，企业的应用层面的建模，应用程序架构图、服务导向图、行为类图以及可执行的业务流程都可以在多个角度来支持企业应用的完整建模，应用架构主要是我们对整个系统的技术逻辑架构设计，比如应用的模块组织形式:基于组件的、基于服务的、基于中间件的等等，普遍的 WebApp、MobileApp 应用技术架构，后端开发语言是用 Python 还是 Java,应用容器是用 SpringBoot 还是 Django，前端使用 Ng 还是 Vue,移动 App 是做在微信小程序，还是 iOS 和 Android 本地程序,都属于应用架构模型。

 

• 信息架构
  ，企业数据层面的建模，用户可以利用概念数据模型、逻辑数据模型以及物理数据模型、类图、XML 模型来完成信息层的设计和实现。现代企业管理讲一个三流合一，业务流、财务流、信息流，三者在管理层面最终合一为信息流表现形式。信息架构是业务架构的体现，每一个业务关系、业务过程、业务交易，关于业务的一切都要由信息模型来体现，现在数据架构中普遍的业务数据流模型也算是一个信息模型。互联网应用中的树状内容组织结构和网状数据链接结构也是一种比较典型的信息架构

 

• IT 设施架构
  ，技术实现形式，硬件、网络操作系统这些基础技术设施服务都属于 IT 设施架构,现在云服务的 IaaS 层属于典型的 IT 基础设施，根据上面三层每一层的需求和决策所决定。

 

二、企业应用架构成熟度模型

架构的本质是抽象性，包括业务抽象和技术抽象两方面，需要设计合理的技术架构以满足业务抽象的实现。在企业各种业务活动中会发现有很多重复的类似问题在不同场景下出现，企业的规划架构者将这些问题进行抽象与建模，找到一个比较好的解决办法在未来能够有效的解决类似的问题。这种成为结构性问题的程序化解决方法。一个好的解决方法需要满足以下的四个方面

• 重用：避免重复建设，降低成本。

• 透明 ：把具体的细节问题隐藏起来，仅呈现需要的部分，暴露接口。

• 延展 ：即使对业务做总结与抽象避免重复性的问题，也会受到业务的需求易变影响。

• 简明 ：能够在满足目的的情况下尽可能简单明了。

 

企业架构从诞生到现在已经存在了 30 多年，在传统企业的落地方法论还有落地的案例还是非常多的， 从企业架构的能力成熟度来讲是可以度量的。企业业务规范化与成熟有一套比较简单企业架构的衡量准则：

 

• 探索阶段:

开始构建并部署服务而不再是传统应用

认为企业架构优化能够提供商业价值

配备精选的人员

让项目受到关注

为试验项目重新定义成功的标准

• 优化阶段

流程、标准被采用，以促进应用开发

流程、标准和工具集被采用，以促进应用开发

很多原有系统仍然保留为以前的技术，但其缺点却已明了

设立架构管理部门、专业团队

• 利用阶段：

业务流程重组的需求很容易满足

业务需求提出得更快，并开始充分利用基于 SOA 的 IT 组织的敏捷性

项目组成和设计首先寻找现有的服务，然后提出新的服务来补充与与需求之间存在的缺口。

建立以业务为主的开发组织

 

• 成熟阶段：

非面向服务的代码几乎已经消失

所有主要的核心业务已经重组成为适当粒度的服务

众多 IT 人员直接转移到业务部门中

业务人员对不断变化的业务需求作出越来越迅速的反应,无需 IT 部门的介入

 

 

 

从企业应用架构能力模型来看，从准备阶段开始抽取组件化，通过组件化组成服务化并能够满足需求，再有一堆服务化组成产品线做输出，看来是被系统平台化的一个过程。组件化是探索与优化阶段、从优化阶段到使用阶段是服务化的阶段，提供完整的流程、规范、标注与工具化的大量使用。在系统化属于成熟阶段，就是被平台产品化。

 

三、面向服务体系的结构

面向服务的体系结构 ”SOA“，《微服务设计》第 1.3 节：

SOA 是一种设计方法，其中包含很多个服务，而服务之间通过配合最终会提供一系列功能。一个微服务通常以独立的形式存在与操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通讯。

 

如果企业在商业模式上不停的快速尝试，每一个涉及到的系统都需要去做补丁，不停的升级，所带来的问题就是产品系统一直采用单个应用实现这种方式，Case by Case 的考虑， 通过一个规划的 IT 应用来满足响应的业务功能。非常显然的这种方式简单明了可以快速实现，纯属堆积。随着业务复杂度提升、业务变革速度加快，需求实现难度与后期维护成本显著加大。 

 

 

针对这样的问题，需要选择一种顾全大局以及可持续良性发展的方式来支撑企业的业务发展需要，随着组织机构和业务流程复杂度的提升，以及业务发展多样化的客观要求导致技术上要有开放的、松耦合、可复用的柔性应用架构。

 

只有通过持续的应用架构优化，实现柔性应用架构，才能解决和克服复杂问题，表现出快速创新、降低成本、优质服务等业务发展特点。从 IT 角度出发，面向服务的企业(Service Oriented Enterprise) 包括很多不同的层面，面向服务仅仅是最上面的一层而已。服务的实施，服务的基础架构，都是服务：

• 面向服务的基础架构：

• 面向服务的集成 ：

• 面向服务的实施：

• 面向服务业务应用：

 

“SOA  是面向服务的体系架构，更确切地说是一种架构的风格”。面向服务 是

一种风格和理念，强调的是资源共享和复用、企业架构动态和柔性的组合。

 

四、银行应用架构的平台服务化

 

银行的业务作为小案例来讲解面向服务的体系化案例，在当前的日常生活以及经济活动中，离不开的就是银行。一个常见的银行业务如下图所示:

 

 

从业务的角度来理解，现在很多工作的人工资是发到银行的个人工资卡， 买房买车的贷款， 基本上也是在银行进行，民众日常接触到的银行业务只是比较小的一块，大家只是使用个人存贷业务、转账业务等，公司还有使用到的对公业务，结算业务等。这些业务如果换成 IT 的角度来看呢，如下图所示：

 

上面这张图是一个银行的企业级架构的一个上帝视角，基本上包含了完整的企业架构。在以前各支行及网点的典型运作方式仍旧是传统的“手工作坊式”作业模式。在集中的后台运营中心，采用类似组织机构的矩阵式模式

• 一方面对应专业化细分建立对统一的业务处理环节负责操作的专业人员队伍。

• 一方面为了与前台能方便对接，仍按照业务处理条线，建立票据处理、支付结算、信贷审批和贸易服务等服务处理中心。
• 
  

前后台通过影像视频等工作流技术与前台对接，网点的大量帐务和单据等事物处理的业务集中到后台，为网点腾出更多的空间和人力资源。

 

后来银行在经过数字化、服务化迭代升级后，把整体的运营模式实现向后台的集中，对网点的业务处理流程进行改造，与后端的 结算中心、服务中心、放款中心、个贷中心和票据中心业务流程相整合，同步进行银行服务模式和运营风险管理模式。是的网点的

小前台

+总行运营中心及城市处理分中心

大后台的模式

，前台通过影像视频流技术实现业务票据和客户档案的电子化，中间由大工作流平台把前后台的业务流程串联起来。

 

例如下图，给出的一个银行经过数字化改造后的一个模式：

 

 

 

• 前端交付渠道：是银行与客户接触及提供服务的渠道，也包含给内部员工提供业务前端操作服务的渠道，包含了：
• ATM/POS/自助服务终端、电话银行、手机银行、银企直联和网上银行等客户服务渠道；
• 分行高柜、分行销售与服务及运营操作门户等内部业务人员使用的前端业务操作渠道；
• 在后台为这些业务渠道提供统一技术支撑的渠道控制及整合平台和 SSO 统一认证身份管理服务；

• 前后台的整合平台，包括服务整合、流程整合：
• 服务整合平台一方面担负企业服务总线的集成功能，提供快速配置生产复杂的组合交易服务，服务间的交互及交易控制功能，避免在各前端系统中分散进行复杂的代码开发工作，降低业务流程及后台服务变更对前端业务系统的影响；另一方面负责管理后端的所有服务，对服务进行统一的安全控管，对服务生命周期提供管理服务（服务的注册发布/订阅、服务版本的控制、服务 SLA 的监控等）；
• 流程整合平台负责提供跨全行范围内业务系统的任务流程管理及通过一个统一的业务流程串联各业务系统实现“流程银行”的业务目标；

• 销售及建议服务平台：包含了个人客户关系管理、公司客户关系管理、财务管理及 ECIF 统一客户视图

• 后台产品及交易处理：包含了核心帐务系统、离岸及海外业务系统、中间业务系统、产品/服务捆绑管理及资金管理服务等银行核心的业务及产品交易处理服务

• 后台集中作业处理：是以后台集中运营机制为目标的服务集合。其中包括了专业化细分建立对统一的业务处理环节进行集中处理的业务服务；也包括对应业务处理条线的票据处理、支付结算、信贷管理、个人贷款和贸易服务等服务

• 后台信用风险控制支撑服务：是对客户的信用风险进行管理，提供信用控制和统一客户额度管理的服务

• 后台数据整合服务：作为后台的交易及业务处理系统与后台管理系统间的一个统一的数据整合平台，起到桥梁和信息及数据整合的服务功能。把原来各后台管理型应用系统及需要批量加载日终业务数据的需求统一起来，对各交易及业务处理系统中的业务数据进行统一的抽取、加载及转换清洗等整合处理。然后给各需要批量加载业务数据的系统提供服务。

• 银行决策管理服务：为行内高层领导对业务的管理决策提供支持和信息的服务。主要包含财务管理/绩效管理、风险内控管理等服务。而数据仓库是建立这些服务的基础和重要的支撑。

• 银行内部管理服务：为银行的内部日常事务的运行及管理所提供支持的服务。包括支撑内部办公的 OA 办公自动化系统；企业内部人事管理服务；行政管理及财务管理服务。

 

以上的那些方面总结一下就是 渠道共享、流程再造、服务整合、信息整合四个角度做的服务化平台化得改造 。把上图的从四个角度来做一个领域映射，就是下面图所显示：

 

企业级架构包括从对外的系统开始，一直包括到我们内部的后台管理系统。它是一个经过综合考量的全局化的架构。应用与应用间的衔接，数据的存放，系统的整合，如何将现有系统有效地利用起来，在尽量减少成本的情况下加大产出，从而更好得支撑日益增长的业务。这个平台整合的每个部分分别都是做什么的，可以展开来看一下。

 

 

从 服务化 角度来看平台的整合，分为数据整合、服务整合、渠道整合、流程整合，这些角度的整合其实让企业应具有迅速提高或者降低生产水平，或者迅速地将生产能力从一种产品（服务）转移到另一种产品（服务）的能力。

 

• 数据服务整合，对外的数据服务包括：数据报送服务，数据交换服务，数据视图服务，数据接口服务，以提供不同功能和不同粒度的服务。所以数据整合包含：
• 数据接入（数据迁移接入，数据交换接入，手工数据接入）
• 数据预整理，按照统一数据标准，形成基础层数据（ODS 数据预处理，数据接入标准检查，日常数据处理，历史数据处理）
• 数据集市信息导入，按各数据集市要求，确定数据粒度，通过聚合、分类、组合、运算等方法，将结果导入数据集市
• 提供数据访问服务，对 2 预整理结果和 3 数据集市信息，对外提供数据访问服务
• 搭建统一的数据展现平台，组合数据访问服务，快速提供数据服务。
• 降低数据安全风险，通过统一的数据访问权限控制以避免保密信息外泄。
• 提供统一的数据存储方案。

 

• 服务整合，平台一方面担负企业服务总线的集成功能，提供快速配置生产复杂的组合交易服务，服务间的交互及交易控制功能，避免在各前端系统中分散进行复杂的代码开发工作，降低业务流程及后台服务变更对前端业务系统的影响；另一方面负责管理后端的所有服务，对服务进行统一的安全控管。主要功能包括：
• 建立应用服务整合标准
• 结合流程服务总线，通过渠道服务的接入和组合，交易服务的组合和交互，数据服务的接入和组合形成综合服务模式。

 

• 渠道整合平台的系统架构通过构造一套基于应用服务器的核心交易平台，来实现对各种渠道的整合。同时，为基于这样一套核心交易平台的应用系统开发提供完整的开发工具，来配合应用系统开发。  渠道整合平台的主要功能有：
• 提供统一的渠道服务，实现对渠道服务的统一管理，包括后台金融服务的统一发布，渠道服务的统一调度，组合服务的开发和发布。
• 渠道互动，渠道整合通过共享服务，服务组合，应用交互等方式，实现服务交互，同步授权，客户通知和提醒的渠道协作功能，发挥渠道优势提供全面客户服务。
• 统一渠道管理，可有效实现相同技术特性的多个渠道系统的归并和集合，渠道系统软件的统一版本控制，对各渠道的开启、关闭、监控。

 

• 流程整合平台的目标是将服务开通系统内外的资源灵活地组织成业务流程，而无需关心底层的 IT 实现。主要完成：
• 将业务功能以服务组件的方式体现出来。
• 对服务组件提供的服务和系统资源进行编排和配置。
• 根据业务的需要对流程的运行进行动态的控制和协调。
• 提供流程自动化与人工岗位的介入进行灵活的整合。
• 在实现流程整合的基础上，还提供了对流程的管理功能，主要体现在流程管理与策略管理
• 流程管理方便管理人员能够根据管理的需要对流程进行控制与调度。
• 策略管理满足开通服务根据事先的策略定义来动态的管理流程的业务行为

 

在做不同的业务数据时，也是经常听到架构这个词。比如做接到一个数据建设项目，按照数据的流向 ETL 规程、数据仓库层次图、到业务的应用完全画出来，这个算是架构。

 

后来有接触日志埋点、管理与指标统计的内容，需要对 Android、Ios 的埋点框架，数据采集传输存储处理的过程很了解、对于日志统计之上的应用都会做产品化设计落地，感觉这个也是架构。

随着面对的业务越来越复杂，需要做的数据产品也是越来越多，日志采集这条线、面向 TO C 业务的、面向 TO B 业务的高层应用、部门应用、面向数据仓库、数据处理过程等工具的应用一堆堆的数据产品，

要理清各种关系。尤其是在面向用户地方的架构在随着企业的慢慢壮大会变的越来越重要，尤其是在业务中会有各种的方法论。

 

与架构有关的一个职业就是架构师，可能架构师不是一个人而是一个组织，但是这个角色必须在掌握整体的同时需要去规划与探索局部问题、性能、瓶颈。一般的架构师这个角色可以分为业务架构师、应用架构师、系统架构师。

留个问题：企业架构的本身数字化该如何？