业务架构图设计过程总结

我从6月初开始和领导一起进行知识平台业务架构图相关的设计，这其中经历了很多坎坷，积累了不少经验，特意记录下来，以备分享。

一、明确知识平台的定位

针对具体的应用场景，对接原始数据资源。将原始数据（即输入数据），通过半监督或无监督的形式加工生成语料数据、知识数据，服务于自然语言处理等知识应用。知识管理平台主要积累语料数据、知识数据以及加工过程数据。

二、明确产出物

1. 基于系统需求级别的业务架构图

2. 基于系统需求级别的业务流程图

3. 基于模块需求级别的业务架构图

4. 基于模块需求级别的系统定位说明书

三、基本设计规范

1. 业务架构图分层原则

建议按照“用户层、业务应用层、业务支撑层、信息资源层、基础设施层”五个基本结构进行分层，各层最多设置三个子级。

用户层：不仅仅局限于人，既可以包含具体的用户角色，又可以包含知识平台服务的系统。

业务应用层：业务即需求，它不等同于系统划分，一个系统里可以包含多个业务，一个业务也可以分布在多个系统里。在考虑模块级需求时，我把系统模块名称当成了业务需求，导致业务描述不清楚。

例如“个人中心”可以是系统里一个模块的名称，却无法表达我的需求。实际上我想表达的业务需求是“个人信息管理”，这个词能清楚地表达出我对个人信息的查询、修改等需求。

业务支撑层：为业务应用提供算法等支撑服务，例如自然语言处理等。

信息资源层：为业务应用提供数据支撑，它不等同于数据库的划分。

基础信息资源错误示例：非结构化文本信息资源、结构化文本信息资源、视频信息资源、音频信息资源。

错误原因：分类层级标准不同。

正确示例：

方式1 - 文本数据、图片数据、音频数据、视频数据、文件数据

方式2 - 非结构化信息资源、结构化信息资源、流媒体数据资源

基础设施层：为业务应用、业务支撑、业务资源提供硬件、软件支撑。它基本是固定的，会根据具体业务情况进行调整。

例如，业务中是否使用docker技术，如果使用了，则添加到软件资源中。

例如，网络可根据实际情况划分成互联网+局域网，或者互联网+内网+专网等。

2. 业务架构图命名原则

咬词咬句、顾名思义、避免歧义，看到名字应该能明确业务内容。

例如，知识审计、知识审核这两个词容易产生歧义，最后定为知识审计、标注审核。

3. 画图的基本原则

（1） 简单，不繁琐

（2） 合理利用空间

（3） 合理搭配色彩

（4） 同级字体一致

（5） 整体风格统一

画架构大图的过程中，图块的大小可以直接保持一致，无需两端对齐。

画流程图的过程中，要注意箭头、方框、图标的使用，整个PPT图例保持一致。

注意业务图与流程图之间的衔接。

4. 思考流程

a. 首先确认业务应用层

b. 从业务应用层出发推理业务资源层，确认业务架构图的基本骨架。

c. 由业务应用层出发推理用户层,明确用户的角色、定位与权限。

d. 根据业务应用层、业务资源层、用户层，画出业务流程大图。

e. 由业务应用层出发推理业务支撑层，确认算法支撑内容。

f. 综合以上层级推理基础设施层。

确认完整体的架构之后，进行二次梳理，查漏补缺。当所有模块确认无误后，对业务应用进行模块及需求细分，明确主要功能、辅助功能，明确业务模块定位。

注意：各个层级的上下逻辑要通顺。需要思考：用户会使用哪些业务？业务会产生哪些资源？资源依托的基础设施环境是什么？业务依托的算法支持是什么？一定要能够一一对应。

四、总结

每一个公司对业务，甲对架构图都有一套自己的思路，所以要结合公司现有的特点进行架构图的设计。

之前看的架构图总感觉他们就只是填了一些文字，通过颜色区分开。经过这次业务流程图的整体的梳理与会议过程，我发现业务架构图远远没有想象中的简单，每一个小方块儿后面都蕴含着无数的逻辑思考，瞬间对架构师仰慕。

前期设计过程中，遇到了一些问题，。我们所有的架构图直接通过xmind，或者直接在PPT上调整。xmind使用确认很方便，当信息过多时，它会非常琐碎，不利于逻辑化的展示。PPT上的信息不容易大范围管理。后来我们升级了方式，先使用Excel，将所有的信息一级一级列出来，加上备注或模块定义。Excel能方便添加修改删除模块，大大提高了思考记录速度。确认基本的业务信息后，我们将其转述为PPT的展示形式。

转岗产品经理之后，越来越发现熟练掌握Office工具太重要了，能提升不少效率。