本章描述了业务架构的开发，以支持商定的架构愿景。
4.1 目标
B阶段的目标是：
- 开发目标业务架构，描述企业需要如何运营以实现业务目标，以及 响应架构愿景中规定的战略驱动因素，以解决架构工作声明的方式和 利益相关者关注的问题
- 根据基线和目标业务架构之间的差距确定候选架构路线图组件
4.2 输入
本节定义阶段 B 的输入。
- 架构参考资料
- 架构工作请求
- 业务原则、业务目标和业务驱动因素
- 能力评估
- 沟通计划
- 企业架构的组织模型，包括：
- 受影响的组织范围
- 成熟度评估、差距和解决方法
- 架构团队的角色和职责
- 体系结构工作的约束
- 预算需求
- 治理和支持战略
- 定制架构框架，包括：
- 量身定制的架构方法
- 定制的架构内容（可交付成果和工件）
- 已配置和部署的工具
- 批准的架构工作声明
- 架构原则， 包括业务原则，如果预先存在
- 企业连续体
- 架构存储库， 包括：
- 可重复使用的构建块
- 公开可用的参考模型
- 组织特定的参考模型
- 组织标准
- 架构愿景， 包括：
- 问题描述
- 建筑工作声明的目标
- 摘要视图
- 业务场景（可选）
- 细化了高级别利益相关者的关键要求
- 架构定义文档草案，其中可能包括任何架构领域的基线和/或目标架构
4.3 步骤
阶段B中所涉及的详细程度将取决于整个体系结构工作的范围和目标。
描述业务需求的新模型需要在阶段B中详细定义。要在目标环境中继承和支持的现有业务工件可能已经在以前的体系结构工作中充分定义；但是，如果没有，它们也需要在阶段B中定义。
阶段B中步骤的顺序以及它们正式开始和完成的时间应根据既定的体系结构治理，适应当前的情况。特别是，确定在这种情况下，是否适合首先进行基线或目标体系结构开发。
在这些步骤中启动的所有活动都应在最终确定业务体系结构步骤期间关闭（请参见4.3.8最终确定业务架构）。从这些步骤生成的文档必须在创建/更新体系结构定义文档步骤中正式发布
阶段 B 中的步骤如下：
- 选择参考模型、视点和工具
- 开发基线业务架构说明
- 开发目标业务架构描述
- 执行差距分析
- 定义候选路线图组件
- 解决整个体系结构环境的影响
- 进行正式的利益相关者审查
- 完成业务架构
- 创建/更新体系结构定义文档
从架构存储库中选择相关的业务架构资源（参考模型、模式等），在 业务驱动因素和利益相关者关注点的基础。
选择相关的业务架构观点（例如，运营、管理、财务）;即那些将启用 架构师，以演示如何在业务架构中解决利益相关者的关注点。
确定用于捕获、建模和分析的适当工具和技术，并与选定的 观点。根据所保证的复杂程度，这些可能包括简单的文档或电子表格，或更多 复杂的建模工具和技术，例如活动模型、业务流程模型、用例模型等。
业务建模和战略评估是构建组织业务目标状态的有效技术 体系结构。该活动的输出为 然后用于阐明缩小 当前状态和目标状态。如3.5方法所述，这些地图的框架 可能已经存在，应该加以利用，现在使用它们来描述差距并更好地映射业务价值以实现目标 业务架构。
对于每个视点，使用所选工具或方法选择支持所需特定视图所需的模型。
确保涵盖所有利益相关者关注的问题。如果不是，请创建新模型来解决未涵盖的问题，或增加 现有模型（请参阅 4.5.7 应用建模技术）。业务场景是一种有用的技术 发现和记录业务需求，并且可以在层次结构中的不同详细级别迭代使用 业务架构的分解。业务场景在 TOGAF® 系列指南：业务场景中描述。
4.5 方法中描述的技术可用于逐步分解业务：
- 业务能力图：对业务所需的业务能力进行识别、分类和分解 有能力为一个或多个利益相关者提供价值
- 信息映射：收集对业务最重要的信息概念及其关系
- 组织映射：表示业务（包括第三方域）的组织结构， 描述业务部门、将这些部门分解为较低级别的职能以及组织关系 （单元到单元并映射到业务功能、位置和其他属性）
- 流程建模：阐明企业业务流程的活动，以实现分析和 起色
- 结构化分析：确定体系结构范围内的关键业务功能，并映射这些功能。 业务职能和业务内组织单位的能力
- 用例分析：一种用于从用户的 透视
- 价值流图：组织为创造价值而执行的活动的端到端细分 与利益相关者交流
价值流图说明了组织如何交付价值，并在一组特定的利益相关者的背景下，以及 利用业务能力创造利益相关者价值，并与目标业务的其他方面保持一致 建筑。
所需的分解水平和严格程度因企业而异，也因企业内部而异，并且 架构师应考虑企业的目标、目的、范围和目的 企业架构工作 确定 分解级别。
目录捕获业务核心资产的库存。目录本质上是分层的，并捕获 构建块的分解以及相关构建块（例如，组织/参与者）的分解。
目录构成了开发矩阵和视图的原材料，也是管理业务的关键资源 和 IT 能力。
TOGAF 标准 — 架构内容包含 在业务架构中应考虑开发的目录，详细描述它们并将其与 TOGAF 企业元模型中的实体、属性和关系。
矩阵显示相关模型实体之间的核心关系。
矩阵是发展观点的原材料，也是影响评估的关键资源，作为 差距分析的一部分。
TOGAF 标准 — 架构内容包含 在业务架构中应考虑开发的矩阵，详细描述它们并将其与 TOGAF 企业元模型中的实体、属性和关系。
图表根据 利益相关者的要求。
TOGAF 标准 — 架构内容包含 在业务架构中开发应考虑的图表，详细描述它们并将其与 TOGAF 企业元模型中的实体、属性和关系。
一旦开发了业务架构目录、矩阵和图表，架构建模就完成了 正式确定实现目标体系结构的以业务为中心的需求。
这些要求可能：
- 与业务领域相关
- 为数据、应用程序和技术体系结构提供需求输入
- 提供在设计和实施过程中要反映的详细指导，以确保解决方案解决原始问题 体系结构要求
在此步骤中，架构师应确定架构应满足的需求。
在许多情况下，体系结构定义并不旨在为解决方案提供详细或全面的要求 （因为这些可以通过一般需求管理纪律更好地解决）。需求内容的预期范围 应在架构愿景阶段建立，并记录在批准的架构工作声明中。
超出架构工作声明中定义范围的任何要求或需求更改都必须是 提交到需求存储库，通过受治理的需求管理流程进行管理。
在支持目标业务所需的范围内，制定现有业务架构的基线描述 建筑。要定义的范围和详细程度将取决于现有业务元素的可能程度 延续到目标业务架构中，以及是否存在架构描述，如 4.5 方法中所述。尽可能确定相关的业务架构构建块，利用 架构存储库。
如果需要开发新的体系结构模型以满足利益相关者的关注点，请使用步骤 1 中确定的模型作为 创建新体系结构内容以描述基线体系结构的指南。
在支持架构愿景所需的范围内，为业务架构制定目标描述。这 要定义的范围和详细程度将取决于业务元素与实现目标体系结构的相关性 愿景，以及是否存在建筑描述。尽可能确定相关的业务架构 构建块，利用架构存储库。
如果需要开发新的体系结构模型以满足利益相关者的关注点，请使用步骤 1 中确定的模型作为 创建新体系结构内容以描述目标体系结构的指南。
如果合适，调查不同的目标体系结构备选方案，并使用体系结构备选和权衡技术与利益相关者讨论这些方案。
验证架构模型的内部一致性和准确性：
- 执行权衡分析以解决不同视图之间的冲突（如果有）
- 验证模型是否支持原则、目标和约束
- 注意对架构存储库和文档中所选模型中表示的视点的更改
- 根据需求测试架构模型的完整性
使用差距分析技术确定基线和目标之间的差距。
在创建基线架构、目标架构和差距分析结果之后，需要业务路线图 确定未来各阶段活动的优先次序。
此初始业务架构路线图将用作原材料，以支持对合并的更详细定义， 机会和解决方案阶段的跨学科路线图。
一旦业务架构最终确定，就有必要了解任何更广泛的影响或影响。
在此阶段，应检查体系结构环境中的其他体系结构工件，以确定：
- 此业务架构是否会对任何预先存在的架构产生影响？
- 最近是否进行了对业务架构产生影响的更改？
- 是否有机会在组织的其他领域利用此业务架构的工作？
- 此业务架构是否会影响其他项目（包括计划的项目以及正在进行的项目）？
- 此业务架构是否会受到其他项目（包括计划的项目以及当前项目）的影响 进度）？
检查架构项目的原始动机和针对拟议业务的架构工作声明 架构，询问它是否适合支持其他架构领域的后续工作。细化 仅在必要时提出业务架构。
- 为每个构建块选择标准，尽可能多地重用从 架构存储库
- 完整记录每个构建基块
- 根据业务目标对整体架构进行最终交叉检查;记录构建块决策的基本原理 在体系结构文档中
- 记录最终需求可追溯性报告
- 记录架构存储库中架构的最终映射;从选定的构建基块中，标识 那些可能被重用的（工作实践、角色、业务关系、职位描述等），并通过 架构存储库
- 完成所有工作产品，例如差距分析结果
- 在体系结构定义文档中记录构建块决策的基本原理
- 准备架构定义文档中与预期范围和用途相关的相应业务部分 建筑
如果适用，请使用建模工具生成的报表和/或图形来演示体系结构的关键视图。路由 文档供相关利益相关者审查，并纳入反馈。
4.4 输出
阶段B的输出可能包括但不限于：
- 架构愿景阶段可交付成果的改进和更新版本（如适用），包括：
- 架构工作声明，必要时更新
- 经过验证的业务原则、业务目标和业务驱动因素，必要时进行更新
- 架构原则
- 架构定义文档草案，包括：
- 基线业务架构，已批准（如果适用）
- 目标业务架构，已批准，包括：
- 组织结构 — 确定业务位置并将其与组织单位相关联
- 业务目标和目的 — 针对企业和每个组织单位
- 业务功能 — 一个详细的递归步骤，涉及将主要功能区域连续分解为 子函数
- 业务能力 — 企业为实现其目标而需要拥有或交换的能力
- 业务服务 — 通过封装独特的“业务行为元素”来支持业务的服务;一个服务 在企业外部提供的业务服务可能得到支持
- 产品 — 企业向客户提供的产出;产品包括材料和/或服务
- 业务流程，包括度量和可交付成果
- 业务角色，包括技能要求的开发和修改
- 业务数据模型
- 组织/业务职能与业务能力的关联 — 将业务能力与组织单位联系起来 以矩阵报告的形式
- 与解决主要利益攸关方关切的选定观点相对应的观点
- 架构需求规范草案，包括以下业务架构要求：
- 差距分析结果
- 技术要求 — 识别、分类和优先处理对其余架构中工作的影响 域;例如，通过依赖/优先级矩阵（例如，指导事务处理速度和 安全）;列出预期生产的特定模型（例如，表示为 Zachman 的基元 框架）
- 更新的业务需求
- 架构路线图的业务架构组件
TOGAF标准-体系结构内容包含了对这个阶段可能产生的体系结构工件的详细描述。
4.5 方法
业务架构是能力、端到端价值的整体、多维业务视图的表示 交付、信息和组织结构;以及这些业务观点和战略、产品、 政策、倡议和利益相关者。
业务架构将业务元素与其他领域的业务目标和其他元素相关联。
业务架构知识是在任何其他领域（数据、应用程序、 技术），因此是需要进行的第一个架构活动，如果已经在其他方面得到满足 组织流程（企业规划、战略业务规划、业务流程再造等）。
实际上，业务架构也经常是必要的，作为展示商业价值的一种手段 关键利益相关者的后续架构工作，以及这些利益相关者从支持和 参与后续工作。
阶段B的工作范围主要由阶段A中规定的架构愿景决定。业务战略 定义了目标、驱动因素以及成功的指标，但不一定是如何实现目标的。这就是企业的角色 架构，在阶段 B 中详细定义。
这在很大程度上取决于企业环境。在某些情况下，业务架构的关键元素可能 在其他活动中完成;例如，企业使命、愿景、战略和目标可能被记录为一些 更广泛的业务战略或企业规划活动，在企业内有自己的生命周期。
在这种情况下，可能需要验证和更新当前记录的业务战略和计划，和/或桥接 一方面是高级业务驱动因素、业务战略和目标，另一方面是特定的业务需求 与此体系结构开发工作相关。
在其他情况下，迄今为止可能很少或根本没有完成业务架构工作。在这种情况下，将需要 架构团队，研究、验证并获得对架构的关键业务目标和流程的支持 支持。这可以作为一项独立的练习来完成，无论是在架构开发之前，还是作为阶段 A 的一部分。
在这两种情况下，业务场景技术或任何其他方法 阐明关键业务需求并指示可以使用的IT架构的隐含技术要求。
一个关键目标是尽可能多地重复使用现有材料。在架构上更成熟的环境中，将有 现有的架构定义，（希望）自上一个架构开发周期以来一直保持。哪里 存在架构描述，这些可以用作起点，并在必要时进行验证和更新;
仅收集和分析允许做出与此体系结构范围相关的明智决策的信息 努力。如果这项工作集中在（可能是新的）业务流程的定义上，那么阶段B必然涉及 很多详细的工作。如果重点更多地放在其他领域（数据/信息、应用程序系统、 基础设施）以支持基本存在的业务架构，那么在阶段构建完整的画面非常重要 B不涉及不必要的细节。
如果企业已有体系结构描述，则应将其用作基线描述的基础。该输入可能已经在开发架构愿景的阶段A中使用过，例如3.5.2创建架构愿景中引入的业务能力图或核心价值流集，并且其本身可能足以满足该基线。
更新这些材料的原因包括缺少业务能力、新的价值流或改变了以前未在企业架构项目范围内进行评估的组织单位。4.5.3通过4.5.6应用业务能力应用信息映射解决了使用核心业务体系结构方法对由阶段A的战略范围驱动的业务体系结构进行建模的问题。注意，将这些方法付诸行动，以推动后续体系结构工作的重点和目标状态，并不意味着阶段A的基本框架，诸如通用企业业务能力映射之类的应用程序必然会发生变化，而是以特定企业体系结构项目的范围和需求驱动的方式应用它们。
如果不存在体系结构描述，则应收集信息并开发业务体系结构模型。
无论特定项目的范围是什么，重要的是要确定是业务的基本视图在变化，还是使用这些视图来确定特定项目相对于企业其他部分的范围、优先级和关系。
在体系结构愿景阶段找到或开发的业务能力图提供了业务的独立视图 独立于当前的组织结构、业务流程、信息系统和应用程序等 产品或服务组合。这些业务能力应该映射回组织单位、价值流、 企业架构项目范围内的信息系统和战略计划。此关系映射 更深入地了解每个域的对齐和优化。
另一种常见的分析技术涉及热图，可用于显示同一的一系列不同视角 一组核心业务能力。其中包括成熟度、有效性、性能以及每项能力的价值或成本 业务。不同的属性决定了业务能力图上每个功能的颜色。
例如，业务能力成熟度热图将特定能力的所需成熟度显示为绿色，一个级别 向下为黄色，向下为两级或更多级为红色。其他颜色可能表示状态，例如紫色表示 在公司中尚不存在，但需要，或者可能作为一种资金过剩且拥有更多资源的能力 必要。这种差距分析与正在进行的企业架构项目直接相关;差距仅在 业务需求的上下文，并在此阶段提供更多映射或后续体系结构阶段的优先级。
价值流为利益相关者提供了宝贵的背景信息，说明为什么组织需要业务能力，而业务 能力提供了组织在特定价值阶段取得成功所需的内容。
从体系结构愿景阶段中记录的业务价值流模型的初始集合开始。在特定企业架构项目的范围内，如果广度足够大，则可能需要存储库中尚未存在的新价值流。
新的或现有的价值流可以通过热图（按价值流阶段）在项目范围内进行分析，或者 通过围绕价值流的完整定义开发用例。项目可能侧重于特定的 利益干系人，业务价值的一个要素，或强调某些阶段而不是其他阶段，以制定更好的解决方案要求 后期阶段。
最实质性的好处来自于将价值流中各个阶段之间的关系映射到业务能力， 然后在价值实现的业务价值的上下文中对功能（如热图）执行差距分析 特定利益相关者的流
组织地图显示构成企业生态系统的关键组织单位、合作伙伴和利益干系人组。 地图还应描述这些实体之间的工作关系，这与仅 显示分层报告关系。地图通常被描述为关系和交互的网络或网络 在各个商业实体之间（见明茨伯格和范德海登的《组织图：绘制公司如何真正运作》）， 1999).
业务部门是用于建立组织地图的主要概念。与相对不受约束的观点保持一致 构成企业，企业可以是正在进行的项目的一个业务单位，可以包括所有业务单位， 或还包括第三方或其他利益相关者群体。解释取决于体系结构工作的范围。
此地图是业务架构的关键元素，因为它为整个企业提供了组织上下文 架构工作。虽然能力映射揭示了企业的工作，而价值流映射揭示了它如何提供价值 对于特定的利益干系人，组织将拥有或使用这些标识的业务部门或第三方映射标识 能力，并参与价值流。
结合4.5.3应用业务能力、4.5.4应用价值流和相关指南中的方法，组织图提供了对哪些业务单元参与架构工作、谁和何时讨论给定需求以及如何衡量各种决策的影响的理解。
在业务架构阶段表征信息从对业务最重要的元素开始，例如 产品、客户、工厂等通过这些关键元素的列表，跨学科团队可以列出和映射以下信息： 最重要的以及如何使用业务术语来描述它。信息域可以派生自以下分组或类别： 商业术语在逻辑上属于。这些域是开始信息图谱完整性和最高性的好地方 值，然后再继续了解数据类型的详细信息。
然后，可以将信息域之间的关系添加到地图中，作为良好基线的下一个理解级别 信息地图。因此，最显著的好处是在信息和业务能力之间构建矩阵。这 对业务最重要的信息与描述应用能力的业务功能之间的链接 创造价值的信息是业务架构的一个关键方面。这些信息映射和与业务的关系 然后，功能将应用于数据表征、应用程序和基础结构的后续体系结构阶段。
此处提供的建模和映射技术是实现业务功能、价值流和 上述阶段 B 中描述的组织映射到业务实践中。他们扩展了运营模式，这是一个 表示组织如何跨一系列领域运作以实现其目的（请参阅 确定流程重用机会以增强运营模式，M. de Vries 等人）。
除了上述技术（能力图、价值流和组织图）之外，还有各种其他技术 如果认为合适，可以采用建模技术。例如：
- 活动模型（也称为业务流程模型）描述了企业的业务活动、数据 和/或活动之间交换的信息（内部交换），以及与其他活动交换的数据和/或信息 模型范围之外的活动（外部交流）
活动模型本质上是分层的。它们捕获业务流程中执行的活动，以及输入， 这些活动的控制、产出和机制/资源 （ICOM）。活动模型可以用显式语句进行注释 的业务规则，表示 ICOM 之间的关系。例如，业务规则可以指定谁可以在下面执行哪些操作 指定的条件、所需的输入和控件组合以及生成的输出。一种创建活动的技术 模型是集成计算机辅助制造（ICAM）DEFinition（IDEF）建模技术。
对象管理小组（OMG）开发了业务流程建模符号TM（BPMNTM），这是一种业务流程建模标准，包括一种用于指定业务流程、其任务/步骤以及生成的文档的语言。
- 用例模型根据对应于 业务流程和组织参与者（人员、组织等）
用例模型在用例图和用例规范中描述。
- 逻辑数据模型（或类模型）)
逻辑数据模型描述实体、其属性、这些属性的可接受值以及 各种实体之间的关系。特别有用的是用于分析的“is-a”关系。例如，如果轿车 一种汽车，它是一种车辆，那么所有车辆的一般业务规则可以一次自动编写 为所有类型的汽车和卡车拾取。
类模型通过包含实体特有的服务（方法）来扩展逻辑数据模型以包含行为（现在 称为类）。通常，应用程序和信息架构师将使用类图，业务架构师将使用 逻辑数据模型。
上面所有三种类型的模型都可以用统一建模语言TM（UML®）表示，并且存在用于生成此类模型的各种工具。
某些行业部门具有特定于相关部门的建模技术。
作为阶段 B 的一部分，架构团队需要考虑哪些相关的业务架构资源可用 架构存储库，在 特定：
- 与组织行业相关的行业参考模型
- 特定于企业的业务架构视图（功能图、价值流图、组织图等）
- 特定于企业的构建块（流程组件、业务规则、工作描述等）
- 适用标准