【企业架构】TOGAF概念之三

 导读：学习TOGAF（The Open Group Architecture Framework，开放组架构框架）相关概念的意义和价值，体现在它为企业架构（Enterprise Architecture, EA）实践提供了标准化方法论、跨领域协同框架、战略落地工具，并能显著提升个人与组织的竞争力。

21.  架构治理

定义	是对企业架构进行管理和控制的系统； 是一个关系结构确定的决策过程
三要素	架构委员会 、架构契约 、架构合规性
层级	公司/技术/架构 （在企业层面被管理和控制）/IT 治理
治理原则	纪律： 遵守流程 、规程 、权限结构 透明： 所有实施行动接受检查 独立： 所有流程 、决策 、机制的制定， 最大程度减少或避免冲突 问责： 可识别群体拥有授权， 并对其行为负责 责任： 契约各方要对组织和利益相关者负责

---

22.  架构委员会

定义	负责监督架构治理策略实施的人员
代表	所有关键利益相关者
组成	决策者
主要职责	为所有架构相关决策提供基础 确保子架构之间的一致性 确立组件复用的目标 执行架构合规性 为超出范围的决策提供能力升级支持 保持架构能力 负责变更管理

---

23.  架构契约

定义	开发合作伙伴与发起人就架构可交付物 、质量和适用性达成的协议。
作用	建立契约并确保需求按照记录的方式得到实施。 持续监测所有架构相关活动的完整性 、变更 、决策和审计 符合架构原则 、标准和要求 识别风险 确保在架构制品的开发和使用上可问责 、负责任并遵守纪律
架构契约与 ADM	A 阶段的架构工作声明实际上是架构契约 BCD 阶段的领域架构可通过架构契约外包 架构实施可以在 F 阶段结束， G 阶段开始通过架构契约外包

---

24.  架构工作声明：

 架构开发周期的范围和方法： 将用于完成整个架构开发周期的计划。

TOGAF的架构开发周期通过ADM的10阶段循环，为企业提供从战略到执行的全链条支持。其范围覆盖业务、数据、应用、技术四维架构，支持全生命周期迭代规划；方法上结合标准化流程与灵活性调整，适配不同规模和行业需求。

---

25.  架构工作请求： 

从发起组织发送到架构组织的文件： 用于触发架构开发周期的开始。

从发起组织发送至架构组织的文件（如AWS、架构愿景文档、BRD）是触发ADM周期的关键输入，其核心价值在于：

• 明确方向：定义架构开发的目标、范围及约束条件。
• 对齐战略：确保架构与业务战略、技术投资重点一致。
• 减少风险：通过标准化文件管理利益相关者期望，避免需求变更导致的返工。

---

26.  架构定义文档：

项目进展过程中为重要的相关信息创建的架构制品可交付物容器；跨全部架构领域， 考察所有架构状态 - 基线/过渡/目标。

架构制品可交付物容器的核心设计原则

1. 领域全覆盖
   • 包含四大架构领域：业务架构（Business Architecture）、数据架构（Data Architecture）、应用架构（Application Architecture）、技术架构（Technology Architecture）。
   • 每个领域下细分子领域（如数据架构包含数据模型、数据流、数据治理）。
2. 状态三维度
   • 基线架构（As-Is）：当前架构状态，反映现状痛点。
   • 过渡架构（To-Be Transition）：分阶段演进路径，明确里程碑与依赖关系。
   • 目标架构（To-Be Target）：最终理想状态，与业务战略对齐。
3. 可追溯性与一致性
   • 通过唯一标识符（如ID）关联不同领域的制品，确保跨领域分析时数据一致。
   • 支持版本控制，记录架构演进历史。
4. 可访问性与协作
   • 采用集中式存储（如企业架构工具：ArchiMate、Enterprise Architect）或协作平台（如Confluence），支持多角色（架构师、业务代表、IT团队）协同编辑与查看。

容器结构：分层分类模型

1. 顶层：架构领域分类

架构领域	子领域示例	核心制品类型
业务架构	业务流程、组织结构、业务能力	业务流程模型、组织结构图、业务能力地图
数据架构	数据模型、数据流、数据治理	概念/逻辑/物理数据模型、数据流图、数据字典
应用架构	应用组件、接口、交互关系	应用组件图、接口规范、服务目录
技术架构	基础设施、技术栈、部署模型	技术栈清单、部署拓扑图、网络架构图

2. 中层：状态维度划分

每个领域下按基线、过渡、目标三状态组织制品：

• 基线制品：描述现状（如“当前业务流程模型”）。
• 过渡制品：定义演进路径（如“阶段1：核心系统云迁移计划”）。
• 目标制品：定义最终状态（如“目标业务能力地图”）。

3. 底层：制品实例与元数据

• 制品实例：具体文件（如PDF、Visio图、Excel表）或模型（如ArchiMate模型）。
• 元数据：包括制品名称、版本、作者、关联领域、状态、审批记录等，支持搜索与过滤。

---

27.  架构需求/定义规范： 

通过一系列定量陈述， 概括说明实施计划如何与架构保持一致

目标一致性：量化指标对齐架构愿景

1. 业务目标覆盖率
   • 陈述：实施计划中100%的关键业务目标（如“用户注册转化率提升15%”“系统响应时间≤200ms”）均直接映射至架构需求中的业务能力指标，且偏差不超过±5%。
   • 示例：
     • 架构需求：支持每秒10,000笔并发交易（TPS）。
     • 实施计划：Q3完成负载均衡模块开发，Q4通过压力测试验证TPS达10,500（达标率105%）。
2. 技术目标达成率
   • 陈述：实施计划中90%以上的技术目标（如“API调用成功率≥99.9%”“数据一致性延迟<1秒”）均通过架构定义中的非功能需求（NFRs）量化，并设定明确验收标准。
   • 示例：
     • 架构需求：数据同步延迟≤500ms（99%分位值）。
     • 实施计划：Q2部署Kafka流处理集群，Q3监控显示实际延迟480ms（达标率96%）。

范围一致性：功能与非功能边界量化

1. 功能范围覆盖率
   • 陈述：实施计划中100%的功能模块均对应架构需求中的功能规格说明（FRS），且功能点完成率与架构定义偏差不超过±3%。
   • 示例：
     • 架构需求：用户管理模块需支持“多因素认证（MFA）”“角色权限动态分配”。
     • 实施计划：Q1完成MFA开发（100%覆盖需求），Q2完成权限分配接口（实际覆盖98%，因遗漏1个边缘场景）。
2. 非功能范围约束满足率
   • 陈述：实施计划中所有非功能需求（如性能、安全、可扩展性）均通过量化约束条件（如“支持10万用户并发登录”“通过ISO 27001认证”）明确，且满足率≥95%。
   • 示例：
     • 架构需求：系统需通过PCI DSS合规认证（涉及12项安全控制）。
     • 实施计划：Q3完成11项控制实施（满足率91.7%），Q4通过外部审计补全剩余1项（最终满足率100%）。

约束一致性：资源、时间与技术限制量化

1. 资源约束匹配度
   • 陈述：实施计划中人力、硬件、预算分配与架构定义中的资源约束（如“开发团队≤15人”“云服务器成本≤$5,000/月”）偏差不超过±10%。
   • 示例：
     • 架构约束：总开发成本≤200万元。
     • 实施计划：Q1-Q4实际成本195万元（偏差-2.5%），因采用开源工具替代商业软件。
2. 时间约束里程碑达成率
   • 陈述：实施计划中所有关键里程碑（如“架构设计评审完成”“UAT测试通过”）均与架构定义中的时间约束（如“6个月内上线”）对齐，且延迟率≤5%。
   • 示例：
     • 架构约束：系统需在Q4前完成迁移。
     • 实施计划：Q3完成80%迁移，Q4第2周全量上线（延迟率0%，因提前完成测试）。
3. 技术约束兼容性
   • 陈述：实施计划中所有技术选型（如编程语言、数据库、中间件）均符合架构定义中的技术约束（如“必须使用Java 11+”“数据库需支持ACID”），且兼容性验证通过率100%。
   • 示例：
     • 架构约束：微服务框架需支持Kubernetes部署。
     • 实施计划：选择Spring Cloud Kubernetes（验证通过），拒绝不符合要求的Dubbo（因缺乏原生K8s支持）。

质量一致性：验收标准与架构质量模型对齐

1. 代码质量达标率
   • 陈述：实施计划中所有代码提交均需通过架构定义中的质量门禁（如“单元测试覆盖率≥80%”“SonarQube严重漏洞=0”），且达标率≥95%。
   • 示例：
     • 架构需求：核心模块代码复杂度（Cyclomatic Complexity）≤10。
     • 实施计划：Q2代码评审显示平均复杂度为9.5（达标率100%），拒绝2个复杂度>15的模块重构。
2. 架构合规性检查通过率
   • 陈述：实施计划中每个迭代周期均需通过架构合规性检查（如“服务拆分是否符合领域驱动设计（DDD）”“API设计是否符合OpenAPI规范”），且通过率100%。
   • 示例：
     • 架构需求：所有服务需遵循“单一职责原则”。
     • 实施计划：Q3发现1个服务违反原则（如同时处理订单和支付），要求立即拆分（最终通过率100%）。

演进一致性：变更管理与架构弹性量化

1. 变更请求处理率
   • 陈述：实施计划中所有架构变更请求均需通过量化评估（如“变更成本≤$10,000”“影响范围≤3个服务”），且高风险变更（如核心数据库迁移）拒绝率≥20%。
   • 示例：
     • 变更请求：将Redis从单机模式改为集群模式。
     • 量化评估：成本增加$15,000（超预算50%），性能提升仅10%（ROI<1）。
     • 决策：拒绝变更（因成本收益比失衡）。
2. 架构弹性指标达成率
   • 陈述：实施计划中所有弹性设计（如自动扩缩容、熔断机制）均需通过架构定义中的弹性指标（如“系统在50%流量激增时自动扩容时间≤1分钟”），且达标率≥90%。
   • 示例：
     • 架构需求：服务降级时用户无感知率≥95%。
     • 实施计划：Q4模拟故障测试显示，98%用户未感知降级（达标率103%）。

监控与反馈一致性：量化指标驱动迭代

1. 监控指标覆盖率
   • 陈述：实施计划的监控体系需覆盖90%以上架构定义中的关键指标（如服务响应时间、错误率、资源利用率），且数据采集频率≥每分钟。
   • 示例：
     • 架构需求：微服务调用链追踪覆盖率100%。
     • 实施计划：Q3部署SkyWalking，实际覆盖99%（遗漏1个内部工具调用），Q4补全后达100%。
2. 迭代反馈响应率
   • 陈述：实施计划中所有监控告警均需在≤1小时内触发响应，且根因分析（RCA）完成率100%。
   • 示例：
     • 监控告警：数据库连接池耗尽。
     • 实施计划：15分钟内定位为慢查询导致，30分钟内优化SQL并重启服务（响应时间45分钟，达标率100%）。

---

28.  架构路线图：

架构路线图是技术团队与业务方对齐目标、规划资源、监控进度的核心工具，它通过结构化分解目标架构为可执行的工作包，并明确时间节点、依赖关系与风险缓冲，最终实现从现状到目标架构的平滑过渡。

展示实现目标架构的工作包及其时间安排，提供对项目进展的可视化跟踪。

核心价值：

案例：背景：某电商企业需从单体架构迁移至云原生，支撑业务从日均10万订单增长至100万订单。

实践指南：

---

29.  架构合规性：

架构合规性是确保系统设计符合组织战略、行业标准、技术规范及最佳实践的关键过程，其核心目标是通过主动预防、持续监控和透明沟通，降低技术债务、规避合规风险，并为管理层提供决策依据。

尽早发现错误，保证应用最佳实践，识别标准是否需要调整， 向管理层汇 报项目准备就绪程度， 当识别出重大差距向各方告知。

合规性价值：

架构合规性实施流程：PDCA闭环管理。

架构合规性沟通策略：分层汇报与透明化。

实施建议：

通过系统化实施架构合规性，企业可实现“设计即合规、开发即安全”的目标，将合规成本从“事后修复”转变为“事前预防”，最终提升系统韧性、降低法律风险，并为数字化转型保驾护航。

---

30.  架构视图： 

架构视图（Architectural Views）是架构设计的核心工具，用于从不同角度抽象和展示系统的关键特性，帮助利益相关者（如业务方、开发团队、运维人员）理解复杂系统的不同方面。

对架构的不同展示形式

案例：场景：设计一个支持百万级并发的在线教育平台