企业架构框架入门Togaf、FEAF、Zachman
今天看到一个帖子, 开价很高招聘 金融类的业务架构师, 任职条件第三条提到:
"3.掌握企业架构方法与较好的实践应用，例如Togaf、FEAF、Zachman等；掌握领域建模、业务价值链分析方法并根据业务抽象提炼业务需求与业务架构；"
Togaf、FEAF、Zachman是一般企业架构师不太接触的. 属于 企业数字化转型需要的一些技术, 针对这几个方法寻找了一些入门知识.
1. Zachman 方法
来自 https://zhuanlan.zhihu.com/p/397754925
不同的企业架构理论的内容不尽相同。第一个企业架构的框架理论是由约翰·扎克曼（John Zachman）于1987年创建的。至今，这个架构还是企业和政府最易接受的理论，国际上称之为Zachman Framework。
尽管创建的时间已经有30多年，随后产生了很多新的技术和理念，但是Zachman框架在北美和欧洲还被认为是最基础的理论（特别是在企业领域）。Zachman的论文《信息系统架构框架》（Framework for Information System Architecture）直到今天在业界仍然被认为是一个权威的理论，是其他框架的源泉。Zachman的名声不仅是由于他在框架理论上的工作，还由于他早期在IT系统规划方面的贡献。系统规划在20世纪70年代是IBM广泛使用的信息规划的方法论。作为一个系统和有效的理论，系统规划给IBM的主要核心领导、规划部门、技术部门提供了一个强大的工具。从70年代以来，Zachman先生一直致力于信息系统规划和企业架构的推广工作。他出版了很多有关的书籍，撰写了很多相关文章，还为全球的企业和政府提供教育和咨询，带动了企业架构的发展。
1987年，Zachman先生发表的关于企业架构的论文中，有下面一张示意图，如图A-1所示。
图A-1 Zachman论文中的房屋架构图
这张图是Zachman先生的一个建筑架构师朋友画的设计图，是建筑师与他的客户讨论一个新建房屋的设计图。不同颜色和形式的线条代表了新房子需要有的功能，将会指导建筑队、电工、管道工等相关人员进行施工；也保证了客户的需要得到表达和满足。正如房屋架构图一样，企业建设也需要企业架构图。在Zachman的论文中，他提出以下5个层次的企业框架：规划者、业务属主、系统设计者、技术设计者、开发人员。Zachman没有提出它们之间的依赖关系和如何实施这个框架，而且主要是从IT架构的角度提出的，并没有全面涵盖业务架构的内容，如图A-2所示。
图A-2 Zachman框架组成的层次和元素
在图A-2中，Zachman框架由5行6列共30个元素组成。这个框架以最简单的形式描述了企业架构内的元素和它们的层次，以及这些元素在设计中的作用。Zachman框架认为，一个系统的建设需要6个方面的信息，称为6W：数据（What）、功能（How）、网络（Where）、人员（Who）、时间（When）、动机（Why）。从第一层到第五层，信息和规则越来越多，设计越来越细化。通过6W的划分，使复杂、庞大的系统设计工作简单化。在设计30个元素内容的时候，它们相互不能重复，而且组合在一起就能清晰地定义一个IT系统。
Zachman各个层次之间是有层次的，从高层次的战略和方向性的设计，逐步细化到详细设计。
- 业务范围（scope）：系统支持的业务范围，规划系统在功能和成本等方面的整体性要求。
- 业务模型（business model）：描述业务实体和它们之间的关系，以及业务流程。
- 系统模型（system model）：系统设计者决定系统提供的功能和数据模型。
- 技术模型（technical model）：考虑系统开发的工具、技术方案和平台等。
- 具体定义（detailed decription）：定义具体的数据库、系统模块、业务规则等，能够分配给开发者开展工作。
由以上5个方面定义架构和需求，就可以建立在业务运营中实际运转的工作系统。所以，Zachman架构主要还是解决系统建设的问题，不涉及业务和流程的设计。
Zachman表格的缺陷：整体来看，Zachman本身还是很粗糙的，并不是一个完整的解决方案。有太多的问题它都没有描述。Zachman没有给出一步一步构造一个构架的过程。所以需要结合其它方法来构造一个完整的解决方案。
2. FEAF 方法
https://www.cnblogs.com/zscyun/archive/2013/05/03/3057843.html
美国联邦政府可以说是企业架构应用的先行者和最大倡导者。通过企业架构的发展历史我们可以看出，早在上世纪九十年代以来，美国军方就对这种全局性的信息共享的理论开始了研究，并开发出符合其特色企业架构框架理论（DoDAF）。除此之外，在Zachman框架引入到美国联邦政府各部门之后，首先是美国国家技术标准研究所（NIST）于1989年发布了NIST企业架构模型（NIST EA Model，后来的联邦企业架构框架FEAF的便是以此为基石而建立起来的），随后各个政府部门也推出了他们自己的企业架构框架理论用于指导各自企业架构的开发，例如财政部（DOT）的企业架构框架TEAF（Treasury Enterprise Architecture Framework）。虽然各个部门都建立了符合各自特点的企业架构框架，并据此逐步实现着各自的企业架构，但是在当时这些企业架构的范围还是局限在各自的部门范围内，而从美国联邦政府这一整体角度来看，诸如组织目标与信息系统的相互适配以及信息系统和资源的冗余浪费等方面的问题并没有得到完美的解决。无论从组织架构、组织职能，还是从其服务对象的角度来审视，美国联邦政府可以算得上是世界上最复杂的组织系统之一了，这并不是一家企业或者某一个政府部门的复杂度所能比拟的，因而如何站在美国联邦政府这一全局角度来考虑企业架构所面对的问题是极具挑战的。为了解决这一问题，一个从联邦政府这一整体性角度出发的企业架构框架需要被开发出来，并以此为基础建立和维护适合联邦政府自身的企业架构，从而能够促进各个政府部门之间的信息整合和共享，提高整个联邦政府在信息化投资方面的效率。这一思想在付诸实行后历经多年演进最终结晶为联邦企业架构FEA。
正如名字中说到的那样，联邦企业架构的产生和发展有着明显的政府色彩，它的出现与发展和一系列的政府法令息息相关，并由专门的政府机构负责协调和实施。一般来讲，人们在提到联邦企业架构的时候总会从1996年颁布的Clinger-Cohen法案（亦称为信息技术管理改革法案）讲起，因而该法案也被当作联邦企业架构出现的始因。这部法案的主旨是美国政府指导其下属的各联邦政府机构通过建立综合的办法来管理信息技术的引入、使用和处置等，并且该法案要求各政府机构的CIO负责开发、维护和帮助一个合理的和集成的IT架构（ITA）的实施。在此法案的推动之下，CIO委员会于1999年发布了FEAF（Federal Enterprise Architecture Framework），用于指导联邦政府各部门创建企业架构。随后，联邦企业架构创建和管理工作被移交给了美国的管理和预算办公室（OMB），而OMB也随即成立了联邦企业架构程序管理办公室（PMO）来专门开发联邦企业架构（FEA），并于2002年2月发布了第一版的FEA。
FEAF
FEAF是自Clinger-Cohen法案颁布之后出现的第一个专门用于构建联邦政府企业架构的框架理论。CIO委员会自1998年4月启动了FEAF的开发，通过借鉴NIST企业架构模型、Zachman框架以及企业架构规划（EAP，Enterprise Architecture Planning）等技术，最终于1999年9月发布了FEAF 1.1版。通过这份文档，CIO委员会针对FEAF产生的目的、背景以及组成进行了详尽的描述。FEAF是一个以架构建设过程为重点的企业架构框架理论，并且对于企业架构内容也有着一定程度的归纳（虽然标准化程度并不高），同时最重要的是FEAF所提出的片段架构（Segement Architecture）的概念对于以后的FEA的影响是非常大的，并且为日后大型企业创建企业架构指明了一条道路。
随后，在2001年CIO委员会又发布了联邦企业架构实施指南（ 《A practical guide to Federal Enterprise Architecture》）。在这篇指南中，CIO委员会介绍了联邦企业架构建设的具体流程和企业架构框架（例如FEAF等）如何在企业架构建设过程中发挥作用。并且在此指南中，企业的生命周期也被定义成由企业架构过程与其他几个企业管理过程相互结合并互相作用的过程，从而体现了企业架构在一个组织中的重要意义。
FEAF的出现
在FEAF出现之前美国联邦政府的许多机构已经开始了企业架构的建设，并提出了很多企业架构框架理论，这些理论和实践虽然为FEAF的创建提供了借鉴，但是这种繁杂的背景同时也为一个全局性的联邦企业架构的建立带来了不小的挑战。由于联邦企业架构所管理的信息资源分布于各个机构之中，所以FEAF必须能够被各个机构方便地采用，并且不能影响到各个机构已有的企业架构，从而保护各机构为各自企业架构所付出的投资和努力。在这个背景之下，当时负责指定FEAF的CIO委员会为联邦企业架构框架制定了三个方向：
- 传统方法：首先在时间和资金上申请大量的初始投资，然后开发一个能够对架构进行描述的框架，并使用此框架对当前架构以及目标架构进行描述。在此之后，通过设计、开发以及系统采购等方式实现企业架构的演进。
- 片段方法：建立一个结构化的企业架构框架，并对中的架构片段进行增量式开发，从而达成联邦企业架构的建设目的。在此方法中每个片段被限定在一个特定的业务领域内。
- 维持现状。
第三个方向其实不用多说，因为维持现状所带来的还是老生常谈的无法信息共享，以及缺乏针对环境变化而进行快速反映的能力，而且最关键的是无法符合Clinger-Cohen法案的要求（不要忘了联邦企业架构的政府色彩）。第一种方向听起来最合理，因为大部分企业架构框架理论都符合此特征，但是由于联邦政府的复杂性，此种方法虽然逻辑上可行，但实际上却很容易陷入“分析瘫痪”（paralysis by analysis），因为从根本上对联邦政府进行一步到位的描述几乎是不可能完成的任务，甚至可能会影响到各机构已经建立的企业架构的发展，而且即便采用这种方法，那么联邦架构的开发过程将会不可思议的漫长。经过反复权衡，CIO委员会采取了第二种方式，即将整个联邦政府架构看成若干片段，每个片段对应某个特定的业务领域，同时针对每个片段采用架构描述方法对各个业务领域进行架构描述。如此一来，联邦政府架构的建设可以被分割为若干较小型的针对某一业务领域的企业架构的建设，并最终组合成联邦的整体企业架构。
从系统分析方法论的角度看，如果一个系统过于复杂，则对其进行分析的最好方法就是按照某种角度对整个系统进行解构。随着系统的解构，系统的复杂度也会被分解到各个部件中，因而分析各个部件将会相对容易，并且通过将各个部件的分析结果组合在一起将最终形成对整个系统的分析结果。实际上第一种传统方法可以看作是一种通用的企业架构建设方法，理论上如果资源充足应该能够适用于所有组织中的企业架构建设，但是其之所以不能实现就是因为联邦政府这一系统的复杂性所带来的资源需求无限制化倾向。因而一种能够将系统复杂度分解的方法与传统企业架构建设方法相结合的方法论才是能够打开联邦企业架构建设之门的金钥匙，而这也正是FEAF所采用的“片段方法”的主旨所在。在“片段方法”中，首先从各个业务领域的视角开始对整个联邦政府在逻辑上进行分解，然后采用传统企业架构建设方法对每个分解出来的片段进行建设。也正是由于这种“片段方法”，联邦企业架构的建设过程也成为了一个基于各个业务领域的增量式的演进过程，而且由于建设单元被细化，联邦企业架构针对外界变化的反应能力得到了增强。不过笔者认为，分段方法并不能减少问题的总体复杂度，而是使复杂的问题简单化，从而使复杂问题的解决成为可能，但是问题的总体复杂度依然守恒。从全局看，问题的复杂度并不会降低，某一局部的便利总会需要其他方面复杂度的提高来平衡。同理，这种片段式的方法只是通过分解复杂度使得建立如此庞杂的企业架构成为可能，至少降低了这一宏大项目的实施门槛，不过就总体复杂度来讲却不见得有任何减轻。原来整体的一块被分解为相对琐碎的若干片段，虽然就每个片段来说实现难度下降了，但由于这些片段之间的相互联系性，维持这些片段一致性发展就会成为新的问题点，如果只注重于某个片段的发展而忽视片段之间的协调性，那么类似于之前所说的“技术驱动”路线的弊端还会显现，甚至更为严重，因而一个全局的针对联邦政府企业架构的治理、共享和评测机制也需要建立起来，并施以同样的重视度，我想这就是在后面将提到的联邦过渡框架（FTF）、企业架构评估框架（EAAF）和企业架构实施指南等框架和导则存在的原因之一。但不论怎么说，FEAF的这种“片段方法”可以说是联邦企业架构的主要特色，此后OMB建立的FEA的很多内容实际上也是该方法的延伸和具体化。
FEAF的构成
在联邦企业架构的建立方面，FEAF首先是一种组织机制，被用来管理企业架构描述的开发和维护，而在将企业架构付诸实施方面，FEAF还提供了一种结构，用于组织联邦政府资源以及描述和管理联邦企业架构的相关行为。在联邦企业架构框架的设计过程中，CIO委员会将企业架构的开发和维护过程以模型的形式进行表述，并且他们还将这一模型分成八个相互结合并互相作用的子部件：
- 架构驱动力（Architecture Drivers）：架构驱动力是促使架构产生和演进的原动力，一般来说包含两种类型的来自于外界并对企业架构的变革产生刺激的推动力：业务驱动力和设计驱动力。其中，业务驱动力包括新的法规、新的管理举措、用于加强重点领域的预算增加以及市场力量等，而设计驱动力则会包括新的软件或硬件技术，以及新的针对软硬件系统的部署方式等。
- 战略方向（Strategic Direction）：战略方向指导者目标架构的开发，包括愿景、原则和目标。
- 当前架构（Current Architecture）：通过描述企业架构的当前状态，展示了企业当前的业务能力和技术能力。它包括企业当前的业务架构和设计架构（设计架构可以进一步分为应用、数据以及技术这些方面）两个部分。
- 目标架构（Target Architecture）：描述了企业架构将要达到的目标状态，展示了企业未来的业务和技术能力。它包括企业的目标业务架构和设计架构两个部分。
- 过渡过程（Transitional Process）：用于支持从当前架构到目标架构的迁移。联邦政府的重要过渡过程包括了资本的IT投资规划（capital IT investment planning）、迁移规划（migration planning）、配置管理（configuration management）以及工程变更控制（engineering change control）。
- 架构片段（Architectural Segments）：如前所述，整个企业架构被分为若干部分，而每一部分对应一个架构片段。
- 架构模型（Architectural Models）：定义了用于对各个架构片段进行描述的业务和设计模型。
- 标准（Standards）：代表架构开发和维护过程中所涉及的所有标准（有些可能是强制性的要求）、导则和最佳实践。
将此八种部件组合在一起就形成了FEAF开发和维护企业架构的模型：
FEAF第一层粒度示意图
由此图我们可以得出如下结论：
- 在FEAF的世界里企业架构的出现和变更都是在一系列的架构驱动力的刺激之下来进行的。由于外界的刺激以及环境的变化总是绝对的，因而FEAF是站在一个适应变化的角度上阐述企业架构的开发和维护过程，并将其定义为一个循环往复的过程，这是非常客观的。
- 在架构驱动力的推动之下，企业的战略方向也会跟随演进，并且目标架构的制定是需要与企业的战略方向相一致的。由此可见，FEAF将外界推动、企业战略结合了起来，并将企业战略细化为更加具体的目标架构描述，从而使企业战略即符合现实需要，又在整个组织范围内得到了一致认同。
- 当前架构和目标架构需要使用相同的方式和语言（架构模型）进行描述，从而可以分析出现实和目标的差距，并将这些差距具体化为一系列的过渡过程，从而指导企业和企业架构的同步演进。并且在演进过程中，所需要遵循的各项标准，以及所采用的导则和最佳实践等工具也被明确了出来，从而达成在实施过程中的无障碍沟通性和标准性。
- 架构片段的划分大大降低了开发联邦企业架构的复杂性，并且也可以按照增量的方式对联邦企业架构进行循序渐进的开发和维护。
- 采用相同的架构模型对各个架构片段进行描述可以提高各个架构片段开发的标准性，并且不同架构片段之间的沟通也更加通畅，例如通用性架构片段对各个具体业务领域架构片段的支持和融入将变得非常容易。
上述模型表达了FEAF针对开发和维护企业架构的行为和流程在最高层次的抽象。为了进一步描述这一企业架构开发和维护过程，FEAF还通过四种粒度（上述模型为最粗粒度的描述）对其进行了更加详细的阐述。需要注意的是，在这四种描述粒度中前三种是针对整个企业架构开发和维护过程进行逐级深入的描述，而第四种粒度只是针对架构模型内容方面做了更加细致的种类划分。
基于前述关于FEAF第一粒度层次的描述，在第二粒度层次中原来模型中的架构驱动力、当前架构、目标架构以及架构模型的内容被进一步从业务和设计两个方面进行了细化：
FEAF第二层粒度示意图
在第二粒度层次的细化中，业务方面代表着企业业务能力方面的内容，而设计方面则代表用于实现企业业务能力的技术方面的内容：
- 架构驱动力细化为业务驱动力和设计驱动力两个方面：
- 业务驱动力代表着联邦政府的核心业务需求，例如公众访问需求、Clinger-Cohen法案对架构开发的要求、其他新法案要求电子化访问或者电子签名的使用，以及关于政府行为的各种创新。
- 设计驱动力代表用于实现联邦政府业务需求的各种革新方法，例如使用Internet。
- 当前架构的内容也被从业务和设计两个层面进行了划分：
- 当前架构的业务层面代表了在当前技术能力支持下企业目前的业务需求。
- 当前架构的设计层面代表了用于实现当前业务需求的数据、应用和技术方面的内容。
- 目标架构的内容也被从业务和设计两个层面进行了划分：
- 目标架构的业务层面代表了在未来技术能力支持下的企业未来的业务需求。
- 目标架构的设计层面代表了用于支持未来业务需求的数据、应用和技术方面的内容。
- 架构模型包含了用于描述架构内容的各种架构制品。在第二粒度层次的细化中，架构模型的内容也被分为业务模型和设计模型：
- 业务模型为在架构驱动力推动下出现的各种业务需求进行建模。
- 设计模型为支持业务需求而必须的数据、应用和技术进行建模。
接下来，FEAF采用了第三粒度层次对企业架构的开发和维护过程模型进行了最后一个层次的细化。经过这个层次的细化，FEAF表现如下：
FEAF第三层粒度示意图
在第三粒度层次的细化中，组成FEAF模型的各个组件作了如下的扩展：
- 在上个层次中的当前设计架构被细化为当前的数据架构、应用架构以及技术架构。
- 数据架构定义了用来支持业务各种数据，以及他们之间的关系。
- 应用架构定义了用来管理数据并支持业务功能的各个应用。
- 技术架构定义了用于为管理数据和支持业务功能的各个应用提供支持的各种技术。
- 与当前设计架构的细化类似，目标设计架构也被细化为数据架构、应用架构以及技术架构。
- 在上个层次中的架构设计模型被细化为数据模型、应用模型和技术模型，他们分别为数据、应用和技术架构的描述提供了更加详细的描述方式。
- 在这个层次中每个架构片段对应联邦政府中的一个主要业务领域。一个架构片段的选择和定义需要与框架以及加载到联邦企业架构资源库中的模型、架构信息相符合。一个架构片段也可以看作为一个事件驱动的流程，它贯穿联邦组织机构，并拥有足以使其被纳入到联邦企业架构中的投资回报率（ROI，return-on-investment）。
- 过渡过程的内容也被进一步细化和明确，包括且不限于如下几个过程：
- 资金IT投资规划和决策制定（Capital IT Investment Planning and Decision Making）：根据筹资预测、投资回报率和成本效益等判定条件来评估投资是否值得为其编制预算。
- 投资管理审查（Investment Management Review）：为投资审查决策过程提供架构信息。
- 片段协调（Segment Coordination）：协调片段架构与联邦企业架构的整合，同时配置管理和工程变更控制过程也必须到位。
- 市场调研（Market Research）：执行一个周期性的市场搜索和分析，用以寻找先进的且具有潜在收益的技术。
- 资产管理（Asset Management）：管理所有基于联邦企业架构的基础设施资产。
- 采购实践（Procurement Practices）：使采购活动与架构以及其他过渡过程相同步。
- 架构治理（Architecture Governance）：协调架构建设和维护过程中的种种活动，从而避免工作的混乱、误解和返工。
- 标准的内容也被进一步细化和明确，包括且不限于如下几种标准：
- 安全标准（Security Standards）：包括所有方面都必须遵循的各种安全准则。这不仅包括信息技术方面的各种安全方针，还包括在业务领域也需要遵循的各种安全准则。
- 数据标准（Data Standard）：用于描述数据、元数据以及他们之间关系的各项准则。
- 应用标准（Applications Standards）：应用于各种应用软件上的各项原则和标准。
- 技术标准（Technology Standards）：应用于各种操作系统、平台以及硬件系统等信息技术基础设施上的各项标准。
与上面的三个细化粒度不同，FEAF在最后一个粒度层次的细化中仅是针对架构模型的内容来进行的。在这个细化层次中，FEAF通过借鉴Zachman框架的内容将架构模型的内容进一步细分如下：
|
视角 |
数据架构 |
应用架构 |
技术架构 |
|
|
|
规划者 （目标和范围） |
业务对象列表 |
业务流程列表 |
业务地点列表 |
业务架构模型 |
|
|
拥有者 （企业模型） |
语义模型 |
业务流程模型 |
业务物流系统 |
||
|
设计师 （信息系统模型） |
逻辑数据模型 |
应用架构 |
系统空间部署架构 |
设计架构模型 |
|
|
建造者 （技术模型） |
物理数据模型 |
系统设计 |
技术架构 |
||
|
分包商 （详细规范说明） |
数据定义、字典 |
执行方案 |
网络架构 |
||
|
|
数据架构模型 |
应用架构模型 |
技术架构模型 |
||
与Zachman框架不太一样，FEAF只采用了Zachman框架中的前三列的内容，将在第三个层次中细化出来的业务架构模型、数据架构模型、应用架构模型和技术架构模型分别按照不同参与者的视角进行了更加详细定义。在上面的架构模型定义表格中：
- 业务架构模型被进一步细化，包括了规划者视角下的业务对象列表、业务流程列表、业务地点列表，以及拥有者视角下的语义模型、业务流程模型和业务物流系统。
- 数据架构模型的内容被细化为逻辑数据模型、物理数据模型，以及数据定义和字典。
- 应用架构模型的内容被细化为应用架构、系统设计和执行方案。
- 技术架构模型的内容被细化为系统空间部署架构、技术架构和网络架构。
由此可见，作为用于描述组织核心任务的业务架构模型，其主要关注者就是承担规划者和业务拥有者角色各个干系人，他们所关注的范围包含了数据、应用和技术等所有方面，只不过相对于下面用于支持业务的参与者来说，他们对于这三方面的描述角度是站在业务相关的立场上的，因而业务架构模型与从属于设计架构模型的数据、应用和技术架构模型并不是一个平行的层次关系，而是不同角色的干系人针对相同事物在不同角度的所看到的不同视图。相对于业务架构模型与设计架构模型这两者根据视角的不同而采取的水平划分方法，对于设计架构模型的细化采取的就是垂直划分了，即从数据、应用和技术这三个方面对设计架构模型进行划分，并且在每个划分出来的模型区域中又根据设计师、建造者以及分包商所具备的视角分别制定更加详细的模型制品。
除了对架构模型内容的细化，FEAF还通过借鉴企业架构规划技术（EAP，Enterprise Architecture Planning）为业务架构模型的建立提供了方法。企业架构规划是指为利用信息支持业务而定义架构的过程，以及用来实现这些架构的规划。（原文：EAP is the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures）。EAP可以看作是关于数据、应用和技术的一张高层次（业务和管理视角）蓝图，并借此保证他们之间的协调发展（alignment）。具体到FEAF，EAP为上面的FEAF架构模型中的业务架构模型（第一和第二行内容）提供了一套实现方法。在CIO委员会的FEAF文档中，EAP的作用表现如下：
EAP在架构模型中的作用
与Zachman框架将关注点放在架构内容描述上不一样，EAP所关心的是对信息技术与业务的相互校准过程进行规划和管理，因而EAP所采用的是不同于具体设计和实现的高层次的视角。
3. TOGAF总论及架构开发方法（ADM）概述
https://www.cnblogs.com/zscyun/archive/2013/06/05/3118483.html
TOGAF（The Open Group Architecture Framework）可以说是当前最为流行的企业架构框架理论了，截止到作者写本书之时，福布斯排行榜上排名前50的企业中已经有很大一部分在使用这一企业架构框架了，并且中国企业对它的认可度也超过了50%。TOGAF可以说是企业架构理论从政府进入到社会各研究机构的一个典型案例，它起源于美国国防部的信息管理技术架构框架（TAFIM，Technical Architecture Framework for Information Management），并在获得美国国防部的允许和鼓励之后，借助于美国政府大笔资金的投入，并经过多年的努力最终于1995年发布了TOGAF的第一版。发展至今TOGAF已经发布到了第九个版本，即TOGAF 9（目前最新的版本是2011年发布的TOGAF 9.1），而这也正是这一章节所要描述的对象。
按照TOGAF规范中的定义，TOGAF是众多企业架构框架理论中的一种，它为一个企业或组织对于企业架构的接受、创建、使用和维护提供了一系列辅助方法和工具。同时TOGAF还是一个基于迭代过程模型的企业架构框架理论，而作为支持该过程模型的重要基石包括了各种最佳实践，以及一系列可重用的现有企业资产。总的来说，TOGAF的内容涵盖了企业架构生命周期中的方方面面，尤其是通过在2009年发布的第九版中引入了内容框架，TOGAF一改往昔只重视架构开发过程和方法的风格，在有关架构内容描述和指导方面填补了以往的空白。在TOGAF 9中，The Open Group将TOGAF的各部分内容以及他们之间的关系通过如下的示意图进行了表述：
TOGAF内容结构
借助于TOGAF的内容结构示意图我们可以看出，TOGAF所包含的各种企业架构相关方法与工具在企业的业务愿景、驱动力和业务能力之间建立起了一座沟通的桥梁，即在TOGAF中各部分内容的帮助下，这两个原本沟通不畅的部分得以被联系在一起，从而使得作为企业发展蓝图的业务愿景与各种驱动力可以一起通过一种有条理的方式促进企业业务能力的实现和发展，而且经过长期的运营，企业的业务能力又为企业的业务愿景反馈了新的需求和发展推动力。从图中我们可以看出，TOGAF的内容被分为三个主要部分：
- TOGAF能力框架（TOGAF Capability Framework）：为了在一个企业中有效地操作企业架构并使其发挥最大的效能，一系列适当的组织结构、流程、技能、角色和责任需要被定义并结合起来，而TOGAF的能力框架正为如何组织好这些元素提供了指南。
- TOGAF架构开发方法和内容框架（TOGAF ADM（Architecture Development Method）& Content Framework）：此部分是TOGAF的核心部分，它包含了两个方面的内容。其中架构开发方法是TOGAF针对企业架构建设方法的论述，它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤，并对每个步骤的输入、输出以及所采用方法都进行了详尽的阐述；作为新晋的内容框架部分，它针对企业架构中所包含的各种工作产品以及他们之间的关系作出了详细的描述。
- TOGAF企业连续体和工具（TOGAF Enterprise Continuum and Tools）：企业连续体是企业架构资源库的一张视图，它为企业中的各种架构和解决方案制品提供了一种分类和组织的方法。企业架构过程是一个动态的过程，因而这一针对工作制品进行组织分类的方式也不仅仅是一个静态方法，还是一种能够随着企业架构演进而变化其分类方式的动态方法。在此方法的视角中，随着企业架构的演进发展，其内容也从通用走向特化，其详细程度也由简略转为详尽，而随着实践的沉淀，原来特化的架构或解决方案制品也可能成为在更广泛范围内通用制品。除此之外，该部分内容还提供了几个用于帮助企业架构建设的参考模型以及其他的一些辅助工具。
上述三个部分的内容相对比较独立，其中能力框架方面的内容着重于帮助企业更好地使用企业架构，架构开发方法和内容框架着重于帮助企业提高其企业架构建设和维护过程的标准化水平和执行效率，而企业连续体以及各种方法工具则更关注于为企业在企业架构的开发、使用和维护过程中提供参考和最佳实践。虽然这三个部分相对独立，但是一个优良的企业架构的创建、使用和维护是他们三者紧密配合、相互作用的结果。不过作为一个开放且灵活的企业架构框架标准，TOGAF并不要求所有引入它的企业都必须一个不漏的照搬这三个部分的内容，而是可以根据各自的需要选择相应的部分进行采用，即便是已经建立了企业架构的组织（哪怕他采用别的框架理论来创建其企业架构）也可以将TOGAF中的内容与当前企业架构进行融合。本章接下来将对这几部分的内容分别进行详细阐述。
1. 架构开发方法
架构开发方法（ADM，Architecture Development Method）为开发企业架构所需要执行各个步骤以及他们之间的关系进行详细的定义，同时它也是TOGAF规范中最为核心的内容。一个组织中企业架构的发展过程可以看成是其企业连续体从基础架构开始，历经通用基础架构和行业架构阶段而最终达到组织特定架构的演进过程，而在此过程中用于对组织开发行为进行指导的正是架构开发方法。由此可见，架构开发方法是企业连续体得以顺利演进的保障，而作为企业连续体在现实中的实现形式或信息载体，企业架构资源库也与架构开发方法有着千丝万缕的联系。企业架构资源库为架构开发方法的执行过程提供了各种可重用的信息资源和参考资料，而企业架构开发方法中各步骤所产生的交付物和制品也会不停地填充和刷新企业架构资源库中的内容，因此在刚开始执行企业架构开发方法时，各个企业或组织常常会因为企业架构资源库中内容的缺乏和简略而举步维艰，但随着一个又一个架构开发循环的持续进行，企业架构资源库中的内容将日趋丰富和成熟，从而企业架构的开发也会越发明快。
架构开发方法各阶段
架构开发方法建立在一个循环迭代的模型基础之上，并且TOGAF还通过定义一系列按指定顺序排列的阶段和步骤来对这一迭代过程进行了更加详尽和标准的描述。不过需要注意的是，这一迭代过程中所包含的各个阶段以及每个阶段所包含的各个实施步骤并不是一个绝对不变的存在，鉴于 TOGAF本身的开放性和灵活性，针对架构开发方法中各步骤的执行也具备着很高的灵活性，而这一灵活性通常表现为：
- 如前所述，由于TOGAF并不排斥组织中对其他企业架构框架理论的引入和使用，因而在多个企业架构框架同时并存的情况下，企业架构开发方法各阶段的输入与输出可以不拘泥于企业架构开发方法的定义，而可采用适合组织自身情况的其他框架中所定义的相关内容。
- 企业架构开发方法中各阶段之间的先后顺序也并不是绝对的，各组织可以按照自己的实际情况进行适当的修改。
- 由于各组织的规模和特性千差万别，因而他们对企业架构开发方法的适应程度也各不相同。对于一个中小型企业来讲，如果严格按照上述架构开发方法的阶段定义来执行，其繁琐程度可能会将人们的热情迅速冷却，因而针对企业架构开发方法进行适当的裁剪并使其符合组织自身情况对于各个组织来讲是非常必要的。
- 架构开发是一个循环迭代的过程，但是并不意味着每次循环都要走完图中所有的步骤，而且如果必要的话，在任何一个步骤的执行过程中都可以根据遇到的情况而开展一个新的循环过程。
企业架构开发方法为组织中企业架构的开发制定了一个循环迭代的流程，并且随着每个架构开发循环过程的完成，组织中企业架构的范围以及交付物的深度和广度都得以演进，但对于企业架构范围的决定却应独立于这一企业架构开发方法的执行过程。在每一次架构开发方法迭代过程开始之前，组织都需要针对如下几点进行考虑：
- 组织将要在什么范围内进行架构定义和建设？
- 需要采用何种详细度进行架构描述？
- 需要建设的企业架构的目标时间区间是什么？
- 所能够使用的架构资产（包括上次迭代过程中产生的各种架构资产以及存在于组织外的行业通用资产）都有哪些？
以上四个要点制约着企业架构以及相关架构活动的范围。理论上来将，为整个组织的方方面面进行全面的建模是企业架构的终极目标，而在现实生活中如此理想的目标往往会成为不可能的任务，而更加理性的做法应该是立足于当前的状况对每次架构工作的范围进行约定，并通过一次次的工作迭代逐步丰富企业架构内容的深度和广度，从而逐渐接近于理想状态。这种方式对于结构复杂的大型组织来说尤为重要，这种组织往往是由若干业务单元通过联邦的方式组合而成，而在这种情况下一个有效的企业架构过程应该是对架构的范围和活动进行明晰的划分，并在最后进行有效的整合的过程（美国联邦政府的FEA就是一个很好的例子，虽然具有着独特的架构建设和维护方法，但是在如何应对繁杂组织的复杂度方面，其与TOGAF有着相通的见解）。总的来说，TOGAF的企业架构开发方法的基础是对企业架构的范围进行适当限定和定义，而这些限定和定义的方面包括：
- 企业范围或着眼点：用于表述企业的整体范围，以及架构活动所涵盖的范围。
- 架构领域：一个完备的架构描述需要涵盖四个架构领域中的内容，即业务、数据、应用和技术，而这也正是限定架构内容范围的维度之一。
- 详细度：用于表述架构内容的详细程度，即何种程度的架构描述才是足够的。
- 时间段：用于表述架构愿景所描述的是在未来哪个时间段的目标，以及此目标是否可以在指定的详细度上被描述清楚，如果不能则需要对中间过渡状态进行制定，并且对每个过渡状态的描述所采用的详细度应符合指定的需要。
一般来讲，企业架构范围的定义和限定首先需要明确企业范围或着眼点、详细度和时间段这三个方面。在这三个方面被确定之后，组织需要根据所面对的问题开展针对各种架构领域的选择和组合，从而实现针对企业架构范围的最终确定。需要注意的是，之所以架构范围需要被限定，是因为现实中的资源不是无限的，这些限制一般包括如下方面：
- 架构开发团队的权力有一定限制。
- 企业中不同角度的干系人的关注点千差万别。
- 人力、资金等资源的限制。
综上所述，企业架构开发方法是一种非常灵活的架构开发指导方法，任何组织不论其身处何种行业或是具备什么样的规模都可以将其作为指导自身企业架构建设的方法。需要注意的是，企业架构开发虽然能够指导企业架构的建设，但是企业架构的范围则需要组织自身根据实际情况来进行定义和限定，也只有这样才能让企业架构开发方法的进行得以处在一个现实可行的环境当中。那企业架构方法具体如何进行呢？为了解答这个问题，本节随后的内容将会对企业架构开发方法的各阶段和步骤进行详细描述。
一个爱好者书写收集整理的更多文章 https://zhuanlan.zhihu.com/p/93787316
