快捷搜索:  汽车  科技

togaf 系统架构(TOGAF学习比较知识点精要)

togaf 系统架构(TOGAF学习比较知识点精要)& Content Framework):是 TOGAF 的核心部分,它包含了两个方面的内容。其一,架构开发方法是 TOGAF 针对企业架构建设方法的论述,它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤,并对每个步骤的输入、输出以及所采用方法都进行了详尽的阐述;其二,作为的内容框架部分,它针对企业架构中所包含的各种工作产品以及他们之间的关系作出了详细的描述。2、 TOGAF 架构开发方法和内容框架(TOGAF ADM(Architecture Development Method)TOGAF 所包含的各种企业架构相关方法与工具在企业的业务愿景、驱动力和业务能力之间建立起了一座沟通的桥梁,促进企业业务能力的实现和发展,而且经过长期的运营,企业的业务能力又为企业的业务愿景反馈了新的需求和发展推动力。TOGAF 内容分为:1、 TOGAF 能力框架(TOGAF C

第1章 企业架构开发方法(ADM)概述1.1 认识 TOGAF

TOGAF(The Open Group Architecture Framework)起源于美国国防部的信息管理技术架构框架(TAFIM,Technical Architecture Framework for Information Management),在获得美国国防部的允许之后,借助美国政府大笔资金投入,并经过多年的探索后,最终于 1995 年发布了 TOGAF 1。发展至今 TOGAF 已经发布到了第九个版本,即 TOGAF 9(目前最新的版本是 2011 年发布的 TOGAF 9.1)。

TOGAF 是众多企业架构框架理论中的一种,它为一个企业或组织对于企业架构的接受、

创建、使用和维护提供了一系列辅助方法和工具。同时,TOGAF 还是一个基于迭代过程模型的企业架构框架理论,支持该过程模型的重要基础是全球最佳实践,以及一系列可重用的现有企业资产。总的来说,TOGAF 的内容涵盖了企业架构生命周期中的方方面面,尤其是通过在 2009 年发布的第九版中引入了内容框架,在有关架构内容描述和指导方面填补了以往的空白。在 TOGAF 9 中,The Open Group 将 TOGAF 的各部分内容以及他们之间的关系通过如下的示意图进行了表述:

togaf 系统架构(TOGAF学习比较知识点精要)(1)

图表 TOGAF 内容结构图

TOGAF 所包含的各种企业架构相关方法与工具在企业的业务愿景、驱动力和业务能力之间建立起了一座沟通的桥梁,促进企业业务能力的实现和发展,而且经过长期的运营,企业的业务能力又为企业的业务愿景反馈了新的需求和发展推动力。

TOGAF 内容分为:

1、 TOGAF 能力框架(TOGAF Capability Framework):为了在一个企业中有效地操作企业架构并使其发挥最大的效能,需要定义一系列适当的组织结构、流程、技能、角色和责任,并将它们进行结合。TOGAF 的能力框架为如何组织好组织结构、流程、技能、角色和责任提供了指南。

2、 TOGAF 架构开发方法和内容框架(TOGAF ADM(Architecture Development Method)

& Content Framework):是 TOGAF 的核心部分,它包含了两个方面的内容。其一,架构开发方法是 TOGAF 针对企业架构建设方法的论述,它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤,并对每个步骤的输入、输出以及所采用方法都进行了详尽的阐述;其二,作为的内容框架部分,它针对企业架构中所包含的各种工作产品以及他们之间的关系作出了详细的描述。

3、 TOGAF 企业连续序列和工具(TOGAF Enterprise Continuum and Tools):企业连续序列是企业架构资源库的一张视图,它为企业中的各种架构和解决方案制品提供了一种分类和组织的方法。企业架构过程是一个动态的过程,因而这一针对工作制品进行组织分类的方式也不仅仅是一个静态方法,还是一种能够随着企业架构演进而变化其分类方式的动态方法。在此方法的视角中,随着企业架构的演进发展,其内容也从通用走向特化,其详细程度也由简略转为详细,而随着实践的积累,原来特化的架构或解决方案制品也可能成为在更广泛范围内通用制品。除此之外,该部分内容还提供了几个用于帮助企业架构建设的参考模型以及其他的一些辅助工具。

上述三个部分的内容相对比较独立,其中能力框架方面的内容着重于帮助企业更好地使用企业架构,架构开发方法和内容框架着重于帮助企业提高其企业架构建设和维护过程的标准化水平和执行效率,而企业连续序列以及各种方法工具则更关注于为企业在企业架构的开发、使用和维护过程中提供参考和最佳实践。虽然这三个部分相对独立,但是一个优良的企业架构的创建、使用和维护是他们三者紧密配合、相互作用的结果。不过作为一个开放且灵活的企业架构框架标准,TOGAF 并不要求所有引入它的企业都必须一个不漏的照搬这三个部分的内容,而是可以根据各自的需要选择相应的部分进行采用,即便是已经建立了企业架构的组织(哪怕他采用别的框架理论来创建其企业架构)也可以将 TOGAF 中的内容与当前企业架构进行融合。

1.1.1 现有的企业架构框架

1.1.1.1 Zachman 框架

Zachman 框架起源于 John Zachman 先生在 1987 年完成的那篇著名的信息系统架构论文

(《A framework for information systems architecture》 ),并一直发展至今。在这篇论文中 Zachman 先生以修建房屋为例从两个维度将与信息系统架构设计相关的各种元素归纳到如下表格之中:

表格中的每一行代表了在信息系统构造过程中所涉及到的不同的干系人在描述信息系统时所采用的视角,具体表述:

1、 范围/规划师(Planner):包括整个信息系统描述所处的环境上下文、产生于内部与来源于外部的各种约束,以及其他视角下对信息系统的描述所需要考虑的相关构成部分的列表。

2、 业务模型/拥有者(Owner):有关最终产品的概念视图,反映了最终产品的使用特性,即用户准备如何对最终产品加以使用。具有此视角的干系人包括最终产品的客户或用户。

3、 系统模型/设计师(Designer):有关最终产品的逻辑视图,反映了最终产品的本质规律以及逻辑约束。具有此视角的干系人包括工程师、架构师以及能够将期望所得与现有的物理、技术上的实现联系起来的各种中间人。

4、 技术模型/建造者(Builder):反映了在产品构建过程中现有技术的物理约束。具有此视角的干系人包括制造工程师、总承包商以及具有生产最终产品所需的技术能力的组织或人员。

5、详细表述/分包者(Sub-Contractor):关于为了达到生产目的而对复杂对象进

行分解的详细描述,这些内容在从设计媒介到最终产品媒介的转换中起着非常重要的作用。例如,用于将技术模型中所阐述的技术约束与供应商为所提供的产品联系在一起的产品规格说明。

6、产品/运行中的企业(Functioning Enterprise):在 1987 年的论文(《A framework for information systems architecture》)中并没有这一行的内容,实际上此行的内容也并不在架构描述的范畴的之内,不过为了使得架构 Zachman 框架对于架构的表述更加完备,这一行最终还是被加了进去。这一行的内容代表了最终产品,是架构在客观现实中的实例体现。例如,对信息系统架构来说,此行的内容就是最终产出的信息系统,同理,对于企业架构来说,这一行所代表的就是运行中的企业本身。简而言之,前面五行的内容是对于客观对象的描述,而这最后一行的内容就是客观对象本身了。

表格中的每一列代表了用于描述信息系统的某一个方面。在 Zachman 先生看来,对于任何一个事物只要在几个基本方面对其进行清晰的解释就足将其描述清楚,而且几千年来人类自然语言的特性也证明了这一结论。这些方面包括:

1、 数据(What,即什么内容):用于表示客观对象的材料组成,即材料清单。对于企业来说,此部分内容就是组成事物模型(Thing Model,之所以将其称为组成事物模型而不是数据模型是因为由于不同的行代表了不同的视角,而仅在设计师所处的第三行才会关注真正信息化意义上的"数据模型",因而在此才使用"组成事物"来对所有视角在此列中的描述对象进行指代)。

2、 功能(How,即如何工作):用于表示功能和转换行为。对于企业来说,这部分内容就是流程或功能模型等。

3、 网络(Where,即何处):用于表示各组成部件的坐落位置以及相互之间的联通关系。对于企业来说,这部分内容就是物流或网络模型等。

4、 人(Who,即何人负责):用于描述了何人应该做何事,例如用户手册和操作说明等。对于企业来说,这部分内容就是人力模型或工作流模型等。

5、 时间(When,即什么时间):用于描述事物发生的时间以及不同事物之间的相对时间关系,例如生命周期和时序图等。对于企业来说,这部分内容就是时间或动态模型等。

6、 原因(Why,即为什么做):用于表示最终结果和意义。对于企业来说,这部分内容就是动机模型等。

1.1.2 TOGAF 发展

togaf 系统架构(TOGAF学习比较知识点精要)(2)

1.2 架构开发方法(ADM)

架构开发方法(ADM,Architecture Development Method)为开发企业架构所要执行各个步骤以及他们之间的关系进行详细的定义,同时它也是 TOGAF 规范中最为核心的内容。一个组织中企业架构的发展过程可以看成是其企业连续序列从基础架构开始,历经通用基础架构和行业架构阶段而最终达到组织特定架构的演进过程,而在此过程中用于对组织开发行为进行指导的正是架构开发方法。由此可见,架构开发方法是企业连续序列得以顺利演进的保障,而作为企业连续序列在现实中的实现形式或信息载体,企业架构资源库也与架构开发方法有着千丝万缕的联系。企业架构资源库为架构开发方法的执行过程提供了各种可重用的信息资源和参考资料,而企业架构开发方法中各步骤所产生的交付物和制品也会不停地填充和刷新企业架构资源库中的内容,因此在刚开始执行企业架构开发方法时,各个企业或组织常常会因为企业架构资源库中内容的缺乏和简略而举步维艰,但随着一个又一个架构开发循环的持续进行,企业架构资源库中的内容将日趋丰富和成熟,从而企业架构的开发也会越发明快。

togaf 系统架构(TOGAF学习比较知识点精要)(3)

架构开发方法(ADM)建立在一个循环迭代的模型基础之上,并且 TOGAF 还通过定义一系列按指定顺序排列的阶段和步骤来对这一迭代过程进行了更加详尽和标准的描述。不过需要注意的是,这一迭代过程中所包含的各个阶段以及每个阶段所包含的各个实施步骤并不是绝对不变的;鉴于 TOGAF 本身的开放性和灵活性,针对架构开发方法中各步骤的执行也具备着很高的灵活性,而这一灵活性通常表现为:

1、 TOGAF 并不排斥组织中对其他企业架构框架理论的引入和使用,因而在多个企业架构框架同时并存的情况下,企业架构开发方法各阶段的输入和输出可以不完全按照 TOGAF企业架构开发方法(ADM)的定义,换可以采用适合组织自身情况的其他框架中所定义的相关内容。

2、 企业架构开发方法中各阶段之间的先后顺序也并不是绝对的,各组织可以按照自己的实际情况进行适当的修改。

3、 由于各组织的规模和特性千差万别,因而他们对企业架构开发方法的适应程度也各不相同。对于一个中小型企业来讲,如果严格按照上述架构开发方法的阶段定义来执行,其繁琐程度可能会将人们的热情迅速冷却,因而针对企业架构开发方法进行适当的裁剪并使其符合组织自身情况对于各个组织来讲是非常必要的。

4、 架构开发是一个循环迭代的过程,但是并不意味着每次循环都要走完图中所有的步骤,而且如果必要的话,在任何一个步骤的执行过程中都可以根据遇到的情况而开展一个新的循环过程。

企业架构开发方法为组织中企业架构的开发制定了一个循环迭代的流程,并且随着每个架构开发循环过程的完成,组织中企业架构的范围以及交付物的深度和广度都得以演进,但对于企业架构范围的决定却应独立于这一企业架构开发方法的执行过程。在每一次架构开发方法迭代过程开始之前,组织都需要针对如下几点进行考虑:

1、 组织将要在什么范围内进行架构定义和建设?

2、 需要采用何种详细度进行架构描述?

3、 需要建设的企业架构的目标时间区间是什么?

4、 所能够使用的架构资产(包括上次迭代过程中产生的各种架构资产以及存在于组织外的行业通用资产)都有哪些?

以上四个要点制约着企业架构以及相关架构活动的范围。理论上来将,为整个组织的方方面面进行全面的建模是企业架构的终极目标,而在现实生活中如此理想的目标往往会成为不可能的任务,而更加理性的做法应该是立足于当前的状况对每次架构工作的范围进行约定,并通过一次次的工作迭代逐步丰富企业架构内容的深度和广度,从而逐渐接近于理想状态。这种方式对于结构复杂的大型组织来说尤为重要,这种组织往往是由若干业务单元通过联邦的方式组合而成,而在这种情况下一个有效的企业架构过程应该是对架构的范围和活动进行明晰的划分,并在最后进行有效的整合的过程(美国联邦政府的FEA 就是一个很好的例子,虽然具有着独特的架构建设和维护方法,但是在如何应对繁杂组织的复杂度方面,其与 TOGAF 有着相通的见解)。总的来说,TOGAF 的企业架构开发方法的基础是对企业架构的范围进行适当限定和定义,而这些限定和定义的方面包括:

1、 企业范围或着眼点:用于表述企业的整体范围,以及架构活动所涵盖的范围。

2、 架构领域:一个完备的架构描述需要涵盖四个架构领域中的内容,即业务、数据、应用和技术,而这也正是限定架构内容范围的维度之一。

3、 详细度:用于表述架构内容的详细程度,即何种程度的架构描述才是足够的。

4、 时间段:用于表述架构愿景所描述的是在未来哪个时间段的目标,以及此目标是否可以在指定的详细度上被描述清楚,如果不能则需要对中间过渡状态进行制定,并且对每个过渡状态的描述所采用的详细度应符合指定的需要。

一般来讲,企业架构范围的定义和限定首先需要明确企业范围或着眼点、详细度和时间段这三个方面。在这三个方面被确定之后,组织需要根据所面对的问题开展针对各种架构领域的选择和组合,从而实现针对企业架构范围的最终确定。需要注意的是,之所以架构范围需要被限定,是因为现实中的资源不是无限的,这些限制一般包括如下方面:

1、 架构开发团队的权力有一定限制。

2、 企业中不同角度的干系人的关注点千差万别。

3、 人力、资金等资源的限制。

综上所述,企业架构开发方法是一种非常灵活的架构开发指导方法,任何组织不论其身处何种行业或是具备什么样的规模都可以将其作为指导自身企业架构建设的方法。需要注意的是,企业架构开发虽然能够指导企业架构的建设,但是企业架构的范围则需要组织自身根据实际情况来进行定义和限定,也只有这样才能让企业架构开发方法的进行得以处在一个现实可行的环境当中。那企业架构方法具体如何进行呢?为了解答这个问题,本节随后的内容将会对企业架构开发方法的各阶段和步骤进行详细描述。

第2章 预备阶段

togaf 系统架构(TOGAF学习比较知识点精要)(4)

2.1 目标

1、 对进行企业架构活动的组织的背景和环境进行审查。

2、 明确企业架构的赞助人,以及其他将被创建企业架构这项业务指令所影响的主要干系人,并确定他们的需求和优先级、他们与组织的关系,以及他们之间所需的工作行为。

3、 确保所有将要被涉及到的或受益的人员致力于架构过程的成功。

4、 促使架构赞助者为将要受到影响的业务领域的工作制定需求。

5、 明确受此业务指令影响的各个企业组织元素,并对其范围进行界定。此外,还需要为这些元素定义各种约束和假设。

6、 定义组织的"架构足迹",包括负责执行架构工作的人员、他们的位置以及职责。

7、 定义用于进行企业架构建设的框架和详细方法。

8、 确定一个治理和支持框架,用来在整个 ADM 过程中为架构治理提供业务流程和资源方面的支持。此种框架将会确保目标架构的适用性(fitness-for-purpose),并对其在进行过程中的效能进行评测。

9、 选择和落实用于支持架构活动的各种工具和基础设施。

10、 定义架构原则,而这些原则将会成为约束架构工作的一个部分。

2.2 方法

预备阶段在于为企业或组织定义在哪里、为什么、谁负责、如何创建架构,以及架构的大体内容是什么,具体包括如下几个主要方面:

1、 确定企业的范围,并借此明确将要从企业架构中获益的各个干系人。

2、 为了在某个企业中为采用何种框架做出一个有效且明智的决定(包括如何对框架进行裁剪,从而适合组织的需要),明确组织背景和环境是必需的,这包括针对如下几个方面的考虑:

①.企业架构的商业模型和企业架构活动的预算计划。

②.企业中与架构相关的干系人以及他们的关注点。

③.组织的意向和文化。

④.当前用于支持变更执行和 IT运营的各个流程。

⑤.基线架构景观,包括企业当前的状态以及其景观如何通过文档的形式来表现。

⑥.将要使用架构框架的组织的技能和能力。

3、 架构工作需求:处在架构工作背后的业务需求驱动了针对架构工作的需求和性能指标的制定。这些需求应该足够清晰,从而使得业务输出和资源需求得以被界定,同时简要的企业业务信息需求以及与之相关的企业架构工作策略也将被定义出来。

4、 制定原则:在此阶段制定的架构原则将会成为日后用于约束架构工作的各种内容的重要组成部分。

5、 明确组织的管理框架:企业架构开发方法是一种通用的方法,它既可以适用于各种行业,亦可以与企业中已经存在的各种管理框架相融合。一般来讲,能够与 TOGAF相互协调的管理框架包括业务能力管理、组合/项目管理方法、运营管理方法和解决方案开发方法。这些框架并不是相互隔绝的,而是相互交叠并组合在一起来为组织提供价值,因而TOGAF 也不能仅仅着眼于 IT 实现,而应该扩展视野,将关注点放到其对整个组织的影响之上。这种与组织中其他框架的融合也为组织在引入 TOGAF 时提出了要求,即组织应根据自身特点对其进行适当的改造。

6、 将各种管理框架进行关联:由于组织中存在着各种作用不同的管理框架和方法,因而他们与企业架构之间的合作关系应该得到明确的定义。在 TOGAF规范中列出了如下图所示的一张管理框架关系图:

togaf 系统架构(TOGAF学习比较知识点精要)(5)

7、 组织中管理框架之间的关系与交互为企业架构/业务变更的成熟度评估进行规划:能力成熟度模型(CMM,Capability Maturity Model)是一个根据各种选定因素而进行评估的有效方法,在企业架构的建设中亦是如此。成熟度的实际水平为组织的变更能力提供了一个战略上的评测以及一系列用于改善组织能力的步骤。一个好的企业架构成熟度模型应该在很大程度上涵盖了企业的各项特性,这既包括业务方面,也包括技术方面。每个组织都可以根据自身情况制定各项评测因素,并据此建立起适合于自己的成熟度模型,不过 TOGAF建议组织应以某现存并且开放的成熟度模型(例如NASICO、美国联邦企业架构成熟度模型等)为基础来定制符合自身需要的成熟度模型,而不要凭空创建。

2.3 输入输出2.4 步骤

1、 界定将要受到影响的企业组织的范围。

①.识别出将会受到架构工作最大影响的核心单位。

②.识别出工作组将会发生变化、但不会直接被影响的单位。

③.识别出不在被界定的范围的企业内的扩展单位,这些单位会被他们自身的企业架构所影响。

④.识别出涉及到的各个群体-那些利益相关者会受到影响,那些人属于一个群体。 ⑤.识别涉及到的治理方法。

2、 确定治理和支持框架。

①.这一步骤的主要输出是一个作为机构治理的框架。

②.现有的组织治理和支持模型可能需要改变。

③.目前的治理和支持模型需要评估,以了解其内容。

④.有关的潜在影响,将需要咨询赞助者和利益相关者。

3、 定义并建立企业架构团队和组织结构。

①.确定现有企业和业务能力

②.进行架构/业务变更成熟度评估

③.识别在现有的工作领域的差距

④.为企业架构能力的管理和治理分配关键的角色和职责

⑤.撰写对现有项目的变更需求

⑥.新企业架构工作的范围

⑦.确定对企业架构工作的约束

⑧.与赞助者及其委员会一起评审并达成一致意见

⑨.评估预算需求

4、 明确并制定架构原则。

①.定义架构原则

②.TOGAF架构原则的模板

③.业务原则 ④.数据原则 ⑤.应用原则 ⑥.技术原则

⑦.范例-首要性原则、自助服务、面向服务

⑧.架构原则的五个质量性质

⑨.原则和元模型

5、 选择架构框架,并对其进行定制。

①.术语定制:最好用整个企业都理解的术语。

②.流程控制:ADM是一种通用的流程。定制流程允许我们去掉一些在其他地方完成的任务,增加一些组织特定的任务,并将 ADM 流程与外部流程框架保持一致。

③.内容定制:使用 TOGAF架构内容框架作为基础,也可采用第三方的内容框架

并定制该框架,以支持组织的特定需求。

6、 落实相关架构工具。

①②③④⑤⑥⑦⑧⑨⑩

第3章 阶段 A:架构愿景

togaf 系统架构(TOGAF学习比较知识点精要)(6)

3.1 目标

1、 确保架构开发循环的进展被企业管理层认知和支持,并取得必要的管理线的支持和承认。

2、 在预备阶段中明确的架构框架的整体背景之下定义和组织架构开发循环。

3、 验证业务原则、业务目标、组织的战略业务驱动力,以及企业架构的主要性能指标

(KPIs).

4、 定义基线架构的范围,明确其所包含的组件以及组件的优先级。

5、 定义相关干系人以及他们的关注点和目标。

6、 定义架构工作所要解决的关键业务需求,以及必须应对的各项约束。

7、 阐明架构愿景,并定制价值主张。这些价值主张被用来阐述对于那些需求和约束的回应。 8、创建一个综合性计划,用来表明规划进度、资源、财务、沟通、风险、约束、假设和依赖关系,并应与企业中的项目管理框架相适合(PRINCE2 或 PMBOK 等)。

9、 确保正式批准得以执行。

10、 理解与其他并行的企业架构开发循环之间的相互影响

3.2 方法

架构愿景阶段是从架构组织收到来自于架构赞助组织的架构工作要求书时开始的。在这个阶段中,组织需要基于针对当前资源及其可用性所做的评估来界定架构工作的范围,以及需要应对的种种约束。这些约束通常来源于在准备阶段中制定的各项业务原则和架构原则,而在架构愿景阶段中,组织需要确定这些原则是存在并清晰的,如果不是这样,则需在此阶段对这些原则进行明确的定义。除此之外,在此阶段所涉及到的方法还包括:

3.2.1 创建架构愿景

架构愿景是架构赞助者向各干系人以及决策者推广其所提出的能力的绝佳工具,它描述了新的能力如何满足组织的战略和业务目标,以及当这些能力实现时,相关干系人所关注的问题又是如何获得解决的。因而针对架构愿景的创建实际上就是对架构的目标进行明确,并对如何通过架构开发来达成这些目标进行阐明。架构愿景在一个很高的层面上为基线和目标架构做了有关第一印象的描述,并且这一描述应该涵盖业务、数据、应用和技术这四个层面

(这只是概要性描述,这些层面的具体内容将在后续的相应阶段被逐步细化)。

一旦架构愿景被定义并被记录到架构工作说明书中,接下来在各个干系人中对这份架构愿景形成共识将会成为重中之重,因为如果没有这份共识,那么最终的架构是否能够被组织所接受就无从谈起了。这份共识的获得是通过赞助组织签署架构工作说明书来实现的。

3.2.2 业务情景业务情景方法用于识别和阐明隐含的架构需求和隐藏在新业务能力(用于满足关键业务驱动力的需求)中的业务需求。此技术通过一种循环迭代的方式进行,并针对业务架构的各层次化分解部件采用不同等级的详细度进行描述。

3.3 输入输出3.4 步骤

1、 建立架构项目;①②③④⑤⑥⑦⑧⑨⑩

①.引导企业-特定程序已获得:

A.企业-广泛的认可。

B.公司管理者背书。

C.部门管理者的支持和承诺。

②.参考其他管理框架:

A.解释此项目如何关联到那些框架。

2、 识别干系人、关注点和业务需求;

①.在这里我们必须识别:

A.候选愿景构件和需求。

B.候选范围边界。

C.利益相关者关注、议题、和文化因素。

D.项目相关的关注和视点。

E.项目涉及的利益相关者。

F.项目内的关键角色和责任。

②.另一个关键的任务将是考虑哪一个架构视图和视点需要制定,以满足各种利益

相关者的需求。

3、 确认并阐述业务目标、驱动力和约束;

4、 评估业务能力;

5、 评估业务转型准备情况;

6、 定义范围;

7、 确认并阐述架构原则,包括业务原则;

8、 开发架构愿景;

9、 定义目标架构价值主张和主要性能指标;

10、 明确业务转型风险和缓解措施;

11、 开发企业架构计划和架构工作说明书,并确保被批准。

最后大家最关心架构精要资料的获取!

领取方法:

1.评论文章,没字数限制,一个字都行!然后转发出去!

2.关注小编,成为小编的粉丝!

3.私信小编:“精要”即可!

谢谢大家,祝大家学习愉快!

猜您喜欢: