首页 - 新闻 - TOGAF10®标准中文版--(A阶段-架构愿景)方法

TOGAF10®标准中文版--(A阶段-架构愿景)方法

2023-10-04 18:08

3.5.1 概述

阶段 A 从收到来自 的架构工作请求开始。

TOGAF 标准 — EA能力和治理中讨论了

确保公司管理层、和直线管理层支持和承诺的适当支持和验证所涉及的问题。

A 阶段还定义了建筑工作范围之内和之外的内容以及必须解决的约束。范围决策需要根据对资源和能力可用性的实际评估以及企业实际期望从所选架构工作范围中获得的价值来做出。所涉及的问题在 1.5 架构范围中讨论。架构愿景阶段解决的范围问题将仅限于该 ADM 周期的具体目标,并将受到初步阶段期间建立并反映在架构框架中的架构活动的总体范围定义的约束。

在现有架构框架不适合实现预期架构愿景的情况下,重新审视初级阶段并扩展企业整体架构框架。

约束通常由作为初步阶段一部分制定的业务原则和架构原则告知(请参阅 2. 初步阶段)。

通常,组织的业务原则、业务目标和战略驱动因素已在企业的其他地方定义。如果是这样,A 阶段的活动包括确保现有定义是最新的并澄清任何含糊不清的领域。否则,它将首次定义这些重要项目。

同样,构成架构工作约束的架构原则通常已经在初步阶段定义(参见2. 初步阶段)。 A 阶段的活动包括确保现有的原则定义是最新的并澄清任何含糊不清的领域。否则,需要首先定义架构原则,如 TOGAF 标准 - ADM 技术中所述。

3.5.2 创建架构愿景

架构愿景为发起人提供了一个关键工具,可以向企业内的利益相关者和决策者推销拟议功能的好处。架构愿景描述了新功能在实施时如何满足业务目标和战略目标并解决利益相关者的担忧

架构愿景的一个组成部分是了解新兴技术及其对行业和企业的潜在影响,否则可能会错过许多商机。

澄清并商定建筑作品的目的是本次活动的关键部分之一,目的需要在创建的愿景中得到清晰的体现。架构项目通常是带着特定的目的进行的,一组特定的业务驱动的元素代表了架构开发中利益相关者的投资回报。阐明该目的,并展示拟议的建筑开发将如何实现该目的,是建筑愿景的重点。

通常,架构愿景的关键要素(例如企业使命、愿景、战略和目标)已被记录为更广泛的业务战略或企业规划活动的一部分,这些活动在业务中拥有自己的生命周期。在这种情况下,A 阶段的活动涉及验证和理解记录的业务战略和目标,并可能一方面在企业战略和目标与当前架构现实中隐含的战略和目标之间建立一座桥梁。

业务模型是关键的战略工件,它可以通过展示组织如何向客户和利益相关者交付价值来提供这样的视角。 3.3.4 评估能力引入了业务模型的应用,作为开发架构愿景的一个步骤。

在其他情况下,迄今为止可能很少或根本没有完成业务架构工作。在这种情况下,架构团队需要研究、验证并认可架构要支持的关键业务目标和流程。这可以在架构开发之前作为独立的练习来完成,也可以作为 ADM 启动阶段(初步阶段)的一部分来完成。

此练习应检查和搜索有关基本业务架构概念的现有材料,例如:

  1. 业务能力,代表企业为实现特定目的或结果而可能拥有或交换的特定技能或能力

在此阶段,架构师应确定组织中是否存在代表业务能力的框架。如果不存在,架构师应该考虑该开发框架是否在项目范围内。有关业务能力的介绍,请参阅 TOGAF® 系列指南:业务能力。

  1. 价值流, 代表增值活动的端到端集合,这些活动为客户、利益相关者或最终用户创造总体结果

有关价值流的介绍,请参阅 TOGAF® 系列指南:价值流。

  1. 组织结构图,描述构成业务的主要实体、其合作伙伴和利益相关者之间的关系

由于传统的组织结构图通常缺乏必要的细节来反映企业活动的全部范围,架构师可以帮助识别和理解业务实体之间复杂的关系网络,以及业务功能在何处使用并连接到价值流阶段。 。这些在随后的阶段中得到了完善和扩展。有关组织图表的介绍,请参阅 TOGAF® 系列指南:组织图表

此外,架构愿景还探索了适合现有企业架构的其他领域。这些领域可能包括基本领域的要素,但为利益相关者提供了额外的目的。示例字段可能包括:

  1. 信息化
  2. 安全
  3. 数字化
  4. 网络管理
  5. 知识
  6. 特定行业
  7. 服务
  8. 合作伙伴
  9. 网络安全

这些域可以是独立的,也可以与其他域链接,以提供组织愿景和结构的企业范围视图。

架构愿景阶段涉及进行业务评估(例如使用业务场景),其中记录关键因素并评估各种行动方案。记录高层的优势和劣势,包括风险和机遇,并选择最佳行动方案作为架构愿景的基础。

架构愿景提供了基线和目标架构的初始高级描述,涵盖业务、数据、应用程序和技术领域。这些摘要描述将在后续阶段中制定。

一旦在架构工作说明书中定义并记录了架构愿景,就必须使用它来建立共识,如 TOGAF 标准 —EA功能和治理中所述。如果没有这种共识,最终的架构就不可能被整个组织接受。共识由主管机构在《架构工作说明书》签名表示。