第16章 架构的应用设计
结束了业务架构的概要设计和详细设计，下面就要将业务架构设计的成果转换为用系统要素表达的应用架构，架构的应用设计重点给出业务架构的实现机制。架构的应用设计构建了“人-机-人”的工作环境，它是决定客户对信息系统价值大小、满意度高低的主要章节之一。
16.1 基本概念
16.1.1 定义与作用
1．定义
架构的应用设计，是用系统要素进行的架构设计。它是依据架构的概要设计成果——业务架构图、架构详细设计的业务流程规格书（流程5件套）等的业务设计内容，加入系统功能，以及设计出在系统中驱动这些架构的“运行机制”，最终形成应用架构规格书。业务架构与应用架构的区别如下。
（1）业务架构：要素是功能（包括：系统、模块、功能），关联关系是业务逻辑。
（2）应用架构：要素是控件（包括：系统、模块、组件），关联关系是系统机制。注：关于“系统、模块”在业务设计和应用设计中都是一样的，表明的都是最小要素（功能、控件）的集合体。
2．作用
架构的应用设计主要就是构建信息化的工作环境，也就是具体地设计出“人-机-人”的工作机制，让客户直接感受到优化设计完的业务在未来的信息化环境中是如何运行的。架构的应用设计是进入技术设计阶段前的最后一站，重点是增加系统要素，以及将“业务逻辑”向“系统机制”转换，机制转换的过程分为以下两步。
第一步：从业务知识中抽提出业务规律，形成“业务逻辑”（概要设计、详细设计）。
第二步：从业务逻辑中进一步抽提出规律，转换成“系统机制”（应用设计）。系统机制的表达方式更加符合技术设计与开发的习惯，系统机制也是实现“复用”的重要概念，完成了系统机制的设计就完成了全部架构层的设计工作。
16.1.2 内容与能力
由于应用设计是业务设计和技术设计的交界处，应用设计在对业务设计成果转换的同时还要加入与技术设计交互的内容，因此，在架构的应用设计作业中包括两大部分：一是应用架构的方法，二是将业务架构成果转换为应用架构的方法。
1．作业内容
1）应用架构
在架构的应用设计中重点要解决的课题之一就是给出应用架构的方法。根据客户信息化的目的、功能需求、设计理念等确定应用架构的形式，业务设计阶段已经可以满足业务方面的需求，应用设计阶段还要满足诸如随需应变、功能复用等非业务性的需求。如何应对这类需求也会极大地影响到应用架构的形式。关于这方面的设计可以分为两个部分：系统机制的设计，基线系统的设计。
（1）系统机制的设计：根据客户目的，确定“需求应变和系统复用”的机制。
（2）基线系统的设计：可以满足“需求应变和系统复用”产品的架构。
2）业务架构的转换业务设计中完成的架构图有5种：拓扑图、分层图、框架图、分解图和流程图，这5种图在应用设计阶段中有如下作用（不限于此）。
（1）拓扑图：常用于对硬件、网络等的规划设计。
（2）分层图：分层图用于数据不同层的表达。
（3）框架图：以业务功能为核心，加入辅助的系统功能等。
（4）分解图：用于数据结构分析等。
（5）流程图：以业务流程为基础，设计业务流程可以自行运转的驱动机制等。
2．能力要求
架构的应用设计，重点是将业务设计成果与构成系统的其他要素相结合，因此需要应用设计师不但要熟知业务设计，而且还要具有技术方面的相关知识和能力。
（1）掌握业务架构中的概要设计、详细设计部分知识和能力。
（2）能够识别出业务设计中的共性和个性，并从共性中抽提出具有规律性的内容。
（3）掌握建模方法，将共性部分用模型表达，为设计通用的机制打下基础（本章重点）。
（4）掌握技术设计知识、数据库知识、软件的开发过程，最好具有一定的开发经验。
16.1.3 思路与理解
应用设计阶段的架构，核心工作是将业务设计成果向应用架构方向进行转换，不论是开发“产品”还是开发“项目”，信息系统的“复用、应变”都是应用设计师追求的重要目标，达成这个目标不仅是技术设计师的责任，因为处在设计工程末端的技术设计师或是开发工程师是不具备完成这个目标的完整知识和能力的，而且到了技术设计或是开发阶段再考虑这个问题就已经迟了，要达到这个目标必须从业务设计中解耦，在应用设计中建模，在技术设计中完成。这个目标的达成需要具有“系统的思考方法”，实现复用是需要有“业务设计知识、应用设计知识和技术设计知识”三个方面的知识，缺一不可。
（1）首先在业务设计中对“业务需求”进行充分的解耦设计，解耦的设计成果反映在业务架构的规划设计、功能设计、业务功能的协同中。如果在业务设计中不进行解耦设计，则无论后续的技术设计、开发如何努力都不会达到产品灵活复用的目的。
（2）在应用设计中以“应用效果”为前提，充分地思考如何让业务设计的解耦成果落实下来，用什么样的“机制”可以实现“解耦”的效果。
（3）在技术设计中给出开发实现的方法，信息系统的复用设计是以业务设计成果为前提、以应用效果为指导目标、以技术实现方法为基础的应用设计成果。信息系统的复用设计首先是从业务设计的解耦、规划开始的，有了业务设计的贡献，才有可能实现复用的目标。
业务架构利用分离原理进行了拆分、解耦，同时采用了组合原理的三元素“业务逻辑、业务功能（要素）、业务架构模型”进行了建模。在应用架构中同样也符合组合三元素的定义，但是应用架构使用的三元素要转换成为“系统机制、业务组件（元素）、应用架构模型”，它们与业务架构的组合三元素有对应关系。由于它们要在系统中实现，因此，它们的建模方法和运行机理与业务架构还是有着很大的区别的。
16.2 应用架构设计的概念
下面就以基干原理为参考，说明符合“组件+机制”的应用架构设计方法。这个部分的主要内容是：应用架构设计是如何支持复用和需求应变的、它的机制是什么、实现它的设计方法是什么等。当然，实现方法不止一种，这里重点是帮助应用设计师了解和掌握一些从系统视角看设计的概念和知识，有了这样的知识后业务设计师和技术设计师也可以参加到应用架构设计中来。
16.2.1 应用架构的概念
业务设计阶段的架构工作主要是为了梳理和优化“业务”，产生的业务架构图表达了对业务进行优化后的成果；架构的应用设计阶段工作是为了构建实现业务设计成果的“应用系统”。
业务架构的要素是业务功能，那么应用架构的要素是什么呢？业务架构完成后形成了很多用于不同目的的业务功能群（子系统、模块），它们内部都是业务功能。按照基干原理的理念，不论业务内容是什么样，其系统的构成机制都是一样的，对比业务和应用设计两个阶段，理解应用架构的概念，不论按照业务处理内容可以划分出多少种软件的类型，把它们按照系统的要素进行拆分和归集后，就会发现归集出来的系统要素内容是有限的。
1．业务设计视角
从业务处理内容的分类来看（业务视角），这些软件都是不一样的，它们是由不同业务功能组合成的不同目的的软件，例如，项目管理（PM）、资源管理（ERP）、自动办公（OA）、财务管理等。
2．应用设计视角
从另一个角度看（系统视角），不从业务处理的内容分类而是从系统的构成要素来区分，则不论什么业务处理它的系统构成要素都采用了组件、按钮控件、接口、数据库、流程机制等内容。在信息系统中，业务功能被包装在了这些组件之内，由于组件和控件的机制都一样，且用户是通过操作这些组件和控件来处理业务的，所以，从应用架构的视角来看前面所提到的软件都是一样的。
再进一步对这些构成应用架构的系统要素进行分类、分层，可以更加深入地理解应用架构的概念，以最下面为第一层，从下向上观察。
第一层：首先设计应用架构的最小要素——控件（控件用编码的方式开发，不在此叙述）。
第二层：用“控件+规则”的方式形成组件。
第三层：用“组件+机制”的方式形成系统。
第四层：用“系统+机制”的方式形成产品。
不论业务处理内容分类有多少种，应用架构使用的系统要素都是有限的，导出这个结论为后续构建可以复用和应变的应用架构打下了基础。
16.2.2 基线系统的概念
如何利用支持应变的应用架构形成一个可以支持复用和应变的系统。通常用于相同业务领域的信息系统，尽管客户不同，但由于业务领域相同，所以信息系统功能的共性应该不小于50%。也就是说，只要是相同领域的企业共性化需求应该有一半是相似的（否则就不能称之为相同的业务领域了）。我们在实际的设计开发实践中也印证了这一点。基于此，软件公司会不约而同地想到要做一个可以复用的系统：对共性部分进行固化，它是可复用的部分；对个性的部分不要固化，个性化部分的设计决定了产品的随需应变能力（随需应变的能力包括如下指标：标准化、模块化、可增加可减少等）。下面将基线系统的概念作为一个解决方案，借助这个方案可以更好地理解应用架构以及复用、应变的设计方法。
1．复用与应变能力
产品的开发，通常是利用一款已有的系统作为基本原型，然后通过不断地提供给不同的客户使用、验证，同时根据客户的新需求不断地增加新的功能而形成的。这种做法有个不足之处，就是久而久之会使得原有的信息系统的功能变得越来越多、性能越来越差。
2．基线系统的架构
可以满足系统复用和应变的需求系统就称之为“基线系统”。所谓的“基线系统”，就是将系统中共性的部分功能抽提出来，形成一个“中核”，这个中核不会因为业务需求的变化而变化（微小的变化可以忽略），由于这个中核部分采用了基干原理（组件+机制）的架构方法，可以灵活地增减个性部分的功能，所以这个中核部分称为“基线”，以基线为基础构成的系统称为“基线系统”。
①具有共性的组件和机制构成的整体称为基线系统。
②与业务领域无关的共性部分。
③具有行业共性的业务组件。
④与业务无关的系统机制（按照“机制组件”的方式设计）。
⑤个性化的其他业务功能（组件库），按需导入。
3．产品型与项目型系统的区别
由于商业目的的不同，软件企业一般会将软件分为项目型系统和产品型系统。
（1）项目型：为客户定制的系统，特点是个性化的功能需求比较多，或是首次涉及的业务领域，因此大部分的功能是不能复用的。
（2）产品型：在某个业务领域内系统功能的大部分都是可以复用的。如果能够实现基线系统的架构，则产品型系统和项目型系统就不存在本质上的区别了。产品型系统可以理解为是以项目型系统为基础，按照销售需要固化了项目系统中的部分功能而获得的系统，而且未来客户的个性化需求会越来越多，就不存在绝对的产品型系统了。
基线系统型的系统具有很多优点，但是根据能量守恒定律，开发这样的系统的成本和技术要求也是较高的，如何判断是否需要基线系统式的架构呢？
（1）需要的场合：某类系统根据客户的使用情况需要不断改变，且因为系统复杂维护成本高（时间、资源），或是系统内的某些功能具有复用的价值等。
（2）不需要的场合：项目涉及的业务领域是一次性的，需求基本上不会发生变化，系统简单，维护成本不高等。
16.3 应用架构设计1——框架图
框架图的主要作用是规划，给出每个阶段的总体设计、系统划分、系统边界，以及系统之间的关系等，它是每个设计阶段最为重要的顶层设计用图。因此，在应用设计阶段同样要先做框架图，做出对应用架构的整体规划。
16.3.1 业务框架的转换
在架构的概要设计阶段，业务框架图是基于需求工程的业务领域划分、再加上对未来业务的规划、业务的优化成果等设计而成的，此时尚不考虑未来系统的实现方法，只集中于对业务处理的设计内容，因此这个阶段获得的框架图是“业务框架图”。
在应用设计阶段的框架图中，最为重要的就是要规划出辅助业务处理的功能（这些功能不是直接用来处理本系统的业务对象，但却是构成一个信息系统不可或缺的功能），或者是增加附加价值的功能。架构的应用设计重点之一就是将业务设计的框架图与这部分的功能整合在一起。这部分的功能种类很多，而且会因系统的业务对象的不同而不同，这里仅举一些构成系统常见的功能作为启示和参考（不限于此）。
16.3.2 应用框架的设计
应用框架是以业务功能为核心进行架构的，追加的系统功能都是为业务功能提供支持服务的。
①门户类：这类功能是进入系统的前端，是本系统与外部进行信息输入／输出的门户。
②支持类：它们是系统得以运行的重要功能，包括组织、权限、流程、规则等的设定。
③维护类：它们是对系统进行基本设置的功能，包括注册、安全、权限赋予等。
④应用类：其他软件系统、平台等。当然，由于应用设计师的见解不同，功能的选择和设置的位置也会有所不同。
例如，企业知识库，其内容与业务处理紧密相关，则可以作为业务架构框架图的一部分；反之，关联不紧密，而且也没有与业务功能的界面做智能化的链接，则可以将企业知识库归入到应用架构框架图中，作为辅助功能看待。
16.3.3 技术框架的介绍（参考）
技术设计虽然不属于本书的范围，但是为了更好地理解框架图在不同阶段功能的叠加过程，加入技术阶段的框架图进行对比，在技术设计阶段加入了技术部分的功能形成了最终的完整框架图。这个框架图也可以帮助读者从整体上理解软件工程三个设计过程（业务设计、应用设计和技术设计）的区别。虽然由于着眼点不同，表达的内容不同，但确实是经过了三个不同阶段的努力，三个不同阶段的设计成果共同构成了最终的系统。从上述过程可以明显地看出来，每一个设计阶段都会为最终的信息系统增加一部分新的功能，业务→应用→技术，最后形成的系统是由“业务+应用+技术”三个部分构成的。这三个功能实际是价值的不断增加，通过这样的分知识、分层次、分粒度地进行设计最终完成全部系统所需的功能。业务设计阶段的工作需要由业务设计师完成，技术设计阶段的工作需要由技术设计师完成，应用设计阶段的工作是两者共同参与的部分。
16.4 应用架构设计2——业务流程
在架构的概要设计中已经掌握了绘制业务流程图，这些流程图是用业务逻辑将功能串联在一起形成的，应用设计阶段要解决的是这些流程在系统中的运行方法，根据业务设计师的设计理念、目的不同，业务流程的实现方法也不同，在本节里说明流程运行机制的设计方法，以及如何利用应用设计知识让用户获得良好的体验价值。
16.4.1 业务流程的转换
在系统中实际运行的流程是由“组件”构成的，应用设计师在应用设计阶段会将业务流程上的活动（节点）转换为系统流程的组件，同时还会由于系统的运行性能、数据安全等原因再度对原有的活动进行拆分或是组合，所以完成后的系统可能存在着“业务流程节点数≠系统流程节点数”的现象。
业务流程上的业务功能个数，以及业务功能界面上的字段等内容，只有等到功能的应用设计完成后才能够最终确定下来，因此，系统流程最终的节点数也要等待功能的应用设计的结果。这里要注意，虽然一般来说架构层的设计在前、功能层的设计在后，但是因为功能内部字段、规则的调整反过来也会影响到已经完成设计的架构层的内容，架构层和功能层之间是存在着设计的迭代关系。
16.4.2 流程机制的概念
进入了流程的应用设计后，应用设计师的关注点就不在业务处理和业务逻辑上了（已在业务设计中完成），而是将关注点放到了流程上节点之间的推送关系，以及实现这个关系的运行机制上了。
1．流程的机制
业务流程是一系列工作的协同“过程”，审批流程是对一条流程上某个节点管理的“控制点”，每个组件内的业务处理完成后，都需要判断审批流程和业务流程的有无，以决定下一步的流转方向。
在业务设计中，对于两个活动之间关系的表达常用“逻辑关系”，而在应用设计中则采用“机制关系”，与业务设计用图中表达逻辑关系相比，应用设计用图中更多表达的是机制关系，机制关系是逻辑关系在应用设计中的表达。逻辑表达的关系不强调是否是可复用的常态关系，但是机制关系一定是一个可以复用的常态关系。具有复用价值的机制是在逻辑关系的基础上经过抽提、建模从而建立起来的。
2．流程机制的使用判断
懂得了流程的应用设计方法后，是否采用流程机制的方法来实现流程的运行呢？这取决于系统的需求是什么。这里举两种场景做判断。
【场景1】流程需要灵活应变，具有复用功能。
采用“流程机制”的设计方法，这样完成的流程可以通过改变配置规则就能适应各类不同流转条件，因为不需要通过修改代码来实现流程变化，所以效率高、响应快速，并且可以复用，它给用户带来的体验价值较高。但是这个方式的第一次开发成本较高，有一定的设计和开发难度。
【场景2】流程不需要具有应变性和复用功能。
这种场景可以考虑为是一次性的，即系统使用期间不变化，因此可以将流程按照业务流程图的逻辑用代码固化（通常所说的“用代码写死了”），它的设计和开发成本较低，技术要求相对也简单。但是一旦需要变化时，就需要重写流程代码。
16.4.3 流程机制的设计
通过业务流程设计获得了业务逻辑，业务逻辑不但为后续的功能和数据设计提供了支持，还为应用设计中进一步提升客户的体验价值奠定了基础。下面就通过一个案例来说明如何利用业务逻辑作依据，将业务逻辑转换为业务流程机制，以提升用户的信息化体验价值。
1．流程机制一：事找人
所谓的“事找人”，就是以业务流程的逻辑关系为依据构建一个可以“自行驱动”的流程机制。采用信息“推送”的方式形成一个可以让业务流程的上游组件完成处理后，自动地通知下一个组件的用户，以此类推，从而形成“事找人”的流程形式。这个由“启动、处理、提交、通知、接受”等构成的运转过程就称为“事找人的业务流程机制”，以下“流程”均指“业务流程”。这个“事找人”的机制是由流程上的组件、菜单控件、流程中心、通知功能、门户（待办事宜）等构成的。
最终，让系统的使用者感受到的不是“业务流程的逻辑”，而是“事找人的过程”，业务流程的逻辑都融入到了事找人的过程中。
2．流程机制二：人找事
上述讲的“事找人”的效果是利用业务逻辑设计的“主动推送”方式，那么“人找事”这种被动的工作方式是否就没有价值了呢？不是的，利用应用设计的手法结合也可以设计出有实际意义和价值的“人找事”的方式。这个机制是由功能菜单、导航菜单、查询功能等构成的。
从这个设计可以看出，“人找事”并非不如“事找人”，前者可以通过导航菜单的反复使用，加深对业务架构／流程的理解。当然，如果将“事找人”和“人找事”的功能组合起来，则效果更好（但是设计和开发成本会高一些）。
注：导航菜单与系统菜单
导航菜单与系统菜单上可以直接打开的功能要一致，如果不能从系统菜单上直接打开的功能，则在导航菜单上可以显示但不能加链接，这样保证两者的一致性（因为系统菜单上有权限等的设计）。从业务架构设计与流程机制设计的结果对比来看，两者明显目的不同、作用不同、设计的方法也不同，主要表现如下。
（1）业务流程：表达的是为实现某个目的而进行的一系列业务处理的“过程”。
（2）流程机制：表达的是某一类业务工作规律的“重复”。
流程机制是在业务流程之上通过抽提、归集和建模获得的，因此，做流程机制类的设计所需要的知识和能力要比业务流程设计的要高一些，特别是需要设计师懂得一些技术设计和开发的知识。
16.5 应用架构设计3——审批流程
16.5.1 审批流程的概念
按照分离原理，审批流程的作用只是对某个流程上节点（活动）的处理结果给予判断，包括：评审意见、是否放行，原则上审判者是不能直接操作业务功能内部的数据的。审批流程的形态根据企业用户的需求存在很多的形式，。
①串行审批：有前后顺序，不可逾越。
②并行审批：对上级的提交没有前后顺序，复数的上级可以同时审批。
③回行审批：上级可以对提交的审批内容向下级退回。
④混合审批：一条路线是既定审批流程，另外一条是临时指定，可视情况由下级按照规定确定送交哪些人参与审议。
16.5.2 审批流程的设计
审批流程的设计大都采用了辅助设计软件（工作流软件），根据客户的组织结构、岗位设置等要求，在软件上设计完成后直接就可以运行了。审批流程的设计大同小异。
小结
从架构的概要设计、详细设计到应用设计，这三步构成了架构的全部设计过程，架构三步设计的最后一步，是将业务设计阶段的架构设计成果转换为应用架构的设计形式，并且给出在“人-机-人”环境下业务流程是如何运行的、提供运行的驱动机制是如何设计的。
在概要设计阶段与详细设计阶段是以“架构”在“人-人”环境下为背景进行的优化设计，重点研究的是业务架构本身的合理性，并用“业务逻辑”的形式表达出来（业务架构图）；而应用设计阶段则是将“架构”置于“人-机-人”的环境下，此时设计的是未来在信息系统中运行的“系统架构”，并用架构运行“驱动机制”的形式表达出来（应用架构图）。从图形的表达方式上可以看出因为“业务架构”与“应用架构”的目的不同，因此表达的内容、形式是不同的，例如，在“人-人”环境下，业务流程是由“人”来驱动的，在“人-机-人”环境下，业务流程可以由系统按照预先的规定自动地驱动流程运行。如何将业务逻辑与系统机制有效地结合起来，充分地发挥出信息化手段的作用，给客户的业务处理带来效率的提升是架构的应用设计的价值所在。
应用设计，为客户带来信息化惊喜
应用设计确实是既非纯业务设计，也非纯技术设计，而且它也不是通常所说的UI设计。UI设计应该是应用设计构成的一部分。
网友评论