• 驾驭复杂系统的整体设计

• 整个体系的架构设计和价值

• 事物背后的思考

Zachman proposes a logical structure for classifying and organizing the descriptive representations of an enterprise, in different dimensions, and each dimension can be perceived in different perspectives.

[A Method to Define an Enterprise Architecture using the Zachman Framework (Carla Marques Pereira,Pedro Sousa)]

Zachman框架（Zachman Framework™）是一个纲目（schema）——两种有几千年历史的分类法的交集。第一种是建立在原始疑问词上的沟通基础要素：什么、如何、何时、何人、何地以及为何。这些问题答案的集成，能够对复杂的想法形成全面、综合的描述。第二种来自具体化，即古希腊哲学中假定的抽象观念到实例的转换，在Zachman框架中记为：辨别、定义、表达、规定、配置和实例化。

Zachman说，框架分类的最初启发是来自对建筑、飞机和其它复杂的工业产品的观察经验。对于上述定义，他还强调，Zachman框架是一种描述企业的本体，是元模型，而不是关于创建对象的最终实现（实例）的方法学。它是关于结构的，而不是过程。它是企业架构（EA）的基础。

Zachman框架起源于John Zachman先生在1987年完成的那篇著名的信息系统架构论文（《A framework for information systems architecture》 ），并一直发展至今。在这篇论文中Zachman先生以修建房屋为例从两个维度将与信息系统架构设计相关的各种元素归纳到一个矩阵表格中.

Zachman框架模型分两个维度：横向维度采用6W（what、how、where、who、when、why）进行组织，纵向维度反映了IT架构层次，从上到下（Top-Down），分别为范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。

横向结合6W，Zachman框架分别由数据、功能、网络、人员、时间、动机分别对应回答What、How、Where、Who、When与Why这六个问题。

基本结构

Zachman框架是一个综合性分类系统。它相当于通过6×6的分类矩阵，把企业架构涉及的基本要素（而不是企业本身）划分成36种单元（Cells），并清楚地定义了每个单元中的内容（组件、模型等）性质、语义、使用方法等。从相关介绍可以知道，在找到现在这种二维矩阵的划分方式之后，对每个单元的内容也在逐步认识、实践和总结。考察现在的标准叙述，仍可以感觉到，单元的内容和单元间的关系，远不像架构的整体方案所暗示的那样明确、直观。标准中对多单元上用法说明，有些也并非显而易见。这一方面体现在这个表面简单的结构中，还蕴藏着不少“道理”，同时可能也说明，这里还有不少可以探讨的空间和不同的可能性。

详细的分类矩阵，可以由其网站上看到。5W1H的描述展开，看来“非常基本”，似乎只有用或不用的选择，但并非没有讨论余地，特别是，如果站在企业规划、建模、模型工作机制这样一些角度上，会更有多的讨论空间——不仅是关于5W1H这一方案的选择，而是在更深的层面上（参见后续的分析文章）。相对于行的展开，按照“具体化”层次展开的列，则更需要仔细考察。下表将Zachman提示的具体化标志与实际矩阵上的标签对应起来，以便于观察。同时，对照列出了“Who”这一列单元格里的基本提示。单元格里放的东西，前五层都表现为模型（或文档），而最底层是实例。

image

[Ref: https://blog.csdn.net/kunlong0909/article/details/7710571]

Zachman 企业模型架构

The following diagram is an adaptation of the Zachman Enterprise Framework. The Zachman framework provides provides a useful model for documenting the systems, processes and people in large organisations.

image

[http://www.technical-communicators.com/framework/]

Enterprise Architecture is a framework or “blueprint” for how the organization achieves the current and future business objectives. It examines the key business, information, application, and technology strategies and their impact on business functions. Each of these strategies is a separate architectural discipline and Enterprise Architecture is the glue that integrates each of these disciplines into a cohesive framework

image image

• 业务视图

• 应用视图

• 数据视图

• 技术视图

• 产品视图

The Business Architecture is the result of defining the business strategies, processes, and functional requirements. It’s the base for identifying the requirements for IS, which support the business activities.

**The Application Architecture **provides a framework focused on developing and/or implementing applications to fulfill the business requirements and to achieve the quality necessary to meet the needs of the business.

The Information Architecture describes the data’s physical and logical aspects, as well as the management of the data resources. It’s the result of modeling the information that is needed to support the business processes and functions of the enterprise.

**The Technical Architecture **provides the foundation that supports the applications, data and business processes identified in the other three architectural layers. The Technical Architecture identifies and plans the computing services that form the technical infrastructure for the enterprise.

The Product Architecture is a subset of Technical Architecture and it identifies standards and configurations for the enabling technologies and products within the Technical Architecture.

Although all of these architectures compose the Enterprise Architecture, in this paper we will exclude the Technical Architecture and consequently the Product Architecture.

[A Method to Define an Enterprise Architecture using the Zachman Framework (Carla Marques Pereira,Pedro Sousa)]

image

Zachman框架(Zachman Framework for Enterprise Architecture and Information Systems Architecture)。Zachman"框架"实际上是一种组织构架工具（用来设计文档、需求说明和模型的工具）的一种分类学。包括工具的目标（例如，商业拥有者、创建者）是谁，哪些特殊的问题（例如，数据、功能）需要阐明。

Zachman是这样描述他的杰作的：

当这个框架应用于企业时，它仅仅是用来分类和组织企业（在这些企业里，企业的管理和企业系统的开发同样重要）的描述形式的逻辑结构。 许多Zachman框架的支持者认为它是跨学科的，它的影响不仅仅局限于IT行业。

例如，一本关于Zachman的书中这样说：

在适当的时候，你会发现框架不仅仅是存在于IT项目中，它存在于你所做的每一件事情中。当你完全理解了这个框架之后，做任何事情都会变得高效。我指的是任何事情，这个断言并不武断。

Zachman框架是一种逻辑结构，目的是为IT企业提供一种可以理解的信息表述，它对企业信息按照特定的要求进行分类，从不同角度进行描述。

根据抽象规则，它定义企业信息的一个方面，一个框架采用了一种六行，每行中包含36个子单元的格式。

image image

六行(即纵向维度)反映了IT架构层次，从上到下（Top-Down）。包括了范围模型、企业模型、系统模型、技术模型、详细模型、功能模型。

如同建筑构架为不同的角色提供不同的材料。每个角色都需要完整的信息，不过对于不同的角色而言，所需的完整信息也是不同的。拥有者感兴趣的完整描述是建筑物的功能和美感。构造者感兴趣的完整描述是建筑材料和构建过程。拥有者并不关心墙里面的螺栓钉在哪儿，构造者也不关心卧室的窗户如何排列，以便在早晨能够迎来第一缕阳光。

纵向按企业中不同角色的关注点进行划分：

规划人员关注范围模型，能够看到企业的发展方向、业务宗旨和系统边界范围。

系统所有者关注企业模型，能够用企业术语定义企业的本质，看到的是企业的结构、处理、组织等。

体系结构师设计人员关注系统模型，能够用更严格的术语定义企业业务，看到的是每项业务处理所要完成的功能。

构建人员关注技术模型，使用技术模型来解决企业业务的信息处理需求。

集成人员关注详细模型，需要去解决关于特定语言、数据库存储表格及网络状况等具体细节。

用户关注功能模型，也是系统的最终用户，考虑系统能否支持自身的工作。

从两个维度将所有IT构件进行分割，可以划分成小的相对独立的模块，便于独立管理。

六列（即横向维度）采用6W（what、how、where、who、when、why）进行组织。即分别为做什么（数据）、如何做，什么地点，谁来做、什么时间、为什么做。

以列描述中的"数据（What）"为例：

从商业拥有者的角度，"数据"意味着商业实体。它可能包括实体本身的信息，如客户和产品，也可能包括实体间关系的信息，如人口群体和库存。如果你打算和一个商业拥有者讨论数据，你应该用到这些语言。

从数据库的实现者的角度来看，"数据"就不是商业实体了，而是保存在数据表中的行和列，还有通过连接（join）和映射（projection）生成的表。如果你在和一个数据库设计者讨论"数据"，不要讨论客户的群体，而应该讨论关系数据表。

并不是从一个角色的角度看就比从另外一个角色的角度看要好，也不是越详细越好，也不是某一个的优先级比其他的更高。作为一个整体，无论是从谁的角度都很重要。

正如Zachman说过的：

我们在信息系统构架方面与另外的构架沟通时有很多困难，因为存在很多构架表现形式，而不是仅仅只有一个构架。其中一个出错了，其他的也跟着出错。构架是不同的。它们是附加的和补充的。选择为开发每个构架表现形式而支出资源是有原因的。如果不开发任何构架表现形式是有风险的。

正如我前面提到的，Zachman框架由六个功能焦点组成，每个功能焦点都会从一个角色的角度考虑。

image

zachman framwork 3.0

尽管商业拥有者对数据的看法和数据库管理员不同，但它们应该是有关系的。一个人可以遵循商业需求，并且显示出设计的数据就是被需求驱动的。如果有商业需求并没有追踪到数据库设计，那么就得想想商业需求是否与企业构架相符。另一方面，如果数据库设计的元素没有需求与之对应，我们就应该问问自己，在数据库层面是否存在不必要的设计。

Zachman表格可以从以下五个方面帮助我们开发企业构架：

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

通过把每个焦点精简到每个特殊观众涉及的焦点来提升构架材料的质量。 　　确保每个商业需求能够追踪到技术实现。

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

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

但是Zachman本身并不是一个完整的解决方案。有太多的问题它都没有描述。例如，Zachman没有给出一步一步构造一个构架的过程。在决定我们将要构建的构架是否是最好的时候，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架构的管理维护机制。

[https://www.cnblogs.com/jadesun/archive/2013/05/26/3100440.html]

---

Kotlin 开发者社区

国内第一Kotlin 开发者社区公众号，主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。

Kotlin 开发者社区