Version 23.1 by superadmin on 2022/01/16, 23:39
Show last authors
1 **申明：**
2
3
4 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众
5 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信
6 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
7
8
9 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
10
11
12 本文档翻译工作参与人员：
13
14 翻译：张志华
15
16 审校：魏钧军
17
18
19 总审：长河
20
21 审核：戚依军
22
23 统筹：常宏
24
25
26
27 ----
28
29 {{box cssClass="floatinginfobox" title="**Contents**"}}
30 {{toc/}}
31 {{/box}}
32
33 = 1 关于本文件 =
34
35 本文档为架构管理实践提供了实用指南。它分为五个主要部分，内容包括：
36
37 * 实践的一般信息
38 * (((
39 实践的流程和活动及其在服务价值链中的作用
40 )))
41 * 实践中涉及的组织和人员
42 * 支持实践的信息和技术
43 * 有关实践的合作伙伴和供应商注意事项。
44
45 == **1.1 ITIL^^®^^4鉴证方案** ==
46
47 本文档中的选定内容可作为以下教学大纲的部分考试范围：
48
49 * **I**TIL专家-高速IT。
50
51 有关详细信息，请参阅相应的教学大纲文档。
52
53
54
55 ----
56
57 = 2 一般信息 =
58
59
60 == 2.1目的与描述 ==
61
62 全面的架构管理实践适用于所有级别的组织架构。主要包括：
63
64 * 业务架构
65 * 产品和服务架构
66 * 信息系统架构，包括数据和应用程序架构
67 * 技术架构
68 * 环境架构。
69
70 实践的范围由组织的定位、愿景和战略定义。例如，内部IT服务提供商的架构管理实践可能专注于其产品、服务、信息系统和技术的架构。在其他情况下，如果第三方为组织提供基础架构和平台，则其范围可能不包含较低级别的技术架构。这也可能会反映在IT系统架构中。但是，我们应该在组织的所有级别，以及架构的所有级别上始终如一的开发架构管理实践。
71
72
73 架构管理实践应该描述组织的服务价值系统和所有服务管理四维模型的资源，它们是：
74
75 * 组织和人员
76 * 信息和技术
77 * 流程和价值流
78 * 供应商和合作伙伴。
79
80 图2.1中对此进行了说明。
81
82 (% style="text-align:center" %)
83 [[image:1639633625741-287.png]]
84
85 图2.1 架构级别和服务管理四维模型
86
87
88 架构管理实践可以确保：
89
90 * 理解组织的当前架构，并映射到组织的战略
91 * 识别并商定目标组织的架构
92 * 不断优化组织的架构，以实现其目标架构。
93
94 为了实现这些目标，架构师分析组织并描述当前架构。并评估其当前架构，旨在识别当前或未来可能阻碍组织战略实现的可优化之处。定义目标架构用以解决这些阻碍。架构管理实践允许组织从其当前的架构演变为所需的架构；它还允许随着组织的策略和环境变化，在过程中修正。
95
96
97
98 == 2.2 **术语和概念** ==
99
100 架构管理实践包含几种类型或级别的架构。下面将进一步详细描述。
101
102
103
104 === **2.2.1 业务架构** ===
105
106 **定义：业务架构**
107
108 组织如何使用资源实现其战略和目标的正式描述。
109
110
111 业务架构探索组织如何使用资源在组织内与其利益相关者共创价值。组织使用资源来创建产品，并基于这些产品提供和交付服务。
112
113
114 === **2.2.2 产品和服务架构** ===
115
116 **定义：产品和服务架构**
117
118 对组织的产品和服务、组件及其相互关系、管理设计及其随时间演变的原则和指南的正式描述。
119
120
121 产品和服务架构提供了组织的产品和服务的全景图。它还探讨了服务和描述结构的模型之间的交互，例如组件如何装配在一起，例如活动和资源流的动态，以及每个产品和服务的交互。这些模型可以作为多种产品和服务的模板。和支持信息技术、运营技术和通信技术一样，数字化产品和服务基于应用和数据。
122
123
124 === **2.2.3 信息系统架构** ===
125
126 **定义：信息系统架构**
127
128 对组织的应用、数据资产和数据管理资源的正式描述。信息系统架构展示了应用和数据如何互连和管理，以使组织受益。
129
130
131 信息系统由基础设施和平台支撑，整合了信息、运营和通信技术。这些在技术架构中有正式描述。
132
133
134 === **2.2.4 技术架构** ===
135
136 **定义：技术架构**
137
138 对组织的技术基础设施的正式描述，包括信息、运营和通信技术，它们的相互关系以及对组织信息系统的支持方式。
139
140
141 === **2.2.5 环境架构** ===
142
143 **定义：环境架构**
144
145 影响组织和驱动变更的外部因素，以及环境控制和管理的所有方面、类型和级别的正式描述。
146
147
148 组织可能会发现保留其运作环境的说明大有裨益，可以确保其产品和服务适应环境，并且不与外部约束相冲突。
149
150 环境架构包括：开发、技术、业务、运营、组织、政治、经济、法律、法规、生态和社会影响。它可以帮助组织了解和管理其在所处的生态系统中的定位。
151
152 架构管理实践包括范围的定义和架构的结构，该实践基于组织的战略和定位。
153
154
155
156 == 2.3 **范围** ==
157
158 架构管理实践的范围包括：
159
160 * 了解和描述组织的当前架构
161 * 定义组织的目标架构，并与相关利益相关者达成一致
162 * 持续优化组织，以满足目标架构
163 * 持续监督进行中的变更，以确保与商定的目标架构保持一致。
164
165 若干活动和职责领域尽管与架构实践密切相关，但不在架构管理实践的范围内。表2.1中列出了这些内容，以及可以找到它们的实践的引用。重要的是要记住，ITIL实践只是用于价值流上下文中的工具集合，应视情况按需组合。
166
167
168 表2.1其他实践指南中描述的架构管理实践的相关活动
169
170 (% style="width:703px" %)
171 |(% style="width:459px" %)**活动**|(% style="width:241px" %)**实践指南**
172 |(% style="width:459px" %)解决方案设计（产品、服务、信息系统和技术）|(% style="width:241px" %)服务设计
173 |(% style="width:459px" %)架构实施路线图|(% style="width:241px" %)(((
174 项目管理
175
176 变更支持
177
178 组织变革管理
179 )))
180 |(% style="width:459px" %)架构选型的投资决策和授权|(% style="width:241px" %)投资组合管理
181 |(% style="width:459px" %)组织方向和目标的定义|(% style="width:241px" %)战略管理
182 |(% style="width:459px" %)配置项目和资产的详细映射|(% style="width:241px" %)(((
183 服务配置管理
184
185 IT资产管理
186 )))
187
188 == ​​​​​​​2.4 **实践成功因素** ==
189
190 **定义：实践成功因素**
191
192 实践的复杂功能组件，用于实现实践目的。
193
194
195 实践成功因素（PSF）不仅仅是一项任务或活动，它还包括所有服务管理四维模型的组件。活动的特性和实践成功因素PSF的资源可能有所不同，但它们共同确保实践有效。
196
197
198 架构管理实践包含以下实践成功因素PSF：
199
200 * 确保目标架构支持组织的战略
201 * 确保组织的架构不断朝目标状态演进
202
203 === **2.4.1 确保目标架构支持组织的战略** ===
204
205 组织的架构应该进行优化，以实现并支持其战略。这需要目标架构模型。
206
207 为了制定有效且现实的目标架构，架构师需要了解以下内容：
208
209 * 组织的战略及其当前的绩效
210 * 组织的当前架构、优势和约束
211 * 主要痛点及其在架构的映射
212 * 组织的产品组合和持续发展
213 * 环境因素和趋势
214 * 技术趋势、风险和机会
215 * 其他相关趋势和因素。
216
217 通过分析这些方面，您可以从架构的角度了解组织的当前状态和期望状态，并基于此开发当前和目标的架构模型。根据组织的战略，架构的有效性可以表现为以下特性：
218
219 * 可扩展性
220 * 成本效益
221 * 与其他组织的兼容性
222 * 符合法规的合规性
223 * 敏捷
224 * 可持续性
225 * 安全。
226
227 这不是一个最完整的清单。我们也可以创建其他目标来确保架构有效性。
228
229 由于组织的战略可能会不断演进，因此架构建模不应该是孤立的工作。当前的架构模型应随着组件变化而调整，并应根据战略的变化来审查目标架构模型。这些更新将启动架构路线图的评审（请参见[[2.4.2>>path:#_bookmark0]])
230
231 架构分析和目标架构规划与其他实践紧密结合进行（有关这些实践的列表，请参见2.3）。重要的是要确保架构模型正确、现实，并且与利益相关者共享对当前和目标架构的理解。现实的架构计划基于对当前架构的充分理解，包括被内部和外部利益相关者采用的遗留系统、约束、重要的业务功能和行为模式。考虑其他要求和约束，例如预算，法规等。最后，对技术前景（包括新兴技术和行业趋势）的充分了解非常重要。
232
233 除了描述目标架构之外，路线图还应包括以下方面的建议和要求：分类法、标准、指南、流程、模板和工具，并用于具有重要架构意义的举措（例如生产和服务设计、变更和项目等）。这包括将推荐的架构控件集成到相关实践和价值流中，以确保组织的活动与商定的发展方向一致。
234
235
236 === **2.4.2 确保组织的架构不断朝目标状态演进** ===
237
238 创建架构路线图可以确保组织朝目标架构演进。路线图是旨在从当前架构更改到目标架构的一系列设计计划。在适当情况下，可以将这些计划作为项目集或项目进行管理。实现架构变更涉及多个利益相关者和实践，视变更的性质而定。架构管理实践确保所实施的变更遵循商定的路线图，并支持组织向其目标架构演进。
239
240
241 **关键信息**
242
243 从当前的架构到目标架构的转换几乎不是一场革命。相反，它是由组织同意遵循的一组架构原理、标准和准则促成的演进。一些旧解决方案可能会与新解决方案共存很长时间。从当前架构到目标架构的变更始终取决于投资组合决策和谨慎的优先级。架构管理实践用于定义目标架构，并保持一致的架构演进方向和步伐。
244
245
246 架构管理实践活动的另一个重要方面是，它通过遵循推荐的架构分类法、标准、指南、流程、模板和工具，确保其对组织的资源、产品和服务所做的变更支持架构的演进。它们也不应与架构的要求和原理相抵触。这意味着架构管理实践涉及每个服务价值流，其中包括引入新组件、新的第三方服务或其他影响架构的变更。
247
248
249 == ​​​​​​​2.5 **关键指标** ==
250
251 ITIL 实践的有效性和绩效应在每个实践所贡献的价值流背景内进行评估。与任何工具的性能或绩效一样，实践的绩效只能在应用程序的背景下评估。但是，工具在设计和质量上可能会有很大差异，这些差异决定了工具在根据其用途使用时有效的潜力或能力。与指标、关键绩效指标（KPI）和其他相关技术的进一步指导，请参见测量和报告实践指南。
252
253
254 架构管理实践的关键指标已映射到其实践成功因素PSF。在价值流中，它们可以作为KPI，以评估实践对价值流有效性和效率的贡献。表2.2中给出了一些关键指标的示例。
255
256 表2.2 实践成功因素的关键指标示例
257
258
259 (% style="width:795px" %)
260 |(% style="width:368px" %)**实践成功因素**|(% style="width:425px" %)**关键指标**
261 |(% style="width:368px" %)确保目标架构支持组织的战略|(% style="width:425px" %)(((
262 对目标架构的商定要求的实施情况
263
264 限制组织战略实现的架构约束的数量和影响
265
266 架构不支持的战略决策的数量和影响
267
268 基于内部和独立评估，目标架构的完整性和质量
269
270 战略更新和目标架构对齐之间的延迟时间和影响
271 )))
272 |(% style="width:368px" %)确保组织的架构不断朝目标状态演进|(% style="width:425px" %)(((
273 未遵循商定的目标架构实施的变更数量和影响
274
275 尚未评估是否符合商定的架构的重大更改的数量和影响
276
277 架构路线图的实施进度
278 )))
279
280 ----
281
282 = ​​​​​​​3.价值流和流程 =
283
284
285 == **3.1价值流的贡献** ==
286
287 与任何其他ITIL 管理实践一样，架构管理实践有助于多个价值流。重要的是要记住，价值流永远不会由单个实践构成。架构管理实践与其他实践相结合，可以为消费者提供高质量服务。该实践促成的主要价值链活动包括：
288
289 * 契动
290 * 交付和支持
291 * 设计和转换
292 * 改进
293 * 获取/构建
294 * 计划。
295
296 图3.1中显示了架构管理实践对服务价值链的贡献。
297
298 (% style="text-align:center" %)
299 [[image:1639652021295-354.png]]
300
301 图3.1：架构管理实践对服务价值链活动的贡献热图
302
303 == 3.2 **流程** ==
304
305 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
306
307
308 架构管理活动构成三个流程：
309
310 * 架构治理
311 * 目标架构的开发和路线图
312 * 持续的架构控制。
313
314 === **3.2.1 架构治理** ===
315
316 该流程包括表3.1中列出的活动，并将输入转换为输出。
317
318 表3.1 架构治理流程的输入、活动和输出
319
320 (% style="width:660px" %)
321 |(% style="width:306px" %)**关键输入**|(% style="width:195px" %)**活动**|(% style="width:157px" %)**关键输出**
322 |(% style="width:306px" %)(((
323 组织的原则、政策和愿景
324
325 组织战略
326
327 环境因素
328
329 组织结构
330
331 产品和服务组合
332
333 项目集和项目组合
334
335 客户组合
336
337 架构评审报告
338
339 审计报告
340 )))|(% style="width:195px" %)(((
341 分析组织和需求
342
343 开发和商定架构愿景
344
345 监控组织架构
346 )))|(% style="width:157px" %)(((
347 架构愿景
348
349 架构原则和需求
350 )))
351
352 图3.2显示了流程的工作流程图。
353
354 (% style="text-align:center" %)
355 [[image:1639652084225-518.png]]
356
357 图3.2 架构治理流程的工作流程
358
359
360 表3.2 提供了架构治理流程的每个活动的高级描述示例。
361
362 表3.2 架构治理流程的活动
363
364 (% style="width:862px" %)
365 |(% style="width:97px" %)**活动**|(% style="width:354px" %)**“全栈式'架构管理**|(% style="width:408px" %)**IT 架构管理**
366 |(% style="width:97px" %)分析组织和需求|(% style="width:354px" %)组织的执行领导定义架构管理活动的范围，并任命架构委员会|(% style="width:408px" %)CIO、IT架构师、产品负责人和业务分析人员评审有关组织的愿景、战略和需求的可用信息，并任命IT 架构委员会
367 |(% style="width:97px" %)开发和商定架构愿景|(% style="width:354px" %)架构委员会为组织开发架构愿景，并与执行领导商定愿景|(% style="width:408px" %)IT 架构委员会为数字化产品和服务、IT系统以及支持技术开发架构愿景，并与CIO商定愿景。
368 |(% style="width:97px" %)监视组织的架构|(% style="width:354px" %)根据定期的架构评审和审计报告，或基于相关的异常报告，组织执行领导审查架构和架构管理的有效性，并为“分析组织和需求”的活动提供输入|(% style="width:408px" %)根据定期的架构评审和审计报告，或基于相关的异常报告，CIO、IT架构师、产品负责人和业务分析人员审查架构和架构管理的有效性，并为“分析组织和“需求”提供输入
369
370 === **3.2.2 开发目标架构和路线图** ===
371
372 该流程包括表3.3中列出的活动，并将输入转换为输出。
373
374 表3.3开发目标架构和路线图流程的输入、活动和输出
375
376 (% style="width:917px" %)
377 |(% style="width:366px" %)**关键输入**|(% style="width:188px" %)**活动**|(% style="width:183px" %)**关键输出**
378 |(% style="width:366px" %)(((
379 架构愿景
380
381 架构原则和需求
382
383 服务配置数据
384
385 资产登记册
386
387 第三方合同
388
389 产品和服务组合
390
391 项目集和项目组合
392
393 客户组合                                                                                                                                            
394 )))|(% style="width:188px" %)(((
395 识别需求
396
397 记录当前的架构
398
399 开发目标架构
400
401 设计标准、框架和指南
402
403 设计、商定并传达架构路线图
404 )))|(% style="width:183px" %)(((
405 架构评估报告
406
407 当前架构模型
408
409 目标架构模型
410
411 架构控制、框架和指南
412
413 商定的架构路线图
414 )))
415
416 图3.3展示了开发目标架构和路线图流的工作流程。
417
418
419 (% style="text-align:center" %)
420 [[image:1639652207003-419.png]]
421
422 图3.3 开发目标架构和路线图流的工作流程
423
424
425
426 表3.4提供了开发目标架构的的每个活动和路线图流程的高级描述示例。
427
428 表3.4 开发目标架构的活动和路线图流程
429
430 (% style="width:836px" %)
431 |(% style="width:106px" %)**活动**|(% style="width:370px" %)**“全栈式'架构管理**|(% style="width:358px" %)**IT 架构管理**
432 |(% style="width:106px" %)识别需求|(% style="width:370px" %)架构委员会分析架构愿景和需求|(% style="width:358px" %)IT架构师分析IT 架构愿景和需求。
433 |(% style="width:106px" %)记录当前架构|(% style="width:370px" %)如果需求范围内的当前架构未经记录或不是最新的，则架构师探索并记录从业务架构到技术基础设施的所有级别的当前架构。|(% style="width:358px" %)如果需求的范围内的当前IT架构未经记录或不是最新的，则架构师探索并记录当前的IT 架构。
434 |(% style="width:106px" %)开发目标架构|(% style="width:370px" %)架构师、业务分析人员、关系经理和产品负责人评审当前的架构，以识别约束和与商定的架构愿景的分歧，并开发各个级别的目标架构模型，从而确保各个级别的一致性。|(% style="width:358px" %)架构师、业务分析人员和产品负责人评审当前的架构，以识别约束和与商定的架构愿景的不一致，并开发目标IT架构模型。
435 |(% style="width:106px" %)设计标准、框架和指南|(% style="width:370px" %)架构师基于目标架构，开发支持的标准、指南、流程、模板和工具，以确保其有效集成至相关实践和价值流中。这要与利益相关者（包括实践负责人、产品负责人或其它）进行讨论并达成共识。|(% style="width:358px" %)架构师基于目标架构，开发支持的标准、指南、流程、模板和工具，以确保其有效集成至相关实践和价值流中。这要与利益相关者（包括实践负责人、产品负责人或其它）进行讨论并达成共识。
436 |(% style="width:106px" %)设计、商定并传达架构路线图|(% style="width:370px" %)(((
437 架构师识别目标架构与当前架构之间最关键的差距；然后，他们提出了针对迁移和当前架构控制的方法。路线图包括确保整个组织遵守商定的架构的控制。产品负责人、风险经理、财务经理以及其他相关领导和专家都支持这项工作。
438
439
440 与执行领导讨论和批准建议的架构路线图。如果未获批准，则路线图将返回到先前的某个步骤。
441
442
443 已批准的路线图以及支持标准、框架、指南和控制措施的详细计划和执行将传达给相关的团队（包括项目集和项目经理、人力资源、投资组合和财务、产品负责人等）。
444 )))|(% style="width:358px" %)(((
445 架构师识别目标架构与当前架构之间最关键的差距；然后，他们提出了针对迁移和当前架构控制的方法。路线图包括确保整个组织遵守商定的架构的控制。产品负责人、风险经理、财务经理以及其他相关领导和专家都支持这项工作。
446
447
448 与执行领导讨论和批准建议的架构路线图。如果未获批准，则路线图将返回到先前的某个步骤。
449
450
451 已批准的路线图以及支持标准、框架、指南和控制措施的详细计划和执行将传达给相关的团队（包括项目集和项目经理、人力资源、投资组合和财务、产品负责人等）。
452 )))
453
454 (% class="wikigeneratedid" %)
455 ​​​​​​​
456
457 === **3.2.3 持续架构控制** ===
458
459 该流程侧重实施架构路线图和维护商定的架构。它包括表3.5所示的活动，并将输入转换为输出。
460
461
462 表3.5持续的架构控制流程的输入、活动和输出
463
464 (% style="width:858px" %)
465 |(% style="width:307px" %)**关键输入**|(% style="width:302px" %)**活动**|(% style="width:255px" %)**关键输出**
466 |(% style="width:307px" %)(((
467 商定的架构路线图
468
469 变更待办列表
470
471 项目计划
472
473 产品待办列表
474
475 持续改进登记册
476
477 服务配置数据
478
479 资产登记册
480
481 第三方合同
482
483 产品和服务组合                                                                                           
484 )))|(% style="width:302px" %)(((
485 识别架构上重要的变更和事态
486
487 检查是否符合目标架构
488
489 升级不符合项
490
491 评审架构路线图的进度
492 )))|(% style="width:255px" %)(((
493 架构（不合格）报告
494
495 架构评审报告
496 )))
497
498 图3.4显示了持续架构控制流程的工作流。
499
500
501 (% style="text-align:center" %)
502 [[image:1639652311065-812.png]]
503
504
505 图3.4持续的架构控制流程的工作流
506
507
508 表3.6提供了持续的架构控制流程的每个活动的高级描述示例。
509
510 表3.6持续的架构控制流程的活动
511
512 (% style="width:738px" %)
513 |**活动**|(% style="width:591px" %)**示例**
514 |识别重要的架构变更和事件|(% style="width:591px" %)(((
515 当计划重要的架构变更、项目或改进举措时，架构师介入获批准工作流。负责架构计划的角色根据商定的架构控制，识别架构的重要变更。该活动适用于所有具有重要的举措，包括那些专门作为架构路线图组成而创建的举措。
516
517 当识别出重要的架构事件（设计错误、不正确的实施或规避架构控制的变更）时，会将其报告给架构师评审。产品负责人、问题调查人员、风险经理、审计人员及其他人员可以识别这些事件。
518 )))
519 |检查是否符合目标架构|(% style="width:591px" %)(((
520 架构师评审建议的举措和报告的事件，以评估是否符合商定的目标架构模型。
521
522 符合目标架构的举措（包括由架构路线图触发的举措）获得批准，并在相应的价值流中继续处理。
523
524 符合目标架构的事件获得批准，并在相应的价值流中继续进行处理。如果事件规避了商定的批准流程，则架构师将此报告给相关部门（产品负责人、项目经理、变更经理、持续改进经理或其他人员）。
525 )))
526 |升级不符合项|(% style="width:591px" %)(((
527 给相关部门（产品负责人、项目经理、变更权威、持续改进经理、CIO、架构委员会或其他机构）上报识别出的不符合项。
528
529 架构师提供必要的信息，以识别符合目标架构的替代解决方案。
530 )))
531 |评审架构路线图的进度|(% style="width:591px" %)在经过了重要更改和固定间隔后，架构师将生成进度报告，说明架构路线图的实现和维护情况。该报告要传达给相关的利益相关者，并作为架构治理流程的一个输入。
532
533 ----
534
535 = 4. 组织和人员 =
536
537
538 == ​​​​​​​4.1 **角色、能力和责任** ==
539
540 实践指南没有描述实践管理角色，例如实践负责人、实践主管或实践教练，相反，专注于每个实践特有的专业角色。每个角色的结构和命名都可能因组织而异，因此，ITIL中定义的任何角色都不是强制性的，甚至不推荐使用。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
541
542 角色在流程和活动的上下文中有所描述。每个角色均具有基于以下模型的能力简介，如表4.1中所示。
543
544 表4.1 能力代码和简介
545
546 (% style="width:802px" %)
547 |**能力代码**|(% style="width:653px" %)**能力简介（活动和技能）**
548 |L|(% style="width:653px" %)领导者，决策、授权、监督其他活动，提供激励和动机以及评估结果
549 |A|(% style="width:653px" %)管理员，分配任务并确定优先级，保留记录，持续报告，并启动基本改进
550 |C|(% style="width:653px" %)协调员/沟通者，协调多方，保持利益相关者之间的沟通，以及开展认知活动
551 |M|(% style="width:653px" %)方法和技术专家，设计和实施工作技术、记录流程、咨询流程、分析工作和持续改进
552 |T|(% style="width:653px" %)技术专家，提供技术（IT）专业知识，并执行基于专业知识的任务
553
554 表4.2 负责架构管理活动的角色示例
555
556 (% style="width:845px" %)
557 |(% style="width:181px" %)**活动**|(% style="width:185px" %)**负责的角色**|(% style="width:124px" %)**能力简介**|(% style="width:353px" %)**特有技能**
558 |(% colspan="4" style="width:842px" %)架构治理
559 |(% style="width:181px" %)分析组织和需求|(% style="width:185px" %)(((
560 执行领导
561
562 架构委员会
563
564 架构师
565
566 产品负责人
567 )))|(% style="width:124px" %)TCA|(% style="width:353px" %)(((
568 熟知组织及环境、产品组合、产品、资源和客户
569
570 了解架构管理框架
571 )))
572 |(% style="width:181px" %)开发并商定架构愿景|(% style="width:185px" %)(((
573 执行领导
574
575 架构委员会
576
577 架构师
578
579 产品负责人
580 )))|(% style="width:124px" %)TLMC|(% style="width:353px" %)(((
581 熟知组织及其环境、产品组合、产品、资源和客户
582
583 战略思维
584
585 领导技能
586 )))
587 |(% style="width:181px" %)监控组织的架构|(% style="width:185px" %)(((
588 执行领导
589
590 架构委员会
591
592 架构师
593
594 产品负责人
595 )))|(% style="width:124px" %)TCA|(% style="width:353px" %)(((
596 熟知组织及其环境、产品组合、产品、资源和客户
597
598 了解架构管理框架
599
600 战略思维
601 )))
602 |(% colspan="4" style="width:842px" %)开发目标架构和路线图
603 |(% style="width:181px" %)识别需求|(% style="width:185px" %)(((
604 架构师
605
606 产品负责人资源经理
607 )))|(% style="width:124px" %)TAC|(% style="width:353px" %)(((
608 分析技能
609
610 充分理解架构愿景
611
612 熟知当前
613
614 架构
615 )))
616 |(% style="width:181px" %)记录当前架构|(% style="width:185px" %)(((
617 架构师
618
619 产品负责人资源经理
620 )))|(% style="width:124px" %)TMA|(% style="width:353px" %)(((
621 熟悉架构管理框架的实用知识
622
623 充分了解已记录的架构级别上的组织资源
624
625 分析技能
626 )))
627 |(% style="width:181px" %)开发目标架构|(% style="width:185px" %)(((
628 架构委员会
629
630 架构师
631
632 产品负责人
633
634 资源经理
635 )))|(% style="width:124px" %)TMC|(% style="width:353px" %)(((
636 分析技能
637
638 充分理解架构愿景
639
640 深入了解当前架构的优缺点
641
642 充分了解外部机会和威胁
643 )))
644 |(% style="width:181px" %)设计标准、框架和指南|(% style="width:185px" %)(((
645 架构委员会
646
647 架构师
648
649 产品负责人
650
651 资源经理
652 )))|(% style="width:124px" %)TMC|(% style="width:353px" %)(((
653 分析技能
654
655 充分理解架构愿景
656
657 深入了解当前架构的优缺点
658
659 充分了解外部机会和威胁
660 )))
661 |(% style="width:181px" %)设计、商定并传达架构路线图|(% style="width:185px" %)(((
662 架构委员会
663
664 架构师
665
666 产品负责人
667
668 资源经理
669 )))|(% style="width:124px" %)MTCL|(% style="width:353px" %)(((
670 充分理解组织的容量、约束及业务优先级。
671
672 深入了解可能影响架构的组织价值流和实践
673
674 沟通和谈判技能，演讲技能，领导技能
675 )))
676 |(% colspan="4" style="width:842px" %)持续架构控制
677 |(% style="width:181px" %)识别重要的架构变更和事态|(% style="width:185px" %)(((
678 产品负责人
679
680 变更权威
681
682 项目经理
683
684 持续改进经理
685
686 风险经理
687
688 内部审计人员
689 )))|(% style="width:124px" %)T|(% style="width:353px" %)充分理解举措和活动对架构的影响
690 |(% style="width:181px" %)检查是否符合目标架构|(% style="width:185px" %)(((
691 架构师
692
693 产品负责人
694
695 架构委员会
696 )))|(% style="width:124px" %)TM|(% style="width:353px" %)(((
697 熟知商定的目标架构，充分理解商定的架构路线图，包括控制措施
698
699 分析技能
700
701 沟通技能
702 )))
703 |(% style="width:181px" %)升级不符合项|(% style="width:185px" %)(((
704 架构师
705
706 产品负责人架构委员会
707 )))|(% style="width:124px" %)CA|(% style="width:353px" %)(((
708 熟知商定的控制措施
709
710 良好的沟通技能
711 )))
712 |(% style="width:181px" %)评审架构路线图的进度|(% style="width:185px" %)(((
713 架构师
714
715 产品负责人
716
717 架构委员会
718 )))|(% style="width:124px" %)AC|(% style="width:353px" %)(((
719 熟知架构路线图
720
721 分析和沟通技能
722 )))
723
724 === **4.1.1 架构师** ===
725
726 架构师是特定实践的关键角色。该角色可以是专职的，例如业务（或企业）架构师、IT架构师或解决方案架构师，具体取决于实践范围。
727
728
729 架构师的角色是架构管理实践的关键。如上表4.2中所述，大多数实践活动由架构师执行或管理。
730
731
732 架构师的主要能力包括：
733
734 * 了解本组织和服务的客户组织的业务策略、业务模型和运营模式
735 * 了解组织运营的环境
736 * 具备组织使用的技术知识以及组织可用的开发技术知识
737 * 具备组织产品组合的知识：资源、产品和服务、客户
738 * 了解组织的价值流和实践
739 * 架构管理框架（例如Zachman框架TM，TOGAF®）的专业知识
740 * 相关解决方案架构框架（例如AWS，SOA，EMC等）的专业知识。
741
742 架构师的能力简介是TMCAL。架构师是组织的资源和架构管理方法的专家。但是，其沟通和领导技能也很重要。
743
744
745 组织中的架构师职责可能会有所不同，具体取决于实践的范围。业务（企业）架构师致力于组织的战略性规划和业务开发，而解决方案架构师则专注于特定产品或系统的架构。
746
747
748 找到专门的职位来担任架构师角色的情况并不少见。但是，在较小的组织中，解决方案架构师角色有时由产品负责人担任，而业务架构师角色由执行领导者履行，通常是临时担任的。
749
750
751
752 == ​​​​​​​4.2 **组织结构和团队** ==
753
754 当组织开发架构管理实践时，许多人发现组建专门的团队很有用，旨在驱动架构相关计划并确持续构控制。该团队通常被称为架构委员会，由来自组织的不同级别和部门的代表组成。除架构师外，该委员会通常还包括业务职能领导、产品负责人、服务设计师、风险经理、产品组合经理、人力资源经理和财务经理。
755
756
757 架构委员会(有时被称为架构董事会)通常向执行领导团队报告。委员会的决策影响组织的所有领域。
758
759 因此，确保委员会拥有足够的权力非常重要。
760
761
762 = ​​​​​​​5. 信息和技术 =
763
764
765 == **5.1 信息沟通** ==
766
767 架构管理实践的效果取决于所使用信息的质量。这包括但不限于以下信息：
768
769 * 组织的战略
770 * 组织的环境、主要利益相关者
771 * 组织的产品组合：资源、产品和服务、客户
772 * 服务配置和IT资产信息
773 * 变更排期
774 * 项目集和项目组合
775 * 持续改进登记册
776 * 组织架构
777 * 技术趋势。
778
779 该信息可以采用各种形式。在第3节中列出了实践的关键输入和输出。
780
781
782 == 5.2 **自动化和工具** ==
783
784 架构管理实践的自动化侧重于加强信息交流的三个主要领域：
785
786 * 办公自动化工具：文档、电子表格和演示文稿工具
787 * 分析和建模工具，例如：计算机辅助设计、图表和数据建模工具
788 * 通信工具，例如：工作流、任务管理和全渠道通信系统。
789
790 表5.1列出了每一个与架构管理实践相关的特定自动化方法。
791
792
793 表5.1架构管理活动的自动化解决方案
794
795 (% style="width:741px" %)
796 |(% style="width:185px" %)**活动**|(% style="width:153px" %)**自动化手段**|(% style="width:263px" %)**关键功能**|(% style="width:138px" %)**对实践效果的影响**
797 |(% colspan="4" style="width:738px" %)架构治理
798 |(% style="width:185px" %)分析组织和需求|(% style="width:153px" %)(((
799 通信和协作工具
800
801 分析系统
802
803 知识管理工具
804 )))|(% style="width:263px" %)收集、处理和演示不同来源的数据|(% style="width:138px" %)高
805 |(% style="width:185px" %)开发并商定架构愿景|(% style="width:153px" %)通信和协作工具|(% style="width:263px" %)(((
806 协作和
807
808 信息共享
809 )))|(% style="width:138px" %)中
810 |(% style="width:185px" %)监督组织的架构|(% style="width:153px" %)(((
811 通信和协作工具
812
813 分析系统
814
815 知识管理工具
816 )))|(% style="width:263px" %)(((
817 收集、处理和演示不同来源的数据
818
819 报告引擎、仪表板系统
820 )))|(% style="width:138px" %)高
821 |(% colspan="4" style="width:738px" %)开发目标架构和路线图
822 |(% style="width:185px" %)识别需求|(% style="width:153px" %)(((
823 分析系统
824
825 企业架构管理工具
826 )))|(% style="width:263px" %)(((
827 收集、处理和演示不同来源的数据
828
829 报告引擎
830 )))|(% style="width:138px" %)中
831 |(% style="width:185px" %)记录当前架构|(% style="width:153px" %)(((
832 企业架构
833
834 管理工具
835 )))|(% style="width:263px" %)架构映射和分析|(% style="width:138px" %)高
836 |(% style="width:185px" %)开发目标架构|(% style="width:153px" %)(((
837 企业架构
838
839 管理工具
840 )))|(% style="width:263px" %)架构映射和分析|(% style="width:138px" %)高
841 |(% style="width:185px" %)设计控制、框架和指南|(% style="width:153px" %)(((
842 企业架构管理工具
843
844 通信和协作工具
845
846 工作流程和任务
847
848 管理系统
849 )))|(% style="width:263px" %)(((
850 架构映射和分析
851
852 流程设计
853 )))|(% style="width:138px" %)高
854 |(% style="width:185px" %)设计、商定并传达架构路线图|(% style="width:153px" %)(((
855 企业架构管理工具
856
857 通信和协作工具
858 )))|(% style="width:263px" %)(((
859 架构映射和分析，路线图映射
860
861 协作和信息共享
862 )))|(% style="width:138px" %)高
863 |(% colspan="4" style="width:738px" %)进行中的架构控制
864 |(% style="width:185px" %)识别重要的架构变更和事态|(% style="width:153px" %)(((
865 工作流程管理和工作计划工具、ITSM工具集、企业架构管理工具
866
867 监控和事态管理工具
868 )))|(% style="width:263px" %)(((
869 工作计划、评估及批准流程和控制措施
870
871 事态检测及其相关性
872 )))|(% style="width:138px" %)高
873 |(% style="width:185px" %)检查是否符合目标架构|(% style="width:153px" %)企业架构管理工具|(% style="width:263px" %)架构映射和分析、路线图映射|(% style="width:138px" %)中
874 |(% style="width:185px" %)升级不符合项|(% style="width:153px" %)通信和协作工具|(% style="width:263px" %)协作和信息共享|(% style="width:138px" %)中
875 |(% style="width:185px" %)(((
876 评审对抗
877
878 架构路线图
879 )))|(% style="width:153px" %)(((
880 企业架构
881
882 管理工具
883 )))|(% style="width:263px" %)架构映射和分析、路线图映射|(% style="width:138px" %)高
884
885 ----
886
887 = 6. 合作伙伴和供应商 =
888
889 组织的架构应该支持其战略，并确保组织的所有组件有效地为其成功助力。架构不限于组织自己的资源。它包括组织的服务组合及其与其服务使用者的交互方式。但是，不应低估第三方服务。
890
891
892 在业务架构级别上，重要的趋势包括多源、服务集成和管理（或换而言之：非中间媒介）。在技​​术架构级别上，数字化和由此产生的第三方云服务是影响架构的主要趋势。
893
894
895 业务和技术趋势都影响产品和服务架构。这应该在组织架构中反映，并在计划目标架构和路线图时加以考虑。为了解决此问题，架构管理实践应该与其他实践紧密结合，包括：产品组合管理、供应商管理、组织变革管理、风险管理、基础设施和平台管理，当然还有战略管理。
896
897
898
899
900 ----
901
902 = 7. 重要提醒 =
903
904 组织在建立和培养自己的实践时，应该把实践指南的大部分内容作为可以考虑的领域建议。实践指南是组织可以考虑的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
905
906 * 聚焦价值
907 * 从你所处的地方开始
908 * 基于反馈迭代推进
909 * 协作和提升可视化程度
910 * 通盘思考和工作
911 * 保持简单实用
912 * 优化和自动化。
913
914 有关指导原则及其应用程序的更多信息，请参见以下内容的第4.3节。
915
916 //ITIL®Foundation：ITIL 4版出版物。//
917
918
919
920
921 ----
922
923 = 8. 致谢 =
924
925 AXELOS公司由衷感谢为本指南的开发做出贡献的全体人员。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
926
927
928 == **8.1 作者** ==
929
930 帕维尔·德明（Pavel Demin），罗马·朱拉夫列夫(Jouravlev)
931
932
933 == **8.2 审稿人** ==
934
935 黛娜拉·阿迪尔巴耶娃（Dinara Adyrbayeva），安东·利科夫（Anton Lykov），伊琳娜·马坦察娃(Jouravlev)
深圳市艾拓先锋企业管理咨询有限公司