TOGAF企业连续体和工具之企业连续体构成及架构划分
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提出的一个关于企业架构开发的指导性流程，而该流程也正是架构划分的用武之处：
- 预备阶段支持对架构的适当划分进行明确，以及在相关架构分块间治理关系的确立。
- 在架构愿景阶段到迁移规划阶段这一过程中，架构开发方法使得各个架构分块中的架构内容得以被定义。
- 在实施治理阶段和架构变更管理阶段中，架构在其实现过程中得以被有效地治理。这一治理可以被应用到解决方案的直接实现之上，也可以处理在其他架构分块中开发的架构的治理。
最新文章
- Python3 登陆网页并保持cookie
- Dependency Scope
- sdk墙内更新方法
- python3.4学习笔记(十三) 网络爬虫实例代码，使用pyspider抓取多牛投资吧里面的文章信息，抓取政府网新闻内容
- fiddler 挂载 JS文件
- VC++、MFC、COM和ATL的区别
- 使用JQuery Mobile实现手机新闻浏览器
- Object-C 类实现
- android 自定义Toast显示风格
- 面向对象程序设计-C++ Inheritance & Multiple inheritance & RTTI【第十三次上课笔记】
- USACO Longest Prefix 【水】
- Qt 多线程与数据库操作需要注意的几点问题
- Linux文件系统的目录结构
- Lucene的配置及创建索引全文检索
- codesforces 671D Roads in Yusland
- offsetLeft、offsetX等
- 解决nginx reload失败
- 英语笔记-some words about description of girl
- Tomcat 异常关闭排查
- C++学习---指针相关