当前位置：首页 > news >正文

【企业架构】TOGAF架构标准规范-架构规划

news 2025/9/14 7:10:25

导读：架构规划围绕业务战略（Why）→ 架构目标（What）→ 范围界定（Where）→ 方法设计（How）→ 角色分工（Who）→ 成果输出（What）→ 治理管控（确保落地），实现核心价值：通过对业务战略、IT架构及运营管理的系统化设计与协同，确保企业技术投资精准支撑业务目标，提升运营效率、降低风险并实现可持续发展。

1、架构规划概述

2、目标

3、输入

4、步骤

5、输出

6、方法

1、架构规划概述

架构初始阶段的主要工作是制定企业相关的架构规划，架构规划负责解决的问题包括从那些方面做企业架构（where）、做企业架构需要做什么（what）、为什么要做企业架构（why）、谁来做企业架构（who）、如何做企业架构（how），架构规划的标准流程包括制定企业架构的目标、输入企业架构需要的信息资料、按照标准步骤执行处理输入、输出架构规划所需要的标准信息以及文件、提供标准方法支撑架构规划的实施。

2、目标

确定企业期望的架构能力，主要是确定与架构能力相关的组织上下文、企业受影响范围、框架、方法、流程以及能力成熟度。
确立与创建企业架构能力，主要是定义企业架构组织模型、架构治理流程、工具技术选型以及定义架构原则。

3、输入

架构参考，TOGAF架构标准资料、其他企业架构框架标准。
非架构性输入，企业战略、业务策略、IT策略、业务规则、业务目标、业务运营与管理框架、已有的架构治理框架、架构能力、法律法规协议。
架构性输入，企业架构组织模型、组织范围、成熟度模型、解决方案、架构团队的角色责任、需求预算、治理与支持策略、架构方法、架构内容、技术工具、架构原则、架构仓库。

4、步骤

确定企业组织受影响的范围，识别企业核心单元、企业最大受影响者、企业最大受益者，识别企业内外相关单元、项目干系人、企业架构治理相关框架。
确认企业架构治理与支持框架，主要涉及到架构标准、架构指导刚要、架构模型、协议报告、治理流程。
定义与确立企业架构团队与机构，确定企业业务能力、确定企业业务解决方案实施流程的成熟度评估方法、成立架构师或者解决方案架构团队、成立企业架构治理与管理团队、定义团队角色的责任与工作准则、定义企业架构工作的约束范围、定义团队的关键任务。
识别与确立架构原则，主要是根据业务规则制定企业架构的原则，作为企业架构治理的重要基础。
对TOGAF框架或者其他可选的框架实施剪裁，主要包括术语剪裁、过程剪裁以及内容剪裁。
为架构涉及到的工具与技术创建一个策略以及实现计划，在企业实施企业架构开发与治理的过程中需要依赖使用一些工具以及技术，例如，管理工具、决策技术、业务模型、配置仓库管理。

5、输出

企业架构的组织模型，主要包括组织受影响范围、成熟度评估以及解决方案、架构团队的角色与责任、架构工作的约束、预算要求、治理与支持策略。
已剪裁的架构框架，主要包括架构方法、架构内容、架构原则。
已初始化的架构配置仓库、已定义的业务规则、业务目标、架构工作的要求、架构治理框架。

6、方法

定义企业范围，确定企业架构能力的使用范围。
确定组织上下文，主要包括企业的商业模式、企业架构的利益相关者、企业文化、业务策略、业务规则、业务目标、组织流程、企业架构基线、企业架构能力。
定义架构工作要求，包括业务需求、企业战略目标、财务要求。
定义架构原则，架构原则主要用于约束企业架构的实施与治理。
定义管理框架，包括业务能力管理、项目管理方法、运营管理方法、解决方案开发方法。
定义管理框架的关系，主要包括业务计划、企业架构、运营管理、项目管理、解决方案开发之间的关系（企业如何从战略规划，通过架构设计，再落地到项目执行与运营，形成端到端的价值闭环）

Where（从哪些方面做企业架构） → 对应 “架构的范围与业务上下文”

企业架构不是孤立存在的，它要锚定 “业务规划（Business Planning）” 给出的方向（比如企业要进入哪些市场、主打什么产品线）。

同时还要看 “运营管理（Operations Management）” 现状（现有业务流程、IT 系统、组织架构是怎样的），以及 “解决方案开发（Solution Development）” 已有成果对新架构的限制/支撑。

简单说：“在哪里做架构” 要结合「业务战略边界」「现有运营边界」「现有技术/解决方案边界」来划定，确保架构不脱离企业实际运转场景。

What（做企业架构需要做什么） → 对应 “架构的核心交付物与工作范围”

企业架构要产出「架构蓝图（比如 TOGAF 里的业务架构、数据架构、应用架构、技术架构）」「迁移规划（怎么从现状架构到目标架构）」「治理框架（谁来管架构、怎么管）」等核心内容。

从流程上看，就是你在 “标准流程” 里提到的 “输出架构规划所需要的标准信息以及文件” —— 这些文件/信息就是 “做什么” 的具体载体。

Why（为什么要做企业架构） → 对应 “架构的价值与目标驱动”

价值往往来自两方面：一是对齐业务战略（Business Planning 给的方向），让技术/IT 投入真正支撑业务增长；二是解决现有运营/系统的问题（比如流程冗余、系统烟囱林立），通过架构重构实现效率提升、成本降低。

示意图里 “Architecture Governance（架构治理）” 也在保障 “做架构” 能持续对准企业长期目标，避免为了做架构而做架构。

Who（谁来做企业架构） → 对应 “架构的组织与角色分工”

从图中能看到，“Enterprise Architecture” 是核心枢纽，但它不是孤军奋战：

业务侧需要 “Business Planning” 团队提供战略输入；

运营侧需要 “Operations Management” 团队反馈现状痛点；

执行侧需要 “Portfolio/Program/Project Management” 团队落地架构规划；

治理侧需要 “Architecture Governance” 团队做合规与风险管控。

所以 “谁来做” 是一个跨团队、跨角色的协作网络，架构团队要牵头拉通业务、运营、技术、治理等多方角色。

How（如何做企业架构） → 对应 “架构的方法与实施路径”

就是你说的 “标准流程 + 标准方法”：

先「制定目标」（对准业务战略、解决运营痛点）；

再「输入资料」（收集业务文档、运营数据、现有架构蓝图等）；

然后「按步骤执行处理」（比如 TOGAF 的 ADM 循环：架构愿景→业务架构→信息系统架构→技术架构→迁移规划→实施治理→架构变更管理……）；

最后「输出成果 + 提供方法支撑」（产出架构文档、用架构设计工具/方法论保障落地一致性）。