欢迎来到Doker,好久没发管理类的文章了,今天来一篇原版,欢迎点赞和评论!或者加微信进入技术群聊!
TOGAF 标准是一个架构框架。它提供了协助验收、生产、 企业架构的使用和维护。它基于由最佳实践支持的迭代过程模型和 可重用的现有架构资产集。
ISO/IEC/IEEE 42010:2011将“架构”定义为:
“系统在其环境中的基本概念或属性体现在其元素、关系和 其设计和演变的原则。
TOGAF 标准包含但不严格遵守 ISO/IEC/IEEE 42010:2011 术语。除了 ISO/IEC/IEEE 之外 42010:2011 “架构”的定义,TOGAF 标准根据上下文定义了第二个含义:
“组件的结构、相互关系以及指导其设计的原则和准则 随着时间的推移而演变。
TOGAF 标准将企业视为一个系统,并努力在推广概念和 从相关标准中提取的术语,以及大多数 TOGAF 熟悉的普遍接受的术语 读者。
有四个架构领域通常被接受为整个企业架构的子集,所有这些领域 TOGAF 标准旨在支持:
业务架构定义了业务战略、治理、组织和关键业务流程
数据架构描述了组织的逻辑和物理数据资产以及数据管理的结构 资源
应用程序架构为要部署的各个应用程序、它们的交互、 以及它们与组织核心业务流程的关系
技术架构描述了数字架构以及逻辑软件和硬件基础设施 支持业务、数据和应用程序服务部署所需的功能和标准。这包括 数字服务、物联网 (IoT)、社交媒体基础设施、云服务、IT 基础设施、中间件、网络、 通信、处理、标准等
还有许多其他领域可以通过组合业务、数据、应用程序和 技术领域。例如:
信息架构
风险和安全架构
数字架构
TOGAF 框架可以创建这些多维视图并对其进行分类以创建特定的域 使企业能够考虑其企业和能力的更广泛范围。
TOGAF 架构开发方法 (ADM) 为开发架构提供了一个经过测试和可重复的过程。行政管理委员会 包括建立架构框架、开发架构内容、过渡和治理实现 架构。
所有这些活动都是在连续架构定义和实现的迭代循环中执行的 允许组织以可控的方式转变其企业,以响应业务目标和机会。
图 3-1:体系结构开发周期
ADM 中的阶段如下:
初步阶段描述了创建架构功能所需的准备和启动活动 包括 TOGAF 框架的定制和架构原则的定义
阶段 A:架构愿景描述了架构开发周期的初始阶段
它包括有关定义架构开发计划的范围、确定利益相关者、 创建架构愿景,并获得批准继续进行架构开发。
阶段B:业务架构描述了业务架构的开发以支持商定的内容 架构愿景
阶段C:信息系统架构描述了信息系统架构的发展 支持商定的架构愿景
阶段 D:技术架构描述了技术架构的开发,以支持商定的目标 架构愿景
阶段E:机会和解决方案进行初步实施规划和交付确定 用于前一阶段定义的架构的车辆
阶段 F:迁移规划解决了如何通过最终确定 详细的实施和迁移计划
阶段 G:实施治理提供对实施的架构监督
阶段 H:架构变更管理建立管理新架构变更的程序
需求管理在整个 ADM 中运行管理架构需求的过程
有关如何执行指定操作的指南,请参阅 TOGAF 系列指南。
TOGAF 框架建议调整 ADM 以满足企业的需求并支持不同的架构 样式
特别是,ADM 不会:
规定这些阶段必须按任何特定顺序执行
强制采用“瀑布”方法
TOGAF 标准描述了如何迭代使用 ADM 来开发全面的企业架构环境。 与其将 ADM 图形视为流程模型,不如将其视为定义必须执行的操作的参考模型会很有帮助 为了以架构的方式提供解决方案,并确定整个企业和 他们之间的关系。
ADM 中描述的活动通常通过服务交付模型提供。这些服务的组织和呈现方式为 服务类别。这些服务满足独立于组织特定运营模式的特定需求。任何给定 所描述的服务利用 ADM 中的适当活动来满足给定的需求。
表 3-1总结了拟议的服务类别,并提供了一些背景信息。前四个 类别以客户为中心,其他类别则更多地以架构师为内部中心。每个服务类别都简要介绍 在以下小节中描述。
表 3-1:服务类别和描述符
|
描述符 |
|||
类别 |
典型客户 |
典型提供商 |
可交付成果 |
期望的结果 |
以客户为中心 |
||||
企业支持服务 |
C 级管理 |
使用企业架构作为工具的企业分析师 |
问题解答 评估报告 建议 |
更好的企业决策 降低风险 |
设计支持服务 |
计划级决策者 |
企业架构师构建者/建模师 |
计划的 MVA(包括标准和合规性标准、路线图) 合规指南 合规报告 |
更好的设计决策 成功的计划和项目 |
开发支持服务 |
项目级决策者 |
企业架构师构建者/建模师 |
项目/产品的 MVA(包括标准和合规性标准) 合规指南 合规报告 |
更好的产品决策 成功的产品 |
需求启发和理解服务 |
产品经理 |
具有需求理解专业的企业架构师 |
利益相关者关注的问题 要求 评估(价值、能力等) |
由外而内对利益相关者之间平衡的解决方案的需求和价值 |
以内部为中心 |
||||
建筑规划服务 |
架构团队负责人 |
经验丰富的企业架构师 |
建筑项目计划 |
资源架构团队 |
企业架构实践开发支持服务 |
架构组织决策者 |
企业架构实践专家 |
企业架构能力评估 企业架构能力改进建议 |
高技能和有组织的企业架构实践组织(内部或外部) |
此服务类别包含候选服务,这些服务可实现明智的企业决策以支持 组织变革。这些服务可以独立于任何单个项目提供。这些服务专注于回答 问题并提供企业分析以支持战略决策。
此服务类别包含候选服务,这些服务可实现明智的设计决策以支持组织 改变。这些服务通常在项目获得资助后提供,无论是大型还是小型,瀑布式还是敏捷式。 这些服务包括最小可行架构(MVA)的开发和相关分析,以支持设计 决定。
此服务类别包含候选服务,这些服务可实现明智的开发决策以支持 组织变革。这些服务通常在项目的开发阶段提供,无论大小, 瀑布或敏捷。这些服务侧重于回答问题和提供企业分析以支持发展 决定。
此服务类别包含支持需求理解的候选服务。迈出更远的一步 需求管理,这些服务有助于更接近实际需求,从而提供更大的业务价值。
此服务类别包含候选服务,这些服务可实现精心规划和执行的架构项目 支持组织变革。这些服务通常在“项目”开始时提供,无论大小, 瀑布或敏捷。
此服务类别包含支持企业开发和管理的候选服务 建筑实践。这些服务专注于提高企业架构能力。
执行 ADM 的架构师将产生许多输出,作为他们努力的结果,例如流程流、 架构要求、项目计划、项目合规性评估等TOGAF 架构内容框架提供了一个结构模型 允许一致地定义、构建和呈现主要工作产品的体系结构内容。
建筑内容框架使用以下三个类别来描述建筑作品的类型 使用环境中的产品:
可交付成果是合同规定的工作产品,然后经过正式审查、批准、 并由利益相关者签署
可交付成果表示项目的输出,文档形式的可交付成果通常 在项目完成时存档,或作为参考模型、标准或快照转换为架构存储库 在某个时间点的建筑景观。
工件是描述体系结构某个方面的体系结构工作产品
工件通常分为目录(事物列表)、矩阵(显示事物之间的关系)、 和图表(事物的图片)。示例包括需求目录、应用程序交互矩阵和价值链 图。架构可交付成果可能包含一个或多个工件,工件将构成架构的内容 存储 库。根据合同规范,工件可能被视为可交付成果,也可能不被视为可交付成果。
构建基块表示可与其他建筑组合的潜在可重用组件 用于交付架构和解决方案的模块
构建块可以在各种详细级别定义,具体取决于体系结构开发的哪个阶段 已到达。例如,在早期阶段,构建块可以简单地由名称或大纲描述组成。后来,一个 构建块可以分解为多个支持构建块,并可能附带完整的规范。建筑 块可以与“架构”或“解决方案”相关。
架构构建块 (ABB) 通常描述所需的功能并塑造 解决方案构建块 (SBB);例如,企业内可能需要客户服务功能,由 许多 SBB,例如过程、数据和应用软件
解决方案构建基块 (SBB) 表示将用于实现所需组件的组件 能力;例如,网络是一个构建块,可以通过互补的工件进行描述,然后用于 实现企业解决方案
可交付成果、工件和构建块之间的关系如图所示 3-2 .
图 3-2:可交付结果、工件和构建之间的关系 块
例如,架构定义文档是记录架构描述的可交付成果。这 文档将包含许多互补工件,这些工件是与体系结构相关的构建基块的视图。为 例如,可以创建流程图(工件)来描述目标呼叫处理流程(构建基块)。这 工件还可以描述其他构建块,例如参与流程的参与者(例如,客户服务 代表)。图 3-3 说明了可交付结果、工件和构建基块之间的关系示例。
图 3-3:示例 — 体系结构定义 公文
可交付成果、工件和构建块的概念在 TOGAF 标准 — 架构内容中进行了更详细的描述。
TOGAF 标准 — ADM 技术描述了架构 开发方法,包括每个阶段可能创建的可交付成果和工件的摘要列表。TOGAF 标准 — 架构内容包含这些内容的详细描述。
一种体系结构技术,用于将问题区域划分为更小的问题区域,这些区域更易于建模和 因此更容易解决。
抽象级别本质上是分层的,从高级模型移动到更详细的模型。
架构工作可以分为四个不同的抽象级别,这些抽象级别跨越业务、数据、 应用和技术领域,用于回答有关体系结构的基本问题:
为什么 — 为什么需要架构?
什么 — 架构需要满足哪些功能和其他要求?
我们如何 — 我们如何构建功能?
我们应该用什么——用什么资产来实施这个结构?
请注意,为什么、什么和如何与它们在 Zachman® 企业架构框架中的使用无关。
此抽象级别侧重于理解企业运营的环境和上下文 其中规划和执行架构工作。它回答了企业为什么要进行架构工作,范围是什么 工作,以及目标、驱动因素和目标方面的动机。
这个抽象级别的核心是分解需求以理解问题,以及需要什么来理解问题。 解决问题,而不过度关注如何实现架构。它回答了实现 需求,通常使用服务模型(业务服务、应用程序服务、技术服务)进行建模,这些模型表示 期望的行为。
请注意,此抽象级别也可以称为服务抽象或行为抽象。
此抽象级别侧重于识别业务、数据、应用程序和技术的种类 实现概念级别中确定的服务所需的组件。它是关于确定架构如何 以独立于实现的方式进行组织和结构化。可能有几种方法可以将服务分组到 逻辑组件,基于原则和其他分组标准,提供不同的逻辑解决方案替代方案。
此抽象级别管理物理组件的分配和实现,以满足已识别的 逻辑组件。它是关于确定可以使用哪些物理组件实现逻辑级组件。会有 基于原则和其他分组标准,可能有许多方法可以使用物理组件来实现逻辑组件, 提供不同的物理解决方案替代方案。
原则是一般规则和准则,旨在持久且很少修订,提供信息和支持 一个组织着手完成其使命的方式。
根据组织的不同,可以在不同的领域和不同的级别上建立原则。二 关键领域为架构的开发和使用提供了信息:
企业原则为整个企业的决策提供了基础,并告知如何 组织着手履行其使命
这些原则通常被视为协调整个组织决策的一种手段。特别 它们是成功的架构治理策略的关键要素
在企业原则的广泛领域内,通常在企业或企业中拥有附属原则 组织单位;例如,特定于 IT、人力资源、国内运营或海外运营的原则。这些原则 为子公司域内的决策提供基础,并将为该领域的架构开发提供信息。关心 必须采取,以确保用于通知架构开发的原则与 架构能力。
架构原则是一组与架构工作相关的原则
它们反映了整个企业的共识水平,体现了现有企业的精神和思想 原则。架构原则管理架构过程,影响 企业架构。
在企业内部,原则的层次结构始于企业原则。子公司部门 原则必须存在于这些总体企业原则的范围内。因此,在每个层次结构中 级别 这套原则将参考并详细说明从上一级继承的原则,不能超越 他们的边界。
架构原则可以以有效指导架构的术语和形式重申其他企业指南。 发展。
架构原则定义了使用和部署所有内容的基本一般规则和准则 整个企业的资源和资产。它们反映了企业各个要素和形式之间的一定程度的共识 做出未来架构决策的基础。
每个架构原则都应与业务目标和关键架构明确相关 司机。
互操作性的定义是“共享信息和服务的能力”。定义 信息和服务是否共享是一个非常有用的架构要求,尤其是在复杂的架构中。 组织和/或扩展企业。
互操作性的确定贯穿整个架构开发方法 (ADM) 作为 遵循:
在体系结构愿景(阶段 A)中,信息和服务的性质和安全注意事项 交易所首先在业务场景中揭示
在业务架构(B阶段)中,信息和服务交换在业务中进一步定义 条款
在数据架构(阶段 C)中,使用公司数据详细说明信息交换的内容 和/或信息交换模型
在应用程序体系结构(阶段 C)中,各种应用程序共享信息的方式和 指定服务
在技术架构(阶段D)中,允许信息和 指定服务交换
在机会和解决方案(E阶段)中,实际的解决方案(例如,商业现货(COTS)包) 被选中
在迁移规划(阶段 F)中,互操作性是逻辑实现的
有许多方法可以定义互操作性,目的是定义一种在 企业和扩展企业。企业和扩展企业最好使用相同的定义。
许多组织发现将互操作性分类如下很有用:
运营或业务互操作性定义了企业的不同部分如何在 业务级别
信息互操作性定义了如何共享信息
技术互操作性定义了如何共享技术资源或至少连接到一个 另一个
从 IT 角度来看,以与企业应用程序类似的方式考虑互操作性也很有用。 整合;具体说来:
演示集成/互操作性是指通过通用的通用外观和感觉方法 类似门户的解决方案引导用户了解系统集的底层功能
信息集成/互操作性是公司信息在 之间无缝共享的地方 实现的各种企业应用程序,例如,一组通用的客户信息
通常,这是基于普遍接受的企业本体和结构,质量,共享服务,质量, 信息的访问和安全性/隐私。
应用程序集成/互操作性是集成和共享企业功能的地方 这样应用程序就不会重复(例如,地址服务/组件的一次更改;不是每个应用程序都有一个),并且 通过工作流等功能无缝链接在一起
这会影响业务和基础结构应用程序,并且与公司业务流程密切相关 统一/互操作性。
技术集成/互操作性包括用于通信的通用方法和共享服务, 主要在应用程序平台和通信基础设施领域存储、处理和访问数据
TOGAF 标准包括企业连续体的概念,它为 架构并解释如何利用和专门化通用解决方案来支持个人的需求 组织。
企业连续体是企业存储库中保存的资产的分类,它提供了方法 用于对资产进行分类,包括从通用基础体系结构演变为 组织特定的体系结构。企业连续体包括两个互补的概念:架构连续体和 解决方案连续体。
企业连续体的结构和上下文概述如图所示
图 3-4:企业连续体
支持企业连续体是架构存储库的概念,可用于存储 由 ADM 创建的不同抽象级别的不同类别的体系结构输出。这样,TOGAF 标准 促进不同层面的持份者与从业员之间的了解和合作。
通过企业连续体和架构存储库,鼓励架构师利用所有其他 开发组织特定架构的相关架构资源和资产。在这种情况下,TOGAF ADM 可以 被视为描述在组织内多个级别运行的过程生命周期,在整体内运行 治理框架并生成驻留在架构存储库中的一致输出。企业连续体提供了一个 理解架构模型的宝贵上下文:它显示了构建基块及其相互关系,以及 体系结构开发周期的约束和要求。
TOGAF 架构存储库的结构如图 3-5 所示。
Figure 3-5: TOGAF Architecture Repository Structure
体系结构存储库中的主要组件如下:
体系结构元模型描述了体系结构框架的组织定制应用,包括体系结构内容的元模型
体系结构能力定义了支持体系结构库管理的参数、结构和过程
架构环境是运营中部署的资产的架构表示 特定时间点的企业 — 环境可能存在于多个抽象级别以适应不同的 架构目标
标准库捕获新架构必须遵守的标准,其中可能包括 行业标准、供应商提供的选定产品和服务或已在组织内部署的共享服务
参考库提供指南、模板、模式和其他形式的参考资料, 可用于加速为企业创建新体系结构
治理存储库提供整个企业的治理活动记录
架构需求存储库提供了所有授权架构需求的视图,这些需求 已与架构委员会达成一致
解决方案景观展示了支持架构的 SBB 的架构表示形式 企业已规划或部署的环境
TOGAF ADM 提供生命周期管理,以创建和管理企业内的架构。在每个阶段 在 ADM 中,对输入、输出和步骤的讨论描述了许多架构工作产品。
初步建立企业特定的企业架构能力时的一项基本任务 ADM 的阶段是定义:
用于构建架构描述的分类框架,用于构建工作产品 表达架构,以及描述架构的模型集合;这称为内容 框架
了解企业内的实体类型以及它们之间需要的关系 捕获、存储和分析以创建架构描述;这个企业元模型描述了这个 正式模型形式的信息
要开发的特定工件
所选内容框架可能受到以下因素的影响:
选择作为企业架构能力基础的架构框架
用于支持企业架构功能的所选软件工具
内容框架定义用于描述构建基块和项目的分类框架 反映在创建整体架构可交付成果时做出的决策。
架构存储库,是 结构化以存储内容框架中标识的项目和工作产品。内容框架是 企业特定的体系结构框架。
有许多替代内容框架(例如,TOGAF 内容框架、扎克曼框架、DoDAF、 NAF等)。选择内容框架是必不可少的,即使选择内容框架不太重要。决赛 内容框架通常经过调整以适应特定的组织需求。
TOGAF 内容框架旨在:
提供建筑工作产品的详细模型
驱动遵循 ADM 时创建的输出的一致性
提供可创建的架构输出的综合清单
降低最终架构可交付成果集中出现差距的风险
帮助企业强制实施标准架构概念、术语和可交付成果
在最高级别,TOGAF 内容框架(见图 3-6)的结构是一致的 与 ADM 的阶段。
图 3-6:按 ADM 阶段划分的内容框架
架构原则、愿景、动机和需求模型旨在捕获 围绕正式架构模型的背景,包括一般架构原则,形成输入的战略背景 用于架构建模,以及从架构生成的需求
引起架构请求工作的业务上下文的相关方面是 通常在初步和架构愿景阶段进行调查、完善、验证和记录。
业务架构捕获业务的架构模型,专门研究以下因素: 激励企业、其结构和能力
信息系统架构模型捕获 IT 系统的架构模型,查看应用程序 以及符合 TOGAF ADM 阶段的数据
技术架构模型捕获用于实施和实现信息的技术资产 系统解决方案
架构实现/转换模型捕获变更路线图,显示 用于指导和管理体系结构实现的体系结构状态和绑定语句
架构变更管理模型捕获内部和外部的价值实现管理事件, 影响企业架构和行动要求的产生
TOGAF 标准鼓励开发企业元模型,该模型定义了要出现的实体类型 在描述企业的模型中,以及这些实体之间的关系。
例如,企业元模型中的一种类型可能是角色。然后是企业的业务架构模型 可能包括柜员、飞行员、经理、志愿者、客户或消防员等角色实例。当然会是一个 具有所有这些角色的不寻常企业。
企业元模型以多种方式提供价值:
它为建筑师提供了一组入门,其中包含要调查并在模型中涵盖的事物类型。
它为任何架构建模语言或架构元模型提供了一种完整性检查形式, 建议在企业中使用
即,它如何完整地处理企业元模型中的实体类型,并管理所需的事实 关于它们,例如它们的属性和关系?
它可以帮助确保:
一致性
完整性
溯源
请注意,TOGAF 标准的目的不是限制企业的:
工件的选择
建模符号
TOGAF标准可以使用多种建模语言,例如ArchiMate®建模语言、Business Process modeling NotationTM(BPMNTM)、Unified modeling LanguageTM(UML®)、实体关系图、流程图或任何其他可以表达TOGAF思想的符号。
企业内的实体类型及其之间的关系特定于个人 企业。开发高质量的元模型是建立企业架构能力的一个重要方面。
企业元模型是组织特定架构框架的重要组成部分,正如所强调的那样 这里。图 3-7 显示了企业连续体提供了一种从最一般(“基础”)到最具体范围考虑资源的方法 (“组织特定”):
图 3-7:应用企业连续体
为了支持企业元模型的开发,TOGAF 库包括一个基础级核心企业 元模型。它显示类型 实体以及它们之间的关系,这些实体在对大多数企业进行建模时可能需要,并提供上下文 ADM 中建议的工件。
基础企业元模型如图 3-8 所示。
图 3-8:TOGAF 核心企业元模型
为了在企业内有效地开展架构活动,有必要实施 通过组织结构、角色、职责、技能和流程,为体系结构提供适当的业务能力。 TOGAF 架构功能的概述如图 3-9 所示。
图 3-9:TOGAF 架构功能概述
除非纯粹支持变更交付计划的架构功能,否则它越来越得到认可 成功的企业架构实践必须建立在坚实的运营基础上。实际上,企业架构 实践必须像企业内的任何其他运营单位一样运行;也就是说,它应该被视为一项业务。为此, 除了 ADM 中定义的核心流程之外,企业架构实践还应在 以下方面:
财务管理
绩效管理
服务管理
风险和机会管理
资源管理
沟通和利益攸关方管理
质量管理
供应商管理
配置管理
环境管理
操作持续架构概念的核心是执行定义明确且有效的 治理,即所有具有架构意义的活动都在一个框架内进行控制和调整。
随着治理已成为组织管理越来越明显的要求,包括 TOGAF 标准内的治理使框架与当前的业务最佳实践保持一致,并确保 可见性、指导和控制,将支持所有架构利益相关者的要求和义务。
架构治理的好处包括:
提高问责制的透明度,并知情地授权
主动的风险和机会管理
通过最大限度地重用现有架构组件来保护现有资产基础
主动控制、监视和管理机制
在所有组织业务部门中重用流程、概念和组件
通过监控、衡量、评估和反馈创造价值
提高可见性,支持内部流程和外部各方的要求;特别是,增加 较低级别决策的可见性可确保在企业内适当级别监督可能做出的决策 对组织产生深远的战略影响
更大的股东价值;特别是,企业架构越来越代表核心知识分子 企业财产 — 研究表明,股东价值增加与治理良好之间存在相关性 企业
与现有流程和方法集成,并通过添加控制来补充功能 能力
任何企业架构框架的两个关键要素是:
架构活动应生成的可交付结果的定义
应执行此操作的方法的描述
除了一些例外,大多数企业架构框架都专注于其中的第一个——特定的 一组可交付成果 - 并且对用于生成它们的方法相对沉默(故意如此,在某些 案例)。
由于 TOGAF 标准是一个通用框架,旨在用于各种环境,因此它 提供灵活且可扩展的内容框架,支持一组通用体系结构可交付成果。
因此,TOGAF 框架可以单独使用,其通用可交付成果是 描述;否则,这些可交付成果可能会被更具体的集合所取代或扩展,该集合在任何其他框架中定义 建筑师认为相关。
在所有情况下,预计架构师将适应并构建 TOGAF 框架,以便定义 集成到企业流程和组织结构中的定制方法。此架构定制 可能包括采用其他架构框架中的元素,或将 TOGAF 方法与其他标准框架集成,或 最佳实践,如ITIL,® CMMI,COBIT,®® PRINCE2,PMBOK和MSP®。它还可能包括采用来自 TOGAF 库,例如 IT4ITTM参考体系结构。
作为企业架构的通用框架和方法,TOGAF 标准提供了功能和 与其他框架集成的协作环境。组织能够充分利用垂直业务领域, 横向技术领域(如安全性或可管理性),或应用领域(如电子商务)产生有竞争力的 企业架构框架,可最大化其商机。
TOGAF 框架设计灵活,可用于各种架构风格。
建筑风格在重点、形式、技术、材料、主题和时间段方面有所不同。托加夫 标准是一个通用框架,旨在用于各种环境。它是一个灵活且可扩展的框架 可以很容易地适应多种建筑风格。
一个组织的架构景观可以预期包含在许多中开发的架构工作 建筑风格。TOGAF 标准确保在以下背景下适当满足每个利益相关者的需求 其他利益相关者和基线架构。
使用 TOGAF 标准来支持特定的建筑风格时,从业者必须考虑到 建筑表演或表达的独特特征的组合。作为第一步,一个 必须确定样式。
第二步是确定如何解决这些独特特征。解决独特的风格 不应要求对 TOGAF 框架进行重大更改;相反,它应该调整 从业者。
从业者应选择相关的架构资源, 包括模型、观点和工具,以正确描述架构领域并证明利益相关者关注的是 已解决。取决于独特的 功能,不同的建筑风格会添加必须描述的新元素,突出现有元素,调整 用于描述体系结构的表示法,并将架构师的重点放在某些利益干系人或利益干系人关注点上。
解决独特的功能通常包括对架构内容元模型和 使用特定的符号或建模技术以及识别视点。特定建筑风格的主导地位 可以指导从业者重新访问初步阶段,以更改架构功能或解决 在单个ADM周期的预期范围内具有显着特征。
特定于风格的参考模型和成熟度模型是支持从业者的常用工具。
在 TOGAF 框架的生命周期中,已经开发了许多架构样式来解决关键问题 面对从业者,并展示如何在定义的背景下使 TOGAF 框架更具相关性。
为复杂架构的各个部分创建特定“视图”的能力是能够 与利益相关者或利益相关者团体沟通并减轻他们的担忧。获得充分的理解和支持 利益相关者 有必要以每个利益相关者都与之相关和理解的形式呈现信息。
架构视图的作用如图3-10所示,改编自更正式的架构视图 ISO/IEC/IEEE 42010:2011 和 ISO/IEC/IEEE 15288:2015 中的定义。
图 3-10:基本体系结构概念
企业敏捷性是一个常用的术语,但确切的定义因从业者而异。无论如何 该术语是定义的,它很重要,因为它使企业能够通过成为更多的客户和 以产品为中心,更高效,能够更好地确保法规遵从性。
术语“敏捷”经常与与宣言相关的敏捷软件开发过程相关联 用于敏捷软件开发。
虽然这些“敏捷”原则和技术可以应用于适应 TOGAF 框架,但企业敏捷性是一个 比敏捷软件开发更广泛的背景。因此,采用了其他技术来调整 TOGAF 框架 一个敏捷的企业。
企业架构提供了一个变革框架,与战略方向和业务价值相关联。它 提供足够的组织视图来管理复杂性、支持持续更改和管理 意想不到的后果。
TOGAF 框架已经接受了通过 “分区”和“级别”的概念。分区定义了如何将工作分解为多个体系结构计划。水平 定义如何在不同的粒度和细节级别开发整体体系结构。
此外,TOGAF ADM 支持许多以迭代为特征的概念。
有关如何调整 TOGAF ADM 以支持企业敏捷性的更详细说明,请参阅:
TOGAF®系列指南:使用敏捷冲刺应用ADM
TOGAF®系列指南:实现企业敏捷性
开放式敏捷架构TM标准
任何架构/业务转型工作都会存在风险。重要的是要确定, 在开始之前对这些风险进行分类并缓解,以便可以在整个转换工作中跟踪它们。
缓解是一项持续的工作,风险触发因素通常可能超出转型规划者的范围 (例如,合并、收购)因此规划人员必须不断监控转型环境。
同样重要的是要注意,企业架构师可能会识别风险并减轻某些风险,但它 在治理框架内,必须首先接受风险,然后再管理风险。
应考虑两个级别的风险,即:
初始风险级别:在确定和实施缓解措施之前进行风险分类
剩余风险水平:实施缓解措施后的风险分类(如果有)
风险管理过程包括以下活动:
风险分类
风险识别
初步风险评估
风险缓解和剩余风险评估
风险监控
TOGAF 标准中描述了风险管理的定性方法 — ADM 技术。
风险概念包含在 TOGAF 系列指南中描述的企业安全架构中:在 TOGAF®® 企业中集成风险和安全性 建筑。
开放式FAIRTM知识体系中描述了一种更为严格的量化方法,该知识体系包括开放式集团的两个标准:开放式风险分类(O-RT)和开放式风险分析(O-RA)。
大家好,我是Doker品牌的Sinbad,欢迎点赞和评论,您的鼓励是我们持续更新的动力!欢迎加微信进入技术群聊!