开发企业架构时，很多应用程序都需要建模支持。为了高效地处理此工作，您需要建立一个框架来包含和组织所有的建模构件，以支持依赖组之间的协同工作。这样做有两个主要好处：实现模型组织的统一维护和模型间依赖关系的统一管理。本系列 这一部分中，我们将讨论有关可靠企业架构存储库创建的结构与管理问题，以便充分利用组织的现有资产。

　　任何组织最宝贵的资产通常都是其业务流程、应用程序和数据设计——对于开发自己软件系统（经常需要数百万美元的投资）的组织更是如此。不过，关于这些主要资源的关键信息都掌握在组织内少数关键人物的手中。因此，仅仅在这些人员方便的时候才能获得这些信息，如果这些人离开了，这些信息也将从组织中消失。要解决这个问题，就需要将此信息捕获到企业存储库中（通常采用数据、流程和软件模型的形式）。本文将介绍企业架构存储库的结构、组织和管理。

　　企业架构存储库与您当地公共图书馆非常相似。图书馆中的信息采用很多形式，如书籍、参考索引、磁带、CD、照片、地图、期刊、论文和杂志。图书馆的价值不仅在于资料本身——几乎任何顾客都可以结合使用统一的组织模式和标准索引快速找到和使用任何信息。如果采用相反的方式，将所有的东西都堆在一个大房间里，由于几乎不能进行资料搜索，因此会大幅度降低图书馆的有用性。与此类似，即使将资料进行了分类，如果允许顾客将资料放在任意地方，出现的情况将和堆在一起的情况一样糟糕——如果不花时间寻找，就什么也找不到。不过，在很多大企业中就是这个样子，特别是涉及软件开发的企业。

　　通常会编写文档，进行审阅和批准，然后保存到共享驱动器上。很快这些文档就会成为永远没有人问津的数据荒漠的一部分。模型（如果创建过）将保存到本地或共享驱动器上，可能会使用一次，然后就废弃不用了。实际上，这些资料是大量资金、精力和时间投资的成果，因此是非常宝贵的企业资产。将这些资料弃而不用与用钱打水漂一样。主要问题是时间——查找资料的时间、确保资料正确的时间以及更新和存储信息的时间。考虑到项目通常的交付压力，直接重新创建文档或模型可能更快更方便——然后不断重复这样的过程。

　　为了不再进行这样的反复工作，必须将要重用的资料（如需求、模型或设计文档）作为可重用资产对待。可重用项目根据定义良好的归类方法存储，可以快速查找，将作为宝贵的企业资产（而不是可丢弃的项目构件）对待。例如，可能会为正在开发的项目创建用例文档，但不会将其存储在存储库中，因为不大可能用于下一个开发周期——特别是各个周期之间的间隔时间很长时。这就是企业架构存储库的目的所在：它提供将所有信息整合到一起的结构、索引和管理模式。所需要的就是某种形式的版本控制系统，如IBM Rational ClearCase或并发版本系统（Concurrent Version System，CVS），以提供永久文件访问和控制。建立存储库的第一步是建立稳定的结构，以支持组织的业务操作。第二步是建立一组过程和流程，以在以后管理和维护库。

　　技能和能力

　　构建模型结构和实现文件控制系统只是建立企业架构存储库的第一部分。更为困难的任务是在以后维护和管理此结构，特别在建模人员数量增加的情况下更加困难。随着时间的流逝，存储库的结构和内容方面的变更的数量和速度将会逐渐增加，希望查找和阅读资料的团队成员的数量也会增加。因此，确立相应的负责人员来管理所有更改和监控存储库的一致性至关重要。

　　为了实现此目标，我们将介绍三个新的组织角色，如表1中所示。

　　表1. 模型管理角色

　　存储库管理员对存储库的结构负有最终的责任。像在任何图书馆中一样，用户不能确定何时何地存储资料。存储库管理员充当图书馆馆长的角色，接受对核心存储库结构的更改、添加或重新排列的请求并进行审批。如果存储库管理员同意更改，则将计划对其实现并通知所有存储库用户。在大多数情况下，这些决策具有体系结构本质，最好由体系结构团队进行判断。因此，至少在最初的时候，所指定的存储库管理员应该来自恰当的系统或业务体系结构团队。

　　与此相对，模型所有者负责存储库的内容。例如，应用程序架构师负责特定应用程序的模型结构和内容。模型所有者与存储库管理员紧密协作，以建立初始模型结构（这在模型文件受源代码控制影响时尤为有意义）。为了促进一致性，每个存储库区域（即应用程序、数据、业务或服务）应该具有每个团队可用来建立初始模型的公共模型模板。

　　存储库中的所有内容都必须采用某种形式的版本控制加以保护。根据实现工具的不同，此控制可由数据库、文件控制系统或文件版本控制系统提供。结合使用Rational ClearCase、Rational Software Manager和Rational RequisitePro可形成特别强大的组合，用于建立包含需求、模型和其他体系结构相关构件的存储库。在这种情况下，Rational Software Modeler中的模型文件受到Rational ClearCase的控制，与保存到Rational RequisitePro中的需求的结构匹配。这些工具的紧密集成可用于创建业务、应用程序、服务和数据需求的单一无缝模型。通过对存储库部分或全部使用版本控制系统，可使用分叉和合并策略对同一系统进行并行开发。

　　工具和技术

　　任何组织都可以从企业架构存储库获益，但重点关注软件系统开发的将从其获得最大的价值。除了代码外，这些组织经常没有或只有很少用于管理文档和模型等开发构件的正式方法。这样所导致的结果与前面提到的将书籍堆砌在一起的效果类似：共享驱动器上采用含混不清的文件或文件夹名称的大量文档难见天日。通过对开发流程添加一定量规定和要求并创建正式的存储库来管理和承载所有长期使用的开发构件，可以极大地避免这种情况。

　　图1显示了典型的企业架构的顶层结构。注意四个核心框架区域：应用程序体系结构、业务流程体系结构、数据体系结构和面向服务的体系结构（Service-Oriented Architecture，SOA）。此外，可能会有一个或多个支持特定业务需求的其他区域，如用于捕获物理设施模型以支持虚拟电信企业的开发工作的区域。这个额外的支持区域（或许名为物理结构）将用于存储关于网络硬件、电缆连接、物理设施和其他基础设施信息的模型。

　　图1. 企业架构顶层结构
 
　　企业架构框架的实现依赖于用于捕获模型信息的工具。例如，使用Rational RequisitePro的需求管理流程会将存储库结构实现为关系数据库。如果使用Rational Software Modeler创建模型，则可以使用版本控制系统（如Rational ClearCase）来管理模型文件。甚至可以使用开源工具（如CVS）来管理各种建模工具生成的文件。关键是要对体系结构的结构采用某种形式的版本控制和访问管理。

　　业务流程

　　组织通常进行业务建模，以更好地了解各个人员为了支持业务目标而执行的流程。这些流程可能通过手动执行或通过某种软件或硬件自动化执行。企业架构支持通过按照功能区域对工作流进行组织从而为这些模型提供与其他体系结构区域类似的支持（请参见图2）。不过，对于业务流程，存储库文件夹结构可能与其他区域有极大的差别，因为并非所有流程都要实现自动化。例如，在Corporate域中，子文件夹结构并不与应用程序Corporate域直接匹配（请参见图3），因为存在企业测定、Sarbanes-Oxley(SOX)Act报告等手动流程。

　　图2. 业务流程建模结构
 
　　请注意存储在存储库中的资料胜过项目：它们代表真正的企业资产。需求、系统体系结构和数据体系结构等资料并不限制到单个项目，要进行重用。项目级别的资料仅在项目本身中非常有用，因此可以将其存储在单一文件存储位置，如项目百科或共享网站中。

　　应用程序体系结构

　　应用程序体系结构组织结构非常依赖于组织的业务功能。如果组织要遵循IT基础设施库（IT Infrastructure Library，ITIL）所建议的结构，则应用程序体系结构将与图3中所示类似。

　　图3. 示例应用程序文件夹和文件结构
 
　　其他区域可能对公司的其他支持系统有用：

　　·产品管理：

　　产品定价
　　报价
　　产品目录

　　·销售与订单管理：

　　销售团队管理
　　订单输入
　　订单执行
　　工作人员管理

　　在这些主次级别下，可以根据应用程序的主要功能对其进行组织，如销售和订单管理 > 订单输入域下执行订单输入的应用程序。具有多个功能区域的系统，如处理订单输入、库存管理和供应的系统可以细分为存储在相应功能区域中的逻辑子系统。与此类似，如果组织具有多个重叠应用程序，则可以将其分组到采用公共应用程序名称的组下，以便说明合并功能行为的需求。

　　在每个应用程序文件夹下，公共文件管理结构将非常有用，如图4中所示。具体来说，此方法支持使用视角（viewpoint，IEEE 1471标准所倡导使用的一个模型组织结构）。此方法可达到两个目的：首先，它支持将模型划分为独立区域，以支持并行建模（如在进行逻辑分析的同时进行用例开发）。其次，它特别关注模型或特定涉众的需求（例如，操作支持团队和部署视角）。

　　图4. 应用程序体系结构文件夹和模型文件结构
　
　　可以将此结构用于管理代码和模型，也可以将应用程序代码库与模型分开管理（只需要添加相应的引用）。

　　数据体系结构

　　数据体系结构区域用于捕获持久型数据库的结构。所涉及的有两种数据库：依赖于应用程序的数据库 和独立于应用程序的数据库。依赖于应用程序的数据模式是为了支持特定应用程序而创建的，如用于为订单输入系统存储订单。其他数据库支持多个应用程序，如帐单编制引擎等。图5显示了管理依赖于应用程序的数据存储的模型和支持文件的一种方法。请注意，正如您可能猜到的依赖于应用程序的数据存储的情况，数据体系结构区域下的结构与应用程序区域的结构非常类似。对于帐单编制引擎，可能没有与应用程序对应的子程序包，帐单编制引擎是独立的个体。

　　图5. 数据体系结构文件夹与文件结构
 
　　依赖于系统的数据存储或独立于系统的数据存储下具有相同的子文件夹结构：用于描述数据字段的数据词典区域、逻辑数据模型（对于应用程序设计非常有用）和物理数据模型（用于采用数据定义语言（Data Definition Language，DDL）生成数据库脚本）。

　　SOA

　　最后一个感兴趣的企业架构框架区域是企业服务总线（Enterprise Service Bus，ESB）提供的服务，如IBM WebSphere ESB。此体系结构区域的目的是定义应用程序提供或使用的企业服务。支持模型和其他构件的结构也基于功能区域，但现在服务本身定义服务级别的文件夹结构，如图6中所示。

　　图6. SOA文件夹结构
 
　　在每个服务下，文件夹结构应该包括与图6所示类似的内容。需要使用应用程序网关（适配器）与服务的提供者或使用者进行连接。implementation文件夹包括Web服务描述语言（Web Services Description Language，WSDL）文件和其他实现构件。应该将模型组织为与应用程序类似的方式，并包括捕获特定服务设计信息的视角，如数据传输对象的企业对象模型。

　　里程碑

　　建立企业架构存储库是一项非常具有挑战性的任务。直接创建企业可以保留的可用结构本身就已经足够困难了，但还必须在以后对存储库进行维护和扩展——并同时确保资料的最新性、准确性和可用性。为此，请考虑下面这些主要的里程碑。

　　·发现核心业务体系结构：确定组织的真正功能结构，包括产品如何创建、打包、销售和收费；公司如何组织和管理；以及何时何地进行基础设施（如软件）开发。
　　·生成存储库结构：创建初始结构，并将其置于源代码控制之下。此结构应该反映功能业务操作最稳定的部分。
　　·管理存储库：定期检查和评估存储库中的所有资料，以确保正确性、内聚性、一致性和相关性。图书馆最可怕的事情就是资料过期了。

　　如本文中所述，规模足够大的任意企业都可以通过组织开发构件进行重用获得巨大的价值。任何让开发构件尘封的公司无疑都在浪费自己的资金。这样不仅浪费了最初的劳动成果，而且还会在需要进行更改时为了寻找这些丢失的信息而浪费大量的资金和时间。您是否能想像某个组织完全依赖于将重要信息全部保存在自己脑袋中的核心小组的情况？只有将公司的资料组织为可重用资产库（以及创建关于核心业务功能区域的库），才能使得这种情况得到改观。考虑一下您希望如何使用公司的资金——每次需要进行系统更改时，还是增加新客户以及产品开发时？您需要就此作出选择。

　　关于作者
　
　　Benjamin A. Lieberman是BioLogic Software Consulting的首席架构师。Lieberman博士在广泛多样的软件开发主题上提供专业的咨询和培训意见，包括需求分析、软件分析和设计、配置管理、以及开发流程的改进。Lieberman博士拥有十多年的软件体系结构和信息技术的经验，且涉及到包括无线通讯、航空旅行、电子商务、金融服务和生命科学在内的多个领域。他所提供的咨询服务都是基于软件开发的最佳实践，并且他在面向对象的体系结构和分布式计算方面具有特长——特别是，基于Java的系统和分布式 网站开发（J2EE）、XML/XSLT、Perl和基于C++的客户机-服务器系统。Lieberman博士曾为EchoStar、Jones Cyber Solutions、Blueprint Technologies、Trip Network Inc.、Galileo International、Duke University和University of Colorado等组织提供过架构方面的服务。他也是一位颇有成就的专业作家，其著作包括一本书和大量与软件相关的文章。Lieberman博士拥有美国科罗拉多州丹佛市的科罗拉多大学健康科学中心的生物物理学和遗传学博士学位。您可以通过blieberman@biologicsoftwareconsulting.com与Lieberman博士联系。