【企业架构】TOGAF概念之二
导读：学习TOGAF（The Open Group Architecture Framework，开放组架构框架）相关概念的意义和价值，体现在它为企业架构（Enterprise Architecture, EA）实践提供了标准化方法论、跨领域协同框架、战略落地工具，并能显著提升个人与组织的竞争力。
11. 架构范围的维度：
广度 、深度 、 时间 、架构域
一、广度：TOGAF视角：
- 业务广度：对应TOGAF的业务架构（Business Architecture），需覆盖企业所有核心业务流程、价值链、组织单元及利益相关者。例如，零售企业的广度可能包括线上商城、线下门店、供应链、物流等全渠道业务。
- 技术广度：涉及跨技术栈的集成，如云原生、微服务、API网关、数据湖等，需覆盖从基础设施到应用层的全技术链。
- 组织广度：涵盖企业内部各部门（如IT、财务、HR）及外部合作伙伴（如供应商、客户）的协作边界。
TOGAF工具支持：
- 使用业务场景（Business Scenarios）技术定义架构需支持的关键业务场景，确保广度无遗漏。
- 通过架构愿景（Architecture Vision）阶段明确架构覆盖的业务范围和边界。
二、深度：TOGAF视角：
- 技术深度：例如，在数据架构中，需定义数据模型（概念层、逻辑层、物理层）的详细程度，或选择特定技术（如关系型数据库 vs. NoSQL）的深度。
- 流程深度：在业务架构中，需明确流程的颗粒度（如L1到L5级流程分解），以及是否涵盖异常处理、合规要求等细节。
- 安全深度：在安全架构中，需决定是仅定义安全策略，还是细化到具体控制措施（如加密算法、访问控制列表）。
TOGAF工具支持：
- 通过架构定义文档（Architecture Definition Document, ADD）分层描述架构细节。
- 使用架构构建块（Architecture Building Blocks, ABBs）和解决方案构建块（Solution Building Blocks, SBBs）区分高阶设计与详细设计。
三、时间：TOGAF视角：
- 基线架构（Baseline Architecture）：当前状态的架构快照，反映现有系统、流程和技术的状态。
- 目标架构（Target Architecture）：未来状态的架构愿景，通常分阶段实现（如短期、中期、长期）。
- 过渡架构（Transition Architectures）：连接基线与目标的中间状态，需定义里程碑、依赖关系和迁移路
TOGAF工具支持：
- 架构开发方法（Architecture Development Method, ADM）的循环迭代（如Phase A-H）明确时间维度规划。
- 使用架构路线图（Architecture Roadmap）可视化展示时间轴上的关键活动、资源分配和风险点。
四、架构域：TOGAF四域：
- 业务架构（Business Architecture）
- 定义业务战略、组织、流程、职能和角色。
- 示例：绘制企业价值链图，识别核心能力差距。
- 数据架构（Data Architecture）
- 描述数据模型、数据流、存储策略和数据治理规则。
- 示例：设计主数据管理（MDM）框架，确保数据一致性。
- 应用架构（Application Architecture）
- 规划应用系统、组件、接口和交互模式。
- 示例：采用微服务架构重构单体应用，定义API规范。
- 技术架构（Technology Architecture）
- 定义基础设施、平台、网络和部署模型。
- 示例：选择混合云架构，配置容器化平台（如Kubernetes）。
12. 架构景观层级：
战略架构、 能力架构 、分段架构
一、战略架构：核心内容：
- 描述企业未来3-5年的业务模式、技术趋势及关键能力需求。
- 明确架构演进的关键要素（如数字化转型、市场拓展）和关注点（如数据治理、安全合规）。
- 通过架构愿景（Architecture Vision）阶段制定，为后续分层提供方向指引。
- 示例：零售企业战略架构可能包括全渠道零售、智能化供应链、客户体验优化等目标，并规划技术栈（如云原生、AI）支持。
二、分段架构：核心内容：
- 按业务线（如供应链、财务）、技术域（如数据架构、安全架构）或组织单元（如部门、分支机构）划分架构段落。
- 定义各段落的基线架构（当前状态）、目标架构（未来状态）及过渡路线图。
- 通过业务场景（Business Scenarios）技术细化需求，确保与战略对齐。
- 示例：在供应链分段架构中，可能规划仓储自动化、物流网络优化等项目，并明确技术选型（如IoT设备、区块链溯源）。
三、能力架构：核心内容：
- 以业务能力（Business Capability）为核心，细化能力增量（如支付能力、推荐系统）的实现路径。
- 采用敏捷开发模式，通过冲刺（Sprint）迭代交付功能模块（如登录、支付、推荐系统）。
- 支持从能力到战略的双向反馈机制，确保执行层问题能反哺上层优化（如课程安排、服务流程调整）。
- 示例：支付能力架构可能拆解为接口开发、安全认证、对账系统等任务，每个任务通过Sprint迭代完成，并持续优化用户体验。
四、协同逻辑：
- 战略架构提供方向，分段架构拆解领域路径，能力架构落地具体任务，形成“战略→领域→任务”的闭环。
- 各层级均需考虑时间维度（基线、过渡、目标架构），通过架构路线图（Architecture Roadmap）可视化演进节奏。
- TOGAF工具支持：
- ADM（架构开发方法）：提供分层开发的迭代流程（如Phase A-H）。
- ArchiMate建模语言：通过分层视图（业务层、应用层、技术层）描述架构关系。
- 架构内容框架：定义各层级的交付物（如目录、矩阵、图），确保一致性。
13. 业务场景：
帮助识别和理解架构必须满足业务需求的方法
- 1、需求识别：多维度收集业务信息
- 2、需求理解：结构化分析与建模
- 3、需求验证：确保架构与业务对齐
- 4、需求管理：持续迭代与跟踪
14. 互操作性：
共享信息和服务的能力
不同系统、组件或服务之间无缝共享信息、协同工作并有效利用资源的能力。在企业架构中，互操作性是打破数据孤岛、提升业务敏捷性、降低集成成本的核心诉求。
- 交换数据（如结构化数据、非结构化文档）；
- 触发流程（如一个系统的事件触发另一个系统的动作）；
- 共享功能（如复用认证、支付等通用服务）。
15. 业务转型评估：
对组织接受变革的准备程度的评估和量化 。包括：
- l 确定将影响组织的准备因素
- l 使用成熟度模型呈现准备因素
- l 评估并评级准备就绪因素
- l 评估每个准备因素的风险和缓解风险的措施
- l 将这些行动纳入 E 和 F 阶段实施和迁移计划
16. ADM 风险管理：
A 阶段识别风险， G 阶段监控风险 、持续识别风险和更新风险缓解措 施 。未能减缓的风险需启动另外一个 ADM 周期 （不一定是完整的）
风险来源分类： 示例
| 类别 | 示例 | 识别工具 |
|---|---|---|
| 业务风险 | 市场需求变化导致架构过时 | PESTEL分析、场景规划 |
| 技术风险 | 遗留系统与新架构不兼容 | 技术债务评估、兼容性测试 |
| 合规风险 | 数据跨境传输违反GDPR | 法律合规检查表、差距分析 |
| 运营风险 | 供应商依赖导致服务中断 | 供应链映射、SLA评审 |
风险监控指标体系：示例
| 指标类型 | 示例 | 监控频率 | 数据来源 |
|---|---|---|---|
| 触发型指标 | 关键系统错误率＞1% | 实时 | APM工具（如New Relic） |
| 趋势型指标 | 漏洞修复周期延长20% | 每周 | 漏洞管理平台 |
| 阈值型指标 | 供应商交付延迟超过SLA 3次 | 每月 | 采购系统日志 |
17. 利益相关者管理：
分类 | 特征 | TOGAF管理策略 | 典型角色 |
权高利低 | 权力大但利益关联度低，可能因其他优先级忽视架构项目 | 令其满意（Keep Satisfied） | 跨部门高管、外部监管机构 |
权高利高 | 权力大且利益高度相关，直接影响架构成败 | 重点管理（Manage Closely） | CEO、CIO、业务部门负责人 |
权低利高 | 权力小但利益关联度高，可能因信息不足产生抵触 | 随时告知（Keep Informed） | 终端用户、基层业务人员 |
权低利低 | 权力小且利益关联度低，对架构影响有限 | 最小精力/监督（Monitor Minimally） | 外部供应商、非核心部门员工 |
通过精准分类、差异化策略、工具赋能，利益相关者管理可从“被动应对”转向“主动引导”，显著提升项目成功率与组织效能。
最佳实践：
- 利益相关者管理计划（Stakeholder Management Plan）：
- 作为架构开发文档（ADD）的一部分，明确各利益相关者的角色、沟通频率和渠道。
- 示例：为权高利高者制定月度面对面会议，为权低利高者提供月度电子简报。
- 沟通策略（Communication Strategy）：
- 根据利益相关者偏好定制沟通方式（如数据驱动型高管偏好图表，业务人员偏好案例）。
- 示例：用架构愿景（Architecture Vision）文档说服权高利高者，用业务场景（Business Scenarios）演示打动权低利高者。
- 冲突解决（Conflict Resolution）：
- 当利益冲突时，优先满足权高者需求，同时通过补偿机制（如培训、资源倾斜）安抚权低者。
- 示例：若业务部门（权高利高）与IT团队（权低利高）对技术选型有分歧，可引入第三方评估平衡双方诉求。
18. 架构模式：
针对重复性架构问题的标准化解决方案 - 最佳实践/设计原则/实施步骤； ABB/SBB 都属于架构模式。
一、架构构建块（ABB, Architecture Building Block）
- 定义：满足组织业务需求的抽象功能模块，定义业务、数据、应用或技术需求，但不涉及具体实现。
- 设计原则：
- 松耦合：边界与实现解耦，支持多技术平台部署（如“客户关系管理ABB”可适配Salesforce或自建系统）。
- 可组装性：由更小粒度的ABB组合而成（如“订单处理ABB”由“支付ABB”“库存ABB”等构成）。
- 标准化接口：明确输入/输出规范（如RESTful API），确保与其他ABB互操作。
- 实施步骤：
- 需求分析：通过业务场景建模（如订单处理流程）识别核心功能。
- 模块划分：基于价值链或流程图定义ABB边界（如将“物流管理”拆分为“仓储ABB”“运输ABB”）。
- 规范制定：描述功能、接口、依赖关系（如“支付ABB”需支持信用卡、第三方支付接口）。
二、方案构建块（SBB, Solution Building Block）
- 定义：实现ABB功能的具体产品、组件或代码模块，绑定技术选型与供应商方案。
- 设计原则：
- 技术绑定性：明确实现技术（如用Java EE实现“用户认证ABB”的SBB）。
- 可替换性：支持不同供应商方案（如“数据库SBB”可选择MySQL或Oracle）。
- 性能与安全合规：满足非功能需求（如“数据加密SBB”需符合GDPR）。
- 实施步骤：
- 技术选型：评估云服务、开源框架等（如选择AWS Lambda实现“事件处理SBB”）。
- 组件开发：编码或配置SBB（如用Spring Boot开发“订单服务SBB”）。
- 集成测试：验证SBB与ABB的兼容性（如测试“支付SBB”是否符合“支付ABB”的接口规范）。
三、ABB与SBB的协同价值
- ABB解决“做什么”的问题，确保架构与业务对齐；SBB解决“如何做”的问题，平衡技术灵活性与成本。
- 企业可通过构建块库（Repository）实现跨项目复用，例如将“用户认证ABB/SBB”复用于电商、金融等多个业务线。
- TOGAF的架构模式与ADM方法论结合，形成从战略到实施的完整闭环，支撑企业数字化转型的可持续演进。
19. 迁移规划技术
实施因素目录 | 记录影响架构实施和迁移计划的影响因素的文档 |
整合的差距、解决方案和依赖关系矩阵 | 评估亦或多个差距的潜在解决方案和依赖关系 - 根据领域架构的差距分析结果 |
架构定义增量表 | 计划一系列过渡架构；过渡架构用于概述企业架构 在具体时间点的状态 |
过渡架构状态演进表 | 呈现架构按照给定的分类法，在不同层级的推荐状 态 |
业务价值评估技术 | 按照价值和风险两个指数，绘制矩阵来评估业务价 值 |
20. 架构原则
定义 | 一般规则和指南， 很少改动 。用于指导和支持组织实现其使命的方式 |
目的 | 推动决策 、实现企业的对齐 、确保治理 、理解价值观和文化 |
开发 | CIO+利益相关者+架构委员会 |
批准 | 架构委员会 |
模版 | 理由： 描述了与其他原则的关系， 阐明了遵循该原则的商业利益和意图 影响： 强调业务和 IT 的需求 |
特性 | 可理解 健壮性/鲁棒性（可靠性， 各种条件下的表现） 完整性（涵盖所有情况） 一致性（原则之间的协调） 稳定性（长期持续但能适应变化） |