第9章 架构的概要设计
架构的概要设计，是利用架构的手法对系统整体的顶层规划和设计。架构的概要设计是在需求工程分析成果的基础之上对整个系统进行的顶层规划，重点是确定设计规范（理念、主线等），从大的范围和高度对业务进行规划和设计，架构概要设计的成果“业务架构图”是后续各阶段设计的依据、载体。同时，在业务架构的设计过程中明确了业务逻辑，业务逻辑是串联起所有要素的主线，是设计的灵魂。
9.1 基本概念
9.1.1 定义与作用
1．定义
架构的概要设计，是以信息化价值为目标，确定设计规范，对客户需求进行梳理、优化，并用架构模型表达出清晰的业务逻辑，最终确定全部业务的范围、系统／模块的划分、业务的构成、业务的流程。
架构的概要设计是架构层的三个设计步骤（概要、详细和应用）中的第一步。也是设计工程整体的第一步，它承担通常所说的“业务优化设计”中“流程优化”等主要工作。注：“架构”与“设计”的区别“架构”有名词和动词两种含义，本书只取“架构”一词的名词含义，其动词含义用“设计”替代。“设计”是一个大的概念和过程，“架构”只是“设计”含义中的第一个层次，也就是粗粒度的设计。“架构”顾名思义就是搭建产品的“框架”（如同建筑物的“结构”一词的含义），“架构”的行为不能包含全部的设计内容，完成一个产品的设计除去架构层部分外，还有：功能层的设计（如界面、布局、规则等）、数据层的设计（数据结构、表关系、算式等）、应用层的设计（UI、美工等）。
2．作用
架构的概要设计主要作用有两个：确定设计规范、完成业务架构的规划设计。
1）设计规范
设计规范，包含设计的目标、理念、原则、主线、标准等内容，是确定基于客户的目标需求与业务设计师对目标需求的理解，特别是设计理念的不同，使得形成的设计主线就不同，最终围绕着这条主线做出的业务架构也会不同，设计理念和设计主线是系统的灵魂。
2）业务架构
业务架构是承载理念和主线的主要载体，从软件工程的全过程看，这是对需求工程收集到的现状构成图按照架构设计标准进行的第一次设计，也是从需求工程进入到设计工程的转换点，它的作用就是将需求阶段的内容用设计的标准进行梳理、分类、规划，让相关人第一次“看到”有规律性的业务形象，为后面的详细设计奠定基础。
在需求阶段获得的需求是发散的且不成体系的，在业务架构设计时，是将需求阶段收集到的现状构成图、功能需求等用“业务架构”的方法进行“①业务梳理、②业务优化、③业务还原”，通过这个过程让业务设计师从整体上理解和掌握业务的构成、逻辑，它是后续所有的设计（包括业务和技术两个方面）、开发、测试以及上线培训等环节的指导依据。
9.1.2 内容与能力
1．作业内容
1）设计规范的确定
设计规范中对系统构成影响比较大的就是理念和主线，它们的作用分别如下。
（1）设计理念。
针对未来要设计的系统，业务设计师要根据客户的目标需求（目的、价值、期望…）确定对系统的设计理念，这个理念可以指导和判断信息系统应该选用的业务处理的方式、管控的手法，以及系统最终可以为客户带来什么样的使用效果和价值等。
（2）设计主线。
有了设计理念作为追求的目的，寻找支持这个理念的核心价值点，将它们连接成线，并将实现这些价值点的功能沿着主线展开，形成了系统设计的主线。
2）模型与标准的确定
（1）架构模型
理念和主线决定了系统内在的“魂”，架构模型就是系统外在的“形”。理念和主线确定后就是进行业务架构的设计，架构层的概要设计相当于架构的规划设计，这个设计是粗线条的，五个架构模型作为业务架构设计的主要表达方式，即：拓扑图、分层图、框架图、分解图、流程图。
（2）架构标准
业务架构图，是业务设计中最为基础和重要的设计资料之一，它是后续所有设计的指导依据，因此架构设计采用的基本图标、表达方式等都必须是统一的标准，只有统一了设计标准的业务架构图才能作为工程化设计的基础资料。
2．能力要求
架构的概要设计，可以说是软件工程中最为重要的部分，它主要是做信息系统规划的顶层设计（决定理念、主线、标准），以及确定业务的范围、系统的划分等，完成这些内容需要业务设计师具有相对最为全面的能力。
9.1.3 思路与理解
架构、功能和数据，并称为设计工程的三大对象，架构是三大对象之首，而架构的概要设计又是架构三个设计阶段——概要设计、详细设计、应用设计中的第一步，且由于架构在设计工程的每个阶段都处在第一层，所以，架构层还具有对其他两层（功能层、数据层）的设计指导作用。架构设计的指导理念就是基础概念中的“组合原理”。同时架构的概要设计结果对后续的技术设计也起着指导和约束的作用。
1．架构
1）架构的概念“架构”一词有两种词性：名词、动词，在设计工程中各有不同的含义。
（1）名词：表达的是业务要素之间按照某个规律呈现出一种“结构化的形态”。
（2）动词：表达的是将业务要素“组织成某种结构的行为”。
2．架构图
架构图，就是用来描述工程分解三分层中第一层“架构”的图形表达方式。“架构图”描绘的是架构层的设计结果，软件的设计还包括功能层的设计、数据层的设计，它们使用的图形与架构层是不一样的。
软件的业务设计中使用的设计图——业务架构图，“业务架构三视图”，以企业管理为对象。
（1）框架图：表达了内容规划、范围、分区、区域之间的关系。
（2）分解图：表达了某个区域内容的静态分解关系。
（3）流程图：表达了某些活动之间的流程关系。
业务架构设计：用架构模型给企业的业务“画像”，让看不见的“成本管理”“物资采购”“销售管理”等业务对象可以变得能够“看得见”。
3．设计思路的变化
关于业务架构图的表述方式，由于在软件行业中传统上都是以功能实现为主导进行设计的，所以常用的架构表达方式大都是技术视角的，造成这样的原因是可以理解的，因为在企业管理信息化的初期，大部分获取的客户需求都是实体级的，例如：
● 完成一个单体的数据记录，如设计一张收据单、开发一张分析报表等。
● 完成一个窗口型的交易系统，如图书馆出纳、财务报销、超市收款等。在现在构建企业级信息系统时，通常为客户做的第一件事不是收集实体级的需求，而是要先梳理企业各个层级的工作构成、业务流程、存在的问题、难点痛点，以及客户经营管理者提出的目标、希望、价值等的需求，这就大大超出了原有技术视角的设计方法和工具所能应对的范围，此时就需要有一套能够站在客户视角，以业务优化和实现客户价值为核心的分析与设计方法，它先考虑的不是软件如何实现（技术问题），而是如何理解和分析客户的问题。打个比方说，医生为患者看病的顺序是号脉→诊断→开方子，然后才是如何抓药、做手术。前者就是业务设计要做的工作，后者是技术实现要做的工作。
4．业务设计：软件相关人的共同语言
业务架构图虽然是一种绘图的方法，但是在软件工程的过程中它是所有相关人的“共同语言”。
业务设计方法（特别是业务架构图）就解决了这个问题，它的表达载体是符合“技术要求”的逻辑图，但表达的内容是客户的行业“业务”，因此，就实现了让软件的相关人都可以理解，并可以作为沟通、交流、设计和验收的依据。重点是利用架构模型和“架构的思想”进行具体的业务架构设计。
逻辑表达的最佳方式——画图
9.2 设计基础——设计规范
设计规范中的理念承载了“目的”，主线串联了“功能”，功能实现了“价值”。虽然最终的软件设计是针对功能的，但是获取功能是要通过对目的、理念、价值的研究之后才能够最终设计出理想的功能，否则就可能走偏而达不到目的。
9.2.1 设计理念
在着手对系统进行设计之前，首先要参考客户提出的目标需求（目的和希望）及期望收获的价值来确定应该做出什么样的系统才可以满足客户的需求。
1．设计理念的概念
设计理念就是业务设计师要根据客户的希望和目标，融入业务设计师自己的想法然后给出设计指导思路。
2．设计理念的作用
设计产品，不论是汽车、建筑，还是服装等，设计师都需要有一个设计的理念，产品设计、项目研发等，都需要有一条贯穿全局的“设计理念”作为灵魂，这个设计理念指导和保证了设计不走偏。理念设计的精准、到位，则后续设计的脉络、功能、客户价值都会非常清晰，而且也容易设计。如果有设计理念作指导，则很容易为客户设计出一套可以带来更多信息化的附加价值的系统；如果没有设计理念作为指导，则系统可能就像一个没有灵魂的处理功能集合体。
9.2.2 设计主线
确定设计理念后，以实现这个理念为目标，将用于实现目标的功能串联成线，在功能上标注出该功能可以带来的价值，这就是所谓的“主线”。主线包含“功能和对应的价值”，这是作为高级业务设计师所必须具备的设计能力之一。
已经知道了功能需求（来自于需求分析）、目标（来自于理念），为什么还要主线的概念呢？有了功能、目标还不够，因为业务设计师还要思考用什么样的“线”引导这些“功能”到达“目标”，这个引导就是价值。价值可以用来确认功能的作用、该功能是否是达成目标所必需的，功能是否完善等。主线不同，功能模块的组合方式就不同，最后完成的系统就不同。只有将功能模块与价值有机地结合在一起，同心协力指向目标才能完美地完成任务。一个系统内可以有若干条主线，例如，企业治理、成本管理、资金管理等。主线可以是一条完整的业务流程，也可以是若干功能形成的一条“虚拟线”（后者更为常用）。确定理念和主线的概念后，再次理解客户的目标：产业的互联、企业治理的透明化、制造的绿色设计等，是否感觉就没有那么抽象、变得比较容易理解了呢？
主线的概念除了用来支持设计理念的落地外，还有一个重要的作用就是可以帮助业务设计师完善需求。需求调研的结果如果缺失内容、质量不高都会极大地影响到后续的设计，原因有很多，例如，需求调研工程师的能力不足、调研时间不充分、客户的配合程度不够等。如果遇到了要设计的信息系统属于非优化类型时，就算是没有出现前面的问题，也会由于双方都不清楚系统的构成而不能收集到全部的需求细节，此时，业务设计师就需要按照理念提供的目标设计出一条主线，这条主线不但可以将已收集到的功能需求串联起来，而且可以根据理念和主线的指引补全缺失的功能需求。
9.3 设计基础——基础手法
架构的设计知识有两个基本的内容：架构模型和架构手法。的重点是如何通过对一个业务对象进行逐步的拆分、组合，选用合适的架构模型最终表达出业务设计师的想法。
9.3.1 架构设计的基础
1．架构模型的使用——粗粒度的设计
对业务进行粗粒度的架构设计采用架构模型来表达，通过不同粒度的模型对业务对象进行拆分、组合
1 ）整体规划
拓扑图：对项目的全部内容进行整体规划。先将不同业务领域的内容分化成为不同的板块，将没有直接关联的业务分开后，这样易于理解业务的内涵、边界、板块之间的数据交互关系等，这是最上层的规划。
2）局部规划
（1）分层图：对拓扑图中的某个业务板块进行规划、设计。因为每个业务板块都是由业务层（还可再细分为业务、管理等）、数据层、技术层等构成，它们的设计内容、方法等都是不同的，因此第二步用分层图将它们区分开来。
（2）框架图：对分层图中的某个层进行区域划分的规划。通过这个规划可以再进一步对同一层的内容进行划分，分出主营功能、辅营功能以及支持功能等，这个划分的结果决定了信息系统构成的子系统、模块等的基础。
3）构成规划（静态）
分解图：对框架图中某个区域的构成进行规划、设计。通过这个规划可以对每个区域内的业务构成进行详细的规划，通过这个静态的构成给出了该区域内业务要素之间的层级关系，这个分解成果为后续的功能和数据层面的详细设计奠定了基础。
4）运行规划（动态）
流程图：表达对分解图中要素在运行时前后关系的规划、设计。
将分解图中识别出来的要素，按照完成不同目的过程串联在一起就形成了流程图，流程图给出了业务的动态架构关系，这是指导业务运行的最重要的架构。
拓扑图和分层图，在架构设计中更多的是起着“划分、归集”的作用，而框架图、分解图和流程图则不仅有划分和归集，而且还有“构建”的作用，它们的成果也是后续架构的详细设计、应用设计以及数据设计的依据，后3者的设计内容要在系统中有非常具体的落实。例如：
● 框架图：是系统、模块的划分依据，是系统菜单的设计依据。
● 分解图：是基础数据（字典库）的设计依据，如组织结构、材料结构等都用分解图。
● 流程图：从流程图获得的“业务逻辑”是系统运行设计的主要依据。
2．架构手法的使用——细粒度的设计
每个架构模型都是用不同的要素（图标）、逻辑（线、框等）组合出的图形，用以表达不同的含义，这里介绍4种架构设计的手法，即：分层、分区、分线、分点
1）分层
分层，就是将设计对象按照不同的粒度或是不同的分类进行拆分，获得的要素分别置于不同的层上，这是架构设计最为基本的方法，也是最为重要的方法。分层的表达手法在所有的架构模型中都有使用。
2）分区
分区，就是在一个平面上将不同分类的要素归集到不同的区域，同一区域内的要素具有高内聚的关系，不同区域的要素具有低耦合的关系。要注意在同一个平面内的要素，不论是否同在一区，都必须粒度相同，因为这个平面是3D分层其中的一个面，这个面上要素的粒度必须一致，否则就不能在同一个面上了。分区的表达手法可以使用于分层图、框架图、分解图等。
3）分线
以某个目标为终点，将实现这个目标所需要的要素按照发生的前后顺序串联起来，就形成了一条线，这条线上的要素粒度要一致，还要注意要素的分类、属性，例如，不要将动词要素和名词要素连接在一起。流程图是此类架构手法的代表，另外，业务数据线也属于此类型。
4）分点
以某个点为核心（点可以是一个：功能、模块、系统），关联与其有关的其他要素，注意相关联要素的粒度要一致，这个点就是业务功能设计、复杂算式设计等的主要手法。如果点是一个“系统”时，那么还可以按照分层、分区等方法重复上述过程。如果点是一个“功能”时，就不能再划分了（再划分就进入到了功能的内部，进入到功能内部就属于详细设计，不再是业务架构的范畴了）。
3．架构模型与架构手法的区别
架构的“手法”与架构的“模型”是两个不同的概念。
（1）架构模型：利用架构手法形成的具有普遍意义的业务架构图形（是架构的结果）。
（2）架构手法：分层、分区就是具体的架构设计的方法（是架构的过程）。利用架构的手法，可以创造出更多的、本书中没有推荐的架构模型。
9.3.2 设计标准
1．绘图标准
1）模型
包括定义、用途、画法以及标准，在这个范围内这些标准一定要遵守，否则由于标准不统一，每个设计师各自采用自己习惯的表达方式，那么每次的沟通都要从图形符号的识别开始，这就无法高效率地进行设计资料的传递了，也就难以实现工程化设计的效果了。如果在设计的软件中，模型或是图标不够或不匹配，可以增加建立一个适用的体系，这个体系要包括定义、用途、画法以及相应的标准。
2）图标
同样，如果不够用或不匹配，则可以参照模型的方法进行设计。
3）粒度
图形中要素的粒度是否合适，是正确设计一张图的重要基础，关于粒度的说明参见。
2．绘图用语
1）节点
所有在线上的块或是线的交叉点等，都可以称之为节点。“节点”一词可以用来表达一个活动、一个步骤，当然也可以表达某个实际业务（如销售）等，用诸如节点、活动、步骤等用语而不用具体的业务名称描述时，表明此时关心的是这个“位置”，而不是该位置上的具体业务内容。
例如，在描述主线时，可以说“主线上的所有节点都是为了实现目标而存在的”，此时可以不必纠结于这些节点“包含什么内容？具体的作用是什么？”这样的问题。
2）结构图
为了使基本模型具有普遍性，在不针对某个特定专业业务进行讨论时，需要使用不带模型分类名称来描述模型或是图形符号，例如，在泛指一个图形时，只要这个图形包含要素块、关联线，具有一定规律性、结构性，则不论它表达的是分析图、架构图，这个图形都可以称为“结构图”。
3）系统规划
有很多的“单位”用语，不同的场合有不同的定义，在进行系统的整体规划时就要统一，否则设计的“单位”不统一，很多定义也就会出现歧义了。
（1）需求体系
需求调研、分析阶段收集到的功能需求按照业务知识的划分方法进行分类。业务领域＞业务过程＞功能需求其中：
①业务领域为独立的业务，如财务管理、采购管理、物流管理等。
②业务过程为业务领域的下一级，如报销过程、核算过程、支付过程等。
③功能需求为业务过程的下一级，如经费记录、成本核算、支付确认等。
（2）设计体系。设计体系是设计知识体系的划分方法，是未来的系统体系。其中：
①业务系统／子系统可以完成独立的业务，如财务系统、采购系统、物流系统。
②业务模块为系统的下一级，如报销模块、核算模块、支付模块等。
③业务功能为模块的下一级，如经费记录、成本核算、支付确认等。（业务功能还可以分为4个种类：活动、字典、看板和表单。）原则是一样的，但是在实际划分时还需要根据客户的使用习惯、系统菜单的设置方法等共同决定。
3．设计用图与宣传用图的区分
业务架构使用的5种架构模型是正式的设计用图，采用了工业化的制图方式，包括每个点、线和背景框，都有明确的含义，这个“业务设计图”与一般的“宣传类用图”是不同的。
（1）设计用图：用的是逻辑图，要能够经受严格的推敲、分析，系统相关人在看图时必须要能够得出同一个结论，不能有歧义，并且必须要有数据上的关系。
（2）宣传用图：用的是概念图或示意图，用来说明主题的含义，并不要求表达精准的逻辑，不要使用没有严谨逻辑的概念类图等来替代逻辑图作为正式的设计用图。
9.4 架构的整体规划——拓扑图
9.4.1 使用场景
拓扑图的作用是基于需求工程获得的成果，包括：业务现状构成图、功能需求一览等，对未来系统的业务进行最大粒度的整体规划。
在进行大型的复杂系统设计时，通常一个项目可能包含若干不同目的的系统（或是需要将新建系统与既存系统进行整合）此时就要对这个项目进行拆分，按照不同目的、不同的业务内容，划分为几个独立的系统。这些系统相互独立，又在数据、协同上有合作。
拓扑图适合于做最粗粒度的表达。首先用拓扑图进行第一次粗粒度的拆分，然后再使用其他的架构方法，按照不同的视角，进行较小粒度的二次拆分-架构、三次拆分-架构等。另外，拓扑图表达是“逻辑上的划分”，不管系统在物理上是否进行了同样的划分。
9.4.2 使用案例
拓扑图用到了架构的基础手法：分区。
9.5 架构的分层规划——分层图
9.5.1 使用场景
分层图的作用是对某个子系统内部的要素，按照不同的分类和目的进行拆分，以利于集中精力研究其中某个分类的内容
拓扑图已经将处理不同业务的板块划分开来，下面就先要将同一系统内不同作用的内容进行划分，也就是分层，这个“层”是逻辑层面上的层，通过这个分层可以更好地理解和处理不同层内的内容。通过层的划分可以将不同的设计要素分开，使得业务设计师可以集中精力有序地设计每一层内的处理、层与层之间的交互，避免了将要素混杂在一起造成不同要素之间的耦合。
进行逻辑分层的意义在于，在研究业务层面的内容时可以暂不考虑数据层面的内容或是维护层面的内容，但是业务设计师也不会忘掉其他层的存在，对研究对象的分层带来了设计上的便利。
● 从粗粒度、大的层面上对研究对象进行定义、理解。
● 设计时可以只关注整个结构中的其中某一层，进行深入研究。
● 可以降低层与层之间的依赖（理解解耦设计的重要方法）。
● 有利于设计和开发的标准化（不同层有不同的目的和方法）。
● 利于各层逻辑的复用（不同软件项目间的复用）。
● 结构更加明确（要素、维度减少，结构更加收敛）。
9.5.2 使用案例
分层图用到的架构的基础手法：分层、分区。
分层图的核心在于“分层”，实际上不论是三维还是二维的图形中都存在着分层。
1）三维分层图的表达可以从六个面来布置各个层之间的位置，更加形象、直观地表达出各层内容之间的关联关系，缺点是绘图比较复杂。如果表达的内容具有普遍意义，并且有复用价值，可以使用，且具有普遍意义。
2）二维分层图的表达也可以采用二维的表达方式，表达简洁、直观，同时绘图也比较容易。缺点是二维图形只能表达四个面的位置关系，对应内容复杂的对象表现力比较弱，直观效果比三维要差一些。
分层图，粗粒度的分类手法
分层图，起到了一个粗粒度的梳理、划分、确定关系的作用，它将不同的内容分别置于不同的层上，但同时又给出了不同层之间的关系。
9.6 架构的区域规划——框架图
9.6.1 使用场景
框架图，是“业务三视图”之一，是所有系统设计时都必须要绘制的基本图形，当项目是一个小型的或是不复杂的系统时，可以省略拓扑图和分层图，但是不论项目的内容、规模和复杂度，框架图都是不能省略的，因为框架图的内容是对系统的整体描述。
当对某个特定层的内容进行设计时重点就是对同层内的要素根据它们的目的进行划分，划分的方法是“分区”，从分区的结果上可以获得如下信息。
● 这个层覆盖了哪些业务内容、层的边界在哪里。
● 层内有哪些业务领域、各领域的边界在哪里。
● 各个领域的内容，领域之间的相互作用关系等。框架图的结果不但是对业务的分区，还是后续划分子系统、功能模块的依据，甚至是系统菜单的设计依据
（1）系统的划分：核心功能系统、辅助功能系统、应用功能系统。
（2）模块的划分：在“核心功能系统”中划分出不同的模块，如营销、招投标、合同等。
（3）功能的划分：这个企业信息系统的规模比较大，因此在这个框架图中无法直接显示出功能粒度的内容，在一级框架图中的下一层中会有二级框架图等功能，此时就需要在另外的图中表示了，也就是说根据架构对象的规模，需要绘制的框架图可能不止一张。
子系统、模块等都是相对的概念，具体称为子系统还是模块要看系统的规模、业务设计师的设计意图等因素。
9.6.2 使用案例
框架图用到的架构基础手法：分区、分层。
框架图的画法看似最简单，但却是架构图中相对难度最大的图形。框架图多用来进行架构的顶层设计、初始规划，因为越是靠近顶层的设计，图形中的要素就越少，图形的构成就越是要求精简，因此要求业务设计师的抽提能力也就越强，所以判断一张框架图设计的水平高低，并不是图中的要素越“满”越好，而是要层次清晰、粒度合适、逻辑舒畅。
框架图多用于顶层的规划，越是顶层的内容，越是粗粒度的内容，越不易画，理由是顶层的架构需要思考的内容多，要给出大的布局，要有意识地忽略细节，所以落在图面上的内容少，但是可以从大的布局中感受到细节的存在。
9.7 架构的结构规划——分解图
9.7.1 使用场景
分解图，是“业务三视图”之一。分解图用于标示要素的业务结构关系，可以用分解图将要素的关系逐一进行分解展示，反之，也可以用来将具有关联关系的要素进行汇总，展示出它们之间的结构关系。分解图是架构图中使用最为广泛的模型之一，同框架图一样也是所有设计中不可省略的图形。
1．分解的业务要素
用分解图可以表达所有具有上下级、从属等关系的业务要素。
2．分解的系统要素
用分解图可以表达构成系统的要素（节点）的关系。
9.7.2 使用案例
分解图用到的架构基础手法：分层、分区。
分解图，是最为典型的结构表达方式之一
9.8 架构的流程规划——流程图
9.8.1 使用场景
只要研究对象中有连贯性的活动，就会存在流程图。流程图的设计主要分为两个类型：业务流程和审批流程。由于流程图是架构图中最小粒度的设计，且涉及具体的数据和规则（流程分歧）。
业务流程图，是架构图中与用户实际工作关系最为密切的图形，用这个图形可以模拟、优化用户在信息化环境下的工作过程，其他类型的模型是系统设计、开发的重要依据，但是用户在实际工作中不一定能够直观地感受到它们的存在。利用业务流程的设计主要有以下目的（不限于此）。
1．目的一：建立业务流程的标准
每一条业务流程都是为完成某一个特定目标而建立的，设计一条业务流程就是为企业建立实现这个业务目标的标准。确定了流程的目标，然后根据这个目标将相关的业务活动按照一定的业务逻辑进行关联，流程上全部的业务活动都要围绕着这个目标进行设计。
2．目的二：既存业务流程的优化
根据新的管理理念和方法、新的工艺工法等对既存的业务流程进行完善和升级的过程称为“流程优化”，优化后的流程会提升工作的质量、效率、效益。业务流程的优化设计有两个参考对象：一是需求调研阶段获得的企业流程现状构成图；二是企业所属行业内的最佳样板流程。
3．目的三：业务功能的完善
在需求阶段获得的功能需求一览其内容是处于松散状态的，表中的功能之间的关系尚不明确，这些功能需求是否是真实的需求呢？如何来精确地回答这个问题呢？答案是用业务流程来判断，因为业务流程可以表达出清晰的功能之间的业务逻辑、数据逻辑关系，通过这些逻辑关系的推演就可以解决前述的不确定功能，通过业务流程可以帮助确定功能的概要设计的业务功能一览。这也是为什么要在业务功能设计前要先完成业务架构设计的原因之一，没有业务架构，特别是业务流程，难以从业务逻辑的维度来正确地判断功能需求的真伪。
注：目的与目标的区别
“目的”是指行程的最终点，可以将行程分为几个阶段，每个阶段就是一个“目标”，用几个目标的接力就可以完成最终的目的。例如，从北京到广州，广州是最终目的，在全过程中设置了郑州、武汉、长沙三个目标，三个目标依次达成后，就可以达到最终目的了。
9.8.2 使用案例
流程图用到的架构基础手法：分线。
9.8.3 流程划分
在掌握了流程的使用场景和使用方法后，对于流程的规划和设计还需要补充两点，即：流程的分解和长度的确定。这两点主要是由于在系统中流程是非常容易发生变化的架构部分，因此在流程设计时就要特别注意流程在系统中的应变能力。
在掌握了流程的使用场景和使用方法后，对于流程的规划和设计还需要补充两点，即：流程的分解和长度的确定。这两点主要是由于在系统中流程是非常容易发生变化的架构部分，因此在流程设计时就要特别注意流程在系统中的应变能力。
1．流程的分级
流程的设计会根据节点的粒度不同，而出现多级流程的表达。例如，在顶层的设计中，可以用“系统”级粒度的要素作为流程的节点，这样绘制的流程可以帮助业务设计师从高层次上理解业务的运行，但是按照流程的定义，流程的节点只有是“活动”级粒度的要素才能执行，不是活动级的节点是不能执行的，因此就需要对流程进行分级设计
（1）一级流程：节点是系统，是从整体上理解系统之间的作用关系，其中含有二级流程的节点执行完成后，一级流程才能向前推进。
（2）二级流程：节点的粒度小于一级流程的节点，是对一个系统内模块之间关系的表达，其中含有三级流程的节点执行完成后，二级流程才能向前推进。
（3）三级流程：节点是活动，是流程构成的最小粒度，也是流程可执行的最大粒度，“活动”级的节点是由业务功能构成的，因为业务功能中含有数据和规则，所以以活动为节点的业务流程才能够被执行。
2．流程的长度
对在信息系统中运行的业务流程设计，不同于一般管理咨询师所绘制的企业流程。一般管理咨询师在绘制业务流程时，经常会将企业的某个领域内的活动全部画在一条流程上（当然也不区分节点是否是动词），这样的流程非常长、节点非常多，同时流程分歧节点也多，有时会多达5级甚至更多，流程非常复杂。管理咨询师这样绘制业务流程是可以的，因为他只是将企业现状总结梳理出来或是表达未来的企业活动过程，他绘制的流程图不是信息系统的设计图（或只是作为参考图）。但是作为信息系统的业务设计师就应该避免做这样长且复杂的流程，这种流程的设计方式带来的弊端很大，因为这样的流程在系统中运行后，如果在某个节点上发生了需求的变化就很难维护，常常会因为改动一点而影响其他多处，造成“牵一发而动全身”的现象。
设计适合于在信息系统中运行的业务流程时，一定要将业务对象拆分得比较小，每个处理模块或是每条流程都比较简单、短小，然后由小的模块和流程通过“组合”的方式来处理较大的复杂业务对象。在设计流程时，除去前述讲的要分级以外，还要注意流程的长度，碰到需要比较多的活动联合处理才能完成的业务对象时，可以利用一些中间的处理环节将流程变短。
9.9 综合应用案例
9.9.1 各类图形的变化
5种架构的基本模型之间，从表达的业务粒度上、逻辑关系上有以下的关联关系，可以利用这些关系对业务进行分层架构设计。
拓扑图：相对独立的业务板块的集合体。
分层图：将拓扑图中的“A”板块展开，形成一个A板块的分层图。
框架图：将分层图中的“业务层”展开，形成一个框架图。
分解图：将框架图中的“业务2”展开，形成一个分解图。
流程图：将分解图中的“活动1～活动x”组成一条流程图。
在架构的设计手法中谈到了分层和分区的方法，不同的模型中这两个手法基本上都存在，因此，不论是利用分析模型，还是利用架构模型进行绘图时，都要非常注重对图中不同的内容采用分层和分区的方法表达关系。
小结
1．架构对业务梳理的价值通过对原始需求的一系列梳理，最终将“无形”的企业业务整理成“形”。对企业业务的梳理，用图形还是用表格会带来不同的效果。
（1）需求调研：收集客户原始需求，其目的、作用、逻辑关系等不清晰、不准确。
（2）需求分析：按照业务领域归集成表，但是要素间的逻辑关系没有形象化的表达。
（3）业务架构：按照业务逻辑，将需求要素进行架构设计，使得原来不清晰、不准确的关系用架构图全部清晰、准确地表达出来，相当于给企业的业务进行扫描、成像，让企业的业务可以直观地“看到”，从这3个表达方式可以看出架构图给出的信息是无法用语言和表格来表达的，图形表达最重要的特点就是让逻辑“外露”。
2．架构对设计与开发的价值
业务架构图对技术设计和开发有着直接的作用和价值，例如业务流程为设计和开发提供了两大价值（不限于此）。
1）价值1：业务流程提供了业务逻辑
业务功能的详细设计（4件套的内容）是基于业务逻辑才获得了业务功能的上下游的数据来源、数据关系的，可以说没有业务流程就没有业务逻辑，没有业务逻辑就无法进行数据关系、流向的设计。业务流程是通过业务功能的设计（业务4件套）间接地提供了价值。
2）价值2：业务流程提供了进行“事找人”机制设计的基础
让系统中的业务流程可以实现自动地进行“事找人”，这个设计依据就是业务流程，但是“价值2”并没有被广泛使用，这对业务架构设计成果来说是一个重大的损失。
3．模型内容与使用顺序
架构的概要设计，给出了业务架构的5种基本模型的使用方法，以及它们在实际应用中的使用顺序。
（1）拓扑图：对研究对象的内容进行系统的划分、关联。
（2）分层图：对拓扑图中某个系统的内容进行分层规划，如业务层、数据层。
（3）框架图：对分层图中的某个层进行详细的分区规划，如功能区、应用区。
（4）分解图：对分层图中的某个区进行详细分解，如成本分解、采购工作分解。
（5）流程图：对框架图／分解图的活动部分进行流程关联，如采购流程。
4．模型与逻辑的强弱关系
实现了原始需求中的业务知识表达向逻辑表达转换的第一步，通过这一系列的架构设计工作，将原来的“零散业务”，通过架构模型的逻辑表达方式，形成了一套完整的、清晰的、符合开发要求的“逻辑表达方式”。业务不再是用表格、语言、零散的功能需求来表达的，模型从拓扑图到流程图，用不同强弱的逻辑表达形式将研究对象一步一步地从粗粒度的弱逻辑关联走到了细粒度的强关联。