企业架构依赖于用于实现和文档化的一系列工具。这些工具包括从描述架构的综合框架，到描述如何实现的常规文档。不论您使用哪些工具，都要确保您也进行了充分的交流，以巩固支持架构的关系。
　　我们能谈论吗？
　　如果，您正在实现企业架构。这对您非常有好处！既然您已经决定走这条路，那么您需要知道，您可以依靠一些关键的工具来帮助您。事实上，有两种不同类型的工具可用 —— 更形正式的和您自己构建的。形式化工具包括如企业架构框架那样的工具。非形正式的工具是包罗万象的类型，它包括许多东西，其中最重要的两个是适当的交流计划和对应用程序准备和部署的公开对话。
　　使用恰当的框架
　　恰当的框架对简化企业架构的实现大有帮助。市场上有许多框架出售，它们都有同一个主要目标：概括描述一个结构，通过该结构，复杂的对象关系可以相互作用，从而连接人、过程和技术。例如，Open Group Architecture Framework (TOGAF) 或 Zachman Enterprise Architecture Framework —— Zachman Institute for Framework Advancement (ZIFA) 所支持的 —— 都提供了允许您布置帮助将商业需求与 IT 服务相结合的组件的相互关系的矩阵。
　　Zachman 框架在 20 世纪 90 年代产生，它帮助提供了允许组织识别商业和 IT 之间关系的模型。（参见 图 1。）John A. Zachman 认为 IT 太容易忽视商业需求，并且太容易为了 IT 的目的创建 IT 了。虽然确保所有 IT 实践都遵守可靠的设计原则是一种很好的做法，但是确保 IT 基础框架提供的所有服务和产品都与组织的商业策略相结合也是必要的。否则，您最终会以一个导致有功能障碍的 IT 服务的缺口告终。事实上，Zachman 表明日常 IT 的职责是着重于硬件及组成 IT 底层组件的软件，而架构的职责是着重于该基础架构将拥有的内容。这些内容帮助定义该架构。因此，您应该指望框架和模型作为帮助您确定系统的内容，然后指导您选择并实现支持该内容的组件的工具。

　　选择恰当的框架，并且了解它如何概括这些关系，可以帮助您改进或实现您自己的企业架构需求工作。框架没有正确或错误。框架被设计用于辅助您了解您的企业架构的组成和设计。选择您将用于支持架构的框架的最佳方式是分析可用的模型，并且找到一个您最熟悉的。观察这里提到的两个框架，并选择一个对您和您的预期设计最好的框架继续下去。
　　进行充分的交流
　　关于框架的材料已经堆积如山，但是框架不是您的企业架构所依靠的唯一工具。有时候，观察框架并且确定它们如何帮助我们的最简单方法是从较根本的地方出发。框架是用来帮助结合商业和 IT 的，这个过程开始的最佳地方是通过对话。很少有组织进行商业和 IT 间的适当对话。这不足为奇，因为 IT 本身之中经常没有开放的交流渠道。事实上，这种障碍的最普遍迹象之一在 IT 交付新的应用程序的方式上是明显的。让我们来看看一个简单的场景。
　　企业有一个新的需求。要满足该需求，IT 团队决定要组装出一个新的应用程序，这意味着应用程序开发人员必须与企业开始对话，以获得更详细的需求。该阶段是过程中首批潜在缺陷之一出现的地方：不充足的需求定义将导致应用程序失败，因为开发人员不能对业务需求有清晰的了解。
　　开发人员进行的下一个步骤是开始开发应用程序。虽然需求问题会导致需求和结果之间的主要差别，但是这第二个步骤常常是应用程序开发中最大痛点的来源，因为在大多数组织中，IT 和信息服务（information services，IS）之间的交流常常是非常少的。开发人员常常工作在其自己的世界里，构建自己的开发机器和环境。当把应用程序投入生产环境时，应用程序常常会不工作，因为用于准备应用程序的环境不包含实际生产环境基础架构所包含的所有，或任意标准和支持原则。当 IT 试图让应用程序运行时，会出现一些问题，而当 IT 和 IS 都试图推卸对于该问题的责任时就会挑起情绪。
　　缺乏交流是这一不幸 —— 花费时间和金钱 —— 的真实原因，这本可以通过简单的交流原则就能避免。事实上，必须在业务、开发和 IT 之间设置交流三角。交流渠道应该是双向的，连接 IT 到开发、开发到业务，以及业务到 IT，然后再逆向回来。还应该开正式的会议，以确保没有漏掉什么。当召开那些会议时，不要害怕说出真相。太多的组织设置这些交流渠道只是以更糟的情况告终，因为在会议上没有说出真相。不要害怕说出来！
　　巩固您的关系
　　好了，现在您有了辅助您的框架，并且您拥有了交流渠道。您将会很好地建立与所有参与的合伙人之间的改进关系。但您仍会发现自己处于这种情况，当部署到生产环境中时，应用程序仍是无效的。您如何避免这种事呢？很简单 —— 通过控制用于执行开发的环境。
　　开发人员不是基础架构专家，而且构建、管理和维护基础架构也不是开发人员的任务。也就是说，开发人员需要一定的自由来执行他们的工作。给予他们所需的自由的最好方法是向他们提供运行在虚拟平台 —— 例如，VMware、Xen，或 Microsoft? —— 上的虚拟机（virtual machine，VM），并确保这些 VM 是依据您在企业架构的基础架构层上设置的原则构建的。
　　开发阶段经过一些列环境 —— 单元、功能、集成、分段和实验/生产 —— 每个都包含更多组成生产环境的基础架构组件。（参见 图 2。）每一级应该有一个标准的入口规范，以及出口规范。在每个环境中都应该为应用程序设置具体的目标，并且直到这些应用程序达到目标之前，它们都应该处于这些环境中。当应用程序投入生产时，它在前面环境中遇到的任何操作问题都应该被完全解决了。事实上，如果您向开发人员提供入口和出口标准，为每级准备适当文档，以及对每级中包含的技术的适当访问，那么您将极大地简化应用程序的集成过程。文中 环境描述清单 部分概括了您应该向开发人员提供的，用来简化他们的应用程序与您的分段环境的集成的组件。

　　准备
　　当您确定了组成项目的所有关键要素之后，您就可以进行项目的准备了。在此阶段，您将推敲预算、培养将参与项目的团队，并且分配职责。确保在所有团队成员之间建立交流渠道。
　　太多的组织犯了这样的错误，即在此阶段只包含了开发团队成员，这将导致生成一些不能向生产环境交付的产物，以及缺少操作所需的支持、培训和所有其他非开发的机制。因为许多团队需要确保产品的高质量，所以，这次每个团队都应该有适当的代表。交流机制还应该包含对涉众的经常性的反馈，以确保他们在开发过程中完全地意识到了意外的挑战和成功。
　　环境描述清单
　　您向开发人员提供的这个帮助他们整合应用程序与分段环境的清单，应该包含这里所列出的信息。该清单是您在谈论新应用程序整合时的第一步。
　　应用程序服务器需求
　　目标服务器的名称和 IP 地址
　　应用程序管理员服务器帐户
　　软件需求：
　　操作系统
　　Web 服务器
　　开发工具
　　可用性需求
　　目录服务和安全性需求
　　组名
　　访问权限
　　带有确定角色的用户帐户，包括新应用程序的角色
　　带有访问权限的服务帐户名
　　策略组件，如果可用
　　委托需求，如果可用
　　数据库服务器需求
　　登录和访问权限
　　系统管理员组特权，如果可用
　　数据库需求：
　　数据库管理员，如果可用
　　数据库名称
　　数据库大小
　　数据库日志大小
　　性能需求
　　可用性需求
　　门户需求
　　定制模板
　　Web 组件
　　可扩展的标记语言（Extensible Markup Language，XML）文档
　　协作需求
　　定制区域
　　其他环境需求
　　E-mail 服务器
　　File Transfer Protocol (FTP) 功能
　　管理服务器需求：
　　指定监控新应用程序的计数器或对象
　　用于 Web 服务监控的计数器或对象
　　开发工具
　　文档
　　安装说明
　　测试的安装说明
　　数据库安装和配置说明
　　应用程序部署说明
　　操作描述说明
　　失败及恢复计划

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