TOGAF ADM 概述
这 TOGAF ADM 是一种创造知识的逻辑方法. 用于开发 指导有效变革的企业架构.然后知识确保实现预期价值。
TOGAF ADM 分为几个阶段,每个阶段都侧重于创建用于以下方面的知识:
- 选择前进的道路和目标
- 履行 实施治理
- 评估前进的道路并修正路线
什么是 TOGAF C 阶段?
C 阶段进一步推动了 架构领域。此阶段开发应用程序架构和数据架构。正式的阶段 C 拆分将数据架构域和应用程序架构域分开处理。
与阶段 B 一样,阶段 C 以架构愿景为基础。但有一点不同,阶段 C 有进一步的义务来实现业务架构。这并不是将业务架构视为需求,而是确保开发中的概要目标保持一致。
一个领域的变化会将约束和要求带入其他领域。目标是找到跨所有领域的最佳变化组合。
通过阶段 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 阶段如何与敏捷开发保持一致?
应用架构将为敏捷开发提供多重约束和指导。基本指导来自应用程序开发模型。它确定了您不希望敏捷开发的地方。
企业架构和敏捷开发 将在四个区域相交。这 企业架构将:
- 定义敏捷方法
- 指导 sprint 中的积压工作
- 限制 sprint 中的选择
- 解决交叉产品依赖
我们始终将敏捷开发重点放在新颖的差异化活动上,并无情地遵循其他地方已建立的最佳实践。最佳实践来自成熟的商业软件。确保您的应用程序架构与您的业务架构保持一致,并专注于您如何获取系统。
TOGAF C 阶段如何实现企业敏捷性?
企业敏捷性与您编写软件的方式无关.企业敏捷性是关于您的企业对意外威胁和机遇做出反应的能力。如果你需要编写代码,你的能力 应对威胁或机会面临风险.
应用程序架构师将专注于 企业敏捷模型 - 灵活性。我们使用相同的敏捷属性和分数 能力评估指南 识别必须能够快速变化的信息系统。然后我们进行架构设计以实现变革。
企业敏捷模型
- 警觉性——你能发现机会和威胁吗?
- 可访问性——您能否及时访问相关信息以做出回应?
- 果断——你能决定使用可用的信息吗?
- 敏捷性——你能在可用的时间内实施你的决定吗?
- 灵活性——您正在采取哪些措施来减少行动障碍?
TOGAF ADM C 阶段的目标是什么?
在 A阶段,你确定了一个 简化的目标架构——架构愿景.架构愿景包括所有领域。阶段 C 中的活动,进一步开发应用程序和数据架构领域。成功需要:
- 您解决了当前企业如何无法满足利益相关者偏好的问题
- 您了解必须做出哪些改变才能使企业满足利益相关者的偏好? (间隙)
- 您对交付变更所必需的工作有足够的了解(工作包)
- 您了解其他架构领域中更改和约束之间的交互,以保护预期的价值(架构需求规范)
阶段 C 的核心成果是候选应用程序架构。应用程序架构师与其他领域架构师合作,以了解对应用程序架构施加的约束,以及对其他域施加的约束。
请记住,TOGAF ADM 探索潜在的变化。直到你开发 F阶段的实施计划,寻找最便宜的出口匝道。坏主意并不意味着你没有解决问题。你应该丢弃弱 架构替代方案.尽早停止糟糕的想法可以节省资金并实现成功的变革。当一个想法变坏的那一刻,停止死在你的轨道上。扼杀这个想法。庆祝你的胜利!庆祝您正在促成成功的改变!
应用程序架构模式
我们用 架构模式 显着提高架构开发的生产力和质量。我们使用简化的 架构模式模板 这促使我们理解 可预测的问题, 模式方法, 和 困难的部分。模式的适用性通常由所需的工作、约束和限制驱动。
示例应用程序架构模式
示例应用程序架构模式涵盖了应用程序结构、迁移以及如何设计应用程序的问题。
- 应用结构
- MVC(模型-视图-控制器)模式
可预测的问题——代码组织、可维护性和可测试性
方法— 将应用程序分为三个互连的组件 — 模型(数据和业务逻辑)、视图(用户界面)和控制器(处理用户输入并相应地更新模型和视图)
- MVC(模型-视图-控制器)模式
- 应用迁移
- 绞杀者图案
可预测的问题—替换遗留系统
方法—通过围绕现有遗留系统构建新组件来逐步替换或“扼杀”现有遗留系统,以逐步替换系统
- 绞杀者图案
- 应用程序设计(四种应用程序模式组)
作为企业架构师,我们使用设计模式作为应用程序开发团队自由的约束。 (看 企业架构和敏捷 - 约束冲刺)- 单例模式- 确保一个类只有一个实例并提供对该实例的全局访问点
关于 TOGAF ADM 阶段 C 的最终想法
应用程序架构师与 企业架构团队 有一组比设计应用程序更重要的职责。他们需要为人们构建、设计、实施和开发企业的应用程序组合制定指导方针和护栏。简而言之, 企业应用程序架构师不同于解决方案架构师或应用程序架构师 谁不与 EA 团队合作。
在 TOGAF ADM 阶段 C 工作的应用程序架构师扮演着复杂的角色。
- 与利益相关者和 SME 合作,选择应用程序组合中的更改,以实现最佳的未来组织
- 与同龄人一起工作 领域架构师 探索如何在应用程序领域启用或阻止业务领域所需的改进
- 与利益相关者合作,消除应用程序组合中交付太少或成本太高的变化。此外,消除其他领域的变化,这些变化会导致不可接受的成本和应用程序组合的变化
在 TOGAF ADM 阶段 C 中,四个基础之一 企业架构领域 被开发。 TOGAF 非常清楚您在开发其他领域的过程中开发了这种架构。一个域中的更改将启用、强制或阻止另一个域中的更改。
功能强大的 EA 团队不会将其应用程序架构师用作单个应用程序的设计者。该角色是必要的,但如果没有涵盖企业重要部分的应用程序架构,您将无法优化企业。
TOGAF ADM 阶段 C 开发应用程序架构。应用架构是所有现代数字化企业的基础。 使用 TOGAF C 阶段 将稀缺的变革资源集中在获得最大的企业价值上。