Wiki源代码通用管理实践 - 33 架构
由 superadmin 于 2024/12/25, 15:37 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{info}} | ||
| 2 | |||
| 3 | {{/info}} | ||
| 4 | |||
| 5 | |||
| 6 | **申明:** | ||
| 7 | |||
| 8 | 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号:ITILXF**,并回复“**ITIL 4架构管理**”即可。 | ||
| 9 | |||
| 10 | |||
| 11 | 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 | ||
| 12 | |||
| 13 | |||
| 14 | 本文档翻译工作参与人员: | ||
| 15 | |||
| 16 | 翻译:张志华 | ||
| 17 | |||
| 18 | 审校:魏钧军 | ||
| 19 | |||
| 20 | |||
| 21 | 总审:长河 | ||
| 22 | |||
| 23 | 审核:戚依军 | ||
| 24 | |||
| 25 | 统筹:常宏 | ||
| 26 | |||
| 27 | |||
| 28 | |||
| 29 | ---- | ||
| 30 | |||
| 31 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
| 32 | {{toc/}} | ||
| 33 | {{/box}} | ||
| 34 | |||
| 35 | = 1 关于本文件 = | ||
| 36 | |||
| 37 | 本文档为架构管理实践提供了实用指南。它分为五个主要部分,内容包括: | ||
| 38 | |||
| 39 | * 实践的一般信息 | ||
| 40 | * ((( | ||
| 41 | 实践的流程和活动及其在服务价值链中的作用 | ||
| 42 | ))) | ||
| 43 | * 实践中涉及的组织和人员 | ||
| 44 | * 支持实践的信息和技术 | ||
| 45 | * 有关实践的合作伙伴和供应商注意事项。 | ||
| 46 | |||
| 47 | == **1.1 ITIL^^®^^4鉴证方案** == | ||
| 48 | |||
| 49 | 本文档中的选定内容可作为以下教学大纲的部分考试范围: | ||
| 50 | |||
| 51 | * **I**TIL专家-高速IT。 | ||
| 52 | |||
| 53 | 有关详细信息,请参阅相应的教学大纲文档。 | ||
| 54 | |||
| 55 | |||
| 56 | |||
| 57 | ---- | ||
| 58 | |||
| 59 | = **2 一般信息** = | ||
| 60 | |||
| 61 | |||
| 62 | == 2.1目的与描述 == | ||
| 63 | |||
| 64 | 全面的架构管理实践适用于所有级别的组织架构。主要包括: | ||
| 65 | |||
| 66 | * 业务架构 | ||
| 67 | * 产品和服务架构 | ||
| 68 | * 信息系统架构,包括数据和应用程序架构 | ||
| 69 | * 技术架构 | ||
| 70 | * 环境架构。 | ||
| 71 | |||
| 72 | 实践的范围由组织的定位、愿景和战略定义。例如,内部IT服务提供商的架构管理实践可能专注于其产品、服务、信息系统和技术的架构。在其他情况下,如果第三方为组织提供基础架构和平台,则其范围可能不包含较低级别的技术架构。这也可能会反映在IT系统架构中。但是,我们应该在组织的所有级别,以及架构的所有级别上始终如一的开发架构管理实践。 | ||
| 73 | |||
| 74 | |||
| 75 | 架构管理实践应该描述组织的服务价值系统和所有服务管理四维模型的资源,它们是: | ||
| 76 | |||
| 77 | * 组织和人员 | ||
| 78 | * 信息和技术 | ||
| 79 | * 流程和价值流 | ||
| 80 | * 供应商和合作伙伴。 | ||
| 81 | |||
| 82 | 图2.1中对此进行了说明。 | ||
| 83 | |||
| 84 | (% style="text-align:center" %) | ||
| 85 | [[image:1639633625741-287.png]] | ||
| 86 | |||
| 87 | 图2.1 架构级别和服务管理四维模型 | ||
| 88 | |||
| 89 | |||
| 90 | 架构管理实践可以确保: | ||
| 91 | |||
| 92 | * 理解组织的当前架构,并映射到组织的战略 | ||
| 93 | * 识别并商定目标组织的架构 | ||
| 94 | * 不断优化组织的架构,以实现其目标架构。 | ||
| 95 | |||
| 96 | 为了实现这些目标,架构师分析组织并描述当前架构。并评估其当前架构,旨在识别当前或未来可能阻碍组织战略实现的可优化之处。定义目标架构用以解决这些阻碍。架构管理实践允许组织从其当前的架构演变为所需的架构;它还允许随着组织的策略和环境变化,在过程中修正。 | ||
| 97 | |||
| 98 | |||
| 99 | |||
| 100 | == 2.2 **术语和概念** == | ||
| 101 | |||
| 102 | 架构管理实践包含几种类型或级别的架构。下面将进一步详细描述。 | ||
| 103 | |||
| 104 | |||
| 105 | |||
| 106 | === **2.2.1 业务架构** === | ||
| 107 | |||
| 108 | **定义:业务架构** | ||
| 109 | |||
| 110 | 组织如何使用资源实现其战略和目标的正式描述。 | ||
| 111 | |||
| 112 | |||
| 113 | 业务架构探索组织如何使用资源在组织内与其利益相关者共创价值。组织使用资源来创建产品,并基于这些产品提供和交付服务。 | ||
| 114 | |||
| 115 | |||
| 116 | === **2.2.2 产品和服务架构** === | ||
| 117 | |||
| 118 | **定义:产品和服务架构** | ||
| 119 | |||
| 120 | 对组织的产品和服务、组件及其相互关系、管理设计及其随时间演变的原则和指南的正式描述。 | ||
| 121 | |||
| 122 | |||
| 123 | 产品和服务架构提供了组织的产品和服务的全景图。它还探讨了服务和描述结构的模型之间的交互,例如组件如何装配在一起,例如活动和资源流的动态,以及每个产品和服务的交互。这些模型可以作为多种产品和服务的模板。和支持信息技术、运营技术和通信技术一样,数字化产品和服务基于应用和数据。 | ||
| 124 | |||
| 125 | |||
| 126 | === **2.2.3 信息系统架构** === | ||
| 127 | |||
| 128 | **定义:信息系统架构** | ||
| 129 | |||
| 130 | 对组织的应用、数据资产和数据管理资源的正式描述。信息系统架构展示了应用和数据如何互连和管理,以使组织受益。 | ||
| 131 | |||
| 132 | |||
| 133 | 信息系统由基础设施和平台支撑,整合了信息、运营和通信技术。这些在技术架构中有正式描述。 | ||
| 134 | |||
| 135 | |||
| 136 | === **2.2.4 技术架构** === | ||
| 137 | |||
| 138 | **定义:技术架构** | ||
| 139 | |||
| 140 | 对组织的技术基础设施的正式描述,包括信息、运营和通信技术,它们的相互关系以及对组织信息系统的支持方式。 | ||
| 141 | |||
| 142 | |||
| 143 | === **2.2.5 环境架构** === | ||
| 144 | |||
| 145 | **定义:环境架构** | ||
| 146 | |||
| 147 | 影响组织和驱动变更的外部因素,以及环境控制和管理的所有方面、类型和级别的正式描述。 | ||
| 148 | |||
| 149 | |||
| 150 | 组织可能会发现保留其运作环境的说明大有裨益,可以确保其产品和服务适应环境,并且不与外部约束相冲突。 | ||
| 151 | |||
| 152 | 环境架构包括:开发、技术、业务、运营、组织、政治、经济、法律、法规、生态和社会影响。它可以帮助组织了解和管理其在所处的生态系统中的定位。 | ||
| 153 | |||
| 154 | 架构管理实践包括范围的定义和架构的结构,该实践基于组织的战略和定位。 | ||
| 155 | |||
| 156 | |||
| 157 | |||
| 158 | == 2.3 **范围** == | ||
| 159 | |||
| 160 | 架构管理实践的范围包括: | ||
| 161 | |||
| 162 | * 了解和描述组织的当前架构 | ||
| 163 | * 定义组织的目标架构,并与相关利益相关者达成一致 | ||
| 164 | * 持续优化组织,以满足目标架构 | ||
| 165 | * 持续监督进行中的变更,以确保与商定的目标架构保持一致。 | ||
| 166 | |||
| 167 | 若干活动和职责领域尽管与架构实践密切相关,但不在架构管理实践的范围内。表2.1中列出了这些内容,以及可以找到它们的实践的引用。重要的是要记住,ITIL实践只是用于价值流上下文中的工具集合,应视情况按需组合。 | ||
| 168 | |||
| 169 | |||
| 170 | 表2.1其他实践指南中描述的架构管理实践的相关活动 | ||
| 171 | |||
| 172 | (% style="width:411px" %) | ||
| 173 | |(% style="width:274px" %)**活动**|(% style="width:134px" %)**实践指南** | ||
| 174 | |(% style="width:274px" %)解决方案设计(产品、服务、信息系统和技术)|(% style="width:134px" %)服务设计 | ||
| 175 | |(% style="width:274px" %)架构实施路线图|(% style="width:134px" %)((( | ||
| 176 | 项目管理 | ||
| 177 | |||
| 178 | 变更支持 | ||
| 179 | |||
| 180 | 组织变革管理 | ||
| 181 | ))) | ||
| 182 | |(% style="width:274px" %)架构选型的投资决策和授权|(% style="width:134px" %)投资组合管理 | ||
| 183 | |(% style="width:274px" %)组织方向和目标的定义|(% style="width:134px" %)战略管理 | ||
| 184 | |(% style="width:274px" %)配置项目和资产的详细映射|(% style="width:134px" %)((( | ||
| 185 | 服务配置管理 | ||
| 186 | |||
| 187 | IT资产管理 | ||
| 188 | ))) | ||
| 189 | |||
| 190 | == 2.4 **实践成功因素** == | ||
| 191 | |||
| 192 | **定义:实践成功因素** | ||
| 193 | |||
| 194 | 实践的复杂功能组件,用于实现实践目的。 | ||
| 195 | |||
| 196 | |||
| 197 | 实践成功因素(PSF)不仅仅是一项任务或活动,它还包括所有服务管理四维模型的组件。活动的特性和实践成功因素PSF的资源可能有所不同,但它们共同确保实践有效。 | ||
| 198 | |||
| 199 | |||
| 200 | 架构管理实践包含以下实践成功因素PSF: | ||
| 201 | |||
| 202 | * 确保目标架构支持组织的战略 | ||
| 203 | * 确保组织的架构不断朝目标状态演进 | ||
| 204 | |||
| 205 | === **2.4.1 确保目标架构支持组织的战略** === | ||
| 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 | |||
| 231 | 由于组织的战略可能会不断演进,因此架构建模不应该是孤立的工作。当前的架构模型应随着组件变化而调整,并应根据战略的变化来审查目标架构模型。这些更新将启动架构路线图的评审(请参见[[2.4.2>>path:#_bookmark0]]) | ||
| 232 | |||
| 233 | 架构分析和目标架构规划与其他实践紧密结合进行(有关这些实践的列表,请参见2.3)。重要的是要确保架构模型正确、现实,并且与利益相关者共享对当前和目标架构的理解。现实的架构计划基于对当前架构的充分理解,包括被内部和外部利益相关者采用的遗留系统、约束、重要的业务功能和行为模式。考虑其他要求和约束,例如预算,法规等。最后,对技术前景(包括新兴技术和行业趋势)的充分了解非常重要。 | ||
| 234 | |||
| 235 | 除了描述目标架构之外,路线图还应包括以下方面的建议和要求:分类法、标准、指南、流程、模板和工具,并用于具有重要架构意义的举措(例如生产和服务设计、变更和项目等)。这包括将推荐的架构控件集成到相关实践和价值流中,以确保组织的活动与商定的发展方向一致。 | ||
| 236 | |||
| 237 | |||
| 238 | === **2.4.2 确保组织的架构不断朝目标状态演进** === | ||
| 239 | |||
| 240 | 创建架构路线图可以确保组织朝目标架构演进。路线图是旨在从当前架构更改到目标架构的一系列设计计划。在适当情况下,可以将这些计划作为项目集或项目进行管理。实现架构变更涉及多个利益相关者和实践,视变更的性质而定。架构管理实践确保所实施的变更遵循商定的路线图,并支持组织向其目标架构演进。 | ||
| 241 | |||
| 242 | |||
| 243 | **关键信息** | ||
| 244 | |||
| 245 | 从当前的架构到目标架构的转换几乎不是一场革命。相反,它是由组织同意遵循的一组架构原理、标准和准则促成的演进。一些旧解决方案可能会与新解决方案共存很长时间。从当前架构到目标架构的变更始终取决于投资组合决策和谨慎的优先级。架构管理实践用于定义目标架构,并保持一致的架构演进方向和步伐。 | ||
| 246 | |||
| 247 | |||
| 248 | 架构管理实践活动的另一个重要方面是,它通过遵循推荐的架构分类法、标准、指南、流程、模板和工具,确保其对组织的资源、产品和服务所做的变更支持架构的演进。它们也不应与架构的要求和原理相抵触。这意味着架构管理实践涉及每个服务价值流,其中包括引入新组件、新的第三方服务或其他影响架构的变更。 | ||
| 249 | |||
| 250 | |||
| 251 | == 2.5 **关键指标** == | ||
| 252 | |||
| 253 | ITIL 实践的有效性和绩效应在每个实践所贡献的价值流背景内进行评估。与任何工具的性能或绩效一样,实践的绩效只能在应用程序的背景下评估。但是,工具在设计和质量上可能会有很大差异,这些差异决定了工具在根据其用途使用时有效的潜力或能力。与指标、关键绩效指标(KPI)和其他相关技术的进一步指导,请参见测量和报告实践指南。 | ||
| 254 | |||
| 255 | |||
| 256 | 架构管理实践的关键指标已映射到其实践成功因素PSF。在价值流中,它们可以作为KPI,以评估实践对价值流有效性和效率的贡献。表2.2中给出了一些关键指标的示例。 | ||
| 257 | |||
| 258 | 表2.2 实践成功因素的关键指标示例 | ||
| 259 | |||
| 260 | |||
| 261 | (% style="width:535px" %) | ||
| 262 | |(% style="width:212px" %)**实践成功因素**|(% style="width:321px" %)**关键指标** | ||
| 263 | |(% style="width:212px" %)确保目标架构支持组织的战略|(% style="width:321px" %)((( | ||
| 264 | 对目标架构的商定要求的实施情况 | ||
| 265 | |||
| 266 | 限制组织战略实现的架构约束的数量和影响 | ||
| 267 | |||
| 268 | 架构不支持的战略决策的数量和影响 | ||
| 269 | |||
| 270 | 基于内部和独立评估,目标架构的完整性和质量 | ||
| 271 | |||
| 272 | 战略更新和目标架构对齐之间的延迟时间和影响 | ||
| 273 | ))) | ||
| 274 | |(% style="width:212px" %)确保组织的架构不断朝目标状态演进|(% style="width:321px" %)((( | ||
| 275 | 未遵循商定的目标架构实施的变更数量和影响 | ||
| 276 | |||
| 277 | 尚未评估是否符合商定的架构的重大更改的数量和影响 | ||
| 278 | |||
| 279 | 架构路线图的实施进度 | ||
| 280 | ))) | ||
| 281 | |||
| 282 | ---- | ||
| 283 | |||
| 284 | = **3.价值流和流程** = | ||
| 285 | |||
| 286 | |||
| 287 | == **3.1价值流的贡献** == | ||
| 288 | |||
| 289 | 与任何其他ITIL 管理实践一样,架构管理实践有助于多个价值流。重要的是要记住,价值流永远不会由单个实践构成。架构管理实践与其他实践相结合,可以为消费者提供高质量服务。该实践促成的主要价值链活动包括: | ||
| 290 | |||
| 291 | * 契动 | ||
| 292 | * 交付和支持 | ||
| 293 | * 设计和转换 | ||
| 294 | * 改进 | ||
| 295 | * 获取/构建 | ||
| 296 | * 计划。 | ||
| 297 | |||
| 298 | 图3.1中显示了架构管理实践对服务价值链的贡献。 | ||
| 299 | |||
| 300 | (% style="text-align:center" %) | ||
| 301 | [[image:1639652021295-354.png]] | ||
| 302 | |||
| 303 | 图3.1:架构管理实践对服务价值链活动的贡献热图 | ||
| 304 | |||
| 305 | |||
| 306 | == 3.2 **流程** == | ||
| 307 | |||
| 308 | 每个实践可能包含一个或多个流程和活动,它们对于实现该实践的目的可能是必需的。 | ||
| 309 | |||
| 310 | |||
| 311 | 架构管理活动构成三个流程: | ||
| 312 | |||
| 313 | * 架构治理 | ||
| 314 | * 目标架构的开发和路线图 | ||
| 315 | * 持续的架构控制。 | ||
| 316 | |||
| 317 | === **3.2.1 架构治理** === | ||
| 318 | |||
| 319 | 该流程包括表3.1中列出的活动,并将输入转换为输出。 | ||
| 320 | |||
| 321 | 表3.1 架构治理流程的输入、活动和输出 | ||
| 322 | |||
| 323 | (% style="width:448px" %) | ||
| 324 | |(% style="width:178px" %)**关键输入**|(% style="width:147px" %)**活动**|(% style="width:121px" %)**关键输出** | ||
| 325 | |(% style="width:178px" %)((( | ||
| 326 | 组织的原则、政策和愿景 | ||
| 327 | |||
| 328 | 组织战略 | ||
| 329 | |||
| 330 | 环境因素 | ||
| 331 | |||
| 332 | 组织结构 | ||
| 333 | |||
| 334 | 产品和服务组合 | ||
| 335 | |||
| 336 | 项目集和项目组合 | ||
| 337 | |||
| 338 | 客户组合 | ||
| 339 | |||
| 340 | 架构评审报告 | ||
| 341 | |||
| 342 | 审计报告 | ||
| 343 | )))|(% style="width:147px" %)((( | ||
| 344 | 分析组织和需求 | ||
| 345 | |||
| 346 | 开发和商定架构愿景 | ||
| 347 | |||
| 348 | 监控组织架构 | ||
| 349 | )))|(% style="width:121px" %)((( | ||
| 350 | 架构愿景 | ||
| 351 | |||
| 352 | 架构原则和需求 | ||
| 353 | ))) | ||
| 354 | |||
| 355 | 图3.2显示了流程的工作流程图。 | ||
| 356 | |||
| 357 | (% style="text-align:center" %) | ||
| 358 | [[image:1639652084225-518.png]] | ||
| 359 | |||
| 360 | 图3.2 架构治理流程的工作流程 | ||
| 361 | |||
| 362 | |||
| 363 | 表3.2 提供了架构治理流程的每个活动的高级描述示例。 | ||
| 364 | |||
| 365 | 表3.2 架构治理流程的活动 | ||
| 366 | |||
| 367 | [[image:1642347329479-489.png]] | ||
| 368 | |||
| 369 | |||
| 370 | |||
| 371 | === **3.2.2 开发目标架构和路线图** === | ||
| 372 | |||
| 373 | 该流程包括表3.3中列出的活动,并将输入转换为输出。 | ||
| 374 | |||
| 375 | 表3.3开发目标架构和路线图流程的输入、活动和输出 | ||
| 376 | |||
| 377 | [[image:1642347369294-278.png]] | ||
| 378 | |||
| 379 | 图3.3展示了开发目标架构和路线图流的工作流程。 | ||
| 380 | |||
| 381 | |||
| 382 | (% style="text-align:center" %) | ||
| 383 | [[image:1639652207003-419.png]] | ||
| 384 | |||
| 385 | 图3.3 开发目标架构和路线图流的工作流程 | ||
| 386 | |||
| 387 | |||
| 388 | |||
| 389 | 表3.4提供了开发目标架构的的每个活动和路线图流程的高级描述示例。 | ||
| 390 | |||
| 391 | 表3.4 开发目标架构的活动和路线图流程 | ||
| 392 | |||
| 393 | [[image:1642347401801-811.png]] | ||
| 394 | |||
| 395 | [[image:1642347419127-482.png]] | ||
| 396 | |||
| 397 | (% class="wikigeneratedid" %) | ||
| 398 | | ||
| 399 | |||
| 400 | === **3.2.3 持续架构控制** === | ||
| 401 | |||
| 402 | 该流程侧重实施架构路线图和维护商定的架构。它包括表3.5所示的活动,并将输入转换为输出。 | ||
| 403 | |||
| 404 | |||
| 405 | 表3.5持续的架构控制流程的输入、活动和输出 | ||
| 406 | |||
| 407 | [[image:1642347456836-578.png]] | ||
| 408 | |||
| 409 | 图3.4显示了持续架构控制流程的工作流。 | ||
| 410 | |||
| 411 | |||
| 412 | (% style="text-align:center" %) | ||
| 413 | [[image:1639652311065-812.png]] | ||
| 414 | |||
| 415 | |||
| 416 | 图3.4持续的架构控制流程的工作流 | ||
| 417 | |||
| 418 | |||
| 419 | 表3.6提供了持续的架构控制流程的每个活动的高级描述示例。 | ||
| 420 | |||
| 421 | 表3.6持续的架构控制流程的活动 | ||
| 422 | |||
| 423 | [[image:1642347565286-197.png]] | ||
| 424 | |||
| 425 | |||
| 426 | |||
| 427 | ---- | ||
| 428 | |||
| 429 | = **4. 组织和人员** = | ||
| 430 | |||
| 431 | |||
| 432 | == 4.1 **角色、能力和责任** == | ||
| 433 | |||
| 434 | 实践指南没有描述实践管理角色,例如实践负责人、实践主管或实践教练,相反,专注于每个实践特有的专业角色。每个角色的结构和命名都可能因组织而异,因此,ITIL中定义的任何角色都不是强制性的,甚至不推荐使用。请记住,角色不是职务。一个人可以担任多个角色,一个角色可以分配给多个人。 | ||
| 435 | |||
| 436 | 角色在流程和活动的上下文中有所描述。每个角色均具有基于以下模型的能力简介,如表4.1中所示。 | ||
| 437 | |||
| 438 | 表4.1 能力代码和简介 | ||
| 439 | |||
| 440 | (% style="width:567px" %) | ||
| 441 | |(% style="width:102px" %)**能力代码**|(% style="width:463px" %)**能力简介(活动和技能)** | ||
| 442 | |(% style="width:102px" %)L|(% style="width:463px" %)领导者,决策、授权、监督其他活动,提供激励和动机以及评估结果 | ||
| 443 | |(% style="width:102px" %)A|(% style="width:463px" %)管理员,分配任务并确定优先级,保留记录,持续报告,并启动基本改进 | ||
| 444 | |(% style="width:102px" %)C|(% style="width:463px" %)协调员/沟通者,协调多方,保持利益相关者之间的沟通,以及开展认知活动 | ||
| 445 | |(% style="width:102px" %)M|(% style="width:463px" %)方法和技术专家,设计和实施工作技术、记录流程、咨询流程、分析工作和持续改进 | ||
| 446 | |(% style="width:102px" %)T|(% style="width:463px" %)技术专家,提供技术(IT)专业知识,并执行基于专业知识的任务 | ||
| 447 | |||
| 448 | 表4.2 负责架构管理活动的角色示例 | ||
| 449 | |||
| 450 | [[image:1642347629619-777.png]] | ||
| 451 | |||
| 452 | [[image:1642347663018-564.png]] | ||
| 453 | |||
| 454 | [[image:1642347699613-952.png]] | ||
| 455 | |||
| 456 | [[image:1642347711178-534.png]] | ||
| 457 | |||
| 458 | |||
| 459 | |||
| 460 | === **4.1.1 架构师** === | ||
| 461 | |||
| 462 | 架构师是特定实践的关键角色。该角色可以是专职的,例如业务(或企业)架构师、IT架构师或解决方案架构师,具体取决于实践范围。 | ||
| 463 | |||
| 464 | |||
| 465 | 架构师的角色是架构管理实践的关键。如上表4.2中所述,大多数实践活动由架构师执行或管理。 | ||
| 466 | |||
| 467 | |||
| 468 | 架构师的主要能力包括: | ||
| 469 | |||
| 470 | * 了解本组织和服务的客户组织的业务策略、业务模型和运营模式 | ||
| 471 | * 了解组织运营的环境 | ||
| 472 | * 具备组织使用的技术知识以及组织可用的开发技术知识 | ||
| 473 | * 具备组织产品组合的知识:资源、产品和服务、客户 | ||
| 474 | * 了解组织的价值流和实践 | ||
| 475 | * 架构管理框架(例如Zachman框架TM,TOGAF®)的专业知识 | ||
| 476 | * 相关解决方案架构框架(例如AWS,SOA,EMC等)的专业知识。 | ||
| 477 | |||
| 478 | 架构师的能力简介是TMCAL。架构师是组织的资源和架构管理方法的专家。但是,其沟通和领导技能也很重要。 | ||
| 479 | |||
| 480 | |||
| 481 | 组织中的架构师职责可能会有所不同,具体取决于实践的范围。业务(企业)架构师致力于组织的战略性规划和业务开发,而解决方案架构师则专注于特定产品或系统的架构。 | ||
| 482 | |||
| 483 | |||
| 484 | 找到专门的职位来担任架构师角色的情况并不少见。但是,在较小的组织中,解决方案架构师角色有时由产品负责人担任,而业务架构师角色由执行领导者履行,通常是临时担任的。 | ||
| 485 | |||
| 486 | |||
| 487 | |||
| 488 | == 4.2 **组织结构和团队** == | ||
| 489 | |||
| 490 | 当组织开发架构管理实践时,许多人发现组建专门的团队很有用,旨在驱动架构相关计划并确持续构控制。该团队通常被称为架构委员会,由来自组织的不同级别和部门的代表组成。除架构师外,该委员会通常还包括业务职能领导、产品负责人、服务设计师、风险经理、产品组合经理、人力资源经理和财务经理。 | ||
| 491 | |||
| 492 | |||
| 493 | 架构委员会(有时被称为架构董事会)通常向执行领导团队报告。委员会的决策影响组织的所有领域。 | ||
| 494 | |||
| 495 | 因此,确保委员会拥有足够的权力非常重要。 | ||
| 496 | |||
| 497 | |||
| 498 | |||
| 499 | ---- | ||
| 500 | |||
| 501 | = 5. 信息和技术 = | ||
| 502 | |||
| 503 | |||
| 504 | == **5.1 信息沟通** == | ||
| 505 | |||
| 506 | 架构管理实践的效果取决于所使用信息的质量。这包括但不限于以下信息: | ||
| 507 | |||
| 508 | * 组织的战略 | ||
| 509 | * 组织的环境、主要利益相关者 | ||
| 510 | * 组织的产品组合:资源、产品和服务、客户 | ||
| 511 | * 服务配置和IT资产信息 | ||
| 512 | * 变更排期 | ||
| 513 | * 项目集和项目组合 | ||
| 514 | * 持续改进登记册 | ||
| 515 | * 组织架构 | ||
| 516 | * 技术趋势。 | ||
| 517 | |||
| 518 | 该信息可以采用各种形式。在第3节中列出了实践的关键输入和输出。 | ||
| 519 | |||
| 520 | |||
| 521 | == 5.2 **自动化和工具** == | ||
| 522 | |||
| 523 | 架构管理实践的自动化侧重于加强信息交流的三个主要领域: | ||
| 524 | |||
| 525 | * 办公自动化工具:文档、电子表格和演示文稿工具 | ||
| 526 | * 分析和建模工具,例如:计算机辅助设计、图表和数据建模工具 | ||
| 527 | * 通信工具,例如:工作流、任务管理和全渠道通信系统。 | ||
| 528 | |||
| 529 | 表5.1列出了每一个与架构管理实践相关的特定自动化方法。 | ||
| 530 | |||
| 531 | |||
| 532 | 表5.1架构管理活动的自动化解决方案 | ||
| 533 | |||
| 534 | [[image:1642347760716-928.png]] | ||
| 535 | |||
| 536 | [[image:1642347780775-504.png]] | ||
| 537 | |||
| 538 | [[image:1642347802926-668.png]] | ||
| 539 | |||
| 540 | |||
| 541 | |||
| 542 | ---- | ||
| 543 | |||
| 544 | = 6. 合作伙伴和供应商 = | ||
| 545 | |||
| 546 | 组织的架构应该支持其战略,并确保组织的所有组件有效地为其成功助力。架构不限于组织自己的资源。它包括组织的服务组合及其与其服务使用者的交互方式。但是,不应低估第三方服务。 | ||
| 547 | |||
| 548 | |||
| 549 | 在业务架构级别上,重要的趋势包括多源、服务集成和管理(或换而言之:非中间媒介)。在技术架构级别上,数字化和由此产生的第三方云服务是影响架构的主要趋势。 | ||
| 550 | |||
| 551 | |||
| 552 | 业务和技术趋势都影响产品和服务架构。这应该在组织架构中反映,并在计划目标架构和路线图时加以考虑。为了解决此问题,架构管理实践应该与其他实践紧密结合,包括:产品组合管理、供应商管理、组织变革管理、风险管理、基础设施和平台管理,当然还有战略管理。 | ||
| 553 | |||
| 554 | |||
| 555 | |||
| 556 | |||
| 557 | ---- | ||
| 558 | |||
| 559 | = 7. 重要提醒 = | ||
| 560 | |||
| 561 | 组织在建立和培养自己的实践时,应该把实践指南的大部分内容作为可以考虑的领域建议。实践指南是组织可以考虑的事情的目录,而不是答案的列表。使用ITIL 实践指南的内容时,组织应始终遵循ITIL 指导原则: | ||
| 562 | |||
| 563 | * 聚焦价值 | ||
| 564 | * 从你所处的地方开始 | ||
| 565 | * 基于反馈迭代推进 | ||
| 566 | * 协作和提升可视化程度 | ||
| 567 | * 通盘思考和工作 | ||
| 568 | * 保持简单实用 | ||
| 569 | * 优化和自动化。 | ||
| 570 | |||
| 571 | 有关指导原则及其应用程序的更多信息,请参见以下内容的第4.3节。 | ||
| 572 | |||
| 573 | //ITIL®Foundation:ITIL 4版出版物。// | ||
| 574 | |||
| 575 | |||
| 576 | |||
| 577 | |||
| 578 | ---- | ||
| 579 | |||
| 580 | = 8. 致谢 = | ||
| 581 | |||
| 582 | AXELOS公司由衷感谢为本指南的开发做出贡献的全体人员。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。 | ||
| 583 | |||
| 584 | |||
| 585 | == **8.1 作者** == | ||
| 586 | |||
| 587 | 帕维尔·德明(Pavel Demin),罗马·朱拉夫列夫(Jouravlev) | ||
| 588 | |||
| 589 | |||
| 590 | == **8.2 审稿人** == | ||
| 591 | |||
| 592 | 黛娜拉·阿迪尔巴耶娃(Dinara Adyrbayeva),安东·利科夫(Anton Lykov),伊琳娜·马坦察娃(Jouravlev) |