第一个最有影响力的框架方法论就是Zachman框架，它是John Zachman首次在1987年提出的。
　　在理解Zachman框架之前，我们需要了解的是，它并不是一个框架，至少从框架的定义上严格地来看，它不是。从《美国传统词典》上，我们可以找到框架的定义如下：
　　支持或封装其他事情的一种结构，尤其是作为其他的一些已经创建的东西的基础给予其骨架支持；一种外部的工作平台；脚手架；一种基本结构；组成观察显示的一系列的假想、内容、价值和实践。
　　而在分类学中，它是这样定义的：
　　在显示自然关系的有序系统中的有机分类；科学、法律或者理论的分类；系统化；划分成有序的组或类别。
　　Zachman"框架"实际上是一种组织构架工具（用来设计文档、需求说明和模型的工具）的一种分类学。包括工具的目标（例如，商业拥有者、创建者）是谁，哪些特殊的问题（例如，数据、功能）需要阐明。
　　而Zachman是这样描述他的杰作的：
　　当这个框架应用于企业时，它仅仅是用来分类和组织企业（在这些企业里，企业的管理和企业系统的开发同样重要）的描述形式的逻辑结构。
　　许多Zachman框架的支持者认为它是跨学科的，它的影响不仅仅局限于IT行业。例如，一本关于Zachman的书中这样说：
　　在适当的时候，你会发现框架不仅仅是存在于IT项目中，它存在于你所做的每一件事情中。当你完全理解了这个框架之后，做任何事情都会变得高效。我指的是任何事情，这个断言并不武断。
　　在和Zachman讨论问题的时候，他本人也曾说：
　　这个框架已经存在了几千年，而且我敢肯定它在以后的几千年将继续存在。稍微有些改变的是我们对它的理解和怎样使用它。
　　Zachman在解释他的IT分类学时，最初试用了建筑行业作为类比。在建筑行业里，构架材料通过使用二维表格表示出来。表格其中的一维是变量"游戏中的角色"。对于一个建筑物来说，这些选手就是拥有者（谁为这个项目付款）、构造者（负责构建的人）、城市规划委员会（负责确保建筑遵循当地建筑标准的人）。
　　建筑构架为不同的角色提供不同的材料。每个角色都需要完整的信息，不过对于不同的角色而言，所需的完整信息也是不同的。拥有者感兴趣的完整描述是建筑物的功能和美感。构造者感兴趣的完整描述是建筑材料和构建过程。拥有者并不关心墙里面的螺栓钉在哪儿，构造者也不关心卧室的窗户如何排列，以便在早晨能够迎来第一缕阳光。
　　正如Zachman在他的一篇文章中提到的：
　　每个构架表现形式和其他的构架不同，其本质不仅仅是细节的层面。
　　构架材料组织的第二维是材料的描述中心--和项目相关的什么（what）、怎样（how）、谁（who）、何时（when）、为什么（why）。这一维和第一维之间是相互独立的。构造者和拥有着都需要知道"什么"，但是"什么"是什么还得取决于问这个话的人是谁。
　　在Zachman的第一篇论文和随后的详细解说中，Zachman建议有六个描述的焦点（数据、功能、网络、人员、动机）和六个角色的角度（规划者、拥有者、设计者、构造者、转包商、运营企业）。如图1-3所示
　　以列描述中的"数据"为例。从商业拥有者的角度，"数据"意味着商业实体。它可能包括实体本身的信息，如客户和产品，也可能包括实体间关系的信息，如人口群体和库存。如果你打算和一个商业拥有者讨论数据，你应该用到这些语言。
　　从数据库的实现者的角度来看，"数据"就不是商业实体了，而是保存在数据表中的行和列，还有通过连接（join）和映射（projection）生成的表。如果你在和一个数据库设计者讨论"数据"，不要讨论客户的群体，而应该讨论关系数据表。
　　并不是从一个角色的角度看就比从另外一个角色的角度看要好，也不是越详细越好，也不是某一个的优先级比其他的更高。作为一个整体，无论是从谁的角度都很重要。正如Zachman说过的：
　　我们在信息系统构架方面与另外的构架沟通时有很多困难，因为存在很多构架表现形式，而不是仅仅只有一个构架。其中一个出错了，其他的也跟着出错。构架是不同的。它们是附加的和补充的。选择为开发每个构架表现形式而支出资源是有原因的。如果不开发任何构架表现形式是有风险的。
　　正如我前面提到的，Zachman框架由六个功能焦点组成，每个功能焦点都会从一个角色的角度考虑。Zachman框架的描述可参见图1，它描述得很清楚。

　　从图1中，你可以看到，在一个Zachman表格中，有36个方格，每个方格就是一个角色（例如商业拥有者）和每个描述焦点（如数据）的交汇。当我们在表格中水平移动（例如从左到右）时，我们会从同一个角色的角度，看到系统的不同描述。当在表格中竖直移动（例如从上到下）时，我们会看到从不同角色的角度，观察同一个焦点。
　　关于Zachman表格有三条建议，相信它们在企业构架的开发中对我们会有帮助。
　　第一条建议就是每一个构架材料应该存在于一个方格中，而且只能存在于一个方格中。在一个构架材料放在哪个方格里不应该含糊不清。如果某个构架材料的确不知道应该放在哪个方格中，问题很有可能处在构架材料本身。
　　当组织在开发企业构架中开始积累材料的时候，它可以使用Zachman表格解释每个材料的焦点。例如，面向服务构架相关的材料很有可能就放在第三行（从设计着的角度看）。它们一般不会引起商业拥有者的兴趣。
　　第二条建议：仅仅只有当所有的表格都填满了的时候，一个构架才能被称为是完整的构架。当所有的方格都填满了时候，整个表格才有足够的材料定义系统。
　　只有当每个方格都填满了材料的时候，才有足够的信息描述系统：从每个角色（我们现在可以称之为"利益相关者"，Stakeholder）的角度观察系统的每个可能的视角（描述焦点）。所以一个组织可以使用Zachman表格确保企业构架中的所有重要利益相关者之间的讨论都是合适的。
　　第三条建议：表格的每列的方格都是彼此相关的。例如，Zachman表格的数据列（第一列）。从商业拥有者的角度，数据就是关于商业的信息。从数据库管理人员的角度，数据就是数据库中的行和列。
　　尽管商业拥有者对数据的看法和数据库管理员不同，但它们应该是有关系的。一个人可以遵循商业需求，并且显示出设计的数据就是被需求驱动的。如果有商业需求并没有追踪到数据库设计，那么就得想想商业需求是否与企业构架相符。另一方面，如果数据库设计的元素没有需求与之对应，我们就应该问问自己，在数据库层面是否存在不必要的设计。
　　Zachman表格可以从以下五个方面帮助我们开发企业构架：
　　确保每个利益相关着能够从描述的焦点考虑。
　　通过把每个焦点精简到每个特殊观众涉及的焦点来提升构架材料的质量。
　　确保每个商业需求能够追踪到技术实现。
　　确保商业方面不会规划出多余没用的功能。
　　确保技术组包含在商业组的规划中。
　　但是Zachman本身并不是一个完整的解决方案。有太多的问题它都没有描述。例如，Zachman没有给出一步一步构造一个构架的过程。在决定我们将要构建的构架是否是最好的时候，Zachman没有提供更多的信息帮助我们作出决定。就此而言，Zachman也没有给出一种途径展示将来构架的需求。最重要的，从我们的角度，尽管Zachman表格可以帮助组织构架材料，但是它在描述企业复杂性方面几乎什么都没做。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。