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