企业架构需求是什么？
需求：特定架构或工作包必须满足的业务需求的定量陈述。
什么会促进企业架构的开发？
通常，为业务转型需要或彻底的基础架构变更做准备会启动企业架构审查或开发。 关键人物通常会确定需要进行变革的领域，以实现新的业务目标。 这些人通常被称为变革中的“利益相关者”。 架构师的作用是通过以下方式解决他们的担忧：
- 识别和提炼利益相关者的需求
- 开发架构视图，显示将如何解决关注点和需求
- 展示在调和不同利益相关者的潜在冲突问题时将要进行的权衡
如果没有企业架构，所有关注点和需求都不太可能被考虑和满足。
段落语句
架构需求存储库提供了所有已与架构委员会达成一致的核准的架构需求的视图
5.2.3 预备阶段输入 – 预算需求
6.2.3 架构愿景阶段输入 – 重用需求、预算需求
6.3.2 在架构愿景阶段，在所选需求范围内为未来架构工作生成的新需求需要记录在架构需求规范中，超出所选需求范围的新需求必须输入到需求存储库中通过需求管理流程进行管理。
6.3.9 定义目标架构价值主张和 KPI – 评估和定义采购需求
6.3.11 制定架构工作说明书； 安全批准
– 根据业务绩效需求评估需要生产（以及何时生产）的工作产品。
– 评估在所需时间范围内执行工作的资源需求和可用性； 这将包括遵守组织的计划方法和工作产品，以制定执行 ADM 周期的计划
6.4 输出 – 架构愿景 – 提炼了关键高层利益相关者的需求
7.2.3 业务架构输入 – 资源需求
7.3.4 差距分析 – 针对需求测试架构模型的完整性
7.3.8 最终确定业务架构 – 记录最终需求跟踪报告
7.4 输出 – 架构定义文档（草稿）- 业务角色，包括技能需求的开发和修改
7.4 输出 – 架构需求规范（草稿，参见第 IV 部分，第 32.2.6 节，第 354 页），包括以下业务架构需求：
— 差距分析结果
— 技术需求 – 对其余架构领域工作的影响进行识别、分类和优先排序； 例如，通过依赖/优先级矩阵（例如，指导交易处理速度和安全性之间的权衡）； 列出预期生成的特定模型（例如，表示为 Zachman 框架的基元 primitives ）
— 更新的业务需求
7.5.4 应用价值流 – 可以通过热图（按价值流阶段）或围绕价值流的完整定义开发用例，在项目范围内分析新的或现有的价值流。 业务价值，或强调某些阶段而不是其他阶段，以便在后期阶段为解决方案开发更好的需求。
7.5.5 应用组织地图 – 组织地图提供了对哪些业务单位参与架构工作、谁以及何时讨论给定需求以及如何讨论的理解 衡量各种决策的影响。
7.5.6 应用建模技术- 节点连接图描述了业务位置（节点）、它们之间的“需求线”以及交换的信息的特征
节点连接可以在三个层次上进行描述：概念、逻辑和物理。 每条需求线表示两个连接节点之间需要某种信息传输。 一个节点可以代表一个角色（例如，CIO）、一个组织单位、一个业务地点或设施等。 指示信息流方向的箭头被注释以描述数据或信息的特征——例如，其内容、媒体、安全或分类级别、及时性以及对信息系统互操作性的需求。
7.5.6 应用建模技术 – 信息交换矩阵记录了企业架构的信息交换需求。信息交换需求表达了三个基本实体（活动、业务节点及其元素、信息流）之间的关系，并关注信息交换的特性，例如性能和安全性。 他们确定谁与谁交换了哪些信息，为什么需要这些信息，以及以何种方式。
9.3.1.1 确定总体建模过程 – 合理化数据需求并与任何现有的企业数据目录和模型保持一致； 这允许开发数据清单和实体关系
9.3.1.2 确定所需的数据构建块目录 – 一旦将数据需求整合到一个位置，就可以细化数据清单以实现语义一致性并消除差距和重叠。
9.3.1.4 确定所需图表 – 图表根据利益相关者的需求从一组不同的角度（视点）呈现数据架构信息。
9.3.1.5 确定要收集的数据架构需求类型 – 一旦开发了数据架构目录、矩阵和图表，架构建模就通过将实现目标架构的以数据为中心的需求形式化来完成。这些需求可能是：
-与数据域相关
-向应用和技术架构提供需求输入
-提供在设计和实施过程中体现的详细指导，以确保解决方案满足原始架构需求
在此步骤中，架构师应确定架构应满足的需求（参见第 16.5.2 节）。
9.3.8 最终确定数据架构
– 根据业务需求对总体架构进行最终交叉检查； 在架构文档中记录构建块决策的理由
– 记录最终需求跟踪报告
9.3.9 创建架构定义文档 – 准备架构定义文档的数据架构部分，包括：数据互操作性需求（例如，XML 模式schema、安全策略）
9.4 输出 – 架构需求规范（草案，参见第 IV 部分，第 32.2.6 节），包括以下数据架构需求：
— 差距分析结果
— 数据互操作性需求
— 适用于架构开发周期演变的相关技术需求
— 对即将设计的技术架构的约束
— 更新业务需求（如果适用）
— 更新应用需求（如果适用）
9.5.1.1 数据管理 – 当企业选择进行大规模架构转型时，了解和解决数据管理问题很重要。 结构化和全面的数据管理方法可以有效利用数据以利用其竞争优势。考虑因素包括：
– 对支持与企业客户和供应商进行数据集成的软件有什么需求（例如，在数据迁移期间使用 ETL 工具、评估数据质量的数据剖析工具等）？
9.5.1.2 数据迁移 – 替换现有应用程序时，将迫切需要将数据（主数据、事务数据和参考数据）迁移到新应用程序。 数据架构应确定数据迁移需求，并提供有关转换、清除和清理级别的指标，这些级别以满足目标应用的需求和约束的格式呈现数据。 目标是目标应用程序在填充时具有质量数据。 另一个关键考虑因素是确保建立企业范围的通用数据定义以支持转换。
10.3.1.5 确定要收集的应用架构需求类型 – 一旦开发了应用架构目录、矩阵和图，架构建模就通过形式化实现目标架构的以应用为中心的需求来完成。这些需求可能：
– 与应用域相关
– 为数据和技术架构提供需求输入
– 提供在设计和实施过程中体现的详细指导，以确保解决方案满足原始架构需求
10.4 输出 – 架构需求规范（草案，参见第 IV 部分，第 32.2.6 节），包括以下应用架构需求：
— 差距分析结果
— 应用程序互操作性需求
— 适用于架构开发周期演变的相关技术需求
— 对即将设计的技术架构的约束
— 更新业务需求（如果适用）
— 更新数据需求（如适用）
11.3.1.1 确定技术架构整体建模过程 – 开发技术架构的过程包含以下步骤：
– 查看应用和业务对技术的需求
– 技术是否适用于满足新需求（即，它是否满足功能性和非功能性需求）？
11.3.1.2确定所需的技术构件目录 – 如果现有产品无法满足应用架构中确定的需求，请通过检查市场上提供功能并满足所需标准的产品来扩展产品列表
11.3.1.5 确定要收集的技术架构需求类型 – 一旦开发了技术架构目录、矩阵和图，架构建模就通过将实现目标架构的以技术为中心的需求形式化来完成。这些需求可能：
– 与技术领域相关
– 提供在设计和实施过程中体现的详细指导，以确保解决方案满足原始架构需求
12.2.3 机会和解决方案阶段 架构输入 – 架构需求规范（草案，见第四部分，第 32.2.6 节），包括：
— 架构需求
— 差距分析结果（来自业务、数据、应用和技术架构）
— IT 服务管理需求
12.3 E阶段的步骤如下：
– 审查相关业务职能的合并需求
– 整合和协调互操作性需求
12.3.4 步骤：审查相关业务职能的合并需求 – 评估需求、差距、解决方案和因素，以确定最小的需求集，将其集成到工作包中将导致跨参与架构的业务功能更有效地实施目标架构。 这种功能视角通过提供共享解决方案和服务来满足多种需求。 这种与架构组件相关的需求整合的影响对于资源的提供可能是重要的。 例如，可以通过在工作包或项目中提供一组共享的业务服务和信息系统服务来解决由多个业务线提出的多个需求。
12.3.5 整合和协调互操作性需求 – 整合在前几个阶段确定的互操作性需求。架构愿景和目标架构，以及实施因素评估和推演矩阵和合并的差距、解决方案和依赖关系矩阵，应该被合并和审查，以确定潜在解决方案集所需的互操作性的任何限制。一个关键的结果是最大限度地减少互操作性冲突，或确保在架构中解决此类冲突。重复使用的 SBB、商用现货 (COTS) 产品和第三方服务提供商通常会强加相互冲突的互操作性需求。必须在架构中解决任何此类冲突，并且必须考虑所有架构域（业务、应用、数据和技术）之间的冲突。互操作性冲突有两种基本方法；要么创建在冲突构建块之间转换或翻译的构建块，要么对冲突构建块的规范进行更改。
12.4 输出 – 架构路线图（见第四部分，第 32.2.7 节），包括：
架构路线图（见第四部分，第 32.2.7 节），包括：
— 工作包组合：
– 功能需求
– 与架构定义文档和架构需求规范的关系
14.3.3 指导解决方案部署开发
— 制定项目推荐
对于每个单独的实施和部署项目，请执行以下操作：
– 在影响分析中记录战略需求（从架构的角度）
– 在影响分析中记录路线图的时间表需求
— 提供源自企业架构的服务需求
— 指导业务和 IT 运营需求定义
14.4 实施治理阶段输出 – 关于服务交付需求的建议
15.3.2 架构变更管理阶段 步骤15.3.2 部署监控工具 – 确保部署和应用监控工具以实现以下功能：
– 确定和跟踪业务连续性需求
16.4 架构需求管理阶段输出 – 架构需求存储库将作为需求管理阶段的一部分进行更新，并应包含所有需求信息。当出现新需求或更改现有需求时，会生成需求影响说明，其中确定需要重新访问以解决更改的 ADM 阶段。 该说明经过多次迭代直到最终版本，其中包括需求（例如，成本、时间尺度和业务指标）对架构开发的全部影响。 当前 ADM 周期的需求确定后，应更新架构需求规范。
5.5.3 架构工作需求
企业架构工作背后的业务必要事项 business imperatives 推动了架构工作的需求和性能指标。 它们应该足够清晰，以便此阶段可以确定业务成果和资源需求的范围，并定义要完成的企业架构工作的大纲企业业务信息需求和相关策略。 例如，这些可能包括：
- 业务需求
- 文化抱负
- 组织意图
- 战略意图
- 预测财务需求
需要阐明其中的重要元素，以便发起人能够识别参与定义和建立架构能力的所有关键决策者和利益相关者。
7.3.1.6 业务架构阶段 – 确定要收集的需求类型
一旦开发了业务架构目录、矩阵和图，架构建模就通过将实现目标架构的以业务为中心的需求形式化来完成。
这些需求可能：
- 与业务域相关
- 为数据、应用和技术架构提供需求输入
- 提供在设计和实施过程中体现的详细指导，以确保解决方案满足原始架构需求
在此步骤中，架构师应确定架构应满足的需求（参见第 16.5.2 节）。
在许多情况下，架构定义并不打算为解决方案提供详细或全面的需求（因为这些需求可以通过通用需求管理学科更好地解决）。需求内容的预期范围应在架构愿景阶段确定，并记录在批准的架构工作说明书中。
任何超出架构工作说明书中定义范围的需求或需求变更都必须提交给需求存储库，以便通过受治理的需求管理流程进行管理。
16.5.1 架构需求管理阶段 总则
如 ADM 图形中心的“需求管理”圆圈所示，ADM 由需求管理流程持续驱动。需要注意的是，需求管理圈表示的不是一组静态的需求，而是一个动态过程，在此过程中，企业架构的需求和对这些需求的后续变更被识别、存储并输入和输出相关的 ADM 阶段，以及也在 ADM 的周期之间。
处理需求变化的能力至关重要。架构本质上是一种处理不确定性和变化的活动 – 利益相关者所渴望的与可以指定和设计为解决方案之间的“灰色区域”。因此，架构需求在实践中总是会发生变化。此外，架构经常处理驱动因素和约束，其中许多本质上超出了企业的控制（不断变化的市场条件、新的立法等），并且可能以不可预见的方式产生需求的变化。
还要注意，需求管理过程本身并不处理、处理或优先考虑任何需求；这是在 ADM 的相关阶段完成的。它只是在整个 ADM 中管理需求的过程。
建议使用架构需求存储库（参见第 IV 部分，第 37.6 节）来记录和管理所有架构需求。与架构需求规范和需求影响评估不同，架构需求存储库可以保存来自多个 ADM 周期的信息。
16.5.2 需求开发
第一个高阶需求被阐明为架构愿景的一部分，通过业务场景或类似技术生成。
ADM 的每个阶段，从预备到阶段 H，都必须为该阶段选择已批准的需求，这些需求在架构需求库和架构需求规范中保存。在该阶段完成时，需要更新所有此类需求的状态。在阶段执行期间，当前架构工作说明书范围内为未来架构工作生成的新需求需要记录在架构需求规范中，并且当前架构工作说明书范围之外的新需求必须通过需求管理过程输入到架构需求库进行管理。
在 ADM 的每个相关阶段，架构师应确定架构必须满足的需求类型，包括适用的：
- 功能需求
- 非功能性需求
在定义需求时，架构师应该考虑：
- 需求假设Assumptions – 由于外部限制，现阶段尚未完全验证的可能事实陈述。 例如，可以假设现有应用程序将支持特定的一组功能需求，尽管这些需求可能尚未单独验证。
- 需求约束Constraints
- 驱动需求的特定领域原则 principles
- 影响需求的政策 Policies
- 需求必须满足的标准Standards
- 需求的组织指南
- 需求规格
后期 ADM 阶段的可交付物还包含到设计需求的映射，并且还可能生成新的需求类型（例如，一致性需求、实施的时间窗口）。
16.5.3 资源
需求工程的世界充满了需求管理的新兴建议和流程。标准不强制或推荐任何特定的过程或工具； 它只是说明了一个有效的需求管理过程应该实现什么（即“需求的需求”，如果你愿意的话）。
16.5.3.1 业务场景
业务场景技术是发现和记录业务需求的合适且有效的技术。 系列指南：业务场景中详细描述了业务场景。
16.5.3.2 需求工具
有大量且不断增加的商用现货 (COTS) 工具可用于支持需求管理，尽管它们不一定是为架构需求而设计的。 Volere 网站有一个非常有用的主要需求工具列表
37.6.2 架构需求存储库的内容
架构需求存储库保存特定时间点企业所需状态的架构需求。由于整个企业架构生命周期中的庞大数量和不同的利益相关者需求，架构需求分为三个粒度级别：
- 战略架构需求显示了整个企业需求的长期汇总视图。战略架构需求在执行级别确定方向设定的操作和变更需求。
- 分段架构需求为企业内的各个领域提供更详细的运营模式需求。
分段架构需求可以在程序或组合级别识别需求，以识别和调整更详细的变更活动。 - 能力架构需求确定特定能力单元的详细需求。
能力架构需求确定要在管理的组合和程序中分组的单个工作包和项目的需求。随着时间的推移，架构需求的业务成果将反映在解决方案景观中。发生这种情况时，满足架构需求并存档以用于审计目的。