架构合规性审查清单指南
内容提要
本章提供了确保项目符合架构的指南，包括架构功能和IT治理功能的互补流程，架构合规性审查的目标和动机，以及架构合规性审查清单的应用。
延伸解读
合规审查的双重流程：影响评估与正式审查
文章指出，确保项目符合企业架构需要两个互补流程：架构职能准备项目影响评估，说明企业架构如何影响具体项目；IT治理职能定义正式的架构合规性审查流程。这种分工意味着合规不是单一检查点，而是贯穿项目前期的架构影响分析与后期的正式审查相结合。读者应关注这两个流程在组织中的实际衔接方式，避免影响评估流于形式或审查滞后。
合规审查的政治动机：超越质量保证
除了尽早发现错误、应用最佳实践等质量目标，文章还揭示了合规审查的政治性动机：帮助业务决策者在架构替代方案间做出更符合业务利益的选择；为CIO提供可衡量的决策依据；让架构组织参与原本可能绕开架构的开发项目；以及展示架构对业务社区的快速支持。这些动机说明合规审查不仅是技术活动，也是架构团队争取影响力和资源的手段。
清单的使用原则：定制、聚焦与科学提问
文章强调，提供的清单问题过多，任何单一审查都应有选择地定制，通常由主题专家开发或选择。定制时应聚焦高风险领域和预期差异化因素，并理解每个问题背后的原理及回复中应寻找的内容。进行审查时要保持科学态度，用事实和数据支撑建议，提出开放式问题，尊重受访者，并清楚了解征求审查者的目的，避免偏离主题。
不遵守架构的价值：豁免作为变更信号
文章指出，虽然开发和实施需要遵守架构，但不遵守也提供了一种机制来强调需要调整的领域，以及集成到架构中需要考虑的领域。这承认了架构的持续变化和对不守纪律驱动需求的适应性，同时允许通过操作环境中更快的变化来注册变更。通常使用豁免来突出这些变更，并启动流程来注册、监控和评估所需变更的适用性。读者应关注豁免流程是否被有效利用，而非简单视为违规。
Q&A
架构合规性审查的主要目的是什么？
架构合规性审查的主要目的包括：尽早发现项目架构中的错误，以降低后期变更的成本和风险；确保最佳实践应用于架构工作；概述架构与强制企业标准的合规性；确定标准本身可能需要修改的地方；识别可作为企业基础架构一部分提供的服务；记录架构团队间的协作策略；利用技术进步；与管理层沟通项目的技术准备状态；确定采购活动的关键标准；识别重大架构差距并向产品和服务提供商传达。
架构合规性审查清单通常包含哪些领域的典型问题？
清单问题涉及系统工程、信息管理、安全和系统管理等基础学科。具体包括硬件和操作系统、软件服务和中间件、应用、应用集成方法、信息管理、安全/保护、系统管理、系统工程/总体架构、处理器/服务器/客户端、应用服务器、数据服务器、COTS、系统工程/方法和工具等领域。
进行架构合规性审查时有哪些实用指南？
指南包括：定制清单时专注于高风险地区和预期的差异化因素；对于每个问题，了解问题本身、其背后的原理以及在回复中寻找什么；询问学科专家的意见；修复清单问题供自己使用；记住向架构委员会提供反馈。进行审查时，要清楚了解征求审查者的目的，保持正轨；保持科学态度，提出开放式问题；采用非个性化的讨论方式；尊重接受采访的人；帮助练习成为学习经历；审查应包括详细评估活动，并确保结果存储在企业连续体中。
架构合规性审查的输出对CIO有什么价值？
架构合规性审查的输出是为CIO提供的少数可衡量的可交付成果之一，可帮助其做出决策。它有助于CIO了解项目的技术准备状态，识别重大架构差距，并确保IT项目与业务目标保持一致。
架构合规性审查与IT治理功能之间是什么关系？
IT治理功能通常会定义两个互补流程：架构功能准备项目影响评估，说明企业架构如何影响主要项目；IT治理功能定义正式的架构合规性审查流程，用于审查项目是否符合企业架构。此外，架构治理职能还可规定架构职能参与技术选择、外部服务提供和产品采购等商业关系，以最小化误解并最大化集中商业谈判的价值。
架构合规性审查清单中的问题是如何组织和使用的？
清单问题按系统工程、信息管理、安全和系统管理等基础学科组织。清单基于The Open Group成员提供的材料，包含太多问题，旨在针对相关项目有选择地进行定制。实际使用的清单通常由主题专家开发/选择，并打算每年更新。一些清单包括对引发问题的架构原理的简要描述，以及对答案中寻找内容的简要描述。问题可以书面形式（如RFP中）或口头表达（如项目采访或工作会议中）。清单旨在用于单个架构项目，而不是业务域架构或跨多个项目的架构。
