A阶段的目标是:
本节定义了阶段A的输入。
3.2.1 企业外部参考资料
3.2.2 非架构输入
3.2.3 架构输入
■ 企业架构的组织模型(见TOGAF标准——架构内容),包括:
— 受影响组织的范围
— 成熟度评估、差距和解决方法
— 架构团队的角色和职责
— 架构工作的限制
— 重复使用要求
— 所需预算
— 变更请求
— 治理和支持战略
■ 定制的架构框架(见TOGAF标准——架构内容),包括:
— 量身定制的架构方法
— 量身定制的架构内容(可交付成果和工件)
— 架构原则(参见TOGAF标准——架构内容),包括预先存在的业务原则
— 已配置和部署的工具
■ 填充架构库(见TOGAF标准——架构内容)——现有架构文档(框架描述、架构描述、基线
描述、架构构建块(ABB)等)
A阶段所涉及的详细程度将取决于架构工作请求的范围和目标,或与架构开发迭代相关的范围和目
的子集。
A阶段的步骤顺序以及正式开始和完成的时间应根据既定的架构治理适应当前的情况。
A阶段的步骤如下:
3.3.1 建立架构项目
企业架构是一种业务能力;ADM的每个周期通常应该使用企业的项目管理框架作为一个项目来处理。
在某些情况下,架构项目将是独立的。在其他情况下,架构活动将是更大项目中活动的一个子集。
在任何一种情况下,都应该使用企业公认的实践来规划和管理架构活动。
执行必要的程序,以确保项目的认可、公司管理层的背书以及必要的直线管理层的支持和承诺。
包括对企业内使用的其他管理框架的引用,解释该项目与这些框架的关系。
3.3.2 识别利益相关者、关注点和业务需求
确定关键利益相关者及其关注点/目标,并定义架构参与中要解决的关键业务需求。在此阶段,利
益相关者的参与旨在实现三个目标:
这一步产生的主要产品是参与的利益相关者图,显示了哪些利益相关者参与了参与、他们的参与
程度以及他们的主要关注点(见TOGAF标准-ADM技术)。利益相关者图用于支持架构愿景阶段的各种输出,并确定:
另一个关键任务是考虑需要开发哪些架构视图和观点来满足各种利益相关者的要求。正如TOGAF标准-ADM技术中所述,在这个阶段了解哪些利益相关者和需要发展哪些观点对于确定参与范围非常重要。
在架构(Architecture)愿景阶段,需要在架构(Architecture)需求规范中记录在所选需求范
围内为未来架构(architectural)工作生成的新需求,并且必须将超出所选需求的新需求输入到
需求库中,以便通过需求管理过程进行管理。
3.3.3 确认并详细说明业务目标、业务驱动因素和约束
确定组织的业务目标和战略驱动因素。
如果这些定义已经在企业的其他地方定义,请确保现有的定义是最新的,并澄清任何不明确的地
方。否则,请回到《架构工作说明书》的发起人那里,与他们一起定义这些基本项目,并获得公
司管理层的认可。
定义必须处理的约束,包括企业范围的约束和项目特定的约束(时间、进度、资源等)。企业范
围的约束可以通过在初步阶段制定的业务和架构原则来了解,也可以作为A阶段的一部分来澄清。
3.3.4 评估能力
了解企业内的一系列能力是有价值的。一部分是指企业开发和使用架构的能力。第二部分是指企
业的基线和目标能力水平。架构能力中确定的差距需要在架构愿景和初步阶段之间进行迭代,以
确保架构能力适合解决架构项目的范围(见TOGAF标准——应用ADM)。
评估业务模型或阐明业务战略优先级的工件后的一个关键步骤是确定企业必须具备的按战略优先
级行事所需的业务能力。
对业务能力差距的详细评估属于B阶段,是业务架构的核心方面,架构师可以帮助企业了解整个业
务中需要在架构后期解决的多种类型的差距。然而,在架构愿景阶段,架构师应该考虑企业根据正在进行的特定倡议或项目的要求开发企业架构本身的能力。在架构工作是否应该继续的愿景中,通过ADM取得进展的能力差距,无论是来自技能短缺、所需信息、流程弱点还是系统和工具,都是一个严重的考虑因素。架构师可以在第3.5节中找到指导,在早期评估中为企业收集现有的业务能力框架。
在企业执行变更的能力中发现的差距或限制将告知架构师目标架构的描述以及在阶段E和阶段F中
创建的实施和迁移计划(见TOGAF标准——架构内容)。这一步旨在在适当的抽象级别上了解企业的能力和愿望(见TOGA标准——应用ADM)。考虑企业基线能力和目标能力之间的差距至关重要。
通过创建显示相关能力联系的价值链图,可以在整个企业的背景下显示基线和目标能力。评估结
果记录在能力评估中(参见TOGAF标准——架构内容)。
3.3.5 评估业务转型的准备情况
业务转型准备情况评估可用于评估和量化组织对变革的准备情况。该评估基于TOGAF标准-ADM技术中所述的一系列准备就绪因素的确定和分析/评级。
准备状态评估的结果应添加到能力评估中(见TOGAF标准——架构内容)。然后,这些结果用于确定架构的范围,确定架构项目中所需的活动,并确定需要解决的风险领域。
3.3.6 定义范围
定义基线架构和目标架构工作范围内的内容和范围外的内容,理解基线和目标不需要在相同的细
节级别上进行描述。在许多情况下,基线是在更高的抽象级别上描述的,因此有更多的时间来详
细指定目标。第1.5节讨论了其中涉及的问题。特别是,定义:
■ 企业的覆盖范围
■ 所需的详细程度
■ 架构的分区特性(详见TOGAF标准——应用ADM)
■ 要覆盖的特定架构领域(业务、数据、应用程序、技术)
■ 目标时间段的范围,加上任何中间时间段的数量和范围
■ 从组织的架构存储库中利用或考虑使用的架构资产:
— 在企业内ADM周期的先前迭代中创建的资产
— 行业其他地方可用的资产(其他框架、系统模型、垂直行业模型等)
3.3.7 确认并阐述架构原则,包括业务原则
审查开发架构的原则。架构原则通常基于初步阶段制定的原则。它们在TOGAF标准-ADM技术中进行了解释,并给出了一个示例集。确保现有定义是最新的,并澄清任何不明确的地方。否则,回到
负责架构治理的机构,与他们一起首次定义这些基本项目,并获得公司管理层的认可。
3.3.8 发展架构愿景
对所需工件的理解将使利益相关者能够开始确定他们的决策范围,这将指导后续阶段。这些决定
需要反映在利益相关者地图中。
这一阶段需要掌握政策制定和战略决策,以便对后续工作进行量化;例如,合理化决策和指标、
创收以及符合业务战略的目标。还有其他领域需要解决;例如,数字化转型和IT战略,其中关于
架构愿景的决策将在后续阶段为组织提供领导和指导。
对于架构愿景,建议首先确定一个整体架构,展示所有不同架构领域的交付成果将如何组合在一
起(基于所选的行动方案)。
基于利益相关者的关注点、业务能力要求、范围、约束和原则,创建基线和目标架构的高级视图。架构愿景通常涵盖了项目在高层次上确定的范围。经常采用非正式的技巧。一种常见的做法是绘制一个简单的解决方案概念图,简要说明解决方案的主要组成部分以及解决方案将如何为企业带来利益。
业务场景是一种适当且有用的技术,用于发现和记录业务需求,并阐明响应这些需求的架构愿景。
业务场景也可用于架构工作的更详细级别(例如,在阶段B中),并在TOGAF®系列指南:业务场景中进行了描述。
这一步从业务、信息系统和技术的角度生成了基线和目标环境的第一个非常高级的定义,如第3.4
节所述。
这些架构的初始版本应存储在架构存储库中,并根据架构框架中建立的标准和指导方针进行组织。
3.3.9 定义目标架构价值主张和关键绩效指标
此活动的输出应纳入架构工作说明书,以便相应地跟踪绩效
3.3.10 识别业务转型风险和缓解活动
识别与架构愿景相关的风险,评估初始风险水平(例如灾难性、关键性、边际性或可忽略不计)
以及与之相关的潜在频率。为每种风险分配缓解策略。TOGAF标准-ADM技术中描述了一个风险管理框架。
应考虑两个级别的风险,即:
应考虑将风险缓解活动纳入架构工作说明书。
3.3.11 制定架构工作说明书;安全审批
根据一组业务绩效要求评估需要生产的工作产品(以及何时生产)。这将涉及确保:
A阶段的输出可能包括但不限于:
■ 批准的架构工作说明书(见TOGAF标准——架构内容),特别包括:
— 架构项目描述和范围
— 架构愿景概述
— 架构项目计划和进度
■ 业务原则、业务目标和业务驱动因素的精炼陈述(见TOGAF标准——架构内容)
■ 架构原则(见TOGAF标准-ADM技术)
■ 能力评估(见TOGAF标准——架构内容)
■ 定制的架构框架(见TOGAF标准——架构内容)(关于参与),包括:
— 量身定制的架构方法
— 量身定制的架构内容(可交付成果和工件)
— 已配置和部署的工具
■ 架构愿景(见TOGAF标准——架构内容),包括:
— 问题描述
— 架构工作说明书的目标
— 摘要视图
— 业务场景(可选)
— 细化关键高层利益相关者要求
■ 架构定义文件草案,其中可能包括任何架构域的基线和/或目标架构
■ 通信计划(见TOGAF标准——架构内容)
■ 填充架构存储库的其他内容(请参阅TOGAF标准——架构内容)
注意:可以使用多个业务场景来生成单个架构愿景。
TOGAF标准——架构内容详细描述了在此阶段可能产生的架构工件,详细描述了它们,并将它们与TOGAF企业元模型中的实体、属性和关系联系起来。
3.5.1 概述
A阶段从收到发起组织向架构组织发出的架构工作请求开始。
TOGAF标准——企业架构能力和治理中讨论了确保公司管理层的适当认可和背书以及直线管理层的支持和承诺所涉及的问题。
阶段A还定义了架构工作范围内和范围外的内容以及必须处理的约束。范围界定决策需要基于对资
源和能力可用性的实际评估,以及从所选架构工作范围中可以实际预期为企业带来的价值来做出。
第1.5节讨论了其中涉及的问题。架构(Architecture)愿景阶段解决的范围界定问题将仅限于本
ADM周期的具体目标,并将限制在初步阶段确定的架构(architectures)活动的总体范围定义内,
并体现在架构(architectural)框架中。
在现有架构框架不适合实现所需架构愿景的情况下,重新审视初步阶段并扩展企业的整体架构框
架。
约束通常由作为初步阶段的一部分开发的业务原则和架构原则来告知(见第2章)。
通常,组织的业务原则、业务目标和战略驱动因素已经在企业的其他地方定义好了。如果是这样,
A阶段的活动涉及确保现有定义是最新的,并澄清任何模糊的领域。否则,它将涉及首次定义这些
基本项目。
同样,构成架构工作约束的架构原则通常在初步阶段就已定义(见第2章)。A阶段的活动涉及确
保现有的原则定义是最新的,并澄清任何模糊的领域。否则,它需要首次定义架构原则,正如
TOGAF标准-ADM技术中所解释的那样。
3.5.2 创建架构愿景
架构愿景为赞助商提供了一个关键工具,向企业内的利益相关者和决策者推销拟议能力的好处。架
构愿景描述了新功能在实施时将如何满足业务目标和战略目标,并解决利益相关者的担忧。
架构愿景的核心是了解新兴技术及其对行业和企业的潜在影响,否则可能会错过许多商机。
澄清和同意架构工作的目的是这项活动的关键部分之一,目的需要在创建的愿景中得到明确反映。
架构项目通常是在考虑特定目的的情况下进行的——一组特定的业务驱动因素,代表了架构开发
中利益相关者的投资回报。明确这一目的,并展示如何通过拟议的架构开发来实现这一目标,是
架构愿景的重点。
通常,架构愿景的关键要素(如企业使命、愿景、战略和 目 标 ) 已 被 记 录 为 一 些 更 广 泛 的 业务战略 或 企业规划活动的 一 部 分 , 这些活动在企业内有自己的生命周期。在这种情况下,阶段A的活动涉及验证和理解记录的业务战略和目标,并可能在企业战略和目标与当前架构现实中隐含的战略和目标之间架起桥梁。
业务模型是关键的战略工件,可以通过展示组织打算如何向客户和利益相关者交付价值来提供这
样的视角。第3.3.4节介绍了业务模型的应用,作为开发架构愿景的一个步骤。
在其他情况下,迄今为止可能很少或根本没有做业务架构工作。在这种情况下,架构团队需要研
究、验证和认可架构要支持的关键业务目标和流程。这可以作为独立的练习来完成,可以在架构
开发之前,也可以作为ADM启动阶段(初步阶段)的一部分。
本练习应检查和搜索有关基本业务架构概念的现有材料,例如:
此外,架构愿景还探索了适合当前企业架构的其他领域。这些领域可能包括基本领域的元素,但
为利益相关者提供了额外的目的。示例域可能包括:
■ 问询处
■ 安全
■ 数字化
■ 网络管理
■ 知识
■ 行业特定
■ 服务
■ 伙伴关系
■ 网络安全
这些域可以是独立的,也可以与其他域链接,以提供组织愿景和结构的企业范围视图。
架构愿景阶段包括进行业务评估(例如使用业务场景),记录关键因素并评估各种行动方案。记
录高级优缺点,包括风险和机遇,并选择最佳行动方案作为架构愿景的基础。
架构愿景提供了基线和目标架构的初步、高级描述,涵盖了业务、数据、应用程序和技术领域。
这些大纲描述将在后续阶段制定。
一旦架构愿景被定义并记录在架构工作说明书中,就必须使用它来建立共识,正如TOGAF标准——企业架构能力和治理中所述。如果没有这种共识,整个组织不太可能接受最终的架构。赞助组织签署《架构工作声明》代表了共识。