金融业务核心系统要具有很高的可用性、有效性和安全性，该系统建立在完备的多极审批模式基础上。金融作业要通过递进的审批流程，才能做到正确、完整和规范。系统架构师在搭建金融审批模式时，要充分考虑系统环境、子系统关系、需求变更及开发成本和周期等因素，使架构条理清晰、易于维护，并切实适用于所存在的金融业务核心系统。
一、金融审批业务逻辑
　　审批者登录系统后，系统通过角色数据库获取其角色，并将其角色写入Session（会话）。尔后，在每个审批作业的起始点读取Session中审批者的角色，并为其分派审批业务。金融审批业务逻辑如图1所示。
二、金融审批的架构思想
　　（1）单审批作业
　　不同审批者执行相同的审批作业流程，执行结果因审批者角色不同而不同，该架构思想较为普遍。
　　（2）多审批作业
　　不同审批者执行不同的审批作业流程，该架构思想常见于中型金融业务核心系统，也较为普遍。
　　（3）审批逻辑知识库
　　审批逻辑知识库的架构思想包含两部分。第一部分由接口和逻辑处理组件构成，完成从业务面的审批需求获取的逻辑知识库的格式化审批知识拾取，以及从逻辑知识库的格式化审批知识获取的业务面的审批规则产生的功能。第二部分是审批逻辑知识库，其中存放适用于不同业务需求的审批逻辑知识，它具有规范化的格式和维护接口，审批结果由审批逻辑知识决定。这种审批架构思想需要大量核心技术支持，同时要装配大量规则接口，并且这些规则接口能被子系统共用。实现该种架构思想需投入较多开发成本，开发周期较长，适用于大型金融业务核心系统。一旦实现，将受益颇多。
三、金融审批的特殊需求
　　（1）兼职审批
　　同一审批者兼任多个审批角色。该需求实例多见于分公司设立初期，审批人员数量暂时少于审批岗位数量的业务环境。针对该需求所采用的审批架构，会对系统整体效率和安全性产生重要影响。它比较常见，也易实现。
　　（2）跨系统审批
　　某些审批作业需要跨越多个子系统。如签呈审批要跨越签呈和预算系统；财务审批要跨越传票、费用核销和预算系统；投资审批要跨越传票、预算，财务和签呈系统。该需求常见于中（大）型金融业务核心系统。由于子系统具有各自不同的审批特点，所以不易被实现。
　　（3）特殊代理人审批
　　某些特殊岗位（如公司总经理、副总经理）的审批作业需要由特殊代理人（如秘书）来完成。其中特殊代理人不能涉及其他非审批相关信息（如公司机密）。该需求高度特殊，在小企业中并不常见，多见于大型金融集团。
　　（4）更换审批级别
　　用户需要经常更换审批级别或审批流程，该需求会对采用不同审批架构思想的系统产生不同程度的影响。如果架构思想不适用，则会在很大程度上降低系统可用性。
　　（5）重做历史审批
　　由于系统缺陷或人为破坏等原因，导致审批资料错误，需要采用线性修正方法（金融审批是连续递进作业，错误审批时点后的所有审批流程必须被重做）更新错误审批数据。不同审批架构思想会对线性修正的效率和正确性产生巨大影响。
　　金融业务核心系统中三种主流审批架构思想，受以上五种特殊审批需求的影响，因此没有绝对有效或无效的审批架构思想。架构是否适用，关键在于其是否能适用于整个系统，是否能高效满足用户需求，是否能提高金融业务核心系统整体性能。
四、如何实现金融审批的特殊需求
 1．单审批作业架构思想
　　不同审批者执行相同审批作业流程，审批结果由于审批角色不同而不同。其核心是从数据库中获取审批者角色，然后根据角色不同而产生不同的审批结果。
　　以下例来说明单审批作业架构思想对兼职审批需求的实现方式。在费用核销子系统中，三个主要的审批岗位为：部门预算委、财会预算岗和财会部总经理。分公司新成立时，财务作业人员有限，因此就由分公司财会预算岗兼任财会部门预算委。根据这个需求，并基于单审批作业架构思想，可以采用如下两种架构模式。
　　第一种是完全按照正常审批作业流程。审批者首先以财会部门预算委身份登录系统，进行作业后，核销案件的状态更改为待财会预算岗审批。审批者再以财会预算岗身份登录系统，进行审批作业后，案件状态变为待财会部总经理审批，实现了该需求。但是对同一案件，审批者需要重复2次审批作业，使工作量加倍，降低了系统作业效率，如图2所示。

 第二种是通过获取审批者最高审批级别来进行审批作业，如图3所示。它解决了第一种架构模式带来的系统低效问题。

　　审批者不用重复多次审批，节省了作业时间，减少了工作量，提升了系统效率，但也存在弊端。如果审批者跨越审批层级兼职，系统将出现不可逾越的漏洞。仍以费用核销为例，审批者为分公司财会部总经理，同时兼任财会部门预算岗（该种兼职方式跨越了处于中间层的财会部门预算委层级）。审批者审批作业时，系统用审批者最高级别（即财会部门总经理）进行处理，将核销案件状态更改为财务部总经理已审批，结束了案件审批流程。此时，案件虽已结案，但却跳过了财会预算岗审批，系统出现了逻辑后门漏洞（逻辑后门漏洞是由于逻辑架构缺陷导致的系统逻辑错误，它不会引发异常，但审批作业流程不完整，降低了系统安全性）。
　　单审批作业架构思想不能（或很难）解决由跨层级兼职导致的逻辑后门漏洞问题。除非人为禁止跨层级兼职，但是通过人为控制来解决系统漏洞不是可取的方法。后文陈述的二三类架构思想可以解决此问题。
　　由于某些审批岗位的特殊性（例如高管），审批者不能在系统中完成审批作业，需要其代理人（如秘书）代为执行。特殊代理人不能涉及其他面向审批者的信息（如公司机密），他只能录入审批者的决定，该项需求极其特殊，与其他需求没有逻辑共同点。采用单审批作业架构思想的系统只能在源代码中对特殊代理人进行识别（如特殊代理人的工号），当特殊代理人作业时，系统将转为执行被代理人的审批作业。采用单审批作业实现特殊代理人审批需求的流程见图4。

    将特殊代理人识别信息写入系统代码的模式，以牺牲系统灵活为代价，虽然能暂时满足特殊代理人审批需求，但是当用户更换特殊代理人时，系统源代码就不得不被再次更改，造成开发浪费。
 2．多审批作业架构思想
　　该审批架构思想逻辑结构单纯，适用于中小型金融业务核心系统。在审批作业入口处对审批者角色判断，就可以调用相应的审批作业，如图5所示。该审批架构会出现由于少量审批角色不同而带来大量系统冗余的问题。系统扩展空间小，而且开发成本会由于冗余开发而升高。
　　针对兼职审批需求，该架构思想同样存在审批者重复作业的缺陷。但是它能较好地实现跨系统审批需求。无论审批者是否兼有多重角色，其执行某一审批作业的身份是唯一的，系统以审批者这一身份执行操作。当审批者进入另一作业时，系统又以审批者另一身份执行操作。审批者在某一时点执行的作业唯一对应其某一角色，如图6所示。系统较稳定，可用性高。
　　 多审批作业架构思想不能很好地实现特殊代理人审批需求。如果特殊代理人需要跨系统作业，那么当特殊代理人变更时，系统将出现迁一发而动全身的情况，使系统很难维护。如果金融审批作业中含有大量特殊代理人审批需求，建议不采用该架构思想。
　　多审批作业架构思想能很好地满足频繁更换审批级别的特殊需求。类似于兼职审批，无论审批者的角色如何被频繁更换，同一时点，审批者只有一个审批角色，只需加大系统作业前端角色控制模块的灵活性，就能很好地实现该特殊需求。
　　3．审批逻辑知识库架构思想
　　审批逻辑知识库架构思想采用了通用逻辑知识库（通用逻辑知识库类似于专家系统，但比专家系统简单，其中主要包含格式化的审批逻辑知识，有较大通用性），技术含量高，审批逻辑知识库决定审批角色和作业流程，是较为前端的审批架构思想。业务面的对象已由审批角色变为具有高度独立性的逻辑审批知识。逻辑知识库具有灵活的业务平台接口，当逻辑审批需求产生时，通过逻辑知识库接口维护逻辑规则库（即新增、变更、删除等操作），便可实现审批需求更新，如图7所示。该架构思想提高了审批作业的逻辑独立性，应用该思想的金融业务核心系统非常灵活、易扩展，并且稳定，系统使用和维护效率将大为提高。
　　审批逻辑知识库架构思想由审批业务输入接口、审批业务解析器、审批逻辑分派器、审批逻辑接口、逻辑拾取单元、审批逻辑产生器、审批业务输出接口、逻辑知识学习接口、审批逻辑维护接口等组件构成。这些组件互相协作，产生了完整的审批需求结果，确保了审批作业的完整和高效。审批逻辑知识库构成如图8所示。
 审批逻辑知识是对审批业务需求的标准化陈述，它采用规范化的数据格式描述了审批业务需求的实现过程。逻辑拾取单元是由逻辑知识库驱动的小型功能组件，完成拾取审批逻辑知识的功能。审批逻辑陈述标识如图9所示。
 作业流程如下：
　　（1）首先通过审批逻辑维护接口将审批逻辑知识导入逻辑知识库，并为其分配（或新建）逻辑拾取单元；
　　（2）审批作业时，业务需求通过审批业务解析器传递至审批逻辑分派器；
　　（3）审批逻辑解析器将业务面的审批需求转换为格式化的审批逻辑陈述，并为审批逻辑陈述附加业务需求标识；
　　（4）将带有标识信息的审批逻辑陈述传递给审批逻辑分派器；
　　（5）审批逻辑分派器由各种映射表组成，它接收到格式化的审批逻辑陈述后，高效率地将其映射到该审批逻辑陈述对应的审批逻辑接口，然后再次为审批逻辑陈述附加逻辑知识库标识，并将其传递给审批逻辑接口；
　　（6）审批逻辑接口与逻辑知识库唯一对应（只要符合相同标准，一个审批逻辑接口也可以与多个逻辑知识库对应，这个标准需面向整个金融业务核心系统，而不单是其中的某个子系统），它再次为审批逻辑陈述附加逻辑知识单元标识；
　　（7）逻辑知识库收到来自于审批逻辑接口的审批逻辑陈述后，解析其逻辑知识单元标识，并通过逻辑拾取单元拾取符合需求的逻辑审批知识，并将其回传到审批逻辑接口；
　　（8）审批逻辑接口收到的是高度格式化的，且含有大量平衡性冗余数据的审批逻辑知识（高度格式化的审批逻辑知识不能直接被业务面调用，因为业务调用者不能解析它们）；
　　（9）审批逻辑接口将解析其中的逻辑知识库标识，确定业务审批需求类别，去掉冗余数据，并将处理后的审批逻辑知识传递给审批逻辑产生器；
 （10）审批逻辑产生器继续解析审批逻辑陈述中的业务需求标识，确定审批逻辑陈述对应的审批业务需求，将格式化的审批逻辑数据转换为面向业务面的审批需求结果，并将该结果回传给审批业务输出接口。
　　此时，系统完整地完成了从审批业务请求到审批逻辑产生，并回传给审批业务调用者的整个审批业务规则产生过程。另外，根据金融业务核心系统的规模和用户需求，可以为逻辑知识库预留学习接口，提高系统智能。
　　审批逻辑知识库架构思想适用于大型金融业务核心系统，其中的子系统应建立在统一平台上，子系统间应具有较高独立性。满足上述条件的金融业务核心系统能最大效用地发挥审批逻辑知识库的效率。采用该架构思想的系统对上文陈述的几种特殊审批需求将迎刃而解。
　　针对兼职审批需求，业务人员通过审批逻辑维护接口将兼职审批规则导入逻辑知识库，即可实现该需求。针对跨系统审批需求，只要子系统建立在统一平台上，那么子系统就可以通过统一平台获取逻辑知识库的审批逻辑，实现该需求。针对特殊代理人审批需求，业务人员只需将特殊代理人及需要其特殊代理的审批作业导入逻辑知识库，即可实现该需求。用户更换特殊代理人或者是更换其代理审批的作业时，通过审批逻辑维护接口对逻辑知识库进行维护，就可以实现特殊代理变更流程。它保持了业务面系统不受特殊代理变更的影响，提高了系统可用性和有效性。用户频繁更换审批级别或审批流程时，只需将新的审批规则导入逻辑知识库后，再删除旧的逻辑审批规则即可。用户完全可以快捷，方便地设置审批逻辑，系统整体性能得到了极大提高。
　　审批逻辑知识库架构思想是多个领域知识的组合，它已形成了一个复杂的小型（甚至是中型）系统。在整个金融业务核心系统中，它不再作为其他子系统的模块而存在，而是作为子系统与其他子系统平行存在。实现审批逻辑知识库架构思想，需要大量的需求分析工作、整体架构工作，完善的开发工作和完整的测试工作，开发成本较高。它适用于特殊审批需求较多、需求易变，且子系统建立在统一平台上的大型金融业务核心系统。如果金融业务核心系统达不到以上条件，那么就不适于采用该架构思想。后期扩展的系统也可以采用此架构思想，但是该架构给整个系统带来的效能要在后期系统达到相当规模后才会体现出来。　　
五、重做历史审批
　　系统需要建立某种修正机制对由于系统缺陷、人为破坏等原因导致的错误审批结果进行修正。金融业务核心系统中多采用重做历史审批的修正机制对错误审批结果进行线性修正。
　　重做历史审批时，系统需要调用审批者在历史时点的审批级别。如果审批者的审批级别已发生更改（提高或降低），那么系统调用审批者的历史审批级别将非常困难，甚至需要调阅历史记录资料，然后更改系统源代码才能完成。否则，审批数据将再次错误。
　　如果应用了审批逻辑知识库架构思想，那么只需通过审批逻辑接口，拾取审批者在历史审批时点的审批逻辑知识，即可快捷，准确地完成历史审批重做。
六、各种架构思想的适用环境
　　每种审批架构思想都有适用的系统环境。单一审批作业架构思想适用于小型且审批需求固定的金融业务核心系统；多个审批作业的架构思想适用于中型金融业务核心系统；审批逻辑知识库架构思想适用于开发成本较多的大型金融业务核心系统。各种审批架构思想的适用环境如上页表1所示。
 系统架构师在考虑金融业务核心系统采用的审批架构思想时，首先需明确用户审批作业环境，接着详细分析审批需求，对不同审批需求分类，进而考虑系统规模、开发和维护成本，开发周期和系统扩展等制约性因素，才能正确地选择审批架构思想和设计审批模式，完成详细的审批架构，达到提高金融业务核心系统整体性能的目的。