TOGAF ADM 概述
这 TOGAF ADM 是一种创造知识的逻辑方法. 用于开发 指导有效变革的企业架构. 然后确保实现预期价值的知识。.
TOGAF ADM 分为几个阶段,每个阶段都专注于创建用于以下方面的知识:
- 选择前进的道路和目标
- 履行 实施治理
- 评估前进的旅程并修正路线
通过阶段 C 的步骤,建筑师可以开发以下知识:
- 哪种参考架构可以加速架构开发
- 哪些观点将推动利益相关者进行相关分析,以便在架构方案之间进行选择
- 哪些应用程序架构模型和数据模型将有助于找到缺陷的根源以及解决该缺陷的变更
- 应用程序架构的变化会推动其他领域的变化
- 其他领域的变化推动了应用程序架构的变化
它创建了以下核心作品产品:
- 从利益相关者的关注点角度分析候选信息系统架构的观点
- 当前和候选目标应用程序架构
- 应用程序架构差距
- 改变业务的候选人工作产品
C 阶段主要关注应用程序设计、数据流、集成、开发方法、自主研发还是外购以及变更规划等方面。正确评估和理解这一阶段至关重要。.
TOGAF 阶段 C 是什么?
在 TOGAF 阶段 C 中,您正在创建应用程序架构。. 应用程序架构师 领导应用程序架构的开发。 架构决策 在阶段 C 中针对应用程序架构做出的决策与在每个阶段中做出的决策进行交互 企业架构领域.
C阶段行动
应用程序架构将有助于回答以下问题:
- 应用程序组合如何实现价值捕获 – 应用程序开发模型
- 成本注入 IT 投资组合的地方 - 功能模型
- 在 IT 投资组合中注入刚性的地方 - 集成模型
- 企业如何运作 – 系统模型
- 交付产品或服务所需的系统—— 产品型号
- 一个组织必须能够做的事情—— 功能模型
- 企业活动所需的信息流—— 集成模型
- 企业执行的完整活动,通常分组以显示它们之间的相互关系 - 服务模型
- 软件组合是什么 – 物理模型
始终牢记,你正在寻求改进组织。改进需要变革,并带来价值。变革的价值和成本是可以衡量的。不确定性总是会降低潜在价值,也总是会增加成本。我们将不确定性视为几何级数的影响。一点点不确定性就会大大降低潜在价值。.
阅读时,请记住,相同的术语有多种用法。请了解模型的用途,不要被标签与你的称呼不同所困扰。例如,你称之为函数模型的东西,别人可能会称之为服务。在我们的 企业架构咨询, ,我们总是关注我们试图理解的东西,而不是模型的名称。.
不同的模型将解释企业的不同方面。这些模型和所需的变更共同构成了应用程序架构。.
什么是应用程序架构?
应用程序架构是对完整软件组合的描述,它告诉您何时购买、何时使用 SaaS 以及何时构建。它告诉您应该在何处设置系统之间的边界。它告诉您如何处理软件生命周期。.
我们可以保证,您当前的应用程序架构与您的业务架构并不一致。应用程序架构需要 业务架构. 。开发业务架构需要应用程序架构师的参与并与利益相关者进行互动。.
应用程序架构师将与利益相关者和业务架构师一起,探讨软件选择如何支持和限制组织目标的实现。我们会考虑潜在的改进,以了解其短期和中期影响。此外,我们会将那些交付成果过少、工作量过大或不确定性过高的潜在变更从架构路线图中剔除。.
当我们 发展企业架构团队, ,我们告诉 企业架构师 关于 TOGAF 阶段 C(应用程序架构)的两个核心事实。首先,直到你有一个 应用程序开发模型,, 你无法继续下去。除非你了解你的应用程序选择如何赋能和约束你的业务架构,否则应用程序的细节毫无意义。其次,如果他们认为需要深入研究应用程序功能和集成,他们就会开发出低质量的应用程序架构。.
在现代 数字化转型企业, 所有架构领域都会相互作用。一个领域的选择会促成、交付或阻碍另一个领域的结果。大多数业务目标取决于 正确的 IT 架构. 具有讽刺意味的是,只有拥有坚实的业务架构,我们才能开发正确的应用程序架构。.
企业架构师在阶段 C 中扮演什么角色?
在 TOGAF 阶段 C 中,企业架构师的职责是守护整体价值。企业架构师需要根据领域架构师的技能来填补空缺。例如,应用程序架构师可能看不到业务架构变更的影响。或者,他们可能无法以安全架构师能够采取行动的方式清晰地表达需求。.
企业架构师最重要的角色是跨越界限。无论是领域、技能还是权限界限,企业架构师都需要跨越它们。.
EA 团队在应用程序架构中扮演什么角色
请记住,一个领域的缺陷通常会在另一个领域得到解决,并且一个领域的变化通常会给另一个领域带来成本和变化。.
与 TOGAF 阶段 B、阶段 D 和阶段 E 的交互
瀑布式方法无法实现目标。最佳实践的企业架构并非瀑布式活动。唯一成功的方法需要开发业务架构、应用架构、数据架构、技术架构以及 安全架构 同时进行。同时开发需要一种敏捷的方法来测试级联约束。.
许多 TOGAF ADM 图中隐含的经典顺序是我们可以结束架构开发的顺序,而不是启动它的顺序。.
不要误以为'业务'与其应用程序、数据和基础设施是分离的。过去并非如此,在现代数字化企业中更是可笑。这种错觉是消除 企业敏捷性 或者 数字化转型 成功。.
应用程序架构师在企业架构团队中扮演着至关重要的角色。在现代数字化企业中,没有软件就无法开展任何工作。糟糕的应用程序选择会严重影响企业架构。'业务.。应用架构师是某个架构领域的专家。如果没有定期与 商业架构师, 、数据、技术和 安全架构师.
C阶段基本知识
TOGAF ADM 的所有阶段都将引导您发展所需的知识。阶段 C 的成果是候选信息系统架构中包含的候选应用程序架构。.
| 产出与成果 | 基本知识 |
| 这 应用程序架构领域架构 针对所要解决的问题,提出一系列差距,并努力消除利益相关者所理解的差距。. | 当前的软件组合为何无法满足利益相关者的偏好?
为了使软件组合满足利益相关者的偏好,必须进行哪些改变?(差距) 为了实现与所创造的附加价值相一致的改变,需要做哪些工作?(工作包) 利益相关者的优先级和偏好如何根据价值、工作量和变化风险进行调整。(利益相关者的要求) |
表 4 来自 TOGAF系列指南:企业架构师的架构开发指南
C阶段基本框架
在阶段 C,我们可以简化应用程序架构师的工作,使其专注于确定企业如何才能变得更好。这需要了解企业想要擅长什么,在哪些方面还存在不足,以及需要做出哪些改变才能达到最佳状态。.
C阶段的基本内容如下:
- 了解应用程序组合如何实现价值捕获
每个组织都有一条价值链。价值链是指将投入转化为对客户更有价值的东西的活动。应用程序要么创造价值,要么提供记录保存服务。传统上,几乎所有软件都提供记录保存服务。.
您必须针对具体角色(无论是价值创造还是记录保存)优化您的软件。承担记录保存的重任。不要混淆记录保存与价值创造的重要作用。.
了解成本和复杂性的来源
每个应用程序组合都会产生成本和复杂性。我们将软件视为一个复杂的钟表机构,随着时间的推移不断组装。我们将万物互联。随着数字产品和无处不在的IT服务 了解 ITFM 是一项基础技能。.
您必须优化核心产品组合,以降低持续的成本和复杂性。您必须能够 企业敏捷性. 。现代数字化组织只能随着软件的步伐而进步。.
- 了解如何选择软件
软件模式有四种:SaaS、企业套件、专业商业套件和定制开发。每种模式都有不同的成本和优化模型。您需要在合适的场景下应用合适的软件模式。.
- 知道软件何时属于'产品'
我们的组织提供产品或服务。软件是'产品'' 与支持业务的软件有很大不同。.
- 了解信息流
人类拥有无限的灵活性。我们可以决定是否共享信息。我们可以主动观察情况并做出反应。软件会严格按照指令执行。软件只会执行指令。.
信息流围绕软件进行,以完成正确的任务。这种信息流破坏了企业的敏捷性,降低了效率,并增加了成本。.
- 了解软件的期望
有时我们需要一个临时的记录员。有时我们需要一个自主的系统。大多数时候,我们需要一些不需要太多开销就能提供帮助的东西。我们利用 能力模型 指导我们选择应用程序架构。请参阅 业务架构能力评估指南.
- 了解组织必须做什么
每个企业都有一套必须执行的流程:主要价值创造、支持和管理。每个企业都需要软件。每个企业都在创建和生产信息。你需要了解它们是什么,它们消费什么信息,以及谁在执行这些信息。.
- 为了提供最佳的应用程序组合,必须做出哪些改变?
我们开发应用程序架构是为了改进组织。大多数变更不会带来实质性的变化,大多数变更只是些边缘小修小补。请将时间集中在那些能够显著提升企业敏捷性、降低成本或创造价值的实质性变革上。.
C阶段的三个完成要点:
- 第一的, 哪些必须改变?改变重心、组织设计、提升技能、外包、内包、自动化。这些都是改变。我们这样做是为了改进组织。.
- 第二, 什么时候必须更改?是否存在依赖关系?先决条件如何?你的更改是否为后续更改做好了铺垫?
- 第三, 你们如何知道变革是否成功?你们的治理测试是什么?你们将如何守护价值?
企业架构利益相关者负责决定哪些变更以及何时变更。应用程序架构师负责描述治理测试,以使利益相关者能够指导变更项目,这是第二和第三个结果。.
TOGAF ADM 阶段 C 应用架构交付成果
阶段C的核心成果之一是应用程序架构。这是完整企业架构的一部分。.
TOGAF C 阶段应用程序架构交付成果和企业架构用例
开发企业架构有四个核心目的。不同的 TOGAF C 阶段交付成果在每个目的中具有不同的重要性。.
| 支持战略的架构 | 支持投资组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| C阶段工作产品:候选应用程序架构 | 关键交付成果
主要用途是利益相关者对目标和工作的理解。. 次要用途是为建筑师创建架构需求规范 |
关键交付成果
主要用途是利益相关者对目标和工作的理解。. 次要用途是为建筑师创建架构需求规范 |
在项目启动和商业案例最终确定之前
主要用途是为实施者创建架构需求规范 |
在执行合作伙伴(包括内部供应商)参与之前
主要用途是为实施者创建架构需求规范 |
| C阶段工作产品:候选路线图项目 | 关键交付成果
主要用途是利益相关者对工作的理解。. 二次使用为建筑师创造了限制 |
关键交付成果
主要用途是利益相关者对工作和依赖性的理解。. 二次使用为建筑师创造了限制 |
限制使用 可以作为具有多个交互式变化的项目的输入 |
在执行合作伙伴(包括内部供应商)参与之前。.
主要用途是识别所需的变更以及如何执行变更的偏好,以管理解决方案交付合作伙伴的选择和参与 |
| C 阶段工作产品:架构需求规范 | 限制使用
通常建筑师可以从优越的建筑中推断出限制。. |
限制使用
通常建筑师可以从优越的建筑中推断出限制。. |
关键交付成果
项目启动完成前 |
关键交付成果
订婚和签约前 |
候选应用程序架构
开发企业架构有四个核心目的,不同的模型在每个目的中具有不同的重要性。.
候选应用程序架构路线图组件
哪些方面必须改变?如果您要改变应用程序开发模型,那么当前和目标之间的差异就在于路线图候选版本。实现这一改变所需的一切也都在于此。.
我们经常使用系统模型来概括变更。系统模型允许从实际软件中提取足够的抽象,以便进行规划和执行对话。我们通常使用分数和工作包来表达变更。有关使用分数的更多信息,请参阅 业务架构能力评估指南.
我们在以下方面使用所有架构路线图组件 TOGAF 阶段 E - 架构路线图.
候选应用程序架构需求规范
明确如何评估变革。如何评估改进?
我们经常在模型中使用分数来描述需求。每个需求都是对效率、自动化、敏捷性或执行者的衡量。然后,当我们在 TOGAF 阶段 G 表演 架构治理与变革项目 我们使用这些分数来评估设计和实施。.
应用程序架构模型、工具和技术
TOGAF ADM 阶段 C 交付信息系统架构。此阶段旨在开发构成信息系统的应用程序架构和数据架构。在 TOGAF 中,第一步是确定所需的视图和模型。.
利益相关者的关注点将确定观点。核心应用程序架构模型有七种。.
- 应用程序开发模型,描述系统开发的可接受方法
- 系统模型,用于捕获应用程序组合所围绕设计的大型系统
- 功能模型描述了软件组合需要执行的所有操作
- 产品模型,用于识别您组织的产品和服务中使用的功能以及管理这些功能的功能
- 集成模型描述了信息如何在您的应用程序组合中流动
- 服务模型将您的应用程序组合分解为黑匣子,并允许您确保每个服务都具有所需的敏捷性、自动化和其他属性
- 物理模型识别应用程序组合中的真实应用程序(商业、SaaS 或定制)
应用程序架构将有助于回答以下问题:
- 应用程序组合如何实现价值捕获 – 应用程序开发模型
- 成本注入 IT 投资组合的地方 - 功能模型
- 在 IT 投资组合中注入刚性的地方 - 集成模型
- 企业如何运作 – 系统模型
- 交付产品或服务所需的系统—— 产品型号
- 一个组织必须能够做的事情—— 功能模型
- 企业活动所需的信息流—— 集成模型
- 企业执行的完整活动,通常分组以显示它们之间的相互关系 - 服务模型
- 软件组合是什么 – 物理模型
始终牢记,你正在寻求改进组织。改进需要变革,并带来价值。变革的价值和成本是可以衡量的。不确定性总是会降低潜在价值,也总是会增加成本。我们将不确定性视为几何级数的影响。一点点不确定性就会大大降低潜在价值。.
阅读时,请记住,相同的术语有多种用法。请了解模型的用途,不要被标签与你的称呼不同所困扰。例如,你称之为函数模型的东西,别人可能会称之为服务。在我们的 企业架构咨询, ,我们总是关注我们试图理解的东西,而不是模型的名称。.
不同的模型将解释企业的不同方面。这些模型和所需的变更共同构成了应用程序架构。.
应用程序架构模式
我们使用 架构模式 大幅提高我们架构开发的生产力和质量。 架构模式模板 促使我们去理解 可预见的问题, 模式方法, ,以及 硬位. 成功实施该模式需要解决 硬位 (所需工作、约束和限制)。.
示例应用程序架构模式
示例应用程序架构模式涵盖应用程序结构、迁移以及如何进行应用程序设计的问题。.
- 应用程序结构
- MVC(模型-视图-控制器)模式
可预见的问题—代码组织、可维护性和可测试性
方法—将应用程序分为三个相互连接的组件——模型(数据和业务逻辑)、视图(用户界面)和控制器(处理用户输入并相应地更新模型和视图)
- MVC(模型-视图-控制器)模式
- 应用程序迁移
- 绞杀者模式
可预见的问题—取代遗留系统
方法—通过围绕现有遗留系统构建新组件来逐步替换或“扼杀”现有遗留系统
- 绞杀者模式
- 应用程序设计(四人组应用程序模式)
作为企业架构师,我们使用设计模式来限制应用程序开发团队的自由。(参见 企业架构与敏捷 - 约束冲刺)- 单例模式- 确保一个类只有一个实例,并提供对该实例的全局访问点
应用程序架构模型
开发应用程序架构需要开发几个 企业架构模型. 每种模型对企业软件组合的解释都不同。TOGAF C 阶段应用架构旨在通过这些模型开发目标架构。确保目标应用架构师与其他领域协同工作,从而为您的企业带来最佳改进。.
总的来说,这些模型描述了应用程序架构。在完整的企业架构中,这些模型将链接到描述其他企业架构领域的其他模型。.
应用程序开发模型
应用程序开发模型描述了软件的开发方式。该模型需要功能模型或物理模型。功能模型更为理想,因为它能够逻辑地识别软件。.
应用程序开发类型有四种:SaaS、企业套件、专业商业套件和定制开发。每种类型都有其独特的特点和含义。.
- SaaS 的特点包括:软件打包,接口定义明确。生命周期由第三方控制。不支持定制。.
最适合用于行政管理类业务活动,并间接支持价值创造活动。严格的软件限制会限制业务活动,并有助于强制采用标准的行业惯例。.
- 企业套件的特点包括多个重叠的功能模型,并具有明确的数据模型。接口和功能可以配置或定制。定制必然会在生命周期内产生额外成本。生命周期受第三方影响。.
- 专业商业软件包的特点包括针对特定业务活动进行重点关注和功能优化。通常围绕一种业务活动处理方式进行设计。通常具有独特且定义明确的数据模型。接口和功能可配置。可能支持定制。定制在生命周期内必然会产生大量成本。生命周期受第三方影响较大。.
- 定制开发的特点包括:直接协调组织原有的组织边界和活动。始终旨在支持组织现有的沟通模式。重点关注专业活动并进行功能优化。数据模型定义不明确。接口和功能必须定制。生命周期管理通常被忽视,并且持续成本高昂。.
最适合用于主价值链中的业务活动。其灵活性有助于优化价值创造方式。有效利用它需要了解当前和未来的价值创造。.
应用程序开发模型
应用程序开发模型描述了软件的开发方式。该模型需要功能模型或物理模型。功能模型更为理想,因为它能够逻辑地识别软件。.
应用程序开发类型有四种:SaaS、企业套件、专业商业套件和定制开发。每种类型都有其独特的特点和含义。.
- SaaS 的特点包括:软件打包,接口定义明确。生命周期由第三方控制。不支持定制。.
最适合用于行政管理类业务活动,并间接支持价值创造活动。严格的软件限制会限制业务活动,并有助于强制采用标准的行业惯例。.
- 企业套件的特点包括多个重叠的功能模型,并具有明确的数据模型。接口和功能可以配置或定制。定制必然会在生命周期内产生额外成本。生命周期受第三方影响。.
- 专业商业软件包的特点包括针对特定业务活动进行重点关注和功能优化。通常围绕一种业务活动处理方式进行设计。通常具有独特且定义明确的数据模型。接口和功能可配置。可能支持定制。定制在生命周期内必然会产生大量成本。生命周期受第三方影响较大。.
- 定制开发的特点包括:直接协调组织原有的组织边界和活动。始终旨在支持组织现有的沟通模式。重点关注专业活动并进行功能优化。数据模型定义不明确。接口和功能必须定制。生命周期管理通常被忽视,并且持续成本高昂。.
最适合用于主价值链中的业务活动。其灵活性有助于优化价值创造方式。有效利用它需要了解当前和未来的价值创造。.
系统模型
系统模型是围绕活动对软件的抽象。思考一下‘供应链系统’以及供应链中涉及的一切。系统模型的设计将与企业的运营方式保持一致。.
与业务架构师的能力模型类似,系统模型能够帮助你将思考直接导向系统。你可以着眼于改进整个系统,然后将所需的改进重点放在构成系统并与之交互的所有组件上。.
产品型号
产品模型是功能模型的专门版本,它突出了您的产品或服务所需的功能。一个好的产品模型会以可比的方式对执行的操作进行分类。.
良好的产品模型将构成 参考架构 为您的产品。您需要明确产品价值、用途和管理的核心功能。产品模型将指导应用程序开发模型的选择。当这些功能与您的产品和服务相关时,您需要定制开发、复制以及更高的变更能力。.
功能模型
功能模型将你的软件组合分解成功能。它确定了软件需要做的所有事情。好的功能模型能够提供广泛的覆盖范围。.
与业务架构师的流程模型类似,功能模型通常是一种参考架构。当您寻求复制和集成时,它非常有用。它通常构成应用程序开发模型的基础,其中不同的功能块被分配到不同的目标应用程序开发类型。.
在应用程序组合规划中至关重要。复制和集成会增加 IT 产品组合的复杂性和成本。.
BIAN、FEAF、TMForum 的 ODF 和 IndEA 均提供功能模型。.
服务模型
服务模型是功能模型的特化版本,它将功能压缩成具有已知接口的黑盒。良好的服务模型对于开发应用程序开发模型和验证系统模型中的目标至关重要。服务模型中的所有接口都应该在集成模型中得到清晰的识别。.
良好的服务模型将助力企业实现敏捷性。这种敏捷性并非源于应用服务的开发,而是通过将企业某个部门的变更与另一个部门的变更分离。.
物理模型
物理模型是真实的软件组合。我们将使用商业软件供应商和您的应用程序开发程序所使用的术语来描述它。您需要将其与其他应用程序架构模型关联起来,才能将目标转化为实际应用。.
您可以使用物理模型作为抽象应用程序架构模型的约束。它也构成了 通过 F 阶段制定的实施和迁移计划.
应用程序架构技术
我们使用广泛的技术来开发和传达我们的应用程序架构。.
- UML 在良好的模型驱动开发中无处不在。当您在架构中工作以支持解决方案开发时,应该遵循 UML 实践来开发功能模型和集成模型。.
- 4+1 视角对于识别目标对不同社区的影响非常有用。开发 4+1 模型有助于确保您考虑到所有相关的变化。.
- DODAF 的信息需求线提取所有必需的信息流。无论节点是个人、组织还是系统,信息都会流入和流出。消除自动化的最快方法是将手动步骤置于信息流的中间。.
与企业架构用例一致的应用程序架构模型
您使用应用程序架构回答的问题级别将决定使用不同的应用程序架构模型。例如,支持产品组合的架构通常不会开发价值链模型。相反,价值链通常是更高级的架构,并且 限制你的自由.
| 支持战略的架构 | 支持投资组合的架构 | 支持项目的架构 | 支持解决方案交付的架构 | |
| 应用程序开发模型 | 关键交付成果 | 关键交付成果 | 卓越的建筑 | 卓越的建筑 |
| 系统模型 | 定期交付 | 关键交付成果 | 卓越的建筑 | 卓越的建筑 |
| 功能模型 | 定期交付 | 关键交付成果 | 关键交付成果 & 卓越的建筑 | 关键交付成果 & 卓越的建筑 |
| 产品型号 | 偶尔交付
适当的细节水平往往会降低价值 |
定期交付
适当的细节水平往往会降低价值 |
关键交付成果 | 关键交付成果 |
| 集成模型 | 偶尔交付
适当的细节水平往往会降低价值 |
定期交付
适当的细节水平往往会降低价值 |
关键交付成果 | 关键交付成果 & 卓越的建筑 |
| 服务模型 | 偶尔交付
适当的细节水平往往会降低价值 |
定期交付 | 关键交付成果 & 卓越的建筑 | 关键交付成果 & 卓越的建筑 |
业务架构模型对应用架构模型的影响
| 商业模式 | 运营模式 | 价值链 | 能力模型 | 流程模型 | 功能模型 | 信息模型 | 组织模型 | |
| 应用程序开发模型 | 主要输入
需要系统或功能模型 |
主要输入
需要系统或功能模型 |
主要输入
需要系统或功能模型 |
主要输入
需要系统或功能模型 |
主要输入
需要系统或功能模型 |
主要输入
需要系统或功能模型 |
有限的输入 | 有限的输入 |
| 系统模型 | 有限的输入 | 有限的输入 | 有限的输入 | 有限的输入 | 有限的输入 | 主要输入 | 有限的输入 | 主要输入 |
| 产品型号 | 主要输入 | 主要输入 | 主要输入 | 有限的输入 | 有限的输入 | 有限的输入 | 有限的输入 | |
| 集成模型 | 输入非常有限 | 核心设计的主要投入
需要系统或功能模型 |
核心设计的主要投入
需要系统或功能模型 |
最佳输入
直接链接很难找到。值得做这项工作。. |
核心设计的主要投入
需要系统或功能模型 |
有限的输入
仅在没有其他型号时使用 |
核心设计的主要投入
需要系统或功能模型 |
核心设计的主要投入
需要系统或功能模型 |
| 服务模型 | 有限的输入
这些联系很重要,但很难看出直接联系 |
有限的输入
这些联系很重要,但很难看出直接联系 |
有限的输入
这些联系很重要,但很难看出直接联系 |
最佳输入
直接链接很难找到。值得做这项工作。. |
用作完整性测试 | 主要输入
直接链接很难找到。值得做这项工作。. |
主要输入 |
企业架构用例的应用程序架构模型
全部 企业架构用例 都是关于变化的。它们都关注变化的类型,以及如何 企业架构师 帮助决策者规划前进的道路。.
我将企业架构用例视为变更的类型、企业架构团队的目的或常见问题。.
在每个企业架构用例中,我们都在履行相同的职责。我们协助利益相关者做出更明智的决策,并引领成功的变革举措。所有改变的,都只是问题本身。.
| 战略变革 | 渐进式变革 | 改善成本 | 提高质量 | 提高企业敏捷性 | 降低技术风险 | IT现代化 | 数字化转型 | 应用程序组合合理化 | 收购整合 | |
| 应用程序开发模型 | 关键约束 | 关键指南 | 关键约束 | 关键约束 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | ||
| 系统模型 | 非常有用
关键差距和制约因素 |
关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | |||||
| 产品型号 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | |||||
| 集成模型 | 告知约束 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | 关键差距和制约因素 | |
| 服务模型 | 对于差距和限制非常有用 | 对于差距和限制非常有用 | 对于差距和限制非常有用 | 对于差距和限制非常有用 | 对于差距和限制非常有用 | 对于差距和限制非常有用 | 对于差距和限制非常有用 |
将企业架构原则应用于应用程序架构
我们已经确定 每个企业架构师都应该知道的 7 个架构原则. 下表列出了这些架构原则对应用程序架构的影响。在执行 企业架构治理, 您需要测试您的应用程序架构,以确保它符合上级架构。它是否符合企业架构原则?
| 应用程序架构含义 | |
| 不要与成功混为一谈 | 如果项目并非差异化或转型,则应考虑消除变更。应避免所有未明确成本和结果合理的流程或系统变更。. |
| 追求卓越 | 与 运营模式 这 能力模型.
利用应用程序开发模型将支出重点放在差异化上。. 利用产品模型专注于产品和服务的交付。. |
| 为什么不是一个? | 利用应用程序开发模型和产品模型来识别禁止重复的区域。. |
| 数据是一种资产 | 确保数据模型的控制不会以降低数据资产价值的方式被放弃。. |
| 系统在我们工作的地方工作 | 工作地点和工作风格驱动界面和应用模型。. |
| 轻松的用户体验 | 效率计划关注现有的业务流程。.
随着新流程经验的积累,差异化和转型计划需要改变用户界面和参与度。. |
| 自助服务 | 如果应用程序管理活动和部署不是自助服务,则成本很高
用户体验差,成本高。. |
TOGAF 阶段 C 如何与敏捷开发保持一致?
应用程序架构将为敏捷开发提供多种约束和指导。其根本指导来自应用程序开发模型。它能识别出哪些地方不适合敏捷开发。.
企业架构与敏捷开发 将在四个区域相交。 企业架构将:
- 定义敏捷方法
- 指导冲刺中的积压工作
- 限制冲刺中的选择
- 解决交叉产品依赖性
我们始终将敏捷开发重点放在创新的差异化活动上,并严格遵循其他领域既有的最佳实践。最佳实践源自成熟的商业软件。务必确保应用程序架构与业务架构保持一致,并专注于系统获取方式。.
TOGAF 阶段 C 如何实现企业敏捷性?
企业敏捷性与软件编写方式无关. 企业敏捷性是指企业应对意外威胁和机遇的能力。如果你需要编写代码,那么你的 应对威胁或机遇面临风险.
应用程序架构师将重点关注第五个方面 企业敏捷模型 - 灵活性。我们使用相同的敏捷属性和分数 能力评估指南 识别那些必须能够快速变化的信息系统。然后,我们进行架构设计,以支持变革。.
企业敏捷模型
- 警觉性——您能发现机会和威胁吗?
- 可访问性——您能否及时访问相关信息并做出回应?
- 果断性——您能否利用现有信息做出决定?
- 迅速性——您能在可用的时间内实施您的决定吗?
- 灵活性——您正在采取什么措施来减少行动障碍?
TOGAF ADM C 阶段的目标是什么?
在 A阶段, ,你确定了一个 简化的目标架构——架构愿景. 架构愿景涵盖所有领域。阶段 C 中的活动将进一步开发应用程序和数据架构领域。成功需要:
- 你解决了当前企业无法满足利益相关者偏好的问题
- 您了解必须做出哪些改变才能使企业满足利益相关者的偏好?(差距)
- 您对交付变更所需的工作(工作包)有充分的了解
- 您了解其他架构领域中的变化和约束之间的相互作用,以保护预期的价值(架构需求规范)
阶段 C 的核心成果是候选应用程序架构。应用程序架构师与其他领域架构师合作,了解应用程序架构的约束,以及其他领域的约束。.
请记住,TOGAF ADM 探索的是潜在的变化。直到你开发 F阶段实施计划, 寻找最便宜的出口。糟糕的想法并不意味着你没有解决问题。你应该摒弃那些不靠谱的想法。 架构替代方案. 尽早停止糟糕的想法,既能省钱,又能成功改变。一旦想法变糟,就立即停止。彻底放弃这个想法。庆祝你的胜利!庆祝你正在成功改变!
应用程序架构模式
我们使用 架构模式 大幅提高我们架构开发的效率和质量。我们使用简化的 架构模式模板 这促使我们去理解 可预见的问题, 模式方法, ,以及 硬位. 模式的适用性通常由所需的工作、约束和限制决定。.
示例应用程序架构模式
示例应用程序架构模式涵盖应用程序结构、迁移以及如何进行应用程序设计的问题。.
- 应用程序结构
- MVC(模型-视图-控制器)模式
可预见的问题—代码组织、可维护性和可测试性
方法—将应用程序分为三个相互连接的组件——模型(数据和业务逻辑)、视图(用户界面)和控制器(处理用户输入并相应地更新模型和视图)
- MVC(模型-视图-控制器)模式
- 应用程序迁移
- 绞杀者模式
可预见的问题—取代遗留系统
方法—通过围绕现有遗留系统构建新组件来逐步替换或“扼杀”现有遗留系统
- 绞杀者模式
- 应用程序设计(四人组应用程序模式)
作为企业架构师,我们使用设计模式来限制应用程序开发团队的自由。(参见 企业架构与敏捷 - 约束冲刺)- 单例模式- 确保一个类只有一个实例,并提供对该实例的全局访问点
关于 TOGAF ADM 阶段 C 的最终思考
应用程序架构师与 企业架构团队 承担着比设计应用程序更重要的责任。他们需要为企业应用程序组合的架构、设计、实施和开发人员制定指导方针和防护措施。简而言之, 企业应用程序架构师不同于解决方案架构师或应用程序架构师 不与 EA 团队合作的人。.
在 TOGAF ADM 阶段 C 工作的应用程序架构师扮演着复杂的角色。.
- 与利益相关者和中小企业合作,选择应用程序组合中的变更,以实现最佳的未来组织
- 与同事一起工作 领域架构师 探索如何在应用领域中实现或阻止业务领域所需的改进
- 与利益相关者合作,消除应用程序组合中交付过少或成本过高的变更。此外,消除其他领域中导致应用程序组合成本和变更不可接受的变更。
在 TOGAF ADM 阶段 C 中,四个基础 企业架构领域 已开发。TOGAF 非常明确地指出,您应该在其他域的开发过程中开发此架构。一个域中的更改将启用、强制或阻止另一个域中的更改。.
高效的企业架构团队不会将其应用程序架构师用作单个应用程序的设计者。这个角色固然必要,但如果应用程序架构不能涵盖企业的重要部分,就无法优化企业。.
TOGAF ADM C阶段开发应用程序架构。应用程序架构是所有现代数字化企业的基础。. 使用 TOGAF 阶段 C 来 将稀缺的变革资源集中于获取最大的企业价值。.