TOGAF(开放组架构框架)是一个开放的组织框架。该框架本身是一个有据可查的知识体系,包括用于开发企业架构的详细方法和一组支持工具。TOGAF 9.2 是该框架的最新版本。
- TOGAF 由 The Open Group 的成员开发和维护,并在一个名为 Architecture Forum 的团队中工作。TOGAF 第 1 版的第一次开发产生于 1995 年,随后的 TOGAF 版本扩展和改进了这一知识体系。
- TOGAF 是由代表一些世界领先公司和组织的 300 多名架构论坛成员共同努力开发的——因此它是对一般企业架构实践的一个很好的总结。
- 开发和维护企业架构是一个复杂的过程,涉及许多利益相关者和决策过程。TOGAF 通过记录企业架构规范、流程和工作产品来提供帮助。
- 通过使用 TOGAF,组织可以开发一致的企业架构,以反映利益相关者的需求,采用最佳实践,并适当考虑当前需求和未来感知的业务需求。
TOGAF 从何而来?
TOGAF 起源于美国国防部的信息管理技术架构框架(TAFIM)。TOGAF 1.0 经过多年探索,终于在 1995 年发布,得到了美国国防部的许可,并得到了美国政府的大量投资。迄今为止,TOGAF 已经发布了第九个版本,TOGAF 9(最新版本是 TOGAF 9.2)
为什么选择 TOGAF?
IT 架构需要密切反映组织的业务目标。实际上,应该使用特定技术(业务场景)来确保 IT 架构师正确理解业务目标,并在使用 TOGAF 开发的 IT 架构中得到反映。
以下是我们应该采用 TOGAF ADM 进行架构开发的原因:
- 综合通用方法
- 与其他框架互补而非竞争
- 被市场广泛采用
- 量身定制,以满足组织和行业的需求
- 在免费的永久许可下可用
- 供应商、工具和技术中立的开放标准
- 避免重新发明轮子
- 业务 IT 对齐
- 基于最佳实践
- 可能参与框架的演变
什么是 ADM?
架构开发方法 (ADM) 用于开发满足组织的业务和信息技术需求的企业架构。TOGAF ADM 是大量架构从业者为以下目的不断贡献的结果:
- 它描述了一种开发和管理企业架构生命周期的方法,并构成了 TOGAF 的核心。
- 它可以根据组织的需要进行定制,然后用于管理架构规划活动的执行。
架构开发方法——通常称为 ADM 的缩写——是一个详细的分步过程,用于开发或更改企业的架构。
ADM 描述了涵盖架构开发周期的 10 个阶段。
这些阶段是:
- 预备阶段
- A阶段:建筑愿景
- B阶段:业务架构
- 阶段 C:信息系统架构
- D阶段:技术架构
- E 阶段:机会和解决方案
- F 阶段:迁移规划
- 阶段 G:实施治理
- 阶段 H:架构变更管理
- 需求管理
ADM 输入和输出
TOGAF 提供了每个阶段的许多输入和输出可交付成果:
- 这些是建议,不需要完全遵循
- 生成的每个可交付成果都应进行版本控制,以指示何时发生更改
- 显示的版本编号也是一个建议,无需遵循
可交付成果
合同规定的工作产品,然后由利益相关者正式审查、同意和签署。它通常会在项目完成时存档,或者作为参考模型转换为架构存储库
初期:
初始阶段的主要目标是确定和建立组织所需的架构能力。
关键部分之一是确定需要做什么以及如何实施。例如,主要输出是一个 架构工作请求 ,它概述了需求并决定需要什么范围、结构、工具或架构框架来支持这项工作。
在这个阶段,TOGAF 是专门为满足即将到来的 ADM 迭代需求而量身定制的。我们定义基本原则,评估企业结构和业务进行所需更改的能力,并将 TOGAF 与其他管理框架集成。在这个阶段有一些步骤来限制受提议变更影响的公司组织,确认正确的治理和支持框架,定义和建立 EA 团队和组织,识别和建立架构原则,定制 TOGAF 和任何其他框架,以及实施工具. 在这个阶段结束时,EA 团队应该准备好遵循 ADM 周期的迭代。这部分是因为初级阶段显示在 ADM 图表的顶部,位于阶段 A 到 H 的主循环之外。
A 阶段:架构愿景:
阶段 A 提供了清晰的架构工作声明,将在 ADM 的迭代中提供。它还为提议的企业架构提供了愿景。这种方向感对于在整个迭代过程中指导 ADM 的工作至关重要。建筑 工作说明 定义了架构愿景中概述的架构的开发和部署过程。正是这一愿景为提议的企业架构将提供的功能和业务价值提供了高层次的愿望。从施工作业申请开始,阶段 A 提供了一个工具(此愿景),将提议的能力的好处推销给企业中的利益相关者和决策者。业务场景用于理解业务需求并帮助阐明所需功能所隐含的架构需求。这记录在架构工作声明中,并用于建立共识以支持最终架构。当发起组织签署文件时,就会形成共识。
阶段 A 的步骤是将施工工作请求转化为清晰的架构工作声明,并确保公司能够、准备好、愿意并致力于进行必要的架构更改。这涉及建立一个架构项目,包括定义其范围,以及确认和详细说明架构和业务原则。阶段 A 识别利益相关者及其关注点和要求,并确认初步阶段的业务目标、驱动因素和约束。为确保成功,它还评估业务能力,评估业务转型的准备情况,并解决任何转型风险。
B阶段:业务架构:
TOGAF 将企业架构视为提高业务能力的一种方式——这就是为什么架构开发的第一个阶段涉及 业务架构的原因 。
ADM从业务角度——在 基础设施工作的初步阶段 确定强烈的业务需求,并进一步细化为A阶段的 基础设施工作 和 架构愿景陈述 。
业务架构阶段的一个关键目标是开发目标业务架构,展示企业如何实现架构愿景并解决架构工作请求。它的第二个目标是首先确定候选架构路线图组件,以弥合基线和目标业务架构之间的差距。TOGAF 将业务架构知识视为其他领域(如数据、应用程序和技术)架构工作的先决条件。业务架构还向关键利益相关者展示了架构工作的商业价值和投资回报。业务模型,例如活动或流程模型、用例和类模型,或节点连接图,
所有三个架构开发阶段(B、C 和 D)都遵循类似的步骤。重用任何可用的参考模型并定制所有输出以解决利益相关者的观点非常重要。然后,架构师开发业务架构的基线和目标描述,并执行差距分析以确定如何从一个转换到另一个。
阶段 C:信息系统架构:
TOGAF将Phase C-Information System Architecture-分为两部分,涵盖 数据开发 和 应用 架构。TOGAF 文档有一个简短的介绍性章节,涵盖两个领域,然后是关于数据和应用程序的单独章节。与其他架构开发阶段 (B&D) 一样,目标是为数据和应用程序开发目标信息系统架构,并根据基线和目标架构之间的差距确定候选架构路线图组件。
阶段 C 总是涉及数据和应用程序架构的结合。提供两者都包括在内,并且以任何顺序都没有关系 – 两种方法都有倡导者。数据和应用的步骤非常相似——选择参考模型、观点和工具;开发基线,然后定位架构描述,执行差距分析并定义候选路线图组件;并解决对整体架构环境的任何影响。经过正式的利益相关者审查后,最终确定了架构并创建了架构定义文档。
数据和应用程序之间的主要区别在于主题,这体现在使用不同的参考模型、技术和架构表示上。例如,数据架构可以使用实体关系或类图,而应用程序架构可以使用应用程序通信图或软件工程图。
D阶段:技术架构:
D 阶段是 TOGAF 的阶段,为架构项目开发技术架构。技术架构描述了平台服务以及逻辑和物理技术组件的结构和交互。D阶段开发目标技术架构,支持数据和应用组件(C阶段开发)实现业务组件。
将 B、C 和 D 阶段开发的架构结合起来,实现架构愿景,解决利益相关者的关注和建设工作要求。与其他架构开发阶段一样,阶段 D 确定候选架构路线图组件,以实现从基线到目标的过渡。D阶段的步骤与B阶段和C阶段的步骤几乎相同——主要区别在于现在的重点是技术。因此,这包括技术参考模型和技术标准或测量——例如性能、可维护性、位置和延迟或可用性。
确定输出和可交付成果对于帮助构建真正支持信息系统和业务架构的技术架构非常重要。获得正确的范围可以加快回报,而过大的范围会阻碍成功实施。这与部署技术本身无关,而是真正解决架构愿景和工作要求的技术架构的开发。
E 阶段:机会和解决方案:
E 阶段得名——它是通过实施特定的解决方案来寻找提供目标架构的机会。阶段 E 通过结合分析和构建开发阶段 B、C 和 D 的建议,生成架构路线图的第一个完整版本。
在这个阶段,主要关注的是如何提供架构。因此,它专注于创建架构路线图,在时间线中列出工作包以实现目标架构。当变化如此之大以至于无法直接从基线转到目标架构时,阶段 E 将产生一种增量方法,由中间或过渡架构组成。阶段 E 将所需的架构更改映射到具有执行工作包的资金和资源的投资程序和项目,并提供过渡和目标架构。这个阶段的输入几乎就是早期的所有输出。这些步骤采取这些输出;整合它们,分析依赖关系并协调差异;并再次确认组织可以做出改变。E 阶段改进和更新需求、架构文档和架构路线图。关键输出是实施和迁移计划的第一步。
阶段 F:迁移计划:
ADM 的早期阶段确定了架构更改的需求,然后开发了业务、数据、应用程序和技术架构来支持这一需求。然后,在第二阶段,制定高级实施和迁移计划,以利用投资机会并确定具体的解决方案。目标架构:F 阶段最终确定了详细的实施和迁移计划,以及最终的架构路线图。
它还确保该计划与公司内使用的变更管理方法和整体变更组合中的其他计划相协调。最后,阶段 F 确保关键利益相关者充分了解业务价值、工作包的成本以及过渡和未来架构。虽然 ADM 的早期阶段非常受企业架构团队的指导,但从 E 到 H 的阶段需要与其他变革推动者协作。
F阶段特别需要四个管理框架之间的密切合作,以使实施和安置计划取得成功。
这四个领域是:
- 商业计划
- 企业架构
- 投资组合管理
- 项目管理
通过合作,这四个领域必须优先考虑工作,使用绩效评估、投资回报、商业价值、关键成功因素、有效性衡量和战略匹配等标准。
阶段 G:实施治理:
实际开发和实施与阶段 G 并行进行。阶段 G 确保实施项目和其他正在进行的项目符合定义的架构。
通常,目标架构被开发为一系列转换,以尽快实现业务价值和收益,并降低转换计划中的风险。每一次转型都是目标公司实现自身商业利益的一步。
当我们到达 G 阶段时,架构已经开发(在 A 到 D 阶段),提供架构的机会和解决方案已经确定(在 E 阶段),并且详细的实施和迁移计划已经完成(在 F 阶段)。因此,阶段 G 架构团队的角色是监督架构实施。这是通过验证部署的范围和优先级、指导开发和解决方案部署以及执行合规性审查来完成的。
架构合同文件用于推动架构变更。在阶段 G 开始时生成并由架构功能和负责实施的人员批准,它是一种评估架构治理合规性的机制。
H 阶段:结构变更管理:
一切都没有按计划进行——总会有新的需求和架构变化。阶段 H 描述了变更管理过程,以一种有凝聚力和结构化的方式管理对架构的变更。通常,这需要持续监控治理请求、新技术或业务环境的变化。
该过程应该支持已实现的企业架构作为一个动态环境,可以灵活地响应这些变化并快速发展。在阶段 H,治理机构设定标准来确定变更请求是否需要简单的架构更新,或者是否需要启动新的架构开发方法 (ADM) 周期是很重要的。变更必须与业务价值直接相关。如何使用企业架构是架构开发周期中最重要的部分,因此在 H 阶段监控业务增长和下降至关重要。
最后,昨天为组织工作的企业架构不再支持当前或未来的功能。H 阶段变更请求的输出可以归类为简化——通常由减少投资的要求驱动;增量变化——需要从现有投资中获得额外价值;或者重新设计变革,这是一个需要增加投资和创造新价值的驱动。
架构需求管理:
在 ADM 的每个阶段,都需要生成、分析和审查的要求。需求管理阶段描述了在整个 ADM 中管理这些架构需求的过程。需求管理阶段是 ADM 的核心——这就是为什么它显示在 ADM 麦田圈的中心。此阶段描述了需求管理过程以及该过程如何与 ADM 的其他阶段相关联。需求不是静态的——它们在我们完成 ADM 的每个阶段和 ADM 周期之间动态演变。
企业架构的需求以及对这些需求的后续更改将被识别、存储以及与 ADM 阶段相关的输入和输出,以及在 ADM 周期之间。应对需求变化至关重要。架构处理不确定性和变化——利益相关者期望和可能性之间的“灰色地带”!因此,架构要求总是会发生变化。
此外,该架构涉及许多企业无法控制的驱动因素和约束——例如不断变化的市场条件或新的立法——它们将以不可预见的方式产生需求变化。
TOGAF 强调需求管理过程本身不会处理、解决或优先考虑需求,因为这是在 ADM 的相关阶段完成的。需求管理阶段就是对整个 ADM 中的需求进行管理的过程。
ADM 初步阶段
创建架构能力所需的准备和启动活动,包括 TOGAF 的定制和架构的定义
输出成果:
- 架构原则
- 架构存储库
- 业务原则、业务目标和业务驱动力
- 企业架构的组织模型
- 请求架构工作
- 量身定制的架构框架
ADM 阶段 A:架构愿景
架构开发周期的初始阶段。它包括有关定义架构开发计划范围、识别利益相关者、创建架构愿景以及获得批准以继续进行架构开发的信息
输出成果:
ADM 阶段 B:业务架构
业务架构:开发业务架构以支持商定的架构愿景
输出成果:
- 架构定义文档
- 架构原则
- 架构需求规范
- 架构路线图
- 业务原则、业务目标和业务驱动力
- 建筑工作说明
ADM 阶段 C:信息系统架构
信息系统架构:开发信息系统架构以支持商定的架构愿景
ADM 阶段 D:技术架构
技术架构:开发技术架构以支持商定的架构愿景
输出成果:
ADM E 阶段:机会与解决方案
Opportunities & Solutions 为之前阶段定义的架构进行初始实施规划和交付工具的识别
输出成果:
ADM 阶段 F:迁移计划
迁移计划通过最终确定详细的实施和迁移计划来解决如何从基线迁移到目标架构
ADM 阶段 G:实施治理
实施治理提供实施的架构监督
输出成果:
- 改变请求
- 合规评估
- 解决方案构建块
- 建筑工作说明
ADM 阶段 H:架构变更管理
架构变更管理建立了管理新架构变更的程序 需求管理检查整个 ADM 中管理架构需求的过程
概括
ADM 是一种综合的通用方法
- 它推荐了开发架构所涉及的各个阶段和步骤的顺序
- 这是一种迭代方法
- 它借鉴了 TOGAF 的资产和流程的其他部分
- 它可以与其他框架的其他可交付成果一起使用
以下是每个开发阶段的 TOGAF ADM 概述,如下图所示: