企业级架构可视化实践：做好架构可视化的十一个关系
企业为什么要进行架构可视化
- 核心观点：架构可视化是“想清楚”和“说清楚”的必要条件，通过可视化实现架构设计和治理的抽象化、严格化、规范化。
- 可视化目的：帮助业务愿景不清、系统重复建设、技术栈不统一、数据不一致等问题。
- 架构层次：
- 企业架构：信息系统、业务、应用、数据、技术等层面的整体架构，实现端到端治理。
- 企业级架构：跨团队、跨系统的宏观架构治理，强调业务、应用、数据、技术的一致性。
怎样建立架构可视化标准？
- 示意图 vs 蓝图：
- 示意图：不要求准确性和规范性，适用于探索和汇报。
- 蓝图：要求准确、规范，适用于架构治理，需在特定抽象层次保持一致性和完整性。
- 系统 vs 产品：
- 定义：软件系统（简称系统）是独立发布的发布单元，产品是对系统进行打包的业务价值单元。
- 对齐：架构治理中需统一对系统、应用、中间件等概念的理解。
- 规范画法 vs 自定义画法：
- 选择：企业可基于UML Profile机制（C4模型或自定义标准）制定绘制标准。
- 维度 vs 粒度：
- 维度：架构描述的视角（业务、应用、数据、技术等）。
- 粒度：架构描述的范围（企业级、条线级、室组级、单元级）。
- 示例：某企业架构内容体系涵盖业务架构、应用架构、数据架构、技术架构等维度，并按粒度分层描述。
业务架构 vs 领域模型
- 核心观点：为业务概念建模，通过领域模型表达业务能力、领域和用例。
图 vs 表 vs 矩阵
- 表达方式：
- 图：直观表达同一层面架构元素和关系。
- 矩阵：描述不同层面架构元素的关系。
- 列表：详述架构元素。
- 结论：三种方式可全面描述任何架构信息。
怎样推广架构可视化？
- 企业级 vs 团队级架构师：
- 职责分工：
- 企业级架构师：制定标准、组织实施，关注跨团队和系统问题。
- 团队级架构师：执行标准、验证反馈，关注团队和具体技术问题。
- 激励机制：需明确职责和协作关系，并建立激励机制。
- 当前架构 vs 目标架构：
- 基线与方向：当前架构确立基线，目标架构确定方向。
- 版本管理：需做好版本管理，纳入架构资产库（含架构描述、规范、制度、参考）。
- 实现技术：共享文件系统、Wiki、版本控制软件或专用工具。
前期设计 vs 浮现式设计
- 核心观点：架构演进是价值优先、持续演进的过程。
- 对比：
- 集中前期设计：易造成“运动式”推广，难以验证和持续运作。
- 浮现式设计：价值优先、建立框架、持续演进。
手工 vs 自动化
- 好的架构治理工具：
- 保存多维度知识。
- 自动生成架构图。
- 验证架构约束。
- 感知实际架构变化。
- 实施架构守护。
- 版本管理。
- 支持协作绘图。
- 工具区别：架构工具需包含“知识”，区别于绘图工具。
