企业架构研究总结(37)——TOGAF企业连续体和工具之架构资源库及架构工具的选择

image

 

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认证程序中被认证?
  • 培训因素:
    • 可得到性
    • 成本
    • 为得到成效而须要的资金
    • 学习风格
相关文章
相关标签/搜索