又回头看了之前文章的评论,本人也同样感慨这些文章的确像政治课本般的虚无缥缈,所以对费力看完却觉得无从下手的看官致以诚挚的歉意和理解,因为这个问题也同样困扰着笔者本人,而我能做的也只能是纸上谈兵。之前也接触过国家某大型公司的企业架构建设项目,采用的也是TOGAF标准,但是要将其作为例子罗列出来,实在是件伟大的工程,而且本人也真没接触这么多项目内容,无法列举示例还请见谅。就笔者本人的理解,是否符合TOGAF的判定标准主要是企业架构的建设过程是否遵循企业架构开发方法(ADM),至于后面的内容框架(架构制品、交付物和构建块等)并不是决定是否遵循TOGAF的绝对判定标准,其内容也是综合了众多组织经验的抽象之谈,所以过于理论化无可避免。本系列的本意还是还原标准文本,尽力进行普及,虽翻译、理解能力有限,亦希望能纠当前众多中文资料中不负责任的谬误(见开篇的几篇文章就可了解我写本系列的用意)。至于如何掌握这门技术,需要各看官有机遇参与相关项目,于实践中融会贯通,到时这些枯燥的理论应该会助各位一臂之力。不管怎么说,企业架构真的很复杂枯燥,甚至是否应该建设或者其建设到底有多大用处目前还没有谁能有个肯定且量化的回答,笔者读了几年资料并参与了一个相关项目,也能是纸上谈兵,不过作为一个未来方向(笔者自认),能对其有点了解也是好的,毕竟不是具体的软件技术,可以在短时间学以致用,并且也有大把机会可以去实践锻炼。本来打算终止写作TOGAF方面的内容,提早开始写企业架构建模和分析方面的内容,因为这个方面内容例子多了很多,看起来也轻松很多,不过终不想半途而废,还请诸看官耐心一点,并希望有经验的看客对笔者给予指正。
从字面上看企业架构好像是一个独立且包罗万象的架构,但是这种看似能解决所有问题的单一架构却往往只能存在于理想之中。在实践中,一个企业架构应该是由若干具有不同目标的架构所组成的。这些架构具有着各不相同的背景,并因为不同的目标而被创建出来,并且通过这些架构之间的关联关系而形成了一个可以解决各干系人需求的有机整体,亦即企业架构。既然企业架构是由这么多个子架构所组成,那么一个关系混乱且相互冗余的架构构成情况是不能被称之为良好的企业架构的,因而如何界定这些架构的范围对于企业架构的成功与否有着重要意义。在这个方面TOGAF提出了企业连续体(Enterprise Continuum)的概念,用以对企业内外存在的各种架构制品进行分类,并为企业内以及企业与外部的客户和厂商进行架构方面的沟通提供了基点。除此此外,TOGAF还提出了一系列架构划分的原则和方法,从而使得针对企业架构的创建和维护工作的复杂度得以被有效地控制(因为企业架构是为了达成不同干系人的需求而制定的,且干系人及其需求之间的差异性也非常大,所以企业架构所面对的问题域必将是非常复杂的)。在本章的后半部分,我们还将对用于储藏和管理各个架构的架构资源库的组织方式进行阐述,并对用于生成和维护企业架构的自动化工具的选择标准进行了描述。
如前所述,企业架构并不是一个单一的架构,而是由多个具有各自背景且面向不同目标的子架构所组成的,这些子架构或存在于企业之中亦或来源于企业之外,它们包括了架构描述、模型、构建块、模式、视角以及其他的架构制品。举例来讲,对于存在于企业内部的架构制品来说,包括了在之前的架构工作中所产出的各种交付物,而对于外部的制品来说,则包括了各行业中的各种参考模型和架构模式等,例如在TOGAF中定义的具有高度广泛性的技术参考模型(TRM:Technical Reference Model)、IT领域中某一具体方面的架构(例如Web服务架构)、与特定信息处理类型相关的制品(例如,电子商务、供应链管理等),以及与特定行业相关的制品(例如电信业的TMF、零售业的ARTS以及石化行业的Energistics)。面对如此纷繁复杂的架构以及更为繁复的架构间关系,企业必须通过一种合理的分类方法来对他们进行组织和界定,从而使他们成为一个协调的有机整体,而这正是企业连续体的用武之地。简单的讲,企业连续体可以看作是用来对所有架构资产进行存储的资源库(架构资源库,其详细介绍请参阅后面的部分)的一个视图,其目标即是对企业内外的各种架构和解决方案制品进行分类。
虽然企业连续体是一个有关架构分类的方法,但是我们不能把它简单地看作是一个静态的分类法。无论是从字面上,还是从企业架构本身的动态特性来看,企业连续体也是一个针对各个架构制品的动态分类方法,它展示了架构制品是如何从通用的“基础架构”分类层次演进到“组织特定架构”这一分类层次。虽然这看起来像是一个由抽象到具体的架构演进过程,但是我们不能过分强调其动态性而忽略了其分类法的本质,一个架构并不是一定要经历这一演进过程,其本身的特性还是决定其所处分类层次的决定因素。除此之外,我们还要注意的是这个分类法的动态特性不是单向的,一个架构可以由较为通用的分类层次出发经由整合和定制来达到符合各组织特点且更为具体的特化分类层次,同时一个经过长时间考验并在较大范围内得到认同的架构则可以被提升到一个更为通用的分类层次之中,而这也正是TOGAF所以一直强调的“重用”精神的体现。此外,正是由于这个分类法对架构和解决方案制品所进行的分类和规整,企业连续体为在企业内外进行关于架构的理解和沟通提供了基准点,使得企业在内部以及与外部客户和合作团队进行架构交流时,能够明确目标架构所处的分类层次和相应的特性,从而避免南辕北辙式地探讨。由此可见,企业连续体同时也是一个针对架构进行理解和沟通的有力工具。
作为TOGAF中的一个重要内容,与其他关键部分一样,企业连续体与TOGAF的核心内容,亦即企业架构开发方法,有着紧密关系。企业架构开发方法所描述的是一个开发组织特定的架构,以及与此架构相关的解决方案的过程,并且这一过程的实现通常是要借助于针对通用架构和解决方案的采用和定制,而这样一个由“通用”到“特有”的过程与企业连续体的精神是一致的。此外,企业架构开发方法不仅提倡针对可重用构建块的利用,它同时还指导着新的可重用资源的发掘,而在企业连续体中那些被证明是通用的架构也是可以被划入到通用性更高的层次之中。由此可见,企业架构开发方法为架构的开发和维护提供了手段,而企业连续体则为其结果提供了组织机制。除此之外,企业连续体各分类层次中的资源对架构开发方法的各个阶段具有重要的帮助作用,例如在技术架构的开发中,TOGAF的技术参考模型即具有着指导意义,而在业务架构的开发中,一个关于电子商务的参考模型也可能具有同样的帮助作用,这同时也与企业架构的资源重用精神是相符合的。
企业连续体是由三个界限清晰的模块所构成的,即“企业连续体(Enterprise Continuum,此部分名称虽与其整体名称相同,但在这里指的是一个独立的子部件)”、“架构连续体(Architecture Continuum)”和“解决方案连续体(Solutions Continuum)”,他们之间的关系,以及企业连续体与企业资源库之间的关系展示如下:
如图所示,外部存在的各种架构驱动因素被企业连续体子模块所归整,并形成各架构的开发背景和需求。接下来,这些背景元素及需求推动了相应架构的形成,而在此过程中,架构连续体子模块可被用来为企业资源库所包含的各个相关架构资产提供组织结构和分类方法。当架构被定义并组织好之后,位于架构连续体中的各个架构被用来指导和支持相关解决方案的创建,而在此过程中,解决方案连续体子模块被用来对存储于企业资源库中的各解决方案资源进行分类和组织。最后,各解决方案被部署到企业的运营环境之中,并成为新的企业架构背景的组成部分。由此可见,企业连续体的三个子模块被完美地契合入整个企业架构生命周期中(自外部驱动因素的识别开始到最终解决方案的部署),并从架构和解决方案两个主要层面对企业资源库中的资源进行归类和组织。企业连续体的三个子模块的定义如下,并且在后面的部分中我们将对他们的内容进行更加详尽地阐述:
如前所述,企业连续体子模块被用来对背景性资产进行归整。这些资产可能来源于企业范围之内,也可能位于企业的外部环境之中,例如外界的产品、研究、市场因素、商业因素、业务策略以及法律法规等。虽然TOGAF是一个用于指导企业架构开发的框架,但是在企业连续体中所包含的各种资产却往往超出TOGAF的考虑范畴,并且一个架构的形成又经常被架构实践之外的各种因素所决定,所以如何准确反映外部背景因素是非常重要的。尽管具体的外部背景因素在不同的架构之间会有很大的差异性,但是通常可以分为如下几类:
架构连续体描述了各个架构是如何从基础架构(Foundation Architecture)开始,历经通用系统架构(Common Systems Architectures)和行业架构(Industry Architectures),并最终演进为企业自身的组织特定架构(Organization-Specific Architectures)的过程。除了以上这四种分类层次之外,他们之间的双向关系连线也有着非常重要的含义。如图所示,企业和业务的需求以一种详细度渐进的方式从左至右逐级得到满足,而对于架构组建和构建块的重用,企业则需要在架构连续体中自右向左地寻找。如果最终没有寻找到所期望的架构元素,那么对于此缺失的架构元素的需求则以自右向左的方向寻找合适的分类层次。
基础架构是一个包含了一系列构建块和相关标准的架构,这些元素被用来支持通用系统架构以及完备的企业运营环境。The Open Group提供了一个技术参考模型(TRM),它本身就是一个基础架构的良好体现,它描述了一个基本架构,并在此基础之上使得更为具体的架构得以被创建。
通用系统架构对于从基础架构中选择和整合特定的服务提供了指导,从而为创建跨越多个相关领域的通用解决方案建立了架构。从系统的整体功能角度来看,通用系统架构并不完备,它所包含的架构应该是面对某一个特定领域内的问题,因而实现了其中架构的解决方案为企业功能完备的运营状态的建立提供了可重用的构建块。TOGAF中定义了一个名为集成信息基础设施参考模型(III-RM:Integrated Information Infrastructure Reference Model)作为关注于与无边界信息流(Boundaryless Information Flow)相关的需求、构建块和标准的通用系统架构。除此之外,通用系统架构的特定还包括:
行业架构对从通用系统组件到特定的行业组件的集成提供了指导,并为在特定行业中为解决目标用户问题而建立解决方案提供了指南。行业架构的其他特性还包括:
组织特定架构描述并指导了在一个具体企业或相互联系的企业网中针对解决方案组件的最终部署。组织特定架构的其他特性还包括:
解决方案连续体代表了针对各架构连续体层次中架构的详尽描述和构成。解决方案连续体的每个分类层次充满了针对相应架构的解决方案构建块,从而表达了在每个层次用于满足企业业务需求的解决方案。一个基于解决方案连续体并被相关构建块所填充的资源库可以被看作为一个解决方案仓库,它为管理和实施针对企业的改善提供了巨大的价值。与架构连续体相类似,解决方案连续体中除了如图的四种分类层次外,这些分类层次之间的双向关系也同样值得注意:
基础解决方案包含了高度通用的概念、工具、产品、服务和解决方案组件,这些内容同时也成为了企业能力的根本提供者。举例来讲,基础解决方案包括了编程语言、运营系统、基本数据结构、组织结构的通用方法、组织IT运作的基本结构等。
通用系统解决方案是一个针对通用系统架构的实现,它包含了一系列的产品和服务,并代表了在通用系统解决方案所支持的行片段中的一个或多个解决方案的最高级别共性。通用系统解决方案所针对的并不是某个特定客户或行业,而是代表了关于通用需求和能力的集合,并为具体业务和信息需求的运行环境提供了组织方式。举例来讲,通用系统解决方案可以包括一个企业管理系统产品或一个安全系统产品。
行业解决方案是针对行业架构的一个实现,它提供了针对一个特定行业的通用组件和服务的可重用封包。处在基础解决方案中的组件被通用系统解决方案和/或基础解决方案所提供出来,并在行业解决方案中被扩展为行业特定的组件。需要注意的是,在有些情况下,行业解决方案不仅包含针对行业架构的实现,还包括了其他解决方案元素,例如特定产品、服务和与行业相适宜的系统解决方案。
组织特定解决方案是针对提供了所需业务功能的组织特定架构的一个实现。由于在这里的解决方案是为具体的业务运营而设计的,因而通常它们包含了最大量的独特内容,从而满足各具体组织中形色各异的人员和流程的需要。为了支持各个具体的服务水平协议(SLAs:Service Level Agreements),从而确保在期望的服务水平对运行系统进行支持,组织特定解决方案需要通过一种结构化的方式进行组织。例如,一个第三方应用托管提供商就可能在不同水平上对运行系统提供支持。另外一个定义在企业特定解决方案中的重要元素是关键运行参数和质量指标,这些参数和指标可被用来对企业的运行环境进行管理和监督。
企业连续体对企业中的各个架构和解决方案进行了清晰地归纳和组织,但在实践过程中,基于如下的原因我们需要对单个架构和解决方案(或一组相互联系的架构或解决方案)进行进一步的划分,因为:
在实践中,由于架构的多样性,企业更倾向于选择能够反映其经营模式的架构划分方法(回想一下我们在前面部分提到过的联邦企业架构中片段架构的概念就是一个架构划分的具体实例),因而建立一个通用的架构划分模型是非常困难的,但TOGAF还是为架构或解决方案的划分提供了一套分类标准:
TOGAF列出了如下几个用于对解决方案进行分类的特性:
从前面的内容中我们可以了解到架构实际上就是解决方案的一种表现方式,它定义了解决方案的需求,因而在前一部分中对解决方案所定义的特性同样也适用于架构。TOGAF列出了如下几个用于对架构进行分类的特性:
在前面部分中所列出的各个特性为描述、划分架构和解决方案提供了一系列指标维度,并且一旦这些特性被确定,它们就可以被用来对企业连续体中的内容进行划分和组织,从而形成一系列相互关联的架构和解决方案。经过如此方式的划分,每一个架构和解决方案的复杂性将会处于可控范围之内;架构和解决方案的分组得以被定义,并且它们的层次结构和浏览结构也会被定义出来;每个分组相应的流程、角色和责任也得到了适当的分配。除了作为独立的维度而进行划分之外,在实践过程中,这些特性往往还会被按照不同的目标而结合在一起,从而对架构和解决方案进行划分。TOGAF列举了一系列组合式架构划分方法,接下来我们将依次对其进行探讨:
通常来讲架构提供了在特定时间点上架构情景(Architecture Landscape)的摘要视图。下列特性则经常被用来对繁复的架构情景进行划分:
以上这些特性可以被结合在一起来对架构进行划分,但他们同样可以对解决方案连续体中的内容进行划分。需要注意的是,如下的特性通常不会用在针对架构情景的划分中:
有些描述解决方案、最佳实践或模式的架构可以作为参考模型在整个企业内部进行共享。下列的特性通常被用来对这些架构参考模型进行划分:
通常情况下,下列特性将不会被用在针对参考模型的划分中:
借助于上述特性,参考模型可以被划分为如下四种类别:
各个组织通常通过定义并推行一系列标准来对其所期望的方法进行鼓励,而下列的特性可以被用来对架构中的标准进行划分:
通常情况下,下列特性将不会被用在针对标准的划分中:
借助于上述特性,架构标准可以被划分为如下四种类别:
架构的划分使得单一架构或解决方案的规模和复杂程度能够处在一个可管理的水平,并且在开发和维护过程中,具有不同职责的人员可以并行工作,从而提升对最终片段架构所进行的整合工作的效率。架构开发方法是TOGAF提出的一个关于企业架构开发的指导性流程,而该流程也正是架构划分的用武之处: