企业架构框架主流工具比较

企业架构框架主流工具比较

市场经济环境下能合理利用内外部资源，并能根据环境变化做出适当的调整，将使企业具有竞争优势，当企业规模较小时，企业对市场的反应会较灵敏，但随着规模达到一定程度时，企业的战略、组织、流程、内部利益等变得错综复杂，信息传递的链条和管控的链条也变得冗长，很难 “使大象跳舞”，造成的根本原因不是规模，而是难以将业务、应用、数据、技术等领域紧密和组合起来，因此就不能对市场做出快速和正确的响应。

但在实际的实践过程中，真正使用EA的方法构建企业信息化架构的企业不多，更多的是作为思想指引，距离很好的贯彻和落地有很大的距离。这也是为什么很多IT建设项目无法实现预期的价值，企业的现代化变革也需要整体和系统化的方法，这也是渐进过程的每个阶段的基础。

深入的理解企业架构的方法对安全架构设计有较强的指导意义，各类不同的企业架构框架都有不同的侧重点和不同的应用场景，无论是较早期提出的SABSA安全架构框架，还是2018年Gartner提出的安全架构方法，都传承了企业架构的主要思想。

主要企业架构区别

TOGAF框架为领先的EA开发工具，提供了一步步的架构开发和执行指南，创建了快速和交互式的架构开发纲要，适合作为架构执行和治理的指南和向导。

Zachman更加适合理清企业各独立元素之间的关系，以确保不会失去完整的视角来看待企业业务到IT架构的转换；

SABSA作为企业架构的安全部分延申，是目前指导业务驱动安全架构建设的唯一和极具借鉴价值的框架，该框架指导如何将安全关联到业务的目标，基于业务驱动安全的理念，抽象出业务的安全属性，并逐一分析对应的潜在的风险、业务的影响、风险级别和对策、可评价的指标等，建立可跟踪、可度量的安全体系；以各层安全人员的视角分别从业务层、概念层、逻辑层、物理层、组件层、运营层逐层细化安全设计到实现部署于运行。

4+1框架更关注于软件系统架构，强调了使用共同的语言来于系统的关联方沟通；UML框架相当于提供了统一的图表模型、语言模型，供架构师创建完全自定义的架构；

TOGAF – 持续架构开发的标准框架

TOGAF 用于快速开发架构（架构开发方法或 ADM）的既定方法是一个分步过程，描述了在一个周期中安排的十个阶段。需求管理位于流程的中心，反映每个阶段的调整变化和要求的持续过程的阶段。

TOGAF Architecture Development Method

元素代表的含义

初步阶段 -定义未来架构的原则，关注点和要求
架构愿景 -选择架构范围和方法以与利益相关者保持一致
业务架构 - 使用建模方法描述架构愿景
信息系统架构 - 建模数据和应用架构
技术架构 - 将系统的描述转换为架构实现的基础
机会和解决方案 - 定义主要的步骤将当前架构更改为目标架构的，为执行计划的基础

迁移计划-描述实施的估计成本、时间表和路线图
实施和治理的 - 为架构部署的不同阶段分配治理功能
架构更改管理 - 提供技术和业务变更的监控

何时使用TOGAF?

• 以受控方式改变组织的架构和流程

• 反复调整流程与当前目标保持一致

• 支持从关键需求评估到实际实施的所有阶段的架构开发过程

TOGAF已被《财富》500强企业中的60%采用。由于其广泛性，该框架具有很强的适应性、灵活性和协作性。然而，与任何广为人知的方法一样，它也因为以理论为中心的方法而招致了一些批评，很少有人能将其转化为实践。所以，尽管TOGAF 很受欢迎，但它并不是万能的，应该用作指南，而不是可操作的计划。

Zachman 框架 --二维矩阵，以适应角色和想法

Zachman 不是一个方法论，而是一个模板，描述如何从不同的角度看待不同的抽象思想。

此二维矩阵由六行（视角）和六列（基本问题）组成，其相交单元以详细和结构化的方式描述企业的表示。Zachman框架是规范化的，其行和列不能删除，以保持系统的整体概述。尽管如此，它还是足够灵活，可以为任何范围项目工作，以清楚地关注每个元素及其目的，并在框格之间建立上下文关系。最后完成的方案不是架构，它是帮助管理和组织的一个工具。

Zachman Framework

元素代表的含义

高层视角- 规划师寻求有关系统的规模和成本的信息
业务管理视角-一个想要了解业务流程如何于所有者互动
架构师视角-架构师确定软件功能如何代表商业模型
工程师视角- 承包商应用特定技术来解决业务问题
技术员视角-程序员给定的指令
企业视角-操作系统本身

What? – 企业的数据每一行必须处理
How? – 组织的职能和流程
Where? – 地理位置、物流、互连
When? – 商业周期和触发业务活动
Who? – 组织单元和人与技术的交互
Why? – 将业务目标和战略转化为具体方法

何时使用Zachman框架?

• 专注于独立对象，而不会失去整体视角，以及对象之间的关系

• 在与利益相关者对话中，澄清各级别应关注哪些内容时无需深入探讨技术方面

• 作为一个文档化工具，可以很容易地与其他模型相结合

• 简化团队内部的沟通，检查已经描述观点的缺失

SABSA – 风险管理框架，对齐业务和安全

SABSA (Sherwood Applied Business Security Architecture) 是一个运营风险管理框架，包括一系列模型和方法，可独立使用或作为整体企业安全架构解决方案。SABSA为高度可定制和可扩展的框架 -可以在小范围内采用，然后在企业范围逐步实施。SABSA紧随Zachman框架，并适配和聚焦安全，它使用Zachman的六个问题来分析其六层安全架构。

SABSA’s six layers of security architecture

何时使用 SABSA?

• 通过提前记录错误，并在创建架构时避免

• 将安全架构与业务价值保持一致

• 设置可量化的指标来跟踪业务绩效，而不是技术指标

4+1 视图模型 – 解决不同利益相关者的极简工具

4+1方法背后的基本理念在于根据不同利益相关者的利益划分软件系统的不同方面。这是另一个类似于扎克曼方法的框架。该模型的创建者菲利普·克鲁希滕认为，通过将架构分离成不同的视图，它将从每个利益相关者的角度显示，无论是客户还是开发人员。

四个主要视图被描述为：

Logical – 代表系统应提供什么、系统组件及其关系
Process – 显示系统的性能、可扩展性、工作流程规则
Development – 专注于软件模块、软件包和物理使用的环境
Physical --考虑如何将软件映射到硬件

第五个视图（场景或使用案例）代表了整个系统的高级别视图，并说明了架构的一致性和有效性。此视图与所有利益相关者相关。

Scenarios or Use Cases view of the 4+1 framework

何时使用4+1模型?

• 确定不同观点的优先次序并简化组织流程

• 与其他工具（如TOGAF）集成

• 轻松记录单个项目和公司的整个 IT 架构

UML - 创建自定义 EA 框架

大多数企业架构框架提供了有限的观点和方向，因此由必要组合使用。没有一个模型能包括所有的措施并满足每个组织的需要。但是，这允许企业架构师自定义文档并创建独立的系统概要。

统一建模语言（UML） 是一种描述性的视觉语言，提供用于标准化软件开发的可扩展图表。它易于扩展，并可使用扩展机制（UML配置文件）为不同的业务领域进行自定义。企业架构师使用stereotypes、标记和约束来根据特定环境定制语言，从而确保完成的模型能够满足公司特定的要求。一些通用的 UML 图包括部署图，可视化系统的执行架构：活动图、系统的行为模型和这些行为如何关联、表示工作流程和协作的序列图。

活动图表示例

UML 模型允许企业开发一组流程并使用案例来可视化整个企业架构及其内部的每个系统。这是一个复杂的工具，需要培训来操作和适应公司的需求，但这种方法的好处与企业架构师的努力程度相关。

企业框架的主要问题

企业架构框架对于规划和可视化很有价值。在架构变革的早期阶段，它们尤其有助于领导与利益相关者的对话，并可视化业务和 IT 对齐的结果。但Zachman框架（目前使用的 EA 工具中最古老的框架）已创建近30多年，当前企业架构框架使用的主要关心的有如下主要问题：

• 文档不全面

尽管对 80 年代和 90 年代创建的最受欢迎的框架进行了多次更新，但其现代版本仍被视为不切实际和过时。此外，创建和维护 EA 文档需要很多资源，这在许多创新公司的敏捷环境中并不充足。

• 费时且缺乏灵活性

大多数 EA 框架不如现代商业工具包（如商业模型画布）具有活力。需要时间来规划，需要培训来开发和呈现结果，不容易适应快速的变化。更多的是文档，而不是针对创新的实际活动，这往往会因为过度考虑文档化而减缓创新的过程。

• 完全集成是不可行

每个框架的局限性，不能为与公司的新系统和现有系统无缝集成提供机会，需要额外的资源进行大量适配。

这些担忧并不一定意味着多年实践的EA 框架过时，就像任何正规化的方法一样，Zachman 或 SABSA 都会受到批评和强化，在开始和整个流程中引入，并被企业架构师以不同的方式使用。

企业框架给安全架构的启示

除了SABSA专注于安全架构，TOGAF也有在其架构设计方法的每个阶段中提出如何考虑安全的需求和相关安全的设计，但安全的复杂性越来越高，相关参考的安全标准、模型和实践也越来约多，需要构建有效和体系化的安全架构，结合上述企业架构的实践，安全架构的设计也需要从以下几个方面重点考虑：

• 构建不同的安全视角，安全从概念规划、逻辑设计、实现一直到安全运行，需要从不同安全人员的视角去建立完整的视图，以确保安全问题的完整性覆盖；

• 不同层的视角在构建安全能力和活动时，需考虑上下文的关系，即建设必须有所依据，有所目标，确保安全能力和策略都为了支撑业务的目标的实现；

• 安全架构也不是一成不变的，需要汇聚业务需求、合规需求及威胁的变化进行反复调整，也要跟随着业务架构的变化而变化，采用迭代的方法不断更新安全架构；

• 安全架构的设计和建设需要考虑和提供相应的接口与其他安全实践、安全标准对接，典型的如与企业架构集成，关联等保和关基，采用相关基线实践等；

• 安全架构的设计和建设目标要能够有力支撑企业的战略目标的达成，需要在规划阶段就需要考虑是否有明确的安全战略和安全目标，与业务的目标是否一致

• 架构的实现过程，就是逐层映射的过程，从构想到逻辑，从逻辑到物理、人员组织、制度和策略，通过完整的映射，也就确保了底层组件有力支撑战略目标的实现

参考文献：

Enterprise Architecture Frameworks: TOGAF, Zachman, SABSA, and EA | AltexSoft
e Frameworks: TOGAF, Zachman, SABSA, and EA | AltexSoft](https://www.altexsoft.com/blog/business/enterprise-architecture-frameworks-documenting-your-roadmap-to-change/)