【系统架构师修炼之道】（4）：绪论——Zachman 框架

Zachman框架的创始人John Zachman(约翰·扎科曼)早在1987年就提出了这种思想,它全称叫做企业架构和企业信息系统结构架构(Zachman Framework for EnterprisArchitecture and e Information Systems Architecture)。Zachman框架被很多企业管理者认为是一种发展IT企业和进行复杂管理的规则集合。

Zachman框架，其实并不算是现代意义上的框架。词典上的解释是 支持或封装其他事情的一种结构，尤其是作为其他的一些已经创建的东西的基础给予其骨架支持；一种外部的工作平台；脚手架；一种基本结构；组成观察显示的一系列的假象，内容，价值和实践，Zachman框架更像是一种组织架构工具，清晰的划分出工具的目标和功能之间的关系，正如Zachman这样描述这个框架应用于企业时，它仅仅是用来分类和组织企业的描述形式的逻辑结构，这里不得不说，总结的非常准确。同时也表明了Zachman是跨学科的，正如Zachman一本书上说在适当的时候，你会发现框架不仅仅是存在于IT项目中，它存在于你所做的每一件事情。当你完全理解了这个框架之后，做任何事情都会变得高效。我指的的任何事情，这个断言不武断，这个框架已经存在了几千年，而且我敢肯定它在以后的几千年将继续存在，稍微有些改变的是我们对它的理解和怎样使用它。 比如：建筑行业，也是通过二维表来表示的，其中角色有拥有者(项目付款者),构造者(架构师)，城市规划委员会(监工)，其中他们所关心的描述点也不相同。

框架解释

列

• 范围/规划人员（Planner）

包括整个信息系统描述所处的环境上下文、产生于内部与来源于外部的各种约束，以及其他视角下对信息系统的描述所需要考虑的相关构成部分的列表。关注范围模型，能够看到企业的发展方向、业务宗旨和系统边界范围。

• 业务模型/拥有者（Owner）

有关最终产品的概念视图，反映了最终产品的使用特性，即用户准备如何对最终产品加以使用。具有此视角的干系人包括最终产品的客户或用户。关注企业模型，能够用企业术语定义企业的本质，看到的是企业的结构、处理、组织等。

• 系统模型/设计师（Designer）

有关最终产品的逻辑视图，反映了最终产品的本质规律以及逻辑约束。具有此视角的干系人包括工程师、架构师以及能够将期望所得与现有的物理、技术上的实现联系起来的各种中间人。关注系统模型，能够用更严格的术语定义企业业务，看到的是每项业务处理所要完成的功能。

• 技术模型/建造者（Builder）

反映了在产品构建过程中现有技术的物理约束。具有此视角的干系人包括制造工程师、总承包商以及具有生产最终产品所需的技术能力的组织或人员。关注技术模型，使用技术模型来解决企业业务的信息处理需求。

• 详细表述/分包者（Sub-Contractor）

有关为了达到生产目的而对复杂对象进行分解的详细描述，这些内容在从设计媒介到最终产品媒介的转换中起着非常重要的作用。例如，用于将技术模型中所阐述的技术约束与供应商为所提供的产品联系在一起的产品规格说明。关注详细模型，需要去解决关于特定语言、数据库存储表格及网络状况等具体细节。

• 产品/运行中的企业（Functioning Enterprise）

在1987年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构Zachman框架对于架构的表述更加完备，这一行最终还是被加了进去。这一行的内容代表了最终产品，是架构在客观现实中的实例体现。例如，对信息系统架构来说，此行的内容就是最终产出的信息系统，同理，对于企业架构来说，这一行所代表的就是运行中的企业本身。简而言之，前面五行的内容是对于客观对象的描述，而这最后一行的内容就是客观对象本身了。

行

• 数据（What，即什么内容）

用于表示客观对象的材料组成，即材料清单。对于企业来说，此部分内容就是组成事物模型（Thing Model，之所以将其称为组成事物模型而不是数据模型是因为由于不同的行代表了不同的视角，而仅在设计师所处的第三行才会关注真正信息化意义上的“数据模型”，因而在此才使用“组成事物”来对所有视角在此列中的描述对象进行指代）。

• 功能（How，即如何工作）

用于表示功能和转换行为。对于企业来说，这部分内容就是流程或功能模型等。

• 网络（Where，即何处）

用于表示各组成部件的坐落位置以及相互之间的联通关系。对于企业来说，这部分内容就是物流或网络模型等。

• 人（Who，即何人负责）

用于描述了什么人应该做什么事，例如用户手册和操作说明等。对于企业来说，这部分内容就是人力模型或工作流模型等。

• 时间（When，即什么时间）

用于描述事物发生的时间以及不同事物之间的相对时间关系，例如生命周期和时序图等。对于企业来说，这部分内容就是时间或动态模型等。

• 原因（Why，即为什么做）

用于表示最终结果和意义。对于企业来说，这部分内容就是动机模型等。

使用规则

1. 不增加新的行或列
   在Zachman框架看来，框架中的六行视角以及六列描述方面构成了系统描述的最基本元语，即为了构建系统而对其架构所做的描述只要能够从六种视角出发，并能为每个视角在六个方面（什么内容（What）、如何工作（How）、何处（Where）、何人负责（Who）、何时（When）和为什么动机（Why））做出解答，那么此架构描述就是完备的，也由此足以成为系统的复杂度管理和变更管理的基础。

2. 不修改行或列的名称或含义
   在Zachman框架看来，由于本身逻辑框架已经完备，因而修改行或列的标头名称或含义会对整个逻辑框架产生不利的影响。这里需要注意的是，Zachman框架列表中，其行标头和列表头都含有上下两个名称，例如，第一行的标头就具有“范围”和“规划者”两个名称，而第一列也具有“数据”和“什么（What）”这两个称呼。这两种名称系列（用加粗大号字体标明的名称和采用小号斜体字体的名称）代表着Zachman框架的两种使用情境：

   • 企业特定情景：此种情景下，Zachman框架的目标放诸“企业”这一特定的概念之上，而其中各个标头将采用由加粗大号字体标明的名称。

   • 通用情景：此种情景下，Zachman框架具有更高的通用性，例如房屋建筑、飞机等。其中各个标头将采用由小号斜体字体标明的名称。
     需要注意的是，不论是上述哪种使用情境，按照Zachman框架的使用规则，这些标头名称都不能因为实际情况的不同而进行变更。

3. 每一列中的内容都遵从某一通用模型
   由于每一列都代表了所描述架构的某一个方面，因而处于同一列的各个描述在本质上应符合某种经过高度抽象的元模型

   • 数据列（What）应遵从：事物——关系——事物。

   • 功能列（How）应遵从：流程——输入/输出——流程。

   • 网络”列（Where）应遵从：节点——连接——节点。

   • 人列（Who）应遵从：人员——工作——人员。

   • 时间列（When）应遵从：事件——周期——时间。其中，事件指代某一时间点，而周期代表了一段时间区间。

   • 原因列（Why）应遵从：结果——方式——结果。其中，结果代表了目标状态，而方式则用于表示为了达成目标状态而采用的行为。

4. 表格单元中架构描述的详细度与其所在的行无关
   人们很容易有一种错觉，那就是在同一列中不同行里面架构描述的详细度有一个自上而下越来越详细的趋势，因为好像越是位于上面的行，其所代表的视角就越不关注于最终产品的实现细节，因而其中的架构描述也无需太高的详细度，反之越靠下方的行就需要更高的详细度。从实现的角度来说，这一担心不无道理，不过就架构描述的目标来说，这种详细度自上而下渐渐增高的趋势是有待商榷的。由于框架中的每一行代表了不同的视角，但这并不代表所有的视角都关注于最终产品在实现方面的问题，而正因为每个视角的关注点不同，所以仅从实现细节这个角度来说详细度的差异是有问题的。例如第一行的规划者关注于最终产品的所处的上下文环境，因而对在这一角度所进行的描述来说，其详细度应该根据具备这一视角的干系人的要求而定，而其下各行由于关注点不同，所以他们在描述的详细程度方面不具备可比性。由此我们可以发现，不同行的架构描述是相互独立但又互相联系的，他们之间是转换关系而不是演进关系。

5. 不存在可以在不同的表格单元之间共享的元概念元素
   不要在对角线方向上对不同的单元格进行直接联系，这样只会增加沟通障碍。

6. Zachman框架逻辑具有通用性和迭代性
   此框架虽然在企业架构领域名声斐然，不过这并不意味着他只能被应用于这一领域，实际上对于Zachman框架来说，他并不针对于某一具体事物，无论是有形的事物，诸如房屋、飞机等，亦或是抽象的概念实体，例如：企业等，都可以是他描述的目标，因而在这一点上其具备普适性，而也正因为这一普适性，其每个单元格中的内容亦可以作为描述目标而被此框架无限迭代描述下去。

由于表格中的每行或每列都是代表着某一视角或基本元语，因而由他们组成的各个表格单元中的架构描述也应该是独一无二的，所以不同表格单元之间的架构描述不应该出现共享元概念元素的情况。

Zachman 建议

• 每一个构架材料应该存在于一个方格中，而且只能存在于一个方格中。在一个构架材料放在哪个方格里不应该含糊不清。如果某个构架材料的确不知道应该放在哪个方格中，问题很有可能处在构架材料本身。

• 仅仅只有当所有的表格都填满了的时候，一个构架才能被称为是完整的构架。当所有的方格都填满了时候，整个表格才有足够的材料定义系统。只有当每个方格都填满了材料的时候，才有足够的信息描述系统：从每个角色（我们现在可以称之为"利益相关者"，Stakeholder）的角度观察系统的每个可能的视角（描述焦点）。所以一个组织可以使用Zachman表格确保企业构架中的所有重要利益相关者之间的讨论都是合适的。

• 表格的每列的方格都是彼此相关的。例如，Zachman表格的数据列（第一列）。从商业拥有者的角度，数据就是关于商业的信息。从数据库管理人员的角度，数据就是数据库中的行和列。

Zachman 好处

• 确保每个利益相关着能够从描述的焦点考虑。

• 通过把每个焦点精简到每个特殊观众涉及的焦点来提升构架材料的质量。

• 确保每个商业需求能够追踪到技术实现。

• 确保商业方面不会规划出多余没用的功能。

• 确保技术组包含在商业组的规划中。

Zachman IT规划

1. 确定组织的愿景和原则

   • 确定IT架构业务、组织与IT系统范围，识别业务驱动力。

   • 确定IT架构愿景和目标。

   • 制定IT架构定义的原则。

   • 识别IT架构相关需求。

   • 业界IT架构最佳实践研究与学习。

2. 现状描述分析

   • 搜集现有IT系统现状资料。

   • 业务现状分析，识别现有IT系统对业务支撑上存在的问题。

   • 引入最佳实践，并结合企业实际，定义目标IT架构，包括：数据、应用、基础设施架构。

   • 目标架构与现状的差距与改进点分析。

   • 把具体IT需求纳入目标架构框架。

   • 对IT架构的改进点，以及具体需求进行优先级排序。

3. 制定IT架构的实施计划

   • 确定向目标IT架构迁移的具体实施计划。

   • 确定目标IT架构实施的推行组织,优化。

4. 持续改进IT架构规划过程中，各个环节不断优化

   • 制定目标IT架构的持续改进计划。

   • 制定IT架构的管理维护机制。

总结

Zachman框架从本质上来说是对企业架构描述的一种分类法，其对于如何解决企业信息化发展所面临的问题（系统复杂度管理、业务与信息技术的不协调发展）能够提供如下的帮助

• 给出了企业架构内容的描述和分类法，从而可以复杂的系统进行分解描述。

• 确保每个干系人的每一个关注点被照顾到。

• 改进每个架构制品使其更加契合目标受众的关注点。

• 确保业务需求可以被映射到技术实现之上，同时每个技术实现也可以被回溯到业务需求之上。

• 加强业务人员与信息技术人员的沟通和交流，减免以前因缺乏沟通而导致的无谓的内耗。

Zachman框架本身不是一个完整的解决方案。它只告诉了每个角色的关注点，并没有给出架构的过程，它仅仅是一个思想先驱，把现实中的复杂的问题，逻辑简单化。

---

感谢您的耐心阅读，如果您发现文章中有一些没表述清楚的，或者是不对的地方，请给我留言，你的鼓励是作者写作最大的动力，
如果您认为本文质量不错，读后觉得收获很大，不妨小额赞助我一下，让我更有动力继续写出高质量的文章。

• 支付宝
  

• 微信
  

作 者 : @mousycoder

原文出处 : http://mousycoder.com/2015/10/14/the-pragmatic-sa-4/

创作时间：2015-9-1

更新时间：2015-10-16