跳转到主要内容

TOGAF® 是一种使用一组规定工具开发企业架构的分步方法。它可在 Open Group 网站上免费获得,供希望开发企业架构的组织使用。第一个版本是在 1995 年开发的,它基于美国国防部开发的信息管理技术架构框架 (TAFIM)。当前版本为 9.2[1]

TOGAF® 是开放组架构框架的首字母缩写。

开放组架构框架 (TOGAF®) 是一个企业架构框架,它提供了一种设计、规划、实施和管理企业信息技术架构的方法。 TOGAF® 是 The Open Group 在美国和其他国家的注册商标。 TOGAF® 是一种高级设计方法。它通常在四个级别建模:业务、应用程序、数据和技术。它在很大程度上依赖于模块化、标准化以及已经存在的、经过验证的技术和产品。 [2]

TOGAF® 的历史 


TOGAF® 是作为技术架构方法创建的。 1995 年,The Open Group 将其开发为一个综合的企业架构框架——被称为信息管理技术架构框架 (TAFIM)。 TOGAF® 7,即“技术版”,于 2001 年 12 月发布。一年后,TOGAF® 8(“企业版”)发布。 TOGAF® 8.1 于 2003 年 12 月重新发布和更新,“TOGAF®™”于 2005 年正式成为 The Open Group 的注册商标。TOGAF® 于 2006 年 11 月进行了进一步的大修,命名为 TOGAF® 8.1.1。最新版本更新 TOGAF® 9.1 于 2011 年 12 月发布,是目前最新的框架,被 80% 的企业架构师使用。 TOGAF® 9.1 是迄今为止最成功的框架,这反映在它最近在企业架构中的广泛使用以及 22,900 个经过认证的 TOGAF® 中的 16,000 个符合 9.1 标准的事实。自 1993 年成立至今,Open Group 一直是决定 TOGAF® 专业方向的所有者和管理实体。

TOGAF® 的组成部分


框架 TOGAF® 由以下组件组成:

  • 一种架构开发方法 (ADM)
  • ADM 指南和技术
  • 架构内容框架
  • 参考模型
  • 企业连续体
  • 架构能力框架

The Open Group Architecture Framework (TOGAF®)

source: The Open Group

TOGAF® 支柱


TOGAF 9.1 中有四个架构域为企业提供专业化服务。

  • 业务架构:包括有关业务战略、治理、组织以及如何调整组织内任何现有流程的信息。
  • 应用程序架构:根据业务目标、其他组织框架和所有核心业务流程构建和部署应用程序系统的蓝图。
  • 数据架构:定义组织的数据存储、管理和维护,包括逻辑和物理数据模型。
  • 技术架构:也叫技术架构;它描述了开发和部署业务应用程序所涉及的所有必要的硬件、软件和 IT 基础设施。

调整 TOGAF 框架


以业务战略和方向为基础,您可以考虑如何在您的组织中应用 TOGAF,以及您希望通过它实现哪些结果。 TOGAF 是一个非常广泛和通用的框架,重要的是要指定 TOGAF 的哪些元素在您的组织环境中有用,哪些元素不那么相关。 TOGAF 本身认识到这一点:TOGAF 架构开发方法 (ADM) 的第一步是初步阶段。这个阶段是关于在相关企业中定义“我们在哪里、做什么、为什么、谁以及如何做架构”(TOGAF 9.1,第 6.2 节)。换句话说:您将调整 TOGAF 框架并根据您自己组织的要求对其进行自定义。然而,这并不像看起来那么容易。 TOGAF 在此初步阶段提出了一些有意义的步骤,但该方法仍然非常通用。因此,组织可能会发现自己在这个阶段挣扎,导致很多争论但收效甚微。为了从这个阶段获得有价值的结果,我们将精益管理的原则应用到架构过程中:检查所有活动和结果以了解它们增加的价值并消除任何浪费,避免导致延误的不必要的签收,并不断改进您的方式在职的。根据我们的经验,重点关注三个方面很重要:

  • 使用一组有限的 EA 可交付成果。 TOGAF 提出了许多可以生产的可交付成果。根据我们的经验,“少即是多”:只有几个关键的可交付成果就足以启动 EA 计划并取得成果。
  • 要选择和配置这些关键可交付成果,最重要的标准是它们的潜在商业价值。谁将使用它们,用于哪些活动以及预期的收益 尤其是在 EA 计划的早期阶段,向不同的利益相关者(包括业务利益相关者)展示 EA 可交付成果的附加价值至关重要。
  • 通过实践学习。在您开始并以瀑布方法执行之前,不可能定义一个完整的 EA 框架。最好从小处着手,采用迭代方法,学习并改进您在旅途中的工作方式。

TOGAF 9.2 版 - 更改和改进


TOGAF 标准 9.2 版带来了许多变化和改进。一个重要的变化是将 TOGAF 重组为一个核心和一些附加指南,它们共同构成了 TOGAF 知识体系。一个普遍的变化是对术语的细化,包括与 ISO/IEC/IEEE 42010:2011 标准和其他标准保持一致。最有趣的变化是通过业务能力和价值流丰富了 TOGAF 的业务架构部分。这些新增功能使 TOGAF 远离了过去的 IT 重点。在这篇博客中,我将进一步描述这两个新增内容。最有趣的变化是通过业务能力和价值流丰富了 TOGAF 的业务架构部分。

  • 业务能力:业务能力在 TOGAF 中并不是全新的;基于能力的规划技术已经是先前版本的一部分。在新版本中,业务能力得到了更多的关注和关注。首先是术语更加清晰,能力和业务能力之间有明显的区别能力是指组织、个人或系统所具有的能力。业务能力是企业可能拥有或交换以实现特定目的的特定能力。因此,能力是一个更笼统的术语,还包括 IT 和架构能力。基于能力的架构视图强调业务需要什么来实现其目标。它需要识别、分类和分解业务所需的业务能力,以便能够为一个或多个利益相关者提供价值。引入业务能力图以提供独立于当前组织结构、业务流程和信息系统的业务的独立视图。它提供了组织理解的抽象级别,因此是与人们讨论所需更改的一种非常合适的方式。
  • 价值流:价值流在 TOGAF 中是全新的。价值流是为客户、利益相关者或最终用户创造整体结果的增值活动的端到端集合的表示。它们是组织为创造与利益相关者交换的价值而执行的活动分解的结果。它们为业务功能提供上下文和分组。它们为组织需要这些业务能力的原因提供了有价值的利益相关者上下文。对于价值链中的每个阶段,都可以确定所需的业务能力。结果可以在称为价值流阶段目录的新工件中描述。在与业务利益相关者轻松沟通方面,价值流具有与业务能力相同的优势。它们使人们能够根据人们认识的事物以商业术语进行交流。它们可以在稍后阶段细化为流程。同样,它们可以与组织结构中的业务能力一起翻译。组织地图可用于显示组织如何与业务能力相关,从而也与价值流阶段相关。

TOGAF®的批评


存在对 TOGAF® 的某些批评。

  • TOGAF® 是一个非常丰富的框架,完全实施起来非常复杂
  • 巴罗埃罗等人。 (2010) 在具体层面批评业务需求与数据、应用程序和技术之间缺乏真正的联系
  • 德尚等人。 (2012) 指出 EA 和 EAM 缺乏扩展的研究议程,特别是在通过选择和支持的建模方法使软件工程和企业工程的学科更接近方面。
  • 技术人员也可能声称 EA 和 TOGAF® 与技术实施的实际方法无关(Homan 和 Tobey,2006 年)。
  • 米特拉等人。 (2015) 强调 TOGAF® 以及其他 EA 框架(Zachman 和 FEA)缺乏人力资源和组织变革管理支持,并提出了企业变革架构 (ETA) 框架
  • EA 框架(即 TOGAF®)中缺乏对人为因素的关注,这对框架的持久性和可持续性提出了质疑,Weiss et al. (2013)
  • 钟等人。 (2009) 讨论了通过解决实践和鼓励使用一系列组织工具进行转型来将 EA 和 EAM 制度化的必要性。

See Also

 

References

  1.  Defining TOGAF® Burst-Gigital
  2.  Definition of TOGAF® Wikipedia
  3.  History of TOGAF® The Knowledge Academy
  4.  The four architectural domains in TOGAF 9.1 [1]
  5.  Adapting the TOGAF Framework bizzdesign
  6.  TOGAF Version 9.2 - Changes and Improvements ITpreneurs
  7.  Criticism of TOGAF® Torben Tambo et. al

本文: