企业架构研究总结（36）——TOGAF企业连续体和工具之企业连续体构成及架构划分

       又回头看了以前文章的评论，本人也一样感慨这些文章的确像政治课本般的虚无缥缈，因此对费力看完却以为无从下手的看官致以诚挚的歉意和理解，由于这个问题也一样困扰着笔者本人，而我能作的也只能是纸上谈兵。以前也接触过国家某大型公司的企业架构建设项目，采用的也是TOGAF标准，可是要将其做为例子罗列出来，实在是件伟大的工程，并且本人也真没接触这么多项目内容，没法列举示例还请见谅。就笔者本人的理解，是否符合TOGAF的断定标准主要是企业架构的建设过程是否遵循企业架构开发方法（ADM），至于后面的内容框架（架构制品、交付物和构建块等）并非决定是否遵循TOGAF的绝对断定标准，其内容也是综合了众多组织经验的抽象之谈，因此过于理论化无可避免。本系列的本意仍是还原标准文本，尽力进行普及，虽翻译、理解能力有限，亦但愿能纠当前众多中文资料中不负责任的谬误（见开篇的几篇文章就可了解我写本系列的用意）。至于如何掌握这门技术，须要各看官有机遇参与相关项目，于实践中融会贯通，到时这些枯燥的理论应该会助各位一臂之力。无论怎么说，企业架构真的很复杂枯燥，甚至是否应该建设或者其建设到底有多大用处目前尚未谁能有个确定且量化的回答，笔者读了几年资料并参与了一个相关项目，也能是纸上谈兵，不过做为一个将来方向（笔者自认），能对其有点了解也是好的，毕竟不是具体的软件技术，能够在短期学以至用，而且也有大把机会能够去实践锻炼。原本打算终止写做TOGAF方面的内容，提前开始写企业架构建模和分析方面的内容，由于这个方面内容例子多了不少，看起来也轻松不少，不过终不想半途而废，还请诸看官耐心一点，并但愿有经验的看客对笔者给予指正。

      从字面上看企业架构好像是一个独立且一应俱全的架构，可是这种看似能解决全部问题的单一架构却每每只能存在于理想之中。在实践中，一个企业架构应该是由若干具备不一样目标的架构所组成的。这些架构具备着各不相同的背景，并由于不一样的目标而被建立出来，而且经过这些架构之间的关联关系而造成了一个能够解决各干系人需求的有机总体，亦即企业架构。既然企业架构是由这么多个子架构所组成，那么一个关系混乱且相互冗余的架构构成状况是不能被称之为良好的企业架构的，于是如何界定这些架构的范围对于企业架构的成功与否有着重要意义。在这个方面TOGAF提出了企业连续体（Enterprise Continuum）的概念，用以对企业内外存在的各类架构制品进行分类，并为企业内以及企业与外部的客户和厂商进行架构方面的沟通提供了基点。除此此外，TOGAF还提出了一系列架构划分的原则和方法，从而使得针对企业架构的建立和维护工做的复杂度得以被有效地控制（由于企业架构是为了达成不一样干系人的需求而制定的，且干系人及其需求之间的差别性也很是大，因此企业架构所面对的问题域必将是很是复杂的）。在本章的后半部分，咱们还将对用于储藏和管理各个架构的架构资源库的组织方式进行阐述，并对用于生成和维护企业架构的自动化工具的选择标准进行了描述。

1 . 企业连续体的构成

      如前所述，企业架构并非一个单一的架构，而是由多个具备各自背景且面向不一样目标的子架构所组成的，这些子架构或存在于企业之中亦或来源于企业以外，它们包括了架构描述、模型、构建块、模式、视角以及其余的架构制品。举例来说，对于存在于企业内部的架构制品来讲，包括了在以前的架构工做中所产出的各类交付物，而对于外部的制品来讲，则包括了各行业中的各类参考模型和架构模式等，例如在TOGAF中定义的具备高度普遍性的技术参考模型（TRM：Technical Reference Model）、IT领域中某一具体方面的架构（例如Web服务架构）、与特定信息处理类型相关的制品（例如，电子商务、供应链管理等），以及与特定行业相关的制品（例如电信业的TMF、零售业的ARTS以及石化行业的Energistics）。面对如此纷繁复杂的架构以及更为繁复的架构间关系，企业必须经过一种合理的分类方法来对他们进行组织和界定，从而使他们成为一个协调的有机总体，而这正是企业连续体的用武之地。简单的讲，企业连续体能够看做是用来对全部架构资产进行存储的资源库（架构资源库，其详细介绍请参阅后面的部分）的一个视图，其目标便是对企业内外的各类架构和解决方案制品进行分类。

      虽然企业连续体是一个有关架构分类的方法，可是咱们不能把它简单地看做是一个静态的分类法。不管是从字面上，仍是从企业架构自己的动态特性来看，企业连续体也是一个针对各个架构制品的动态分类方法，它展现了架构制品是如何从通用的“基础架构”分类层次演进到“组织特定架构”这一分类层次。虽然这看起来像是一个由抽象到具体的架构演进过程，可是咱们不能过度强调其动态性而忽略了其分类法的本质，一个架构并非必定要经历这一演进过程，其自己的特性仍是决定其所处分类层次的决定因素。除此以外，咱们还要注意的是这个分类法的动态特性不是单向的，一个架构能够由较为通用的分类层次出发经由整合和定制来达到符合各组织特色且更为具体的特化分类层次，同时一个通过长时间考验并在较大范围内获得认同的架构则能够被提高到一个更为通用的分类层次之中，而这也正是TOGAF因此一直强调的“重用”精神的体现。此外，正是因为这个分类法对架构和解决方案制品所进行的分类和规整，企业连续体为在企业内外进行关于架构的理解和沟通提供了基准点，使得企业在内部以及与外部客户和合做团队进行架构交流时，可以明确目标架构所处的分类层次和相应的特性，从而避免南辕北辙式地探讨。因而可知，企业连续体同时也是一个针对架构进行理解和沟通的有力工具。

      做为TOGAF中的一个重要内容，与其余关键部分同样，企业连续体与TOGAF的核心内容，亦即企业架构开发方法，有着紧密关系。企业架构开发方法所描述的是一个开发组织特定的架构，以及与此架构相关的解决方案的过程，而且这一过程的实现一般是要借助于针对通用架构和解决方案的采用和定制，而这样一个由“通用”到“特有”的过程与企业连续体的精神是一致的。此外，企业架构开发方法不只提倡针对可重用构建块的利用，它同时还指导着新的可重用资源的发掘，而在企业连续体中那些被证实是通用的架构也是能够被划入到通用性更高的层次之中。因而可知，企业架构开发方法为架构的开发和维护提供了手段，而企业连续体则为其结果提供了组织机制。除此以外，企业连续体各分类层次中的资源对架构开发方法的各个阶段具备重要的帮助做用，例如在技术架构的开发中，TOGAF的技术参考模型即具备着指导意义，而在业务架构的开发中，一个关于电子商务的参考模型也可能具备一样的帮助做用，这同时也与企业架构的资源重用精神是相符合的。

      企业连续体是由三个界限清晰的模块所构成的，即“企业连续体（Enterprise Continuum，此部分名称虽与其总体名称相同，但在这里指的是一个独立的子部件）”、“架构连续体（Architecture Continuum）”和“解决方案连续体（Solutions Continuum）”，他们之间的关系，以及企业连续体与企业资源库之间的关系展现以下：

      如图所示，外部存在的各类架构驱动因素被企业连续体子模块所归整，并造成各架构的开发背景和需求。接下来，这些背景元素及需求推进了相应架构的造成，而在此过程当中，架构连续体子模块可被用来为企业资源库所包含的各个相关架构资产提供组织结构和分类方法。当架构被定义并组织好以后，位于架构连续体中的各个架构被用来指导和支持相关解决方案的建立，而在此过程当中，解决方案连续体子模块被用来对存储于企业资源库中的各解决方案资源进行分类和组织。最后，各解决方案被部署到企业的运营环境之中，并成为新的企业架构背景的组成部分。因而可知，企业连续体的三个子模块被完美地契合入整个企业架构生命周期中（自外部驱动因素的识别开始到最终解决方案的部署），并从架构和解决方案两个主要层面对企业资源库中的资源进行归类和组织。企业连续体的三个子模块的定义以下，而且在后面的部分中咱们将对他们的内容进行更加详尽地阐述：

• 企业连续体（Enterprise Continuum）：此种类型的连续体用来对与整个企业架构背景相关的资产进行分类和概括。这些背景性质的资产通常并不直接用在架构开发过程之中，但他们对于架构却具备着很是大的影响，例如政策、标准、战略举措、组织架构以及企业级别的能力等。
• 架构连续体（Architecture Continuum）：架构连续体对于认识和定义通用规则、表现方式以及架构间的关系（这些关系包括可追溯性和派生关系，例如一个组织特定架构与其所基于的某个行业或通用标准之间的关系）提供了一种一致性的方法，而且它为各类可重用的架构构建块（ABBs）在其整个演进生命周期内提供了组织结构，同时架构连续体在架构的通用型发掘和冗余消除方面也是一个很是有用的工具。
• 解决方案连续体（Solutions Continuum）：此种连续体为认识和描述在架构连续体中定义的各类架构资产的实现提供了一种一致性方法，而且它为各类解决方案构建块（SBBs）提供了组织结构。解决方案能够说是客户和业务伙伴之间协议的产物，它实现了定义在架构领域中的各类规则和关系，同时解决方案连续体在处理产品、系统和系统服务之间的共性和差别方面也是一个有力的工具。

 

1.1 企业连续体子模块

      如前所述，企业连续体子模块被用来对背景性资产进行归整。这些资产可能来源于企业范围以内，也可能位于企业的外部环境之中，例如外界的产品、研究、市场因素、商业因素、业务策略以及法律法规等。虽然TOGAF是一个用于指导企业架构开发的框架，可是在企业连续体中所包含的各类资产却每每超出TOGAF的考虑范畴，而且一个架构的造成又常常被架构实践以外的各类因素所决定，因此如何准确反映外部背景因素是很是重要的。尽管具体的外部背景因素在不一样的架构之间会有很大的差别性，可是一般能够分为以下几类：

• 外部影响因素，例如法规的变化、技术的进步以及竞争者的活动等。
• 业务策略和背景，包括合并、采购以及其余业务转型需求。
• 反映当前已部署的架构和解决方案所构成的业务运营状况。

1.2 架构连续体子模块

      架构连续体描述了各个架构是如何从基础架构（Foundation Architecture）开始，历经通用系统架构（Common Systems Architectures）和行业架构（Industry Architectures），并最终演进为企业自身的组织特定架构（Organization-Specific Architectures）的过程。除了以上这四种分类层次以外，他们之间的双向关系连线也有着很是重要的含义。如图所示，企业和业务的需求以一种详细度渐进的方式从左至右逐级获得知足，而对于架构组建和构建块的重用，企业则须要在架构连续体中自右向左地寻找。若是最终没有寻找到所指望的架构元素，那么对于此缺失的架构元素的需求则以自右向左的方向寻找合适的分类层次。

 

1.2.1 基础架构（Foundation Architecture）

      基础架构是一个包含了一系列构建块和相关标准的架构，这些元素被用来支持通用系统架构以及完备的企业运营环境。The Open Group提供了一个技术参考模型（TRM），它自己就是一个基础架构的良好体现，它描述了一个基本架构，并在此基础之上使得更为具体的架构得以被建立。

1.2.2 通用系统架构（Common Systems Architectures）

      通用系统架构对于从基础架构中选择和整合特定的服务提供了指导，从而为建立跨越多个相关领域的通用解决方案创建了架构。从系统的总体功能角度来看，通用系统架构并不完备，它所包含的架构应该是面对某一个特定领域内的问题，于是实现了其中架构的解决方案为企业功能完备的运营状态的创建提供了可重用的构建块。TOGAF中定义了一个名为集成信息基础设施参考模型（III-RM：Integrated Information Infrastructure Reference Model）做为关注于与无边界信息流（Boundaryless Information Flow）相关的需求、构建块和标准的通用系统架构。除此以外，通用系统架构的特定还包括：

• 反映了针对某个通用问题域的需求。
• 针对某个特定问题域定义构建块。
• 为构建块的实现定义业务、数据、应用或技术标准。
• 提供各类构建块从而方便重用和下降成本。

1.2.3 行业架构（Industry Architectures）

      行业架构对从通用系统组件到特定的行业组件的集成提供了指导，并为在特定行业中为解决目标用户问题而创建解决方案提供了指南。行业架构的其余特性还包括：

• 反映了针对具体行业的需求和标准。
• 为具体行业定义构建块。
• 包含了行业特定的逻辑数据和流程模型。
• 包含了行业特定的应用、流程模型以及业务规则。
• 为系统集合的测试提供指南。
• 提高在整个行业中的互操做水平。

1.2.4 组织特定架构（Organization-Specific Architectures）

      组织特定架构描述并指导了在一个具体企业或相互联系的企业网中针对解决方案组件的最终部署。组织特定架构的其余特性还包括：

• 在全部的四个架构领域中，为对业务运营进行沟通和管理提供方法。
• 反映了对特定企业的具体需求。
• 为一个特定企业定义具体构建块。
• 包含了组织特定的业务模型、数据、应用和技术。
• 为促进适当的解决方案的实现提供了方法，从而知足业务须要。
• 为评测和选择适当的产品、解决方案和服务提供了判别标准。
• 提供一条演进路线来支持业务需求的发展或新的业务需求

1.3 解决方案连续体子模块

      解决方案连续体表明了针对各架构连续体层次中架构的详尽描述和构成。解决方案连续体的每一个分类层次充满了针对相应架构的解决方案构建块，从而表达了在每一个层次用于知足企业业务需求的解决方案。一个基于解决方案连续体并被相关构建块所填充的资源库能够被看做为一个解决方案仓库，它为管理和实施针对企业的改善提供了巨大的价值。与架构连续体相相似，解决方案连续体中除了如图的四种分类层次外，这些分类层次之间的双向关系也一样值得注意：

• 自左向右，解决方案连续体关注于解决方案价值的提供，亦即基础解决方案为建立通用系统解决方案提供价值，系统解决方案被用来为行业解决方案提供价值，而行业解决方案则为组织特定解决方案的创建提供价值。
• 自右向左，解决方案连续体关注于知足企业的需求。

 

1.3.1 基础解决方案（Foundation Solutions）

      基础解决方案包含了高度通用的概念、工具、产品、服务和解决方案组件，这些内容同时也成为了企业能力的根本提供者。举例来说，基础解决方案包括了编程语言、运营系统、基本数据结构、组织结构的通用方法、组织IT运做的基本结构等。

1.3.2 通用系统解决方案（Common Systems Solutions）

      通用系统解决方案是一个针对通用系统架构的实现，它包含了一系列的产品和服务，并表明了在通用系统解决方案所支持的行片断中的一个或多个解决方案的最高级别共性。通用系统解决方案所针对的并非某个特定客户或行业，而是表明了关于通用需求和能力的集合，并为具体业务和信息需求的运行环境提供了组织方式。举例来说，通用系统解决方案能够包括一个企业管理系统产品或一个安全系统产品。

1.3.3 行业解决方案（Industry Solutions）

      行业解决方案是针对行业架构的一个实现，它提供了针对一个特定行业的通用组件和服务的可重用封包。处在基础解决方案中的组件被通用系统解决方案和/或基础解决方案所提供出来，并在行业解决方案中被扩展为行业特定的组件。须要注意的是，在有些状况下，行业解决方案不只包含针对行业架构的实现，还包括了其余解决方案元素，例如特定产品、服务和与行业相适宜的系统解决方案。

1.3.4 组织特定解决方案（Organization-Specific Solutions）

      组织特定解决方案是针对提供了所需业务功能的组织特定架构的一个实现。因为在这里的解决方案是为具体的业务运营而设计的，于是一般它们包含了最大量的独特内容，从而知足各具体组织中形色各异的人员和流程的须要。为了支持各个具体的服务水平协议（SLAs：Service Level Agreements），从而确保在指望的服务水平对运行系统进行支持，组织特定解决方案须要经过一种结构化的方式进行组织。例如，一个第三方应用托管提供商就可能在不一样水平上对运行系统提供支持。另一个定义在企业特定解决方案中的重要元素是关键运行参数和质量指标，这些参数和指标可被用来对企业的运行环境进行管理和监督。

2. 架构划分

      企业连续体对企业中的各个架构和解决方案进行了清晰地概括和组织，但在实践过程当中，基于以下的缘由咱们须要对单个架构和解决方案（或一组相互联系的架构或解决方案）进行进一步的划分，由于：

• 用单一架构来解决全部问题每每比较复杂。
• 不一样的架构之间会产生冲突。例如，因为企业的状态会随时间的推移而发生变化，于是此时此刻还合做良好的两个架构可能会在将来某个时间点发生矛盾。
• 不一样的人员每每在相同的时间点对架构的不一样组成元素进行开发和维护，于是针对架构的划分可使各我的员明确其所负责的架构部分。
• 一个有效的架构重用方式要求模块化的架构分段形式，这些架构片断能够被合并为更大的架构和解决方案。

      在实践中，因为架构的多样性，企业更倾向于选择可以反映其经营模式的架构划分方法（回想一下咱们在前面部分提到过的联邦企业架构中片断架构的概念就是一个架构划分的具体实例），于是创建一个通用的架构划分模型是很是困难的，但TOGAF仍是为架构或解决方案的划分提供了一套分类标准：

• 首先明确架构和解决方案的特性。
• 以某一个特性为基准将其拓展为一个维度（就像画一条以此特性为标尺的坐标轴同样），并将架构在此维度之中进行排列。例如，若是咱们把“时间”这个特性做为一个判别维度，那么某一架构按此维度的排列就造成了此架构的一张路线图。由此咱们也能够看出，架构划分是以架构或解决方案的特性为基础的，并不只是有关构成方面的划分。
• 根据开发或维护目标的不一样，将若干个特性结合起来对架构进行多维度划分。

2.1 解决方案的分类特性

      TOGAF列出了以下几个用于对解决方案进行分类的特性：

• 主题：用于描述一个解决方案的最显而易见的方法就是检视其内容、结构和功能。此外，也可经过检视一个解决方案的边界和与此边界发生交互的全部外部因素来进行描述，例如前置条件、后置条件、使用者、提供者、拥有权、运行以及影响因素等。
• 时间：全部的解决方案都会存在必定的时间，而其主题和所处的环境也可能会随着时间的推移而发生变化，因此明确解决方案的时间属性是一个关键的考虑要素。此外，当描述将来的解决方案时，这一时间属性表明了一个目标实现日期，并被用来对和组织相关变动活动进行规划。
• 成熟度/波动性：用于描述解决方案的主题和其所处环境随着时间推移而发生变化的幅度。这一属性之因此关键是由于针对不成熟或不稳定的解决方案的管理与针对稳定或成熟解决方案的一般是很是不同的，例如易于变化的环境更适合灵活的解决方案的采用。

2.2 架构的分类特性

      从前面的内容中咱们能够了解到架构实际上就是解决方案的一种表现方式，它定义了解决方案的需求，于是在前一部分中对解决方案所定义的特性一样也适用于架构。TOGAF列出了以下几个用于对架构进行分类的特性：

• 主题：架构针对具体的解决方案进行了描述，它自己也继承了其所描述的解决方案的各个客观特性，例如主题、时间和波动性等。
• 视角：架构的领域和所产生的各具体制品在干系人需求的基础上能够展现解决方案的某一个侧面，而这就是就是架构的视角。视角能够是通常性的，也能够针对某一特定的架构领域（业务、数据、应用和技术），亦或是有关其余方面的考虑（例如，安全、运行管理、继承以及施工等）。
• 详细度：一般来说，详细的架构在针对解决方案的支持和指导中会更加有效，而较为简略的架构则在有关解决方案的总体性沟通中更加适合。
• 抽象水平：用于描述架构对其解决方案的描述所采用的抽象层次。例如，某些架构为其相关解决方案提供了直接的描述，而其余的架构则可能描述了一个能够跨越多个解决方案的方法或模式。
• 准确度：因为架构是一个关于现实的表述，于是它也没必要一丝不差地描述目标解决方案。一般来说，在架构建立中所投入资源的水平和质量将会决定架构的准确度。

2.3 结合多个分类特性进行架构划分

      在前面部分中所列出的各个特性为描述、划分架构和解决方案提供了一系列指标维度，而且一旦这些特性被肯定，它们就能够被用来对企业连续体中的内容进行划分和组织，从而造成一系列相互关联的架构和解决方案。通过如此方式的划分，每个架构和解决方案的复杂性将会处于可控范围以内；架构和解决方案的分组得以被定义，而且它们的层次结构和浏览结构也会被定义出来；每一个分组相应的流程、角色和责任也获得了适当的分配。除了做为独立的维度而进行划分以外，在实践过程当中，这些特性每每还会被按照不一样的目标而结合在一块儿，从而对架构和解决方案进行划分。TOGAF列举了一系列组合式架构划分方法，接下来咱们将依次对其进行探讨：

 

 

 

 

 

2.3.1 经过架构情景划分来理解企业状态

      一般来说架构提供了在特定时间点上架构情景（Architecture Landscape）的摘要视图。下列特性则常常被用来对繁复的架构情景进行划分：

• 主题：主题域一般是对架构情景描述进行组织的主要特性，而架构在功能上也会被分解为由各具体主题域所组成的层次结构。
• 详细度：对于范围比较广阔的主题域来讲，较为简洁的详细度被用来确保架构具有可管理的规模和复杂度，而更加具体的主题域一般须要更为详细的架构。
• 时间：对于特定的主题和详细度来讲一个企业能够建立一个基线架构和一系列目标架构。一般来说，范围广阔并具有较低详细度的架构将在较长的时间中有效，并为企业提供一个将来的愿景。
• 视角：对于特定的主题域、详细度和时间区域来说，架构的干系人将会站在各自的角度针对各自的问题来对架构进行审视。
• 准确度：每一个架构视图在开发过程当中将会逐步加强其准确度，而若是不经妥善维护这些视图在被正式批准以后其准确度也会逐步下降。

      以上这些特性能够被结合在一块儿来对架构进行划分，但他们一样能够对解决方案连续体中的内容进行划分。须要注意的是，以下的特性一般不会用在针对架构情景的划分中：

• 用于描述架构情景的架构一般不是抽象的。
• 解决方案的波动性一般会限制架构对长期的将来进行定义，同时波动性也会随时间的推移而削减架构的准确度。

 

2.3.2 对参考模型进行划分来促进优良的实践和重用

      有些描述解决方案、最佳实践或模式的架构能够做为参考模型在整个企业内部进行共享。下列的特性一般被用来对这些架构参考模型进行划分：

• 抽象水平：因为参考模型的目标就是成为能够在多种环境下使用的抽象且可重用的解决方法，于是抽象水平能够说是一个对参考模型进行组织的良好切入点。
• 主题：在必定的抽象水平之下，相互关联的模型能够用来对应某个特定的主题，于是从主题入手的划分能够方便针对架构的参考和引用。
• 视角：对于任何一个给定的主题，一系列参考模型能够从各类相互补足的视角来对主题进行描述，而且相关的视角也能够被组织起来为所指望的解决方案方法提供一个更加全面的了解。

      一般状况下，下列特性将不会被用在针对参考模型的划分中：

• 参考模型一般是针对某一个特定问题的，而且其所采用的详细度水平也与其描述的解决方法相适合，于是参考模型一般也并不会被分解为具备更高详细度的部件。
• 准确度和成熟度。
• 因为参考模型是抽象的且不会与部署的解决方案有着显式的绑定关系，于是时间特性与其并不相关。

      借助于上述特性，参考模型能够被划分为以下四种类别：

• 基础架构：此种类型的参考模型抽象层次最高，于是能够适用于全部企业架构或解决方案。
• 通用系统架构：展现了适用于多个企业和行业的通用系统的模式和方法，例如企业资源规划（ERP）系统。
• 行业架构：提供了能够适用于一个行业中多个合做伙伴或竞争对手的共享蓝图。
• 组织特定架构：提供了为一个企业特制的通用参考模型，但这些参考模型也仍是能够跨越多个业务领域的。

 

2.3.3 经过标准合规来执行企业策略

      各个组织一般经过定义并推行一系列标准来对其所指望的方法进行鼓励，而下列的特性能够被用来对架构中的标准进行划分：

• 视角：因为标准的意图在于对整个企业中推行一致性的行为，因此在一般状况下，标准会采用一种会涵盖多个领域的“水平”视角来做为标准划分的基础。业务、数据、应用和技术这几个架构领域是常常会被用到的标准划分切入点，固然诸如安全这样的特定视角也是能够独立存在的。
• 主题：在一个特定的视角之下能够经过标准所涉及的主题来对相关标准进行分组。
• 成熟度/波动性：标准的成熟度能够被用来决定其在生命周期中的状态。

      一般状况下，下列特性将不会被用在针对标准的划分中：

• 标准的使用关乎于其成熟度，而对于时间区间并无特定的关联。
• 标准须要被定义得足够详细，从而使得对其进行合规性评估成为可行，因此一般对于标准在详细度层面进行划分是没必要要的。
• 标准一般须要足够具体才能对其进行合规性评估，于是对于标准在抽象水平层面进行划分是没必要要的。
• 标准应该是准确的，于是对于标准在准确度层面进行划分是没必要要的。

      借助于上述特性，架构标准能够被划分为以下四种类别：

• 业务标准：此种类型标准与业务架构领域的实践相关联，包括标准的流程、角色、责任和组织模型等。
• 数据标准：此种类型标准与数据架构领域的实践相关联，包括标准的数据模型、数据治理模型等。
• 应用标准：此种类型标准与应用架构领域的实践相关联，包括标准的应用、应用类型和应用功能等。
• 技术标准：此种类型标准与技术架构领域的实践相关联，包括标准的产品、产品类型和与技术的正当使用相关的约束。

 

2.4 架构划分与架构开发方法

      架构的划分使得单一架构或解决方案的规模和复杂程度可以处在一个可管理的水平，而且在开发和维护过程当中，具备不一样职责的人员能够并行工做，从而提高对最终片断架构所进行的整合工做的效率。架构开发方法是TOGAF提出的一个关于企业架构开发的指导性流程，而该流程也正是架构划分的用武之处：

• 预备阶段支持对架构的适当划分进行明确，以及在相关架构分块间治理关系的确立。
• 在架构愿景阶段到迁移规划阶段这一过程当中，架构开发方法使得各个架构分块中的架构内容得以被定义。
• 在实施治理阶段和架构变动管理阶段中，架构在其实现过程当中得以被有效地治理。这一治理能够被应用到解决方案的直接实现之上，也能够处理在其余架构分块中开发的架构的治理。