TOGAF企业连续体和工具之架构资源库及架构工具的选择

TOGAF企业连续体和工具之架构资源库及架构工具的选择

3. 架构资源库

在一个企业，尤其是在一个大型企业中，建设一个成熟的架构往往会产生大量的工作产品。为了很好地管理和利用这些工作产品，企业需要制定一个正式的针对不同类型架构资产的分类方法，并且还需要专门的流程和工作来辅助这些内容的存储和管理，而这正是架构资源库所关心的。在TOGAF中架构资源库所包含的内容包括了如下几个方面的信息：

• 架构元模型（Architecture Metamodel）：描述了组织为自身量身定制的架构框架，包括架构开发方法和架构内容的元模型。
• 架构能力（Architecture Capability）：定义了用于支持架构资源库治理的各个因素、结构和流程。
• 架构情景（Architecture Landscape）：展示了由组织当前正在使用的构件块所组成的一幅架构视图。为了适用于不同的架构目标，架构情景通常会存在于多个粒度层次中。
• 标准信息库（Standards Information Base）：此信息库储存了新架构所必须遵循的各个标准，包括行业标准、从供应商处所选择的产品和服务，或者是已经部署在组织中的共享服务。
• 参考库（Reference Library）：提供了用来加速企业中新架构创建的导则、模板、模式以及其他形式的参考资料。
• 治理日志（Governance Log）：用于对整个企业中的治理活动进行记录。

上图对以上这些架构资源库中的信息进行了展示，并且他们之间的关系以及他们与外界环境之间的关系也在这张图中进行了描述。由图可见，位于中间部分的架构情景库包含了各个反应了企业当前状况的构建块，而这些构建块的产生和组织结构是由架构元模型而定的，并且在这些构建块的产生过程中，企业还需要借鉴参考库和标准信息库中的各种参考资料和标准，从而提高其创建的效率和质量。架构情景库、参考库和标准信息库之间并不仅仅是单向的借鉴关系，随着企业架构过程的进行，架构情景库中的构建块将会日趋成熟，因而有些构建块可以被验证为在企业或行业甚至更为广阔范围内的最佳实践，从而可以将他们引入到参考库或标准信息库之中，形成新的参考资料或标准，以供后期活动借鉴使用。为了确保企业架构能够被正确地创建、运行和维护，企业架构过程需要一个治理过程来保驾护航。在治理过程中，架构情景库中的各个构建块都是治理的目标所在，并且标准信息库中的各项标准也是标准合规性检查的重要输入。需要注意的是，标准信息库中各项标准的参考实现也可以被保存到参考库之中。

既然架构资源库是为了方便外界针对架构资产的存储和管理而存在的，那么架构资源库与外界环境之间也有着天然的联系：

• 企业可以采用位于企业范围之外的各种参考模型，并将其放入到参考库之中。
• 企业可以采用位于企业范围之外的各种标准，并将其放入到标准信息库之中。
• 架构委员会可以检视治理日志库中存储的各项治理活动记录，并将新的架构治理活动情况录入其中。
• 企业架构的最终目标是塑造企业的各项能力（组织结构、工作流程等），并使其满足企业的战略目标，而反过来讲，这些能力也保障和促进了企业架构的开发和运用。与这些能力相关的产品被存储于架构能力库之中，而架构委员会可以通过其中的内容对各项能力进行管理。

TOGAF针对架构情景库、参考库、标准信息库和治理日志库中的内容进行了详尽的描述，在接下来的各节中笔者将分别针对这些内容进行描述。

3.1 架构情景库

架构情景库包含了用于描述企业当前状态的各种架构块。由于整个企业中存在着形形色色的干系人，并且他们的需求也各不相同，因而架构情景库中的内容包含了如下三个粒度层次：

• 战略架构：提供了一份关于整个企业的长期概括性视图，并为运行和变更活动提供了一个组织框架，从而使得企业可以在领导层进行方向设定。
• 片段架构：为企业中的各个领域提供了更加详尽的运营模型。片段架构可以被应用在方案或项目组合层面，从而用来对更加详尽的变更活动进行组织和运行调整。
• 能力架构：采用一种更加详尽的方式来展示企业是如何支持各个能力单元的。能力架构可以被用来提供一个关于当前能力、目标能力以及能力增量的概览，并使得各个工作包和项目得以被组合到受管理的项目组合和方案之中。

3.2 参考库

参考库中包含了在企业的架构建设过程中所用到的各种最佳实践或模板材料。这些参考性资料可以从各个方向而来，包括：

• 标准组织
• 产品和服务厂商
• 行业协会或论坛
• 由公司团体定义的模板
• 从项目实施中总结而出的最佳实践

为了整合这些来源于各个地方的参考资料，参考库可以采用架构连续体来作为它们的分类方法。

3.3 标准信息库

标准信息库为架构所必须遵守的各种规范说明提供了存储区域，并且标准信息库的建立为架构治理也提供了一个清晰的基础。标准的类型通常分为如下几类：

• 法律和法规义务：这些标准被法律所强制约束，因而企业必须遵守这些内容并面对可能产生的各种严重后果。
• 行业标准：这些标准由行业组织所建立，并被企业选择采纳。行业标准为企业间的互操作和共享提供了潜力。由于针对此种类型标准的控制处于企业之外，所以企业应该对此种类型标准的状况进行监督。
• 组织标准：这些标准在组织内部确立，并基于组织的业务期望。企业需要建立各种流程来保证这些标准的豁免情况和演进。

标准并不是亘古不变的，每个标准都要其生命周期，一般来讲标准的生命周期包括如下几个阶段：

• 试行
• 有效
• 过时
• 废弃

所有的标准都应该按照一定的周期进行检查，从而确保它们处于正确的生命周期阶段。作为标准生命周期管理的一部分，标准生命周期状态的变更影响需要被明确，从而了解标准变更对于企业当前状态的影响，并为适当的处理活动进行规划。

针对存储在标准信息库中的各项标准的划分与TOGAF内容元模型中所定义的各构建块是相关的。在内容元模型中定义的各个实体都具有与其相关的标准。从最高划分层次来讲，标准的分类划分是以TOGAF的各架构领域为基础而进行的：

• 业务标准：
• 标准的共享业务功能
• 标准的角色和执行者定义
• 与业务活动相关的安全和治理标准
• 数据标准：
• 标准编码和数据值
• 数据的标准结构和格式
• 数据源和数据归属标准
• 复制和访问限制
• 应用标准：
• 支持具体业务功能的标准或共享应用
• 应用通信和互操作标准
• 访问、表现和风格标准
• 技术标准：
• 标准硬件产品
• 标准软件产品
• 软件开发标准

3.4 治理日志库

治理日志库为正在进行的与项目治理活动相关的各项信息提供了一个储存区域。针对治理信息的维护是非常重要的，因为：

• 对在项目进行过程中所做的决策进行保留是非常重要的。例如，如果一个系统需要被替换，那么对当初与其实现相关的关键架构决策有所了解是很有价值的，因为它可以对各种约束和限制进行标明，以免这些信息被遗漏。
• 许多干系人对于项目治理的结果是非常关心的，例如项目的客户、架构委员会、其他项目等。

治理日志库的内容应包含如下各方面：

• 决策日志：一个关于组织中所有重要架构决策的日志，通常其内容包括：
• 产品选择
• 项目主要架构特性的缘由
• 标准偏差
• 标准生命周期变更
• 变更请求评估和审批
• 可重用性评估
• 合规评估：在项目过程的重要里程碑之中需要对架构进行一次正式地审查，用于评测项目与定义的标准之间的符合度。对于每个项目来说，此日志内容应包括：
• 项目概述
• 过程审查（时间表、状态、问题、风险以及依赖关系等）
• 完整的架构清单
• 标准合规评测
• 建议的行为
• 能力评估：根据项目目标的不同，某些项目需要进行业务、IT或架构能力方面的评估。这些评估需要周期性进行，并具备可追溯性，从而确保进程的顺利。此日志内容应该包括：
• 用于进行能力评估的模板和参考模型
• 业务能力评估
• IT能力、成熟度和影响评估
• 架构成熟度评估
• 行事历：展示了一份关于还未落地的项目和对于这些项目进行正式审查的日程规划。
• 项目组合：包含了关于所有还未处在架构治理之中的项目的摘要信息，包括：
• 项目名称和描述
• 项目的架构范围
• 与项目相关的架构角色和责任
• 性能评测：基于架构功能的章程，企业需要定义一系列性能指标。性能评测日志应该包含与项目治理相关的指标，以及与架构章程相关的性能指标，从而使得架构的性能可以在一个进行的状态中得以被评测出来。

4. 架构工具的选择

从前面的内容中我们可以了解到，在企业架构的建设过程中会产生出许许多多架构制品。虽然企业可以通过建立架构资源库的方式对这些制品进行储存，但是对于它们的管理和访问，以及对资源库自身的维护来说，单靠手工来做那几乎就是一个不可能完成的任务。从架构制品的使用角度来说，存储在架构资源库中的内容只是一些基础素材，而要满足不同干系人在不同层面的不同需求，企业需要将这些元素进行组合，从而产生基于各种视角的视图，而这一工作也是不可能单靠手工就可以完成的。由此可见，在架构的开发、维护和使用过程中自动化工具的介入和帮助是非常必要的。

对于企业架构自动化工具来讲，其最核心的问题就是如何建立一个统一的工具标准。这个方法从表面看是非常合理的，因为如果真的存在这样一套遵循统一标准的万能工具，那么企业将会因此而获得培训开支缩减、软件授权共享、批量折扣，以及维护和信息交换方面的便利。这的确是一幅美好的画卷，但是在实践过程中这种状态却非常难以达到。客观的讲，单一工具会减少工具之间的竞争，从而妨碍其演进，并且企业架构工具的选择应该与企业的架构成熟度水平紧密关联，而一个能够涵盖所有架构成熟度水平的万能工具是几乎不可能存在的。

虽然当前存在着很多由不同厂商开发的企业架构自动化工具，但是TOGAF作为一个开放性标准，它对于这些自动化工具并没有显式的推荐，而是为企业列举出了一系列用于判断架构工具是否符合自身要求的参考标准。在现实生活中，企业可以参考这些标准，并按照自身情况对其进行定制（例如，为不同的标准设置不同的权重），从而在众多工具之中选择出适合于自己的自动化企业架构工具。需要注意的是，无论采用何种方式对工具进行选择，我们都需要注意如下几个原则：

• 工具的价值依赖于组织的架构成熟度水平。
• 工具的选择需要与组织的能力相匹配。
• 企业对于工具的选择需要在战略层面（组织整体标准和方向等）和战术层面（人员能力和熟练度等）取得良好的平衡。
• 团队对于工具的成功有着重要的影响，这些影响既可能是正面的也可能是负面的。

4.1 功能性考量

4.1.1 关键功能

• 是否支持组织所选择的框架？
• 是否支持产生组织选择的框架所要求的各项交付物？
• 如果不支持，那么是否支持某些现成的企业架构框架，例如TOGAF、Zachman等？
• 术语表：
• 术语表是否可以被扩展为一个分类法？
• 当前术语表是否可以被当作分类法而使用？
• 能够采用某种有意义的方式将架构模型和视图展示给非技术类型的架构干系人的能力。
• 是否支持元模型？例如，配置和定制模型的能力。
• 是否支持企业级应用？例如，对于多用户协作的支持。
• 是否支持向下追溯？例如，概念、逻辑和物理等层面的层层深入。
• 是否提供了一种将需求与用于满足此需求的架构相关联的机制？亦即需求追溯能力。
• 安全特性：
• 是否具有访问控制？例如，对于不同的角色赋予不同的权限。
• 工具的安全设计是否与企业的安全策略相符？
• 是否支持本地报告生成？
• 是否支持通用语言和标注法？

4.1.2 易用性方面

• 是否能够通过一个简易的流程图来指导用户的使用？
• 在线帮助。
• 现成且相关的构件元素，包括业务、数据、应用或技术方面。
• 现成且相关的用于进行架构建设的模板或模式。
• 支持可视化建模。
• 可否被扩展或定制，并是否提供了相关的工具？
• 是否能够对所做的变化进行跟踪和审计？
• 是否提供了一种方法来为各个制品进行一致性命名和组织？
• 是否架构制品或组件能够被很容易地查看、使用和重用？
• 是否支持编程语言的使用，并且相关需求都是什么？

4.1.3 组织相容性方面

• 国际化/本地化能力：
• 是否工具可以适用于架构工作所发生的各种地理位置和语言区域之中？

4.1.4 工具容量/伸缩性方面

• 是否具有容量限制？
• 数据的规模
• 文件的数量
• 数据记录数
• 是否具有可配置点，并且这些配置点是如何实现其伸缩性的？
• 是否存在一种升级方式来应对工具的容量限制被超越的情况？

4.2 工具体系结构考量

• 资源库是分布式的还是集中式的？
• 是否具有动态资源库？
• 是否支持多行业标准数据库（例如Oracle，Sybase等）或采用专用存储库？
• 是否具有后向兼容性，用以兼容之前发布的工具？
• 是否允许将数据整合进中央存储库？
• 是否具有版本控制？
• 可否通过Web客户端进行访问？
• 运行于何种平台之上（硬件、操作系统、数据库管理系统以及网络）？

4.3 架构全生命周期支持考量

• 是否在架构全生命周期中对其进行支持？
• 是否支持各种现成的相关视图？例如业务流程、数据、应用和技术方面的视图。
• 是否支持定制化视图的创建？
• 是否采用与企业架构实践相关的建模方法和技术？
• 是否支持模拟分析？
• 工具所产生的模型是否是可执行的？

4.4 互操作性考量

• 导入与导出：
• 能否将在工具中创建的制品导出到其它通用工具之中，从而使得这些工具的用户可以完好的使用那些制品。
• 能否导入其它工具所产生的制品，从而使得这些制品可以在此工具内被完好地使用。
• 是否可以与其它工具相集成？
• 是否提供并支持符合行业标准的应用程序接口？
• 是否采用了相关的行业标准？例如，XML、HTML、UML等。

4.5 财务考量

• 采购成本是多少？
• 工具的总拥有成本为何？
• 维护
• 装置成本
• 支持成本
• 使其保持最新版本所需的资源数量
• 管理责任/时间约束
• 引入此工具所带来的影响。例如，是否需要架设专门的基础设施。
• 培训
• 授权模式

4.6 厂商考量

• 厂商是否还有效？
• 厂商在此领域所存在的时间有多久？
• 是否厂商具有大量的用户群？
• 是否厂商具有专业的服务？
• 是否需要第三方支持？
• 是否此工具在组织中具有使用历史，且其声誉如何？
• 厂商是否在The Open Group的TOGAF认证程序中被认证？
• 培训因素：
• 可获得性
• 成本
• 为获得成效而需要的资金
• 学习风格