本章提供了确保项目符合架构的指南。
确保单个项目符合企业架构是架构治理的一个重要方面（见架构治理）。为此，企业内的 IT 治理功能通常会定义两个互补流程：
- 架构功能将被要求准备一系列项目影响评估（见项目影响评估（项目切片））；即企业架构的特定项目视图，说明企业架构如何影响组织内的主要项目。(这些有时也被称为架构中的项目切片）。
- IT 治理功能将定义一个正式的架构合规性审查流程（见架构合规性审查），用于审查项目是否符合企业架构。
除了定义正式流程外，架构治理（见架构治理）职能还可规定，架构职能应超越架构定义和标准选择的角色，还应参与技术选择流程，甚至参与外部服务提供和产品采购所涉及的商业关系。这可能有助于最大限度地减少误解企业架构的机会，并最大限度地提高集中商业谈判的价值。
术语 - 架构符合性的含义
架构与实施之间的关键关系在于 "符合"、"遵从 "等术语的定义。虽然不同组织使用的术语可能不同，但《架构符合性等级》中说明的符合性等级概念应有助于制定 IT 符合性战略。
架构合规性审查
架构合规性审查是根据既定的架构标准、精神和业务目标对特定项目的合规性进行的审查。此类审查的正式流程通常构成企业架构合规性策略的核心。
目的
架构合规性审查的目标包括以下部分或全部：
- 首先也是最重要的是，尽早发现项目架构中的错误，从而降低生命周期后期所需的变更的成本和风险。这反过来意味着整个项目时间缩短，业务更快地获得架构开发的底线效益。
- 确保将最佳实践应用于架构工作。
- 概述架构与强制企业标准的合规性。
- 确定标准本身可能需要修改的地方。
- 识别当前特定于应用程序但可能作为企业基础架构的一部分提供的服务。
- 记录多个架构团队之间的协作、资源共享和其他协同作用的策略。
- 利用技术进步。
- 与管理层沟通项目的技术准备状态。
- 确定采购活动的关键标准（例如，包含在商业现货 (COTS) 产品 RFI/RFP 文件中）。
- 识别重大架构差距并向产品和服务提供商传达。
除了上述与质量保证相关的一般目标之外，进行架构合规性审查还有其他更具政治导向的动机，这在特定情况下可能相关：
- 架构合规性审查可能是在架构替代方案之间做出决定的好方法，因为通常参与审查的业务决策者可以根据什么对业务最有利来指导决策，而不是在技术上更令人愉悦或优雅。
- 架构合规性审查的输出是为 CIO 提供的少数可衡量的可交付成果之一，可帮助其做出决策。
- 架构审查可以作为架构组织参与开发项目的一种方式，否则这些项目可能会在架构功能不参与的情况下继续进行。
- 架构审查可以展示对企业业务社区的快速和积极的支持：
- 企业架构和架构合规性有助于确保 IT 项目与业务目标保持一致。
- 架构师有时可以被视为深入技术基础设施而远离核心业务。
- 由于架构合规性审查往往主要关注系统的关键风险领域，因此它通常会强调系统所有者的主要风险。
虽然开发和实施需要遵守架构，但不遵守架构也提供了一种机制来强调：
- 需要调整的领域
- 合规流程发现的集成到架构中需要考虑的领域
后一点确定了架构的持续变化和对可能由不守纪律驱动的需求的适应性，但也允许通过操作环境中更快的变化来注册变化。通常，豁免将用于突出这些变更，并启动一个流程来注册、监控和评估任何所需变更的适用性。
架构合规性审查清单
以下审核清单提供了广泛的典型问题，可用于进行架构合规性审核，涉及架构的各个方面。问题的组织包括系统工程、信息管理、安全和系统管理等基础学科。该清单基于 The Open Group 成员提供的材料，并且特定于该组织。其他组织可以使用以下清单以及根据自己的特定需求定制的其他问题。
所提供的清单包含太多对于任何单一审查而言的问题：它们旨在针对相关项目有选择地进行定制。实际使用的清单通常由主题专家开发/选择。这些领域的利益团体打算每年更新它们。
一些清单包括对引发问题的架构原理的简要描述，以及对在答案中寻找的内容的简要描述。对清单的这些扩展旨在允许对问题进行智能地重新措辞，并使清单的用户了解为什么要提出问题。
有时，问题会被写下来，比如在 RFP 中，或者在与高级项目架构师合作时。更常见的是，它们是口头表达的，作为项目采访或工作会议的一部分。
此处提供的清单旨在用于单个架构项目，而不是用于业务域架构或跨多个项目的架构。（对跨多个业务流程和系统项目的更大活动范围进行架构审查将涉及类似的流程，但清单类别及其内容会有所不同。）
硬件和操作系统清单
- 项目的生命周期方法是什么？
- 项目处于生命周期的哪个阶段？
- 该项目认为已确定或分析了哪些关键问题将推动对网络、服务器和最终用户设备的硬件和操作系统的评估？
- 哪些系统功能将涉及大容量和/或高频数据传输？
- 系统设计如何影响或涉及最终用户设备？
- 使用、数据存储和处理的数量和分布（区域和全球）是多少？
- 哪些应用程序因数据、应用程序服务等方面的相似性而与您的项目密切相关？数据与您的项目的关联程度如何？
- 在系统关键要素的功能设计之前，已经做出了哪些硬件和操作系统选择？
- 如果硬件和操作系统决策超出了项目的控制范围：
- 项目对这些决定的理由有什么认识？
- 随着系统设计的形成，项目如何影响这些决策？
- 不使用企业标准的基本业务和技术要求是什么？
- 这有商业案例支持吗？
- 商业案例中的假设是否经过审查？
软件服务和中间件清单
- 描述如何在应用程序组件之间定义、引发和传播错误条件。
- 描述如何在各种应用程序模块中定义和安排方法的一般模式。
- 描述如何在各种应用程序模块中定义和组织方法参数的一般模式。[in]、[in/out]、[out] 参数是否始终以相同的顺序指定？模块返回的布尔值是否有一致的结果？
- 描述用于最小化客户端和服务器调用之间的往返次数的方法，特别是对于进程外调用以及涉及复杂数据结构时。
- 描述主要系统组件之间传递的主要数据结构。
- 描述主要系统组件之间使用的主要通信协议。
- 描述各种系统组件之间使用的编组技术。描述所使用的任何专门的编组安排。
- 描述系统在多大程度上使用有状态和无状态组件进行设计。
- 描述如何以及何时保存有状态和无状态组件的状态。
- 描述对象被创建、使用和销毁以及通过对象池重新使用的程度。
- 描述系统对线程或关键部分编码的依赖程度。
- 描述系统内部使用的方法和内部文档来记录方法、方法参数和方法功能。
- 描述用于构建系统的代码审查过程。
- 描述用于测试系统组件的单元测试。
- 描述各种系统模块中包含的前置条件和后置条件测试。
- 描述系统中包含的断言测试。
- 组件是否支持它们需要支持的所有接口类型，或者是否对哪些类型的组件将在语言绑定或其他形式的封送方面调用其他组件做出某些假设？
- 描述需要跨不同平台处理大端或小端数据格式问题的程度。
- 描述是否需要在不同平台上以不同方式处理数字或字符串。
- 描述软件是否需要检查浮点舍入错误。
- 描述时间和数据函数如何符合 2000 年标准。
- 描述使用了哪些工具或流程来测试系统的内存泄漏、可达性或总体稳健性。
- 描述系统服务软件的分层。描述主要系统组件之间链接的一般数量。系统是由许多点对点接口组成还是使用主要的消息传递骨干网？
- 描述系统组件松耦合或紧耦合的程度。
- 系统在共享库、通信协议支持、负载平衡、事务处理、系统监控、命名服务或其他基础设施服务方面对基础设施有什么要求？
- 描述如何设计系统和系统组件以进行重构。
- 描述系统或系统组件如何依赖通用消息传递基础设施与独特的点对点通信结构。
应用清单
基础设施（企业生产力）应用
- 是否需要企业标准基础设施应用产品未提供的功能？例如：
- 合作
- 应用分享
- 视频会议
- 压延
- 电子邮件
- 超文本标记语言
- SGML 和 XML
- 便携式文档格式
- 文件处理（专有格式）
- 桌面出版
- 业务演示
- 图像
- 动画片
- 视频
- 声音
- 认知行为治疗
- 网络浏览器
- 数据库接口
- 文件管理
- 产品数据管理
- 数据仓库/集市
- 项目管理
- 计划可见性
商业应用
- 标准产品是否需要提供支持一个或多个业务线应用程序所需的任何功能？例如：
- 业务收购申请
- 销售和营销
- 计算机辅助设计
- 计算机辅助工程
- 数学和统计分析
- 供应链管理
- 客户关系管理
- 企业资源规划 (ERP) 应用程序
- 制造执行系统
- 制造品质
- 制造工艺工程
- 机器和自适应控制
- 航空物流支持
- 维修工程
- 系统工程
- 软件工程
- 网页开发工具
- 集成开发环境
- 生命周期类别
- 功能类别
- 专业类别
- 统计质量控制
应用集成方法
- 该架构针对哪些集成点（业务流程/活动、应用程序、数据、计算环境）？
- 将应用哪些应用程序集成技术（通用业务对象 [ORB]、标准数据定义 [STEP、XML 等]、通用用户界面演示/桌面）？
信息管理清单
数据值
- 标准化数据管理和使用的流程有哪些？
- 什么业务流程支持数据的输入和验证？数据的用途？
- 哪些业务操作对应于数据的创建和修改？
- 哪些业务操作对应于数据删除？它是否被视为业务记录的一部分？
- 业务用户对数据质量有何要求？
- 有哪些流程来支持数据引用完整性和/或规范化？
数据定义
- 购买的应用程序 (COTS) 的数据模型、数据定义、结构和托管选项是什么？
- 定义和维护信息系统所有组件的数据需求和设计的规则是什么？
- 使用什么可共享存储库来捕获模型内容和数据支持信息？
- 用于设计数据库的物理数据模型定义（源自逻辑数据模型）是什么？
- 选择了哪些软件开发和数据管理工具？
- 哪些数据所有者被确定负责通用数据定义，消除计划外冗余，提供一致可靠、及时和准确的信息，并保护数据免遭滥用和破坏？
安全/保护
- 保护数据免遭无意和未经授权的更改、披露和分发的数据实体和属性访问规则是什么？
- 有哪些数据保护机制可以保护数据免受未经授权的外部访问？
- 有哪些数据保护机制可以控制对暂时驻留在企业内部的外部源数据的访问？
托管、数据类型和共享
- 将唯一权威数据作为一个逻辑源进行管理，并为驻留在不同平台上的物理数据定义更新规则，这一规则是什么？
- 管理源自操作性独家授权数据的复制数据的规则是什么？
- 已确定哪层数据服务器用于存储高或中关键运营数据？
- 已确定哪层数据服务器用于存储 C 类操作数据？
- 已确定哪层数据服务器用于存储数据仓库中包含的决策支持数据？
- 已经实施了哪些数据库管理系统（DBMS）？
公共服务
- 什么是标准化分布式数据管理服务（例如，验证、一致性检查、数据编辑、加密和事务管理）以及它们位于何处？
存取方式
- 标准文件、消息和数据管理的数据访问要求是什么？
- 决策支持数据的访问要求是什么？
- 数据存储和应用逻辑位置是什么？
- 使用什么查询语言？
安全检查表
- 安全意识：您是否确保您正在设计的公司安全策略和指南是最新版本？你读过它们吗？您是否了解所有相关的计算安全合规性和风险接受流程？（面试官应列出所有相关政策和指南。）
- 识别/身份验证：绘制应用程序如何识别用户以及应用程序如何验证用户身份的流程。为图表提供支持文档，解释从用户界面到应用程序/数据库服务器再返回到用户的流程。您是否遵守有关帐户、密码等的公司政策？
- 授权：提供从头到尾的流程，显示用户如何请求访问应用程序，指示相关的安全控制和职责分离。这应包括适当的数据所有者如何批准请求、如何将用户放入适当的访问级别分类配置文件、如何创建用户 ID、密码和访问权限并将其提供给用户。还包括如何告知用户与使用应用程序相关的责任、提供访问协议副本、如何更改密码、向谁寻求帮助等。
- 访问控制：记录如何添加、更改、删除和记录用户 ID、密码和访问配置文件。文档应包括谁负责这些流程。
- 敏感信息保护：提供标识需要额外保护的敏感数据的文档。确定负责该数据的数据所有者以及用于保护该数据的存储、传输、打印和分发的流程。包括如何保护密码文件/字段。如何防止用户查看他人的敏感信息？是否与外部各方（合作伙伴、供应商、承包商等）签订了有关信息保护的协议？如果是的话，有什么义务？
- 审核跟踪和审核日志：识别并记录用户或应用程序支持所需的组帐户，包括操作系统组帐户。识别并记录具有超级用户类型权限的个人帐户和/或角色，这些权限是什么，谁有权访问这些帐户，如何控制、跟踪和记录对这些帐户的访问权限，以及如何处理密码更改和分发，包括操作系统帐户。还要确定审核日志、谁可以读取审核日志、谁可以修改审核日志、谁可以删除审核日志以及如何保护和存储审核日志。用户 ID 在审计跟踪中是否被掩盖？
- 外部访问注意事项：应用程序仅在内部使用吗？如果没有，您是否符合公司外部访问要求？
系统管理清单
- 必须分发的软件更改的频率是多少？
- 软件分发使用哪些工具？
- 生产中是否允许使用多个软件和/或数据版本？
- 用户数据备份频率和预计恢复时间是多少？
- 如何创建和管理用户帐户？
- 系统许可证管理策略是什么？
- 需要哪些通用系统管理工具？
- 需要哪些特定的应用程序管理工具？
- 需要哪些具体的服务管理工具？
- 如何接收和发送服务呼叫？
- 描述一下系统是如何卸载的。
- 描述可用于检查系统是否正确安装的过程或工具。
- 描述可用于监视系统运行状况和性能的工具或仪器。
- 描述可用于确定系统安装位置的工具或流程。
- 描述采用什么形式的审计日志来捕获系统历史记录，特别是在发生事故之后。
- 描述系统向服务人员发送错误消息的能力。
系统工程/总体架构清单
一般的
- 还有哪些其他应用程序和/或系统需要与您的集成？
- 描述每个的集成级别和策略。
- 用户群的地理分布如何？
- 该系统对于企业内部或外部的其他用户社区的战略重要性是什么？
- 为企业内部用户提供系统服务需要哪些计算资源？在企业外部并使用企业计算资产？在企业外部并使用自己的资产？
- 本机交付环境之外的用户如何访问您的应用程序和数据？
- 该应用程序的预期寿命是多少？
- 描述适应用户群、存储数据和交付系统技术变化的设计。
- 用户群的规模及其预期的性能水平是多少？
- 您使用什么性能和压力测试技术？
- 软件和数据组件的总体组织是什么？
- 整体服务和系统配置如何？
- 软件和数据如何配置并映射到服务和系统配置？
- 该系统需要什么专有技术（硬件和软件）？
- 描述随着时间的推移如何复制和重新部署软件的每个版本。
- 描述当前的用户群以及该群在未来三到五年内预计将如何变化。
- 描述当前用户群的地理分布以及该群在未来三到五年内预计将如何变化。
- 描述有多少当前或未来的用户需要以移动方式使用该应用程序或需要离线工作。
- 描述应用程序的一般用途、应用程序的主要组件以及主要数据流。
- 描述应用程序中包含的允许监视应用程序的运行状况和性能的工具。
- 描述系统的业务理由。
- 从初始开发成本与长期维护成本的角度描述选择系统开发语言而不是其他选项的理由 。
- 描述用于提出系统架构和系统架构的产品选择阶段的系统分析过程。
- 除了原始客户之外，谁可能会使用该系统或从该系统中受益？
- 在浏览模式和更新模式下使用系统的用户比例是多少？
- 事务性请求的典型长度是多少？
- 您是否需要有保证的数据交付或更新，或者系统是否可以容忍故障？
- 系统的正常运行时间要求是什么？
- 描述系统架构在哪些方面遵守或不遵守标准。
- 描述项目中使用的项目规划和分析方法。
处理器/服务器/客户端
- 描述客户端/服务器应用程序架构。
- 对图片进行注释以说明应用程序功能的执行位置。
客户
- 用户设备上是否执行演示以外的功能？
- 描述所提供的数据和流程帮助设施。
- 描述屏幕到屏幕的导航技术。
- 描述用户如何在此应用程序和其他应用程序之间导航。
- 这个应用程序和其他应用程序是如何从用户设备启动的？
- 是否有应用程序间的数据和流程共享功能？如果是，请描述正在共享的内容以及通过什么技术/工艺进行共享。
- 描述传输到客户端的数据量。
- 支持应用程序的本地数据存储还有哪些额外要求？
- 支持应用程序的本地软件存储/内存有哪些额外要求？
- 是否存在任何已知的硬件/软件冲突或由其他应用程序要求或情况引起的会影响应用程序用户的容量限制？
- 描述您的表示层的外观与其他现有应用程序的外观相比如何。
- 描述客户端需要在多大程度上支持异步和/或同步通信。
- 描述系统的表示层如何与系统的其他计算或数据传输层分离。
应用服务器
- 表示层和应用程序层是否可以在单独的处理器上运行？
- 应用程序层和数据访问层是否可以在单独的处理器上运行？
- 该应用程序是否可以放置在独立于所有其他应用程序的应用程序服务器上？如果没有，请解释依赖性。
- 是否可以轻松添加额外的并行应用程序服务器？如果是的话，负载均衡机制是什么？
- 应用程序产生的资源需求是否已测量，其值是多少？如果是，规划的服务器容量是否已在应用和聚合级别得到确认？
数据服务器
- 是否有其他应用程序必须共享数据服务器？如果是，请识别它们并描述数据和数据访问要求。
- 应用程序产生的资源需求是否已测量，其值是多少？如果是，规划的服务器容量是否已在应用和聚合级别得到确认？
COTS（如适用）
- 供应商是否实力雄厚且稳定？
- 供应商终止后，企业会收到源代码吗？
- 该软件是否配置供企业使用？
- 是否有任何特殊的 A&D 数据或流程会妨碍该软件的使用？
- 这个软件现在可以用吗？
- 描述供应商过去的财务和市场份额历史。
系统工程/方法和工具清单
- 当前的经营方式是否存在衡量标准？
- 系统所有者是否创建了用于指导项目的评估标准？描述如何使用评估标准。
- 是否对现有架构进行了研究以利用现有工作？描述用于发现和理解的方法。这些架构会被集成吗？如果是，请解释将使用的方法。
- 描述将在项目中使用的方法：
- 用于定义业务策略
- 用于定义需要改进的领域
- 用于定义基线和目标业务流程
- 用于定义转换过程
- 用于管理项目
- 用于团队沟通
- 用于知识管理、变更管理和配置管理
- 用于软件开发
- 用于参考标准和方向声明
- 用于交付成果的质量保证
- 用于设计评审和可交付成果验收
- 用于捕获指标
- 如何提供咨询和故障排除？
- 培训如何协调？
- 如何合并和级联更改和增强？
- 如何汲取和传达经验教训？
- 如何提供咨询和故障排除？
- 培训如何协调？
- 如何合并和级联更改和增强？
- 如何汲取和传达经验教训？
架构合规性审查指南
定制清单的指南
- 专注于：
- 高风险地区
- 预期的（和新兴的）差异化因素
- 对于清单中的每个问题，请了解：
- 问题本身
- 其背后的原理
- 在回复中寻找什么
- 询问学科专家的意见
- 修复清单问题供您使用
- 记住需要向架构委员会提供反馈
进行架构合规性审查的指南
- 清楚地了解征求审查者的目的；并保持正轨并交付所要求的内容。例如，他们通常想知道正在构建的系统哪些是对的，哪些是错的；不是所使用的开发方法、他们自己的管理结构等是对还是错。很容易偏离轨道并讨论有趣且可能有价值的主题，而不是所征求的内容。如果您可以阐明和洞察技术方法，但审查不需要讨论，请在审查后自愿提供。
- 如果在讨论过程中明显发现存在其他需要解决的问题，这些问题超出了所要求的审查范围，请随后向会议主席提出。然后可以根据问题的严重程度制定解决问题的计划。
- 保持“科学”。不要说：“我们希望看到大型数据库托管在ABC而不是XYZ上。”，而是这样说：“与XYZ数据库环境相关的停机时间比ABC数据库环境要长得多。因此，我们不建议托管类型M和XYZ环境中的N 个系统。”
- 提出“开放式”问题；即不假定特定答案的问题。
- 在征求评论的人中经常存在“隐藏的议程”或有争议的问题，而您可能不会事先知道这些。采用非个性化的讨论方式可能有助于弥合意见分歧，而不是加剧意见分歧。
- 尊重接受采访的人。他们可能没有按照“应有的方式”构建系统，但他们可能在所处的环境下尽力而为。
- 帮助练习成为您和演示者的学习经历。
- 审查应包括针对架构的详细评估活动，并应确保结果存储在企业连续体中。