企业架构研究总结（45）——企业架构与建模之使用ArchiMate进行分析（全系列完）

4. 使用ArchiMate进行分析

      正如前面所说的那样，一个企业总体效率的提高有时并非经过某一个领域内的优化就能达到的，并且这种忽视全局的作法每每还会形成没必要要的浪费。因而可知，一个可以跨越各个领域、一致性的全局模型是实现企业总体效率提高的重要基础，而这也正是前面几个章节所描述的ArchiMate建模语言的终极目标。不过这样一个全面的企业架构模型的创建并非最终的目标，如何使得企业内外各干系人在决策时可以作到对企业各层面中各自关注的部分有着深刻、一致的洞察才是此模型的终极价值所在。要达到这样一个目标并不容易，这牵扯到如何对企业架构模型进行使用的问题，可是使用这样一个一应俱全的模型并非一件简单的事情，仅从企业架构的规模和复杂度这两个方面来看足够让人望而生畏了。

      在解释如何使用企业架构模型来辅助干系人进行决策以前，咱们首先要明确这一“辅助”的目标是什么，亦即干系人“决策”的含义。“决策”的背后老是“变化”，由于有了变化或将要发生变化干系人才须要进行决策，这既包括在“变”与“不变”进行选择，也包括在各类变化方案之间进行的抉择，而只有对企业各领域具备深刻的洞察才能尽可能确保选择的正确性。在决策过程当中，各干系人须要对各类设计方案进行对比，在成本、质量和性能之间取得权衡，并可以对变化所带来的影响具有明晰的认识。虽然企业架构模型在逻辑上具有这些决策所须要的信息，不过就其自己的复杂度和规模而言，这些信息的获取并非经过前面所说的几个视角以及相关的几张平铺直叙的视图就能实现的，这须要以企业架构模型为基础进行各类针对性的分析才能达成，而这些分析都包括什么，以及如何进行分析正是本章阐述的重点。

      须要注意的是，架构分析技术并不只是一种或一套新式的用于分析架构的方法。与前面所讲的ArchiMate建模语言相相似，本章提到的架构分析方法是对全部以企业架构模型为分析对象的方法的总称，而不是仅要从新创建一套分析方法，他既包括了各领域中已经存在的分析方法，也包括了本章后面将会介绍的新的具有跨领域特性的企业架构分析方法。虽然在各领域当中现存的各类分析方法只是针对其领域自己，而且对于模型的详细度要求又广泛高于企业架构模型这一高抽象度模型所能提供的，可是这并不意味着这些技术或思想不能运用到企业架构分析当中，实际上基于跨领域的企业架构模型的分析每每须要领域已有的技术分析结果做为输入，并且因为企业架构模型的这种高度抽象性，这些已有的分析技术思想在企业架构模型中相关领域内也是兼容的。

4.1 分析技术分类

      在对架构分析技术进行详细描述以前，咱们先对架构分析技术的种类划分进行归纳。 《Enterprise Architecture at Work》从两个维度将各类架构分析技术划分到以下图所示的四个象限之中：

      根据各类分析技术的输入和输出的类别，企业架构分析方法可分为“功能性（Functional）”和“量化（Quantitative）”这两种：

• 功能性（Functional）：功能性架构分析方法着眼于架构的功能方面。此种类型的方法可被用于判断系统与架构内容是否相符、了解变动对于架构所带来的影响，以及验证架构的正确性等。
• 量化（Quantitative）：功能性分析并不能解答诸如“多快”、“多省”这样的具备量化指标的问题，而这正是量化分析所要产出的结果。

      从分析过程所采用的方式这一维度进行区分，不管是功能性的仍是量化的架构分析方法都可被划分为“分析（Analytical）”和“模拟（Simulation）”这两种：

• 模拟（Simulation）：“模拟”能够看做是将模型所描述的客观对象在逻辑上进行虚拟执行的过程。根据前面所述的划分方式，模拟能够进一步划分为功能性模拟和量化模拟这两种：
• 功能性模拟：用于对系统的动态行为进行描述，从而以一种更加直观的方式为各干系人提供更加深刻的有关架构的性质和行为的信息，而也正由于这一特性，功能性模拟在促进干系人间的沟通中也扮演了重要的角色。
• 量化模拟：经过往复循环的屡次量化模拟，相关干系人能够获取有关系统量化指标的统计性信息，从而在指定状况下对系统性能指标进行全面的检验。
• 分析（Analytical）：与模拟相比，分析并不具有统计方面的特性，而是用于为各相关干系人提供惟一且可重复的结果。分析也可被进一步划分为量化分析和功能性分析这两种：
• 量化分析：用于为相关干系人提供有各关系统量化指标的初始印象，并借此识别出系统的瓶颈所在。
• 功能性分析：用于对架构的内在功能和性质进行分析，这既包括对做为架构组成部分的各结构元素的静态分析，还包括了针对架构行为方面的动态分析。

      从以上叙述中咱们能够看出，企业架构的分析方法能够被概括到由两个维度所组成的四个象限之中，不过对于采用“模拟”方式进行的分析来讲，不管是功能性的仍是量化的，其本质上是以对模型的虚拟执行为基础，其具体实施算法仍是以“分析”方式为基础，于是本章后续部分的重点将放到各类架构分析方法之上。

 

4.2 量化分析方法

      企业架构是个跨越组织中多个领域的架构，虽然组织采用的架构方法可能不一样，不过就企业架构的本质来讲，一个完整的企业架构至少应该包括业务、应用和技术基础设施这三个层面，于是针对企业架构的量化分析方法也应该将这些层面联系起来，从而为企业给出总体性的量化评估。这些量化评估包括多个方面的指标，他既包括诸如响应时间、资源利用率、吞吐量这样的与时间相关的性能指标，也多是可靠性方面的度量，亦或是对成本方面所进行的考量。在本章中，咱们将着眼于性能指标，介绍一种量化分析方法，用于计算企业架构模型所描述的系统的性能指标。

      经过基于企业架构模型的量化分析，咱们首先能够在企业的总体范围内得到优化，由于其分析的对象包含了企业各个领域中的内容，从而避免开篇提到过的单独领域的进化非但没有致使效率的提高，反倒促成了浪费的生成；其次，虽然咱们能够经过变化影响分析这一功能性分析方法来获取变动所带来的影响，不过只有结合量化分析，咱们才能对这一影响具有更加深刻的认识，这同时也说明量化分析和功能性分析并非相互隔绝的，在实践过程当中应该结合使用才能发挥出最大效能；再次，经过量化分析咱们能够把企业这一复杂“系统”的输入（业务工做）和支持性资源（用于对业务进行支持的各领域资源，例如业务流程、应用、软硬件环境等）结合在一块儿，并造成联动关系，从而实现容量规划，即获取在假定业务工做量的前提下各支持性资源的容量需求。

4.2.1 量化分析方法基本原理

      对于架构的量化分析方法种类繁多，不过他们大多都是基于某一特定领域模型的量化分析方法，而对于企业架构模型来讲，各类工具所关注的仍是主要在于建模部分，其对于企业架构的量化分析支持的并不充分，因此接下来笔者将重点阐述《Enterprise Architecture at Work》中所介绍的企业架构量化分析方法。此企业架构量化分析方法的目标在于对企业架构模型所描述系统的各项性能指标进行考量。从前面有关ArchiMate语言的介绍中咱们能够知道，并非全部的概念元素是与性能指标挂钩的，诸如“含义”、“价值”之类的概念元素是不该该处于此量化分析方法的计算以内的，于是借鉴以前提到过的视角概念，此量化分析方法的分析基础也应该是处在某种视角下的模型视图。下图（源自《Enterprise Architecture at Work》图8.3）展现了这一视角的元素构成，以及此量化分析方法所需的输入和最终计算目标：

      从上图咱们能够看出，此企业架构量化分析方法视角实际上与前面ArchiMate众视角中的层次视角很是相像，二者都是采用相互交叠的层次对各类概念元素进行组织，其中层次视角中的专用层（Dedicated layer）对应于此量化分析视角中的实现层（Realisation layer），而他们所同名的服务层（Service layer）在本质上是相同的。除此以外，这两种视角中对于层次之间的关系定义也是一致的，即都是经过“使用”和“实现”关系进行关联，其中位于下层的服务层（Service layer）为上层的服务层或实现层提供各类服务，而位于服务层（Service layer）下方的实现层（Realisation layer）或专用层（Dedicated layer）又对各类服务层所提供的服务进行了内部实现支持。须要注意的是，虽然这两种视角之间具备很高的类似度，但从定义上看二者仍是具备明显的区别，因为层次视角并不针对特定的应用环境，于是在此视角之下的视图能够包含全部的概念元素，而对于企业架构量化分析方法视角来讲，因为他所面对是针对各类性能指标的考量，于是此视角只包含与性能指标相关的各类概念元素。所以咱们能够说，此企业架构量化分析方法视角是层次视角的一个子集或具体应用特化。

      在企业架构量化分析方法视角的两种组成层次中，服务层（Service layer）包括了业务、应用和技术领域中的各类服务行为元素，而实现层（Realisation layer）则是由以上三个领域中的各类主动性结构元素（Resource）、被动性结构元素（Object）和用于表示内部实现功能的行为元素（Internal behavior）所组成的。在实现层中，主动性结构元素（Resource）经过分配关系与内部行为元素（Internal behavior）相关联，用于表示由谁执行了何种行为；内部行为元素（Internal behavior）经过访问关系与被动性结构元素（Object）相联系，用于表示各类内部行为的执行所涉及到的各类信息以及他们之间的读/写关系。

      除了企业架构量化分析视角的概念元素构成以外，上图还展现了此分析方法的输入以及目标性能指标。图中标注在各概念元素图符以外变量表明了此分析方法所须要的各类输入（n、f、S、C），而位于各概念元素图符以内的变量则表明了此分析方法中对各概念元素所考量的各类性能指标（R、T、U），即此分析方法的输出：

• 输入：
• 使用次数权重（n）：标注在“使用”和“访问”关系上的参数n用于表示服务元素被使用的平均次数，或被动性结构元素被各行为元素所访问的平均次数。
• 到达频率（f）：标注在概念元素旁边的参数f用于表示到达此节点的外部事务的频率。须要注意的是，虽然在定义方面能够容许对任何概念元素标明此参数，但在实践过程当中咱们一般只为处于模型最高层次（通常为业务层）的概念元素设置此参数的具体值，其他概念元素的此变量值能够经过分析方法推算而得。
• 服务时间（S）：用于表示行为元素在执行过程所消耗的净时间，即行为元素的总执行时间减去在执行过程当中等待其余支持性服务的执行所消耗的时间。例如，假设业务流程A的总执行时间是2秒，并且此流程A使用了B和C两个应用服务，且此二者的服务时间都是0.5秒，那么流程A的服务时间应为2-（0.5 + 0.5）= 1秒。须要注意的是，一般状况下咱们均假设由某内部行为元素现实的服务行为元素的服务时间应与这一内部实现元素的服务时间相同。
• 容量（C）：用于表示执行各类行为的主动性结构元素或资源（Resource）的处理容量。
• 输出：
• 响应时间（R）：用于表示自发起请求开始到收到最终结果这一过程所消耗的时间。
• 处理时间（T）：用于表示某一行为元素在事务处理过程当中所消耗的时间，即此行为元素的服务时间与全部对其进行支持的服务的服务时间之和。例如，若是业务流程A的服务时间是1秒，而且此业务流程的执行过程当中使用了应用服务B和C，且此二者的服务时间分别为0.5秒，那么处理时间应为1+（0.5 + 0.5）= 2秒。
• 利用率（U）：用于表示一个资源（Resource）处于“忙”时的时长所占的比例。利用率是用来衡量各类资源（人力资源或信息系统资源）有效性的客观指标，较高的利用率表示资源被充分利用，不过这也可能标志着性能瓶颈的所在。一般状况下，咱们能够经过增长资源的容量来突破性能瓶颈，不过这也可能导致资源的利用率降低，从而造成浪费。因而可知，不一样的性能指标相互制约，于是在他们之间如何权衡是决策过程的重点所在，而经过基于企业架构模型的量化分析，各干系人能够在一个信息充分的基础上进行决策，从而保证决策的正确性。

      在明确了此企业架构量化分析方法所采用的视角、输入与目标性能指标以后，咱们再来了解一下此方法的算法逻辑：

      上图展现了一个较为完整的企业架构层次模型。这一模型自下而上涵盖了技术、应用和业务这三个领域，不一样的领域之间经过“使用”关系进行链接，即位于下方的领域为处于上访的领域提供各类服务。每一个领域的内部又被细分为两个层次，而在这两个层次中，位于上方的层次包括了此领域对外所能提供的各类服务，而处于下方的层次则包括了实现本领域服务的各类内部实现元素。须要注意的是，上图所展现的是一个企业架构量化分析方法所适用的较为完整的企业架构层次模型，但这并不意味这该分析方法只能针对这种跨越三个领域（业务、应用和技术）的企业架构模型进行分析，实际上在输入信息充分的状况下，此方法也能够适用于跨域两个领域，甚至是仅有一个领域的状况下。此外，虽然图中不一样层次之间相互叠加遮掩，好像只有相邻的两个领域之间才会有直接的“使用”关系，但在实践过程当中跨层次的“使用”关系是家常便饭的，例如业务流程既可使用应用领域提供的应用服务，也可使用技术层所提供的基础设施服务。

      本章介绍的企业架构量化分析方法的计算过程能够分为两个步骤：

• 首先是按照自上而下的顺序（业务—>应用—>技术）未来源于外部的工做负载（到达频率f，例如600个客户请求/天）换算为每一个层次中各个节点的被访问频率，即计算出每一个节点的到达频率。其计算公式为：

      此公式用于计算某个节点a的使用频率，即单位时间内被使用的次数。在公式中：

• ：用于表示某个节点a的总使用频率。

• ：用于表示此节点a自己的到达频率，即除了被其余节点所使用或访问以外，节点a在单位时间内被使用的频率。

• ：用于表示其余节点中对节点a进行直接使用或访问的节点序列的长度。

• ：用于表示其余节点中对节点a进行直接使用或访问的某个具体节点。

• : 用于表示节点a与对其进行直接使用或访问的某个节点之间的使用或访问关系的“使用次数权重”。

• ：用于表示其余节点中对节点a进行直接使用或访问的某个具体节点的总使用频率。

      因而可知，虽然此公式看起来较为繁琐，实际上其意义却较为直白，即任意一个节点的总使用频率等于其自己的到达频率与对其进行直接使用或访问的其余节点各自的总使用频率在通过“使用次数权重”加权后的总和。

• 而后按照自下而上的顺序（技术—>应用—>业务），以每一个节点的到达频率f和服务时间S为基础计算出每一个节点的响应时间R、处理时间T和利用率U。在此过程当中所涉及到的公式包括：

             此公式用于计算某行为元素节点a的处理时间，即该行为元素节点处理某一事务所消耗的时间（不包括等待其所使用的其余行为元素节点在处理同一事务时所消耗的时间）。在公式中：

• ：用于表示行为元素节点a的处理时间。
• ：用于表示行为元素节点a的服务时间。
• ：用于表示行为元素节点a所使用的其余行为元素节点序列的长度。
• ：用于表示行为元素节点a所使用的某个具体行为元素节点。
• ：用于表示行为元素节点a与其所使用的某行为元素节点之间的使用关系的“使用次数权重”。
• ：用于表示行为元素节点a所使用的某行为元素节点的响应时间。

           因而可知，任意一个行为元素节点的处理时间等于其所使用的各行为元素节点的响应时间通过“使用次数权重”加权后所得结果与其自己服务时间的总和。因为在计算性能指标时采用的是自下而上的方式，于是首先被计算的是处于最下层的基础设施行为元素的处理时间，而在这一过程当中，因为这些首先被计算的基础设施行为元素并不使用其余任何行为元素，因此他们的处理时间应与服务时间相等。

            在得到行为元素节点的处理时间后，咱们须要经过上面的公式计算分配到该行为节点的资源节点的利用率。在公式中：

• ：用于表示资源节点r的利用率。
• ：用于表示分配到资源节点r上的各行为元素的数量。
• ：用于表示分配到资源节点r上的某行为元素。
• ：用于表示分配到资源节点r上的某行为元素的总使用频率。
• ：用于表示分配到资源节点r上的某行为元素的处理时间。
• ：用于表示资源节点的容量。

           因而可知，资源节点的容量和其利用率成反比，这意味着若是在资源的利用率太高而成为性能瓶颈的状况下，提升资源的容量能够解决这一问题，不过过度提升资源的容量也会致使其利用率的降低，从而导致浪费的产生。

             行为元素节点的处理时间和资源利用率是决定其响应时间的两个主要因素，于是在经过以上的公式得到这两个参量的值以后，咱们须要对行为元素节点的响应时间进行考量。在公式中：

• ：用于表示行为元素节点a的响应时间。
• ：用于表示以节点a和相应的资源节点 的各项性质（基本为节点a的处理时间和资源节点 的利用率）为变量的用以计算其响应时间的函数。

           须要注意的是，这里并无给出具体的响应时间计算公式，而是代替以函数，这是由于各个节点在事务处理中的各异性致使没法采用统一的计算公式。例如，若是某个节点对于事务处理的数学模型符合M/M/1队列(对于节点a的访问频率符合泊松分布，且此节点的处理时间的统计特性知足指数分布)模型，那么此函数的具体表现形式就应为（其中， 为节点a的处理时间，而为此节点所关联的资源的利用率），而若是节点的处理时间的统计特性不知足指数分布，那么此函数就可能须要采用M/G/1队列模型来进行表述了。须要注意的是，采用各类数学模型对节点进行建模并非惟一办法，咱们还能够结合诸如模拟技术等其余更为详尽的技术来对其进行计算。

 

4.2.2 量化分析方法示例

      为了详尽阐述企业架构量化分析方法，本章以《Enterprise Architecture at Work》中的企业架构量化分析方法示例为蓝本，对此分析方法的使用进行演示。在进行分析以前，咱们先来了解一下示例的相关背景：有一家保险公司将文档管理系统做为其中心办公系统，公司中的多个部门都使用此系统进行办公，那么在已知工做负载和各系统的处理能力的状况下，此文档管理系统以及其余的系统或服务的性能指标如何？是否存在性能瓶颈，以及如何突破这些瓶颈呢？经过企业架构的量化分析方法，咱们能够对以上问题具备明晰的认识。

      上图所示的企业架构模型视图对该保险公司的平常运行状况做了描述。为了对其中的各个元素节点计算其性能指标，此视图中还对各类输入信息进行了标注：

• 在“索赔处理流程”和“索赔提交流程”这两个业务流程之上分别标注了各自的事务到达频率：600次/天和200次/天。
• 对于每一个服务元素则标注了其服务时间S。
• 在视图中的每条“使用”关系之上分别标注了各自的“使用次数权重”n。

      为了明确和简化企业架构量化分析方法的使用，除了上述的几项输入以外，咱们还要作以下的限定：

• 假设天天的工做时间是8小时，即上面输入的“600次/天”和“200次/天”这两个到达频率实际上为600次/8小时和200次/8小时。
• 每一个节点的事务处理数学模型采用M/M/1队列模型。
• 每一个相关资源节点的容量默认为1。

      在得到了如上的输入和限定后，咱们就能够按照下面所示的步骤进行此企业架构量化分析：

• 模型归一化处理。
• 自上而下的工做负载计算。
• 自下而上的性能指标计算。

4.2.2.1 模型归一化

      在实践过程当中，企业架构模型一般与前面所述的企业架构量化分析元模型并不相符，这是由于在建模过程当中建模人员常用各类抽象化规则来简化企业架构。例如，在一系列连续的由使用关系和实现关系组成的关系链能够被简化为关系链的两端元素经过一条使用关系而直接相连，以下图所示：

      在上图的示例中咱们能够看到：在处于左半边的模型中，“数据库管理系统”应用组件直接被“管理员”所使用，不过这样的模型很明显并不符合咱们正在讨论的企业架构量化分析方法元模型的要求，于是经过归一化处理后咱们获得了右侧的架构模型，二者具体含义并没有太大差异，只不过通过归一化的模型知足了此量化分析方法的要求，而且具有更加详尽的信息。

因而可知，所谓的模型归一化操做就是以此企业架构量化分析方法的元模型为基准，对须要进行性能指标考量的企业架构模型进行转换，其实可以符合分析方法的模型要求。就本章节的示例来讲，将此示例图中所示的模型进行归一化后咱们能够获得以下的模型：

      相对于原始的示例模型，此归一化后的模型所作的修改主要在于对内部行为元素的添加。从上图咱们能够看出，原来的资源节点并不对外部服务进行直接的实现，而是经过分配关系为每一个资源节点关联了新添加的用于表示其内部行为的功能概念元素，而且这些内部行为元素与相应的服务元素之间的实现关系也替代了原来的资源节点和服务元素之间的直接实现关系。此外，原来资源节点与其所使用的服务元素之间的使用关系也被转移到内部行为元素之上。须要注意的是，新添加的各内部行为元素节点及相关的使用或访问关系都须要分别注明服务时间和相应的使用次数权重，这其中，服务时间应与其所实现的外部服务元素的服务时间相同，而因为内部实现元素继承了原资源元素针对其余服务的使用和访问关系，因此使用次数权重也与之相同。经过以上的转换，当前通过归一化的模型符合了前面所提到过的企业架构量化分析方法元模型，但这仅仅是一个示例，并不意味着全部的非归一化模型都要遵守这个规则来进行转化，这是由于原始模型所具有的多样性，而这一规则也只是较为常见归一化规则之一，但不管采用何种规则，其最终目的都是要使进行计算的模型符合此量化分析方法的元模型。

 

 

4.2.2.2 工做负载计算

      在得到归一化的模型以后，接下来咱们须要将最上层所承担的工做负载自上而下地传递给下面的各个层次。在进行计算以前，咱们须要再次对此步骤所需的输入和限制进行明确：

• 工做负载来源于最上层，即索赔处理流程和索赔提交流程这两个业务流程的到达频率（分别为600件/天和200件/天）。
• 工做时间为8小时而不是24小时，因此上述的到达频率可分别换算为：

      下表展现了不一样的资源元素所提供的服务元素在前述的工做负载下所承担的工做负载（须要注意的是，与《Enterprise Architecture at Work》中的相应示例相比，本示例中有关的计算结果与原书中的计算结果0.0278不一致，并由此致使了的计算结果也出现了不一致的状况。笔者怀疑原书中的这两个结果与其所示的模型并不相符，若是当“损害报告搜索服务”被索赔处理流程和索赔提交流程这两个流程所共同使用，且其与索赔提交流程之间使用关系的使用次数权重 时会得出0.0278这样的结果，但若是这一结果成立，那么最终的就会由于的改变而由0.02777变为0.0347，这又与原书示例结果相矛盾，于是再一次证明了书中示例的计算结果之间存在矛盾）：

 

4.2.2.3 性能指标计算

      量化分析方法的最后一步采用自下而上的方式，对各个资源节点以及相应的行为元素节点的利用率、处理时间和响应时间进行计算。在进行计算以前，咱们须要再次明确一下必要的输入和限制：

• 每一个行为元素（服务元素和内部行为元素）都须要注明其服务时间。
• 每一个元素节点的工做负载应已在上一步计算中得到。
• 每一个资源元素节点的容量应已经肯定。本示例中，每一个资源节点的容量均默认为1。
• 每一个行为元素节点的事务处理数学模型应已经肯定。在本示例中，每一个行为元素节点的事务处理数学模型均采用M/M/1队列模型。

      本示例中各个元素节点的性能指标以及计算过程总结以下：

      从上表中咱们能够看出，因为资源的容量有限，因此其所分配的行为元素的处理时间会小于响应时间，而且在资源处在高利用率的状况之下，这二者之间的差异还可能会很是大，例如对于“查看组件”来讲，其利用率达到84.4%，而同时其响应时间达到了处理时间的6倍以上，这也印证了虽然资源利用率高代表资源被充分利用，不过这同时也很是多是性能的瓶颈所在，经过增长资源的容量能够改善这个问题，可是也可能致使浪费的产生，于是这二者之间须要作好权衡，但无论如何权衡，这种分析方法起码赋予了决策者更好的洞察力，使其决策更加有理有据。

      除了针对一套输入数据进行分析以外，咱们还能够经过编制不一样的输入数据而获取相应的分析结果，从而对某个性能指标随输入的变化而产生变化的趋势进行更为直观的观察。下图来源于《Enterprise Architecture at Work》中图8.8，他展现了索赔处理流程的不一样到达频率与查看组件的响应时间之间的关系：

      如图所示，当索赔处理流程的事务到达频率达到大约651件/天时，查看组件的相应时间趋近无穷，这就证实在此种状况下该组件的利用率已经达到满负荷的100%，这也代表了此组件在当前容量下的处理极限。在此，咱们能够惊喜的发现业务中的问题和IT方面的支持能力有了量化性的关联，而这种跨领域的联系也正是此量化分析方法甚至是企业架构精神的最佳体现。

 

4.3 功能性分析方法

      从分析目标来看，针对企业架构的功能性分析方法能够细分为静态分析和动态分析两种，前者分析的目标是企业架构的结构关系，然后者则是针对架构所描述的各类行为进行分析。相对于量化分析方法，用于分析架构基本结构和行为的方法长期以来一直是各架构分析方法的重点，不一样的组织已为其贡献了不少很是成熟的分析方法，并且这其中的每一个方法都须要耗费一部整书的篇幅才能描述清楚，于是本节只能对其中具备表明性的方法进行列举，详细内容还须要有兴趣的读者进一步阅读。

      静态分析是以企业架构的结构组成为目标的功能性分析方法，于是其分析主体是各类概念元素以及他们之间的结构关系，而这其中最具表明性的就当数影响分析了（Impact-of-change analysis）。顾名思义，影响分析是以因为变化而产生的影响为分析目标的功能性分析方法，这是一种通用性的分析方法，而并非企业架构所独具的。据笔者考证，影响分析首先是被 Bohner 和 Arnold在1996年于《Software Change Impact Analysis》中所定义的，从书名咱们就能够看出，该分析方法起源于软件设计领域，是用来对软件设计中的变动所产生的影响进行界定的方法。不过此书对于变动影响分析的定义却有着更为宽泛的含义，即变动影响分析旨在明确变动所可能产生的潜在结果，并对为了适应变动所应做的修改进行估计。因而可知，这必定义并无绑定软件设计这一领域，因此将此分析方法放在企业架构中也应该是适用的。

      《Enterprise Architecture at Work》对变动影响分析在企业架构中的应用作了简要的描述，其中心思想在于：以发生变化的结构元素为起点，沿着结构型关系进行搜索，寻找与其发生关联的受到影响的各个结构性元素，再以这些结构性元素为起点，沿着以前的结构关系方向重复这个搜索过程，直到全部受影响的结构性元素被搜索出来为止。书中还经过一个示例形象化地描述了变动影响分析在企业架构方面的应用：有一个保险公司在销售保险的过程当中除了本身销售外还经过第三方的代理来进行保险推销，这些代理的工做也只在于向客户推销保险产品，并保证保险合同签署以前各类文件工做的正确性。目前该公司考虑可否抛开这个代理的角色，但又不知道如此会产生什么样的影响。

      诚然这种事情的影响是没法精确估计和定义的，由于这其中包括了各类没法估计的有形和无形的影响，可是经过对企业架构进行影响分析，公司至少仍是能对从业务到IT各层面中的有形的结构性影响有所认识。如下三张视图就对这种影响进行了展现：

变动影响示例—视图1

变动影响示例—视图2

变动影响示例—视图3

      以上三张视图中：第一张视图展现了因为业务角色“第三方代理”发生变化而受到影响的业务合做集合“洽谈”和“合同订立”；第二张视图展现了“合同订立流程”中因为变动而受到影响的业务交互“规范化申请”和“检查并签署合同”；最后一张视图展现了在应用层面进而受到影响的应用服务“客户管理服务”和应用组件“客户关系管理系统”。虽然这三张视图分别展现了受到变动影响的各个结构元素，可是这并不意味着全部的影响都被这三张图所涵盖了，由于视图是视角的具体表现内容，其所反映的只是企业架构的某一个方面的内容，于是对于变动影响结果的展现须要站在相关干系人视角的基础之上。实际上《Software Change Impact Analysis》根据所分析的目标对象的不一样，将变动影响分析方法分为可追溯性方法和依赖性方法两种，前者着眼于需求、规范、设计元素和相关测试之间的关系，然后者则关注于程序模块、变量和逻辑等之间关系，这实际上也是站在不一样视角对于变动分析方法的具体应用，与企业架构的视角精神是一致的。于是在实践过程当中，咱们的企业架构分析方法应该不是一个具备惟一形式的分析方法，根据视角的不一样，此分析方法所实际关注的概念元素和关系应该是有所区别的。

      与静态分析方法不一样，动态分析方法将企业架构的行为做为分析目标。目前，在各个领域（例如业务领域）中已经存在了不少成熟的动态分析方法。借助于这些方法，咱们也能够对企业架构中的某一领域进行深刻分析，并根据企业架构的跨领域特性，将分析结果延展到企业架构的其余领域以内。这其中常常用到的就是进程代数（Process algebra）和数据流网络（Data flow network）分析方法。经过这些动态分析方法，咱们能够对企业架构的正确性加以验证，也可使干系人对企业架构的行为得到更为深刻的共识。