3.4 组合三元素3——模型
本节重点介绍组合三元素之三的“模型”，模型主要分为两大类型，即：分析模型、架构模型。“模型”是管理信息系统相关人之间传递信息的标准“语言”。
3.4.1 分析模型
分析模型，是建立分析要素与推测结果之间的关联关系，多用于表达“非优化类对象”的分析结果。
本书推荐的分析模型有两类，第一类是在业内具有较高的认知度和使用频率，第二类是基于作者的实践经验设计而成，本书推荐5种分析模型，见图3-32。
1．对模型的描述
对分析模型的描述采用了4个指标：图例、目的、适用、特征，各自的含义如下。
（1）图例：是该模型的标准表现形式。
（2）目的：该模型被选择的目的。
（3）适用：该模型适用的场景。
（4）特征：该模型具有的普遍特征，特别关注的3个特征如下。
● 是否有起点-终点；
● 模型是否具有结构化特征；
● 结果是否呈现收敛性。
2．模型选择的思路
本书推荐这5种分析模型是基于以下几点考量。
1）关联图①
图3-32 分析模型
*1．鱼骨图：由日本的石川馨先生所发明，故又名石川图，也可称之为因果图。
*2．思维导图：由英国的东尼博赞先生（Tony Buzan）所提倡。
*3．排比图：④和⑤由作者整理、设计。
分析对象所包含的要素未必都具有可以结构化的特征，现实中有很多业务场景是非常复杂、耦合度高、难以拆分的，因此，模型①的引入主要是为了解决这类问题。关联图看似简单，实际是为理解和表现最复杂对象场景而引入的。
2）鱼骨图②与思维导图③
它们不但具有较强的方向性，而且还可以自由、发散地收集相关的要素，并在使用中可以边拓展边收集，在收集要素的过程中就完成了对要素的梳理。
3）排比图④⑤
具有一定的结构化形式的模型，这样的模型易于给出分析成果的规律性、收敛方向等，在调研、分析的现场就有很好的实用性，可以比较容易地建立起分析结果与业务架构（流程图）之间的对应关系，加快分析与设计的速度。它是“分析模型”与“架构模型”之间的桥梁。分析类模型的使用方法说明参见第4章。
3.4.2 架构模型
架构模型，是表达符合业务逻辑关系的要素结构图，多用于表达“优化类对象”的设计结果。
1．对模型的描述
根据作者的实践经验以及使用频率，本书推荐下述5种架构模型，见图3-33。对模型的描述采用了5个指标：图例、目的、适用、维度、状态。
（1）图例：是该模型的标准表现方式。
（2）目的：该模型被选择的目的。
（3）适用：该模型适用于什么场景。
（4）维度：模型表达的维度数，有三种：一维、二维、三维。
（5）状态：模型表达的是业务的什么状态，有两种：静态、动态。其中，
● 静态：流程图以外的都是静态表达方式（图中①～④）。
● 动态：流程图（图中⑤）。
2．模型选择的思路
本书推荐的架构模型主要来源于在业内具有较高认知度和使用频率的模型，基于作者的实践经验设计而成的模型（分层图）为辅。本书向读者共推荐5种业务架构模型，见图3-33。推荐这5种架构模型是基于这样的考量。
● 这套模型必须能支持业务架构的全过程，可以满足从粗的规划到细的流程设计。
● 这套模型间具有某种程度的关联性，可以让设计完成的架构图可以相互衔接。
● 这套模型具有较高的辨识度，让没受过培训的读者也能理解（但不一定会画）。
1）拓扑图
为了开拓读者的思路，这里引入一款具有可以响应扩展、灵活部署的架构模型，主要用来做最粗的规划设计，它不但可以用于一般的业务架构，也可以为未来参与软件设计做一些实用知识的铺垫。
2）分层图和框架图
用于复杂对象的第1级、第2级划分，起到了从粗粒度的规划到细粒度的设计的过渡作用，属于架构图中做概要层次描述的表达方法。
图3-33 架构模型
3）分解图和流程图
这两个模型是采用结构化架构方法的核心，它们的作用是承接中粒度架构结果并向下做进一步的细分，属于架构图中做详细层次描述的表达方法。
架构类模型的使用方法说明参见第4章。
3.4.3 两种模型的区别
为什么要导入分析类和架构类两种模型，它们的区别是什么呢？
首先，分析模型多用于非优化类对象在分析阶段的研究，构成这类对象的要素不一定有明确的、精准的逻辑关系，由于这个阶段要素之间的因果关系不清晰，此时如果使用精准的逻辑图形反而不易表达，也不易找出问题所在。
分析类模型可以解决梳理、归集要素并给出分析结果的工作，但是分析模型不能直接用来做分析结果的解决方案，因为无法精准地表达逻辑关系，所以必须将分析得到的要素（业务、管理）融入到“业务架构（如业务流程）”中，才能够发挥出作用。
分析模型与架构模型的目的不同，它们之间的区别，从图3-34中的两幅图的对比可以看出，将实际的业务内容（要素）加入到模型中，观察图形的变化，
图3-34 分析模型与架构模型的区别
1．鱼骨图——成本超标问题（分析模型）
图3-34（a）给出的分析课题是研究成本超标问题，可以看出鱼骨图上呈现的分析要素都是意见、想法、现象、建议等内容，它们是在调研中客户使用的语言，而不是通常设计中使用的业务设计用语，所以，“鱼骨图”+“非业务设计用语（客户用语）”是不能用来表达解决方案中的业务处理、管理控制等内容的。
2．流程图——业务流程图（架构模型）
再看图3-34（b）的内容，采用的都是业务设计用语，图形是严谨的、结构化的，清晰地给出了目标、方向、流程、步骤等信息，也就是说，图3-34（b）模仿的是真实的业务形态，所以也必须使用真实的业务设计用语（要素），流程上所有的节点之间必须用合理的逻辑相关联，这样的架构图才能够用来作业务的解决方案。
注：业务架构图的节点只表达功能
此时，分析模型中归集的问题已经被转换为解决对策融入到实际的业务架构中去了，因此在业务架构图中已经不能直接看到原来的问题要素了。
分析模型可以表现分析成果、需要的功能等，但不一定能够表现出严谨的逻辑关系、可以执行的解决方案，所以分析与架构各自关注的是不同阶段的工作和结果，因此分析模型是不能够代替架构模型作架构图的。
虽然分析工作与架构工作的目的都是用要素来构成一张图，但作图的方法也是有区别的。
● 分析：是用“归集要素”的方法作图，归集后要素的承载结构是分析模型。
● 架构：是用“组合要素”的方法作图，组合后要素的承载结构是架构模型。