基于中台的企业架构设计方法

数字化转型的特征

传统信息系统模式

传统信息系统无法适应数字化转型的需要

 

 粗放式的整合

项目本位管理模式

EA管控体外循环

数模过于后置

数字化转型带来的三个转变

业务角度：从管理流程驱动向业务场景转变

技术角度：从垂直耦合系统向云化、服务化转变

建设模式：瀑布式向敏捷式转变

从流程驱动到场景驱动

 

从垂直耦合系统向云化、服务化转变

基础设施混合云架构

微服务架构

 过度阶段两种架构并行

 从瀑布向敏捷方式转变

 采用双模IT演进，传统功能仍运行在原有的稳态模式下，保持业务延续性，需要面临市场竞争、变化速度块、追求体验和快速响应的功能通过业务拆分，独立部署到云端，逐步形成共享能力。

业务多维建模

 主要是再原有的业务能力主线增加业务场景维度

z-业务身份，根据业务身份进行个性化

业务多维叠加

识别公共服务能力

通过业务能力和业务场景维度的叠加，识别提炼出公共的业务能力

识别扩展点

 共享业务能力的冲突点-识别复杂的业务规则（分支条件和优先级）

共享业务场景的冲突点-识别最小共性流程

 元模型

 元素定义-1

 业务场景展现形式

从这个图来看业务场景式多个业务域的组合，那么业务场景的组织主体应该式什么单元，战略规划团队吗？

业务活动图

 

 工作方法

依据元模型，从业务场景出发，建设期模型组和服务组遵循以下九大业务步骤开展工作，总体推进组统筹工作开展并审核各阶段输出

前七步属于设计阶段，后两步骤式开发

设计阶段交付物：

1) 《业务场景、业务活动、业务对象梳理清单》（业务模型呢？ 这就是业务模型了？）

2）《数据模型设计》

3）《服务清单》《服务设计》

步骤一：定义业务场景（1/2） 

依据公司战略发展纲要，围绕资产生命、客户全方位、能量全过程、核心资源集约化四个大发展方向，梳理公司级核心业务

个人认为：业务场景的划分主要依据企业组织单元横向管理业务能力为标准

步骤一：定义业务场景（2/2）

步骤二：梳理业务活动

方法：参考业务模型说明书，从业务场景出发，拆解出业务多动

步骤三：识别公共业务活动

方法：如果一个业务活动再多个场景中出现，则它式一个公共业务活动

步骤四：梳理业务对象

方法：工具没想公共业务活动的步骤、业务表单、业务规则等识别提炼出业务对象

步骤五：设计数据模型

 

 方法：围绕业务对象，根据业务协同、数据共享、模型重叠原则构建数据模型

步骤六：设计数据服务

 方法：基于数据模型，明确使用的数据对象、操作类型和方式，分别进行服务识别、接口设计和传输数据的消息设计，经过封装、注册和发布供业务调用。

步骤七：设计业务服务

方法：基于业务活动，定义业务服务并开展服务设计，在业务服务中实现业务逻辑，且必须调用数据服务来进行数据读写

原则上，一个业务活动对应一项业务服务

步骤八：服务开发

 步骤九：数据迁移

 方法：以确保数据可用性、完整性、正确性为目标，开展数据迁移工作，包括前期准备、技术开发、环境搭建、实施迁移四个阶段

 问题分析部分

中台的企业架构核心是抽取出来公共服务能力放到中台

公共服务能力的提取：

业务活动与业务场景矩阵，焦点为公共服务

厂商不配合把核心公用的服务提出来放到中台，所以需要公司自己的架构人员介入厂商开发

执行层面需要做的核心点：

1) 总体架构管控的培训

2) 要有组织，架构管理委员会（full，part），工具做自动约束，自动导出文档，自动评审

3）强推管控

元模型是否要划出整体架构和系统架构

        元模型中有些元素同时包括企业层、也有系统层面? (我理解不是这样的，如组织单元：应该是立足于当前主体单位的单元)

ES系统纳管业务范围：

1) 架构资产覆盖：ES系统统建、省公司自建的、直属单位的系统没有维护进去

2）架构资产的使用价值

南网对架构师认证的培训问题

1） 内部认证 

2） TOGAF认证

架构成熟度评估

1 架构资产维护

1) 架构现状

2) 定期发布架构蓝图

3) 技术标准(系统架构)

2架构管控

1) 总部对分公司、直属单位的管控架构保持一致

2) 指导和审查系统架构

3 架构能力的培养

1) 架构平台搭建

2）架构知识库/资产的维护

3）架构人才的梯队、架构的认证

元模型

系统工具

实施约束管理

价值利用