TOGAF中的迁移规划技术提供了一种结构化的方法,用于评估和规划企业架构的实施与迁移。通过使用这些技术,架构师可以确保计划全面且与业务目标保持一致,同时考虑可能影响实施的约束和依赖关系。
每种技术都有其特定的目的,可以在迁移规划过程的不同阶段使用。例如,实施因素评估与推论矩阵有助于识别和记录影响实施的因素,而业务价值评估技术则有助于评估不同选项的价值和风险。
通过结合使用这些技术,架构师可以制定一个全面的迁移计划,充分考虑所有相关因素,确保企业架构的成功实施。
TOGAF ADM 实施因素评估与推论矩阵
TOGAF ADM 实施因素评估与推论矩阵是一种用于识别和评估可能影响企业架构计划实施的因素的工具。该矩阵通常包含三个列,分别为:
- 因素:此列列出可能影响架构计划实施的各种因素。这些因素可能包括风险、问题、假设、依赖关系、行动、影响或其他相关因素。
- 描述:此列对每个因素提供简要说明,解释其含义以及为何在制定计划时需要考虑它。
- 推论:此列概述了基于每个因素需要做出的推论。这些推论表明在制定实施计划时必须考虑的行动或约束。
例如,假设矩阵中列出的一个因素是“风险”。在描述列中,该因素可能被定义为“可能影响实施计划成功与否的潜在负面事件或情况”。在推论列中,矩阵可能表明应评估并优先处理任何已识别的风险,并制定适当的风险缓解策略。
总体而言,实施因素评估与推论矩阵是一种有用的工具,可确保在制定实施计划时考虑所有相关因素,并采取适当措施应对潜在问题或约束。
—
以下是基于转向即时消息的可能的矩阵更新:
| 因素 | 描述 | 推论 |
|---|---|---|
| 技术变更 | ||
| 消息中心关闭 | 决定关闭消息中心,并将即时消息作为主要通信渠道 |
|
| 人员 | 参与实施计划和/或受变更影响的人员 |
|
| 即时消息 | 作为实施计划一部分引入的新技术 |
|
| 成本 | 实施计划的财务影响 |
|
再次说明,这只是基于更新技术重新生成矩阵的一种可能方式,而矩阵中实际使用的因素、描述和推导将取决于所处理的具体业务场景。
整合的差距、解决方案和依赖关系矩阵
整合的差距、解决方案和依赖关系矩阵是TOGAF架构开发过程中使用的一种技术,用于识别和分组架构领域中的差距,评估潜在解决方案及其相关依赖关系。
该技术有助于架构师优先安排工作,并识别出解决方案可能产生最大影响的领域。通过将差距归类,架构师可以更好地理解它们之间的关系,并找出能够同时解决多个差距的解决方案。
该矩阵在规划和创建工作包方面也十分有用。所识别的依赖关系有助于推动项目创建,并为架构开发过程的E阶段和F阶段的迁移规划提供信息。这确保了项目得到恰当的优先排序,并与业务目标保持一致。
总体而言,整合的差距、解决方案和依赖关系矩阵是架构师在整个架构开发过程中使用的宝贵工具,使其能够识别差距、解决方案和依赖关系,优先安排工作,并推动有效的项目规划与执行。
示例
以下是一个整合的差距、解决方案和依赖关系矩阵可能被使用的示例:
假设在架构开发过程的差距分析阶段,架构团队已经识别出当前架构状态中的若干差距。这些差距包括:
- 缺乏客户数据的集中式数据存储库
- 各业务单元间数据定义不一致
- 客户关系管理(CRM)系统与订单履行系统之间的集成有限
为了创建整合的差距、解决方案和依赖关系矩阵,架构团队会将这些差距归类,并评估潜在的解决方案和依赖关系。例如:
以下是再次展示该示例,并在第一列添加了编号:
| # | 差距 | 潜在解决方案 | 依赖关系 |
|---|---|---|---|
| 1 | 缺乏客户数据的集中式数据存储库 | 为客户数据实施数据湖 | 依赖于不一致数据定义问题的解决 |
| 2 | 各业务单元间数据定义不一致 | 建立数据治理框架和通用数据模型 | 依赖于数据湖的实施 |
| 3 | CRM系统与订单履行系统之间的集成有限 | 实施企业服务总线(ESB)以实现实时数据交换 | 依赖于数据治理框架和通用数据模型的实施 |
在此示例中,该矩阵表明,解决客户数据中的差距需要一个分步的方法,包括解决数据不一致问题、实施数据湖、建立数据治理框架和通用数据模型,最后实施企业服务总线(ESB)以实现实时数据交换。
该矩阵可用于规划工作包、识别依赖关系,并在E阶段和F阶段优先安排项目。例如,架构团队可以将数据治理框架和通用数据模型的实施作为解决已识别差距的第一步,因为它既是数据湖实施也是ESB实施的依赖条件。
架构定义增量表
架构定义增量表是开放组架构框架(TOGAF)中使用的一种技术,允许架构师规划并跟踪企业架构随时间的发展。该表列出了将为架构发展做出贡献的不同项目,并为每个项目分配特定的可交付成果,这些成果将在一段时间内分阶段完成。
该表的目的是创建一个路线图,概述过渡架构的计划顺序,这些过渡架构是架构在开发过程中特定时间点将达到的中间状态。每个过渡架构都代表一个比前一阶段更完整、更接近最终状态的架构阶段。
通过将开发过程分解为增量可交付成果,并将其分配给特定项目和时间范围,架构定义增量表有助于架构师:
- 以结构化且可管理的方式规划企业架构的开发
- 确保每个项目得到恰当排序,并且每个增量都能按时完成
- 识别不同项目之间潜在的依赖关系和冲突
- 提供开发过程的清晰概览,可与利益相关者共享,以确保所有人对项目的目标和时间表保持一致。
总体而言,架构定义增量表是一种强大的工具,可以帮助架构师管理复杂的企业架构项目,并确保其成功且按时完成。
以下是更新后的架构定义增量表,整合了增量和开始时间信息:
| 项目名称 | 增量1 – 开始时间 | 增量1 | 增量2 – 开始时间 | 增量2 | 增量3 – 开始时间 | 增量3 | 增量4 – 开始时间 | 增量4 |
|---|---|---|---|---|---|---|---|---|
| CRM系统 | 2023年第一季度 | 概念架构 | 2023年第二季度 | 逻辑架构 | 2023年第三季度 | 物理架构 | 2023年第四季度 | 完全运行的系统 |
| 数据仓库 | 2023年第一季度 | 概念架构 | 2023年第二季度 | 逻辑架构 | 2023年第三季度 | 物理架构 | 2023年第四季度 | 完全运行的系统 |
| 电子商务平台 | 2023年第二季度 | 概念架构 | 2023年第三季度 | 逻辑架构 | 2023年第四季度 | 物理架构 | 2024年第一季度 | 完全运行的系统 |
| 移动应用 | 2023年第二季度 | 概念架构 | 2023年第三季度 | 逻辑架构 | 2023年第四季度 | 物理架构 | 2024年第一季度 | 完全运行的系统 |
在此更新的表格中,每个项目包含四个增量,每个增量都有一个以季度和年份表示的开始时间。这使得架构师能够规划一系列过渡架构,并跟踪每个项目实现完全运行系统的过程。
例如,CRM系统项目始于2023年第一季度,每个后续增量均在下一季度开始。表格显示,完全运行系统增量计划于2023年第四季度。这使得架构师能够规划并跟踪实现CRM系统项目完全运行系统的过程。
同样,该表格显示了其他三个项目的每个增量的开始时间。这有助于架构师规划并跟踪每个项目实现完全运行系统的过程,并识别不同项目之间潜在的冲突或依赖关系。
过渡架构状态演进表
过渡架构状态演进表是开放组架构框架(TOGAF)中使用的一种技术,通过定义的分类体系(如TOGAF技术参考模型TRM)来展示组织在不同层级上的架构拟议状态。该表格是一种可视化工具,帮助架构师识别企业中使用的分类体系中的服务,然后列出这些服务的过渡架构及拟议的转型方案。
该表格应包含所有解决方案构建块(SBB)的列表,并说明它们如何影响并实现所列服务。SBB还应进行标记,以显示它们如何推动企业架构的发展。例如,如果引入一项新能力,将在表格中标记为“新增”或“保留”。如果某项能力正被过渡到新解决方案,则标记为“过渡”。如果某项能力正在被替换,则标记为“替换”。
过渡架构状态演进表清晰地展示了组织架构随时间发生的变革。它使架构师能够看到其拟议的变更如何影响组织的服务,并如何推动组织向目标状态迈进。通过使用此表格,架构师可以确保其拟议的变更与组织的目标和宗旨保持一致,并能够有效实施。
示例
以下是根据您提到的列,过渡架构状态演进表可能呈现的样子:
| 子领域 | 服务 | 过渡架构1 | 过渡架构2 | 过渡架构3 |
|---|---|---|---|---|
| 销售 | 订单管理 | 当前状态 | 过渡状态 | 目标状态 |
| 销售 | 客户管理 | 当前状态 | 过渡状态 | 目标状态 |
| 财务 | 应付账款 | 当前状态 | 过渡状态 | 目标状态 |
| 财务 | 应收账款 | 当前状态 | 过渡状态 | 目标状态 |
| 人力资源 | 薪酬管理 | 当前状态 | 过渡状态 | 目标状态 |
| 人力资源 | 福利管理 | 当前状态 | 过渡状态 | 目标状态 |
在此示例中,第一列列出组织内的子领域,例如销售、财务和人力资源。第二列列出每个子领域内的具体服务,例如订单管理、应付账款和薪酬管理。其余列代表各种过渡架构,可能包括当前状态、过渡状态和目标状态。
表格中的每个单元格都将填写与该服务和架构相关的相关信息。例如,订单管理与当前状态列对应的单元格可能包含用于管理订单的当前架构的描述,而订单管理与目标状态列对应的单元格可能描述未来管理订单的拟议架构。
业务价值评估技术
您描述的业务价值评估技术是一种有效的方法,用于评估和优先考虑各种业务举措或项目。通过使用包含价值和风险维度的矩阵,企业可以根据与战略目标和宗旨一致的客观标准来评估其选择。
价值指数维度包括原则合规性、财务贡献、战略一致性以及竞争地位,有助于确定项目可能为业务带来的潜在收益和机遇。风险指数维度包括规模与复杂性、技术、组织能力以及失败的影响,有助于识别项目可能面临的潜在风险和挑战。
示例
通过为每个标准分配独立权重,企业可以确定每个标准在决策过程中的相对重要性。这有助于确保最关键的因素在评估过程中获得更高的权重。

最后,重要的是在了解选项之前就确定决策标准。这可以确保评估过程保持客观和一致,所有选项都基于相同的准则进行评估。同时也有助于防止偏见和个人偏好影响决策过程。











