企业架构研究总结（21）——TOGAF架构开发方法（ADM）之业务架构阶段

1.3 业务架构（Business Architecture）

企业架构开发方法各阶段——业务架构

 

1.3.1 目标

• 描述基线业务架构
• 开发基于原则、业务目标和策略驱动力的目标业务架构，描述产品和/或服务策略，以及业务环境在组织、功能、过程、信息和地理这些方面的内容
• 分析基线和目标业务架构之间的差距
• 选择和开发相关的架构视角，通过这些视角架构师可以阐述业务架构是如何对各干系人的关注点进行解答的。
• 选择与选中的视角相关的工具和技术

 

1.3.2 方法

      针对业务架构的了解是进行其他领域（数据、应用和技术）架构工作的前提条件，因而如果不是因为组织中其他一些诸如企业规划、业务战略规划以及业务流程再造等方面流程，针对业务架构的制定应该是要首选进行的架构活动。业务架构是用来将其后架构工作的业务价值阐述给相关干系人所必不可少的工具，它也可用来为各个支持和参与后续架构工作的干系人阐明企业架构的投资回报。在实践过程中，业务架构的关键元素也许已经在其他工作中被明确，而在这种情况下，组织就需要验证和更新当前已经文档化的业务战略和规划，并/或在已经明确的业务驱动力、业务战略、目标与架构开发工作相关的特定业务需求之间建立关联。而在另外一种情况下，业务架构工作也许并没有或者很少被执行，而这就需要架构团队研究、验证架构将要支持的各个关键业务目标和流程，并获得相关干系人的认同。然而不论处在以上哪种情况，TOGAF ADM的业务情景技术，或者是其他用来阐明关键业务需求以及为IT架构指明其技术需求的方法，都需要被纳入到架构师的工具箱之中。

      需要注意的是，在架构活动中应尽量重用各种已经存在的材料，并且针对信息的收集和分析也应该依据架构工作的范围而采用那些能够促成明智决策的信息。如果架构活动关注于业务流程的定义，则在此阶段组织需要在此方面进行很多细致的工作，而如果关注点更着重于其他领域（数据/信息、应用系统和基础设施）中的目标架构，那么组织就需要在这个阶段构建一幅无需包含众多非必要细节的全景图。

      除此之外，在此阶段所涉及到的方法还包括：

开发基线描述

      如果企业中已经存在了架构的描述，那么他们可以被用来作为基线描述的基础。这些输入可能在架构愿景阶段中已被用来开发架构愿景，但对于基线描述来说应该也是够用的。而如果这些描述并不存在，组织就需要从各种渠道对这些信息进行收集。针对目标架构的开发通常是采用自上而下的方法，而对基线描述来说，针对当前状态的分析经常是自下而上的，特别是当只有很少或没有架构资产存在时。在这种情况下架构师需要记录关于高层次框架的工作假设，并逐步收集能够将这些工作假设转变为现实的证据。

业务建模

      业务模型是架构愿景中各业务情景的逻辑扩展，架构可以借此将高层次的业务需求细化为更详细的需求。在实践中存在着一系列建模工具和技术可以供组织选择使用，例如：

• 活动模型（Activity Models）：活动模型也称为业务流程模型（Business Process Model），他描述了各种与组织业务活动相关的功能、活动之间进行交换的数据和/或信息（内部交换）以及与模型范围之外的其他活动进行交换的数据和/或信息（外部交换）。活动模型在本质上是具有层次型结构的，它涵盖了在业务流程中所进行的各种活动，以及这些活动的输入、控制、输出和所使用的机制或资源（ICOMs：inputs，controls，outputs，and mechanism/resources），并且各种用于描述ICOMs之间关系的业务规则也可被明确地标注在业务模型之中。当前在业界存在着多种用来构建活动模型的技术，其中之一就是IDEF（Integrated Computer Aided Manufacturing （ICAM）DEFinition）建模技术。除此之外，OMG（The Object Management Group）也开发了BPMN（Business Process Management Notation）标准，用于为业务流程建模提供一种标准性语言。
• 用例模型（Use-Case Model）：依据建模关注点的不同，该模型既可以用来描述业务流程也可以描述系统功能，并且它可以从用例、与业务流程相关的角色以及组织参与者的角度来对企业的业务流程进行描述。通常情况下，用例模型是通过用例图和用例说明来进行表述的。
• 类模型（Class Models）：此模型与逻辑数据模型相类似，主要用于描述静态的信息以及这些信息之间的关系。除此之外，类模型还可被用来描述信息的行为。与其他各种模型类似，类模型也是可以在多种粒度层次上进行模型建设的。根据建模意图的不同，类模型既可以用来表达各种业务领域实体，亦可以被用来描述各个用于进行系统实现的类。一个业务领域模型表达了关键的业务信息、他们的性质、行为和关系。类模型的描述通常通过类图进行表现，不过更加详尽的说明和信息将被记录在额外的说明文档之中。

      以上三种模型都可以通过统一建模语言（UML：Unified Modeling Language）来进行描述，并且在现实生活中存在着很多可以生成这些模型的工具。除了这些通用性的模型之外，每个行业也有着符合自身特点的各种模型和建模技术。以国防部门为例，如下几种模型就是比较有代表性的（需要注意的是，虽然这些模型源于国防部门，但是在其他政府部门中也逐渐得以采纳，而对于非政府环境来说也具有借鉴意义）：

• 节点连接图（Node Connectivity Diagram）：描述了业务位置（即节点）、业务位置之间的需求关系以及节点间所交换的信息的性质。该模型可以在三种层次之上进行描述，即概念层次、逻辑层次和物理层次。每条节点之间的需求连线代表其所连接的两个节点之间对于信息传输的需求，而每个节点则用来代表一个角色、组织单位、业务位置或设置等。标注在连线上的箭头用于表示信息流的传输方向，而箭头附近的标注则被用来描述所传输的数据或信息的性质（例如，内容、媒介、安全或分类等级、时限和信息系统互操作需求等）。
• 信息交换矩阵（Information Exchange Matrix）：记录企业架构的信息交换需求。信息交换需求表述了三种基本实体（活动、业务节点和他们的元素、信息流）之间的关系，并着眼于信息交换的各种特性（例如性能和安全性）。简单来说，该模型表述了什么人与其他何人交换何种信息，这些信息的必要性以及信息交换的形式。

使用架构资源库

      在这一阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与业务架构相关的资源可供使用，特别是在如下几个方面的资源：

• 组织所在行业的通用业务模型（存储在架构资源库的参考资料库中）。前面提到过的联邦企业架构业务参考模型就是个很好的例子。
• 与在IT行业发布的通用高层次业务领域（例如电子商务、供应链管理等）相关的业务模型，例如主要用于财会系统建模的REA（Resource-Event-Agent）业务模型和关注于产品设计和供应链交互方面的STEP（Standard for the Exchange of Product model data）框架。
• 企业特定的构建块（流程组件、业务规则、工作描述等）。
• 各种适用的标准。

1.3.3 输入与输出

      在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

输入	参考资料	架构参考资料
	非架构性输入	架构工作要求书
		业务目标、原则和驱动力
		能力评估
		沟通计划
	架构性输入	企业架构组织模型，包括： 受影响的组织范围 成熟度评测、差距及解决方法 架构团队所担当的角色和职责 架构工作的约束 预算需求 治理和支持策略
		定制的架构框架，包括： 定制的架构方法 定制的架构内容（交付物和制品） 配置和部署工具
		批准的架构工作说明书
		架构原则，包括业务原则（如果事先存在的话）
		架构连续体
		架构资源库，其内容包括： 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准
		架构愿景，包括： 经过改善的关键高层次干系人的需求 基线业务架构0.1版 基线技术架构0.1版 基线数据架构0.1版 基线应用架构0.1版 目标业务架构0.1版 目标技术架构0.1版 目标数据架构0.1版 目标应用架构0.1版
输出	经过改善和更新的架构愿景阶段中的各交付物，包括： 架构工作说明（如有需要，进行修改） 经过验证的业务原则、目标和驱动力（如有需要，进行修改） 架构原则（如有需要，进行修改）
	架构定义文档草案，包括： 基线业务架构1.0版本 目标业务架构1.0版本，具体包括： 组织结构 业务目标 业务功能 业务服务 业务流程，包括评测和交付物 业务角色，包括相关技能需求的发展与改进 业务数据模型 组织和功能之间的相互关联 代表相关干系人关注点的视角下的各种视图
	架构需求说明草案，包括： 差距分析结果 技术需求，用于对其余架构领域中工作的含义进行识别、分类和优先级评定 更新的业务需求
	架构路线图的业务架构组件

1.3.4 步骤

      在当前阶段中所要执行的各个步骤归纳如下：

• 选择参考模型，视角和工具
• 开发基线业务架构描述
• 开发目标业务架构描述
• 进行差别分析
• 定义架构路线图组件
• 通观整个架构景观来明确和解决相关影响。
• 进行正式的干系人审查
• 最终确定业务架构
• 创建架构定义文档