对于IT人员，想要成为好的工程师，首先也要进行规划的设计，其次深入到细节中写代码，想要往上发展，规划的能力

越来越重要。什么是规划？ 在IT中就是你的架构设计，而在架构设计上，TOGAF提供了一套完整的企业架构方法论，可以让我们站在更高的视角去看待技术，看待业务，设计出实施路径帮助达成目标。

一、基本概念

什么是企业架构？

企业架构主要关注业务架构与IT架构，是企业用于实现业务战略的IT的总体规划设计工具。

为什么需要企业架构？

搭建简易狗窝不需要架构，但是搭建大厦必须需要经过设计阶段，对于不复杂的东西，怎么做都不会出差错，但是一旦业务复杂，规则复杂，还涉及变革时，必须有一个清晰的架构才能保证做出来的东西是正确的。

企业架构的目的是在整个企业范围内优化通常分散的流程（手动和自动）遗留到一个集成环境中，该环境响应变化并支持业务战略的交付。

今天的 CEO 都知道，有效管理和利用信息以及数字化转型是企业成功的关键因素，也是获得竞争优势不可或缺的手段。企业架构通过为数字能力的演变和范围提供战略环境来满足这一需求，以响应业务环境不断变化的需求。

例如，社交媒体、物联网、云计算的快速发展，从根本上扩展了企业创造新市场机会的能力。

此外，良好的企业架构使您能够在业务转型和持续运营效率之间取得适当的平衡。它允许各个业务部门在追求不断发展的业务目标和竞争优势的过程中安全地进行创新。同时，企业架构使组织的需求能够通过集成战略得到满足，从而在企业内外实现最密切的协同作用。

简言之：企业架构可以为企业带来价值

提升业务与IT效率

降低未来的风险

为什么是TOGAF？

TOGAF 标准是通过整个社区的共同努力制定的，可以开放使用

TOGAF是目前最流行的企业架构框架，并且一直在维护中

TOGAF框架可以帮助企业快速有效性的实施IT战略

二、TOGAF核心概念

TOGAF定义的架构

ISO/IEC/IEEE 42010:2011 定义：

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

一个系统基本的组织，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及治理其设计和演进的原则上。

TOGAF在其基础上做了一些扩展定义：

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

在系统设计演化过程中，组件的结构，它们内部的关系，原则和参考。

TOGAF旨在支持四种常见的架构，这些架构归为企业架构的子集：

业务架构：定义了企业战略，管理，组织和主要的业务流程。

数据架构：描述一个组织的物理和逻辑数据资产，以及数据资源的结构。

应用架构：提供了一个蓝图，各个应用程序部署，它们之间的相互作用，以及它们的关系，该组织的核心业务流程。

技术架构：描述了需要支持的业务，数据和应用服务部署的逻辑软件和硬件的能力; 这包括 IT 基础设施、中间件、网络、通信、处理、标准等。

架构开发方法ADM

ADM是TOGAF的核心，提供的一种可测试和可复用的开发架构过程，ADM包含建立架构框架、开发架构内容，迁移和治理架构实现的部分。它描述了一种开发和管理企业架构生命周期的方法。

架构内容框架-架构输入与输出结构化

执行架构开发方法的的过程中会产生许多输出，例如流程、架构要求、项目计划、项目合规性评估等。架构内容框架为输出的内容提供了一个结构模型。允许架构师创建的工作结果被一致地定义、结构化和呈现。

TOGAF定义的交付物、目录、矩阵、图： 下图列出了在进行架构开发过程中输出的主要交付结果。

企业连续体—架构演进

描述了企业架构的演进过程，以及根据当前所处的阶段应该用哪一种架构。

视图：一个架构演进的视图 A View Of Architecture Reposory

分类方法：一种分类方法，可以对架构进行分类，从一般到特殊，从抽象到具体，从逻辑到物理 Classifying Architecture and solution artifacts,from generic to specfic

它使架构师能够从广泛的角度阐明企业架构的设计内容、原因和方式，并考虑了所考虑的因素和驱动因素。可以让业务方明白当前企业架构所处的位置，从而进行沟通。

架构能力框架—建设架构能力

为了在企业内成功运行架构功能，有必要设置适当的组织结构、流程、角色、职责和技能来实现架构能力。来支持企业架构的能力。TOGAF提供了一套关于如何建立这样一个架构功能的参考资料

架构存储库-架构知识索引

架构存储库是管理和利用不同类型架构资产的方法和工具，包含内部的架构资产与外部的架构资产。在真正架构设计的过程中，可根据架构存储库中的内容进行索引，找到自己适合的架构进行复业。

三、ADM-架构开发方法

TOGAF ADM(Architecture Development Method) 是大量架构从业者不断贡献的结果。它描述了一种开发和管理企业架构生命周期的方法，并构成了 TOGAF 标准的核心。

架构生命周期

架构本质上是一种处理不确定性和变化的活动 - 它是相关方想要和实际能力之间的“灰色区域”，可能有很多路径，架构要求在实践中总是会发生变化。

1、ADM架构工作由需求进行驱动，需求管理贯穿整个架构生命周期。

2、ADM一共有8个标准的阶段，每个阶段都有该阶段具体的：目的、输入、输出、步骤、和方法。 可根据ADM中参考步骤和方法进行架构工作。输入输出，其也有具体指定。

3、ADM是通用的架构开发方法，但是实际中可以进行扩展或者裁剪相关的阶段适应特定企业的需要。

完整的架构生命周期：https://pubs.opengroup.org/architecture/togaf9-doc/m/pt2.html

交付结果概览图：

预备阶段

在架构工作准备阶段，主要有两件事情：

确定组织具备的架构能力有哪些

检查组织的环境

识别架构能影响组织的范围和元素

确定与架构能力相交的方法、流程、框架

建立能力成熟度目标

建立组织要具备的架构能力

定义和建立组织架构模型

定义和建立架构治理的详细流程和资源，裁剪ADM，定义架构原则

选择和实施支持企业架构的工具

定义架构原则

应用TOGAF框架的企业架构师不能狭隘地关注IT实现，而必须意识到架构对整个企业的影响。

阶段A 架构愿景

愿景表达了一种我们对架构的一种期望结果，阐明重要的相关方、问题以及目标，可以帮助团队关注产品的核心内容，并用来与相关方进行沟通。

架构愿景是在架构开始阶段，企业中的关键决策者一致同意的结果，提供了架构工作要变更的主要内容。

通常架构愿景包含如下内容：

问题描述

利益相关方和他们的关注点

需要被解决的问题/场景列表

架构工作的目的

大概的架构工作视图，0.1版本的业务、应用、技术视图创建完成，还有：

价值链图：企业为消费者创造价值的主要流程。

解决方案概念图：主要包含，目标、需求、约束以及高亮要深入调研的工作区域。

愿景映射的一些需求

架构定义文档的草稿

阶段B 业务架构

业务架构的目的：

开发目标架构来描述企业如何运作能达到业务目标，对应架构愿景中的战略驱动，同时解决一些相关方的关注点。

识别出当前架构与目标架构的架构路线图。

阶段C 信息系统架构 - 数据架构

阶段C 信息系统架构 - 应用架构

阶段D 技术架构

阶段E 机会和解决方案

本阶段目标：

根据 B、C 和 D 阶段的差距分析和候选架构路线图组件，生成架构路线图的初始完整版本

定义整体解决方案构建块以最终确定基于架构构建块 (ABB) 的目标架构

阶段F 迁移规划

F阶段的目标是：

最终确定架构路线图和支持实施和迁移计划

确保实施和迁移计划 与企业管理和实施企业整体变更的方法一致

确保关键利益相关者了解工作内容和过渡架构的业务价值和成本

阶段G 实施治理

阶段H 架构变更管理

需求管理

业务架构

什么是业务架构？

业务架构是企业治理结构、商业能力与价值流的正式蓝图。

业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。

业务架构就是对企业的业务流程，进行根本性的再思考和在思考的彻底性再设计，从而获得成本、质量、速度等方面业绩的巨大的改善或提高。

业务架构包含：战略、企业业务流程(价值链)、当前能力，未来能力；商业能力，IT能力；

业务架构是从战略到实施过渡的桥梁

业务架构是由企业战略驱动的，业务架构发挥了从战略向实施过渡的作用，上接公司战略，下接IT与非IT实施：

战略决定业务，业务支撑战略；

业务决定技术，技术支撑业务；

业务架构优化方法

万般需求皆业务，万般业务皆流程；管理无止境，流程出效益；

在流程优化上，有著名的ESAI理论，目标业务流程设计方法：

Eliminate-删除无附加价值的步骤

过度控制

重叠环节

等待时间

反复校验

部门协调

Simply-简化所有过于复杂的环节

简化所有复杂的步骤

表格

程序

沟通渠道

Integrate-集成功能 ，理顺流程过程

离散到整合

无序到有序

职责，部门，客户，供应商

Automate-运用先进的信息技术自动化

数据收集

数据传输

数据分析

自动化

IT架构

什么是IT架构？

对应到TOGAF中，IT架构又分为应用架构、数据架构、技术架构，主要目的就是为了支撑业务架构。

数据架构：数据的收集，治理(管理)，服务等

应用架构：根据业务场景需要，设计软件的功能分配，集成交互，服务总线(规范与标准)。关注点在功能以及功能交互

技术架构：从技术实现的角度考虑应用的各种功能，技术选型等，硬件与软件的通信。关注如何实现功能，可用性，稳定性等。

常见应用架构模式

分层或N层架构，这是一种传统架构，通常用于构建内部和企业应用，而且常常与传统应用相关联。

微服务架构，它也是一种构建软件的方法。在微服务中，应用被拆分成最小的组件，彼此独立。其中的每一个组件或流程都是一个微服务。

事件驱动架构：对于事件驱动系统而言，事件的捕获、通信、处理和持久保留是解决方案的核心结构。这和传统的请求驱动模型有很大不同。事件是指系统硬件或软件的状态出现任何重大改变。而事件的来源可能是内部也可能是外部原因。

面向服务的架构：（SOA）是一种非常成熟的软件设计模式，它有点类似于微服务架构模式。 SOA 将应用构建为可重复使用的离散型服务，这些服务会通过企业服务总线（ESB）进行通信。

参考：

阮一峰-软件架构入门：https://www.ruanyifeng.com/blog/2016/09/software-architecture.html

RedHat-什么是应用架构：https://www.redhat.com/zh/topics/cloud-native-apps/what-is-an-application-architecture

业务场景

IT架构成功的关键因素是架构与业务需求的关联程度，并且在一定程度上能被证明可以支持和帮助企业完成目标。

在企业架构中，需求是架构的核心，所有的设计工作都是围绕需求来做，识别最有价值的需求也是非常重要的。而识别真正的需求，则需要我们理解需求的的业务场景是什么。

什么是业务场景？

业务场景是在在架构开始之前，或者架构的过程中从企业高层，各方获得的一些输入，然后推导技术架构的特征。业务场景用于识别和理解真正的业务需求，尽可能还原需求提出的背景，以及各种因素。

业务场景描述：

业务流程

业务和技术的环境

在场景中执行的人员和参与者

正确执行预期的结果

业务场景本质上是对业务问题的完整描述，如果没有需求的完整描述和还原，可能设计出来的就是错误的架构，只解决了部分的需求，而不是业务方真正想要的；进而没有交付出价值。

如何创建还原业务场景？

7个区域、3个阶段：

1 - 识别、记录和归类问题 2 -识别、记录场景的业务和技术环境 (输入、输出、工具和技术等) 3 - 识别和记录期望的目标（成功处理问题的结果） - SMART原则 4 - 确定参与者，及其在商业模式中的位置 5 - 识别计算参与者（计算因素）及其在技术模型中的位置 6 - 识别并记录每个参与者的角色、职责和成功衡量标准；记录每个演员所需的脚本，以及处理情况的结果 7 - 检查“适合目的”并在必要时进行改进，重新提炼问题、目标

三个阶段：

收集信息：办业务场景研讨会，通过一些问题来获取有关架构工作正在解决的问题的信息。

分析情况：创建模型描述该信息，通常是视觉化的

审查：将结果反馈给项目发起人的阶段，以确保对问题的全部范围以及技术影响的对所有人达成共识。这个阶段非常重要，因为缺乏共同的期望在许多情况下是项目失败的根本原因。

最后产出一份类似如下的文档：

利益相关方管理

在架构从开始到结束阶段，识别出哪些人，哪些团队可以对项目的进展会有贡献，识别哪些人可能成为阻碍或者投入度低，并且提前进行准备。

针对不同的相关方，采取不同的沟通，合作策略。对做架构的人来说，相关方的管理是一个非常重要的课题，获得相关人员的支持才能确保项目更容易做成。否则，很容易无法推进而失败。

做好利益相关者的管理可以有如下好处：

高层给予一定输入的话，可以让架构模型有更高的质量和形状。

高层支持的话，可以帮助项目获得更多资源，保证项目更容易做成

早期识别相关人员的依赖，可以在事情推动的时候提前做好准备，减少一定的冲突和无效推动。

识别相关方？关键人物Key Person？

首先脑暴所有相关的人员，谁会受到项目的影响，谁有权力改变项目，谁对这个项目有兴趣。可以从上到下考虑一遍。

试着回答以下几个问题：

谁会从这次的改变中获得损失、受益？

谁控制项目？

谁设计系统？

谁做出决策？

谁控制资源？

谁有对项目的影响力？

谁有对项目有帮助作用的技能？

下图是一个相关方分析的按理，其中有22种类型的相关方，5个比较大的种类。不同的项目有不同的分类，目的主要还是为了识别谁会对项目有贡献。

相关方态度处理矩阵

A 最少投入关注 B 通知到位 C 保持其满意 D 关键人物

基本的沟通技巧

简化运用语言，对方如何接受你这个信息是最容易理解的

视觉辅助手段，能用图表，不用图片，能用图片，不用文字。 图表 > 图片 > 文字

积极倾听与有效的反馈

架构设计原则

一般架构原则是由企业架构师和一些企业高层定义，原则是能清晰的表达后续大家做出决策的依据。定义企业架构原则一般考虑以下因素：

企业的使命和愿景：

企业的战略计划：企业的优势，劣势，机会和威胁。

外部约束：市场因素，法律因素

当下的系统和技术：

未来的趋势：金融，政治，技术和市场未来的走向。

衡量原则好坏的标准：

易理解性

有效性、健壮性：通过这个原则能指导做出好的决策。

完整性：原则覆盖了多种场景和视角

一致性：保持不变，不能解释一些相反的东西

稳定性：原则能持久的，并且能适应变化

初始阶段可以使用头脑风暴进行定义有哪些原则，后续在持续开发的过程中不断迭代。

架构原则

基于标准的方法来做，如使用TOGAF架构方法

说不清的不做

没有上层持久推动的不做

达不成意见一致的不做

业务原则

企业利益最大化

业务持久性 对业务发展有长远规划，不能只考虑近期实现范围

业务通用性， 业务是否可以作为一个公用业务架构

业务一致性

合法

数据原则

数据价值性 > 数据正确性 > 数据完整性

数据积累分析需要规范化数据

数据是安全的

数据不只是可以共享的数据，还包含业务规则和策略

应用原则

技术独立性，不绑定到特定厂商

使用过程体现流程性

模块化设计原则

独立业务规则

统一授权，统一界面

应用系统间间调用采用服务调用的方式

与外部系统调用，必须有统一的接口规范信息格式

技术原则

相应变化

可扩展

参考：https://pubs.opengroup.org/architecture/togaf92-doc/arch/

四、架构内容框架

在进行架构的工作中会有很多输出，图表，文档，解决方案，技术沉淀等，内容框架就是讲输出的结果进行结构化的定义以及展示。

架构制品-过程输出

创建架构制品(Architectural artifacts)是为了描述系统、解决方案或企业状态，制品部分的概念在ISO/IEC/IEEE等都有比较正式的定义，并且可以通过一张图表示概念之间的关系。

基本架构概念

环境(environment)：确定对系统的所有影响的设置和环境的上下文。系统的环境包括发展阶段、技术、业务、运营、组织、政治、经济、法律、监管、生态和社会影响。

系统(System)：是为实现一个或多个既定目的，有一定关系的元素的组合。

架构(Architecture)：是系统在其环境中的基本概念或属性，体现在其元素、关系以及设计和演化的原则中。

架构描述(Architecture Description)：是用于表达架构的工作产品；是一些视图，模型，和文档的组合。

利益相关者(Stakeholders)：是对系统感兴趣的个人、团队、组织或其类别。

关注点(Concerns)：是与一个或多个利益相关者相关的系统中的利益。关注点可能与系统功能、开发或操作的任何方面有关，包括性能、可靠性、安全性、分布和可演化性等考虑因素，并可能决定系统的可接受性。

架构视图(Architecture view)：是从相关的一组关注点的角度对系统的表示。它由系统的一个或多个架构模型组成。

架构视角(Architecture viewpoint)：是特定类型体系结构视图的约定规范。它也可以称为这种架构视图的定义或模式。它建立了用于构建：解释和使用架构视图来解决有关感兴趣系统的特定关注点（或关注点集）的约定。

架构模型(Architecture Model)：是感兴趣的主题的表示。模型提供了主题的较小规模、简化和/或抽象表示。

模型种类(Model Kind)：为一种建模类型建立了约定。

观点库(viewpoint library)：是体系结构存储库的参考库部分中包含的体系结构观点规范的集合。

架构图输出

参考：https://pubs.opengroup.org/architecture/togaf9-doc/m/chap31.html

其中每一种图、目录、矩阵的解释和作用可在参考链接中查看完整的描述。

可交付成果

在整个架构过程中产生的可交付成果目录：

架构愿景，架构需求规范，架构原则、架构定义文档、架构合约

业务原则、业务目标和业务驱动因素

架构路线路

沟通计划

符合性评估

实施和迁移计划

实施治理模型

企业架构组织模型

定制架构框架

详细参考：https://pubs.opengroup.org/architecture/togaf9-doc/m/chap32.html

五、一些想法

通过学习企业架构的方法论，在日常工作中，可以让我们有一个更高的视角去看待工作的事情，还有在做事情的时候有一些可以参考的步骤指引，做起事来有一定的章法，更不容易出错。

它的作用类似于做饭时候的提供的一份牛肉酱，有了这一瓶酱，饭菜的味道可以保持在一个平均的水准，不会太差。但是想要做的足够好吃，还是需要要灵活的使用各种调料，结合实际情况实际需要进行组合，而这需要在不断的实践的过程中，慢慢的融会贯通。方法论有用，但是不能一味的生搬硬套，要根据企业实际的场景需要对整个框架进行裁剪和制定，灵活运用。