【TOGAF系列】企业架构能力和治理
购买的数据模型、数据定义、结构和托管选项是什么应用程序（COTS）？定义和维护所有数据要求和设计的规则是什么信息系统的组成部分？使用 使用什么可共享的存储库来捕获模型内容和支持信息数据信息？用于以下目的的物理数据模型定义（从逻辑数据模型中派生）是什么设计数据库？选择了哪些软件开发和数据管理工具？已经确定哪些数据所有者负责共同数据定义，消除计划外的冗余，提供始终可靠、及时和准确信息，并保护数据免遭滥
第1章 介绍
本章提供了TOGAF标准—企业架构能力与治理（本文档）中的指导介绍。为了在企业内成功运营架构功能，必须建立适当的组织结构、流程、角色、职责和治理。
本文档中包含的指南如下：
- 建立架构能力（见第2章）：提供关于如何使用ADM建立架构能力的指南
- 架构治理（见第3章）：提供架构治理的框架和指南
- 架构委员会（见第4章）：提供成立和运营企业架构委员会的指南
- 架构合同（见第5章）：提供定义和使用架构合同的指南
- 架构合规性（见第6章）：提供确保项目符合架构的指南
第2章：建立架构能力
本章提供关于如何使用ADM建立架构能力的指南。
2.1 概述
与任何业务能力一样，建立企业架构能力可以通过TOGAF架构开发方法（ADM）来支持。成功使用ADM将提供以客户为中心、增值且可持续的架构实践，该实践能够支持业务、帮助最大化投资价值，并主动识别获得业务利益和管理风险的机会。
在组织内建立可持续的架构实践，可以通过遵循在组织内建立任何其他能力（如业务流程管理能力）时所采用的相同方法来实现。ADM是架构和治理此类能力实施的理想方法。将ADM与特定的架构愿景相结合，在组织内建立架构实践将实现这一目标。
建立架构实践不应被视为架构项目的一个阶段或一次性项目，而应被视为一个持续进行的学科，它为架构交付提供了背景、环境和资源，以治理和支持组织内的架构交付。随着架构项目在此环境中执行，它可能会请求对架构实践进行更改，这将触发ADM的另一个周期来扩展架构实践。
在组织内实施任何能力都需要设计四个领域架构：业务、数据、应用和技术。因此，在组织内建立架构实践也需要设计：
- 业务架构：将突出架构治理、架构流程、架构组织结构、架构信息需求、架构产品等
- 数据架构：将定义组织的企业连续体和架构存储库的结构
- 应用架构：指定启用架构实践所需的功能和/或应用服务
- 技术架构：描述架构实践的基础设施要求及其对架构应用和企业连续体的支持
建立架构实践的步骤将在ADM阶段的背景下进行解释。因此，读者应参考TOGAF标准—架构开发方法中的相关ADM阶段，以了解每个步骤的完整范围。
2.2 阶段A：架构愿景
在本阶段，建立架构实践的目的是定义或审查架构实践的愿景、利益相关者和原则。本阶段的重点将是架构实践作为一个整体，而不是特定的架构项目。在建立架构实践的背景下，应理解以下步骤：
- 建立项目：本步骤应侧重于定义架构实践的利益相关者。利益相关者将包括参与架构实践的角色和组织单位，以及将从架构实践生成的交付物中受益的人，因此他们可以被定义为架构实践的客户。
- 识别利益相关者和关注点、业务需求和架构愿景：本步骤将从业务信息系统和技术的角度，为架构实践生成非常高级别的基线和目标环境定义。
- 识别业务目标和业务驱动力：了解业务目标和驱动力对于将架构实践与业务对齐至关重要。
- 定义范围：定义架构实践的范围是一个高级项目计划，说明接下来将在架构方面解决的内容。
- 定义约束：本步骤的重点是影响所有架构项目的企业级约束。
- 审查架构原则，包括业务原则：本步骤的目的是定义指导和管理架构实践运行的原则。架构原则通常管理架构交付物，而架构实践原则则处理架构实践的组织、内容、工具和流程。
- 制定架构工作说明书并获得批准：本步骤将生成架构实践愿景和范围。
在本阶段可以考虑的另一个步骤是进行架构成熟度评估。请参考TOGAF®系列指南：架构成熟度模型，以获取有关此主题的指导。
2.3 阶段B：业务架构
在建立或改进架构实践的业务架构阶段，关键关注领域包括：
- 架构本体：定义组织中将使用的架构术语和定义，以建立对这些术语的共同理解。
- 架构流程：ADM将构成该流程的基础，并需要根据组织的需求和架构实践愿景进行定制。请参考TOGAF标准—架构开发方法，以获取开发此流程的指导。所需的架构治理流程应包括在总体架构流程中。
- 架构视点和视图：列出架构实践应解决的所有视点和视图。架构实践的利益相关者将指导该定义。要包含的视点之一是架构治理视点；请参考TOGAF标准—架构内容，以获取有关此输出的指导。
- 架构框架：描述架构实践将生成的各种架构交付物、这些交付物之间的相互关系和依赖关系，以及设计这些交付物的规则和指南。应使用定义的架构视点和视图来指导架构框架的定义。TOGAF标准—架构开发方法和TOGAF标准—架构内容是有用的参考，它们将帮助描述架构框架。
- 架构责任矩阵：定义架构实践中的角色，并将这些角色的责任分配给架构交付物和流程。该矩阵将包括所需的架构治理结构和角色。TOGAF标准—架构开发方法以及第4章、第3章和TOGAF®系列指南：架构技能框架将提供有关此输出的指导。
- 架构性能指标：识别和描述将用于监控架构实践性能以实现其声明的架构实践愿景和目标的指标。
- 架构治理框架：这是定义的架构流程和架构责任矩阵的一个特定视图。
2.4 阶段C：数据架构
架构实践的数据架构将指定并管理组织的企业连续体和架构存储库的结构。数据架构应根据架构框架进行定义。数据架构有时被称为架构实践的元模型。
2.5 阶段C：应用架构
架构实践的应用架构定义了根据架构框架定义架构交付物所需的功能。关键重点应放在建模工具集上，但这不应是唯一重点。请参考TOGAF标准—架构开发方法，以获取选择工具集的指导。发布解决特定架构框架视图的架构交付物有时需要专门化或定制化的功能，不应忽视这一点。
2.6 阶段D：技术架构
架构实践的技术架构应定义支持架构实践的技术基础设施。
2.7 阶段E：机会与解决方案
在规划建立架构实践的这一阶段，需要考虑的一个关键因素是所需的组织变革以及如何实现这一目标。
2.8 阶段F：迁移规划
本阶段的重点不仅应放在信息系统架构组件上，还应包括业务架构。采用架构流程和框架将对组织内架构实践的全面建立产生重大影响。
2.9 阶段G：实施治理
本阶段应侧重于实施架构实践的业务架构。在组织内改变实践以采用更结构化和有纪律的方法将是一项挑战，应通过适当的组织变革技术来解决。
2.10 阶段H：架构变更管理
架构实践的架构变更应由本阶段管理。这些变更通常是在执行架构项目期间触发的。一个典型的变更可能是对新的架构交付物的需求。这将影响架构实践的所有架构领域。
2.11 需求管理
理解和管理架构实践的需求至关重要。需求应明确阐述并与架构实践愿景保持一致。关于如何构建企业架构能力的更多指导，可参见TOGAF®系列指南：TOGAF领导者的企业架构能力建立与演进指南。
第3章：架构治理
本章提供了架构治理的框架和指南。
3.1 引言
本节描述了治理的本质以及企业内的治理层级。
3.1.1 企业内的治理层级
架构治理是在企业级层面对企业架构和其他架构进行管理和控制的实践和方法。架构治理通常不会孤立运作，而是在一个治理结构层级中运作，在较大的企业中，该层级可能包括以下所有内容，作为具有各自学科和流程的独立领域：
- 公司治理
- 技术治理
- IT治理
- 架构治理
每个治理领域可能在企业内的多个地理层级（全球、区域和地方）上存在。公司治理是一个广泛的话题，超出了企业架构框架（如TOGAF框架）的范围。本节及以下小节专注于架构治理；但它们在架构在企业级治理层级中通常运作的上下文中对其进行描述，因为如上所述，架构治理通常在其中运作。特别是，本节及以下小节旨在：
- 提供治理作为独立学科的概述
- 描述架构治理在企业内通常运作的治理上下文
- 描述一个实用的架构治理框架，该框架可以适应并应用于企业架构和其他形式的IT架构
3.1.2 治理的本质
3.1.2.1 治理：通用视角
治理本质上是确保业务得到妥善开展。它较少关注过度控制和严格遵守规则，而更多关注指导和有效、公平地使用资源，以确保组织战略目标的可持续性。
以下概述了经合组织（OECD）确定的公司治理基本原则：
- 关注股东的权利、角色和公平待遇
- 披露和透明度以及董事会的责任
- 确保：
- 组织的战略指导健全
- 董事会对管理层的有效监督
- 董事会对公司和股东负责
- 董事会的责任包括：
- 审查和指导公司战略
- 设定并监控管理层的绩效目标
支持这一点的是，OECD将传统治理观视为：“企业业务管理和控制的系统。公司治理结构规定了企业内不同参与者（如董事会、管理层、股东和其他利益相关者）之间的权利和责任分配，并阐述了制定企业事务决策的规则和程序。通过这样做，它还提供了制定公司目标的结构，以及实现这些目标和监控绩效的手段。”（来源：OECD，2001年）
3.1.2.2 治理的特征
以下特征改编自《公司治理》（Naidoo，2002年），并在此处列出，以强调在组织及其与所有相关方的交易中采用治理方法的价值和必要性：
- 纪律：所有相关方都将致力于遵守组织建立的程序、流程和权威结构。
- 透明度：所有实施的行动及其决策支持都将可供授权的组织和提供方检查。
- 独立性：所有流程、决策制定和机制的使用都将建立起来，以最大限度地减少或避免潜在的利益冲突。
- 问责制：组织内可识别的群体（例如，治理委员会）将对其行动或决策
3.1.3 技术治理
技术治理控制着组织如何利用技术进行商品和服务的研发与生产。尽管它可能包括IT治理活动，但其范围通常更为广泛。技术治理是大多数组织的关键能力、要求和资源，因为技术在组织内部无处不在。
最近的研究表明，许多组织在无形资产而非有形资产的管理上更为均衡。鉴于这些无形资产大多是信息和数字资产，显然，企业正越来越依赖于IT，因此IT治理——即技术治理的一部分——也变得越来越重要。这些趋势还突出了企业不仅依赖于信息本身，还依赖于创造、传递和消费信息的流程、系统和结构。随着许多行业领域通过无形资产增加价值的趋势日益明显，风险管理也必须被视为理解和缓解新挑战、威胁和机遇的关键。
企业不仅越来越依赖于IT来支持关键的业务功能和流程，而且其声誉、品牌和最终价值也依赖于这些信息和支持技术。
3.1.4 IT治理
IT治理提供了将IT资源和信息与企业目标和战略联系起来的框架和结构。此外，IT治理还制度化了规划、采购、实施和监控IT性能的最佳实践，以确保企业的IT资产支持其业务目标。近年来，IT治理已成为现代企业有效治理不可或缺的一部分。企业越来越依赖于IT来支持关键业务功能和流程；为了成功获得竞争优势，企业必须有效地管理贯穿于组织的复杂技术，以便快速且安全地响应业务需求。
此外，全球监管环境越来越要求企业更严格地控制信息，这是由信息系统灾难和电子欺诈事件的增加所驱动的。现在，IT相关风险的管理被广泛认为是企业治理的关键部分。因此，必须建立IT治理战略和相应的实施组织，并得到高层管理的支持，明确谁拥有企业的IT资源，特别是谁对企业范围内的IT资源整合负有最终责任。
3.1.4.1 IT控制框架——COBIT
与企业治理一样，IT治理是一个广泛的话题，超出了TOGAF框架等企业架构框架的范围。关于IT治理的详细信息的一个良好来源是COBIT®框架（信息和相关技术的控制目标）。这是一个由IT治理研究所（ITGI）开发和推广，并由信息系统审计和控制基金会（ISACF）发布的开放标准，用于控制IT。COBIT控制可能有助于实施合规策略。
3.1.5 架构治理：概述
3.1.5.1 架构治理特征
架构治理是一种实践和方法，通过一系列流程、文化导向和明确的职责，确保组织内架构的完整性和有效性。它包括：
- 实施一套对所有架构组件和活动的创建和监控进行控制的系统，以确保架构在组织内的有效引入、实施和演变。
- 实施一套系统，确保符合内部和外部标准以及监管义务。
- 建立支持上述流程在商定参数内有效管理的流程。
- 制定实践，确保向组织内外明确界定的利益相关者群体负责。
3.1.5.2 架构治理作为董事会级别的责任
本节旨在推动IT和架构治理的开放，以便阐明和管理与架构活动和工件相关的业务责任。
3.1.5.3 TOGAF标准与架构治理
TOGAF ADM的G阶段（见TOGAF标准——架构开发方法）专门负责实施治理，这涉及到通过变更项目实现架构。实施治理只是架构治理的一个方面，架构治理涵盖组织内企业架构和其他架构的开发和演变的所有方面的管理和控制。架构治理需要得到架构治理框架（见第3.2节）的支持，该框架有助于识别有效流程和组织结构，以便阐明、沟通和有效管理架构治理相关的业务责任。
3.2 架构治理框架
本节描述了一个架构治理的概念和组织框架。如前所述，TOGAF ADM的G阶段（见TOGAF标准——架构开发方法）专门负责实施治理，这涉及到通过变更项目实现架构。实施治理只是架构治理的一个方面，架构治理涵盖组织内企业架构和其他架构的开发和演变的所有方面的管理和控制。架构治理需要得到架构治理框架的支持，该框架描述如下。
3.2.1 架构治理框架——概念结构
3.2.1.1 关键概念
从概念上讲，架构治理是一种方法、一系列流程、一种文化导向和一套明确的职责，它们共同确保组织内架构的完整性和有效性。关键概念如下图所示。
该图展示了架构治理框架的拆分，包括流程、内容和上下文，这对于支持架构治理计划至关重要，因为它允许在不过分影响流程的情况下引入新的治理材料（法律、监管、基于标准或立法的材料）。这种内容与流程无关的方法确保了框架的灵活性。流程通常独立于内容，并实施了一套经过验证的最佳实践方法来进行主动治理。架构治理框架是企业连续体的一部分，管理所有与架构本身和架构治理流程相关的内容。
3.2.1.2 关键架构治理流程
需要建立治理流程来识别、管理、审计和传播与架构管理、合同和实施相关的所有信息。这些治理流程将用于确保所有架构工件、合同、原则和操作级别协议（OLAs）都得到持续的监控，并且所有决策都具有清晰的审计性。
政策管理与采纳
所有架构修正、合同和支持信息必须通过正式流程进行治理，以便注册、验证、批准、管理和发布新的或更新的内容。这些流程将确保与现有治理内容的有序集成，以便所有相关方、文档、合同和支持信息都得到管理和审计。
合规性
将持续实施针对服务级别协议（SLA）、OLAs、标准和监管要求的合规性评估，以确保稳定性、合规性和性能监控。这些评估将根据治理框架中定义的标准进行审查，并被接受或拒绝。
豁免（Dispensation）
如果合规性评估被拒绝，即设计、运营、服务级别或技术领域不符合要求，则可以对该领域进行调整或重新调整以满足合规性要求，或者请求豁免。豁免是在不符合要求的情况下满足临时合规性的一种替代途径，它们在给定时间段内授予，并附有一组在豁免有效期内必须执行的服务和运营标准。豁免不是无限期授予的，而是用作确保服务级别和运营级别得到满足的同时，在其实施和时机上提供一定灵活性的机制。豁免的时间限制特性使其成为合规周期中的一个主要触发因素。
监控与报告
需要性能管理来确保运营和服务元素都根据商定的标准进行管理。这将包括监控SLA和OLA、提供反馈进行调整以及报告。内部管理信息将在环境管理中得到考虑。
业务控制
业务控制涉及确保符合组织业务政策的流程。
环境管理
这确定了确保支持治理框架的基于存储库的环境有效和高效所需的所有服务。这包括物理和逻辑存储库管理、访问、通信、培训和所有用户的认证。所有架构工件、服务协议、合同和支持信息都必须通过正式流程进行治理，以便注册、验证、批准、管理和发布新的或更新的内容。这些流程将确保与现有治理内容的有序集成，以便所有相关方、文档、合同和支持信息都得到管理和审计。
3.2.2 架构治理框架——组织结构
3.2.2.1 概述
架构治理是管理和控制企业架构和其他架构的实践和方法。为了确保这种控制在组织内有效，必须建立正确的组织结构来支持所有治理活动。
一个有效地实施本节所述方法的架构治理结构通常包括以下级别，这些级别在实践中可能涉及IT治理流程、组织结构和能力的组合。它们通常包括以下内容：
- 全球治理董事会
- 本地治理董事会
- 设计权威机构
- 工作组
下图突出了架构治理计划所需的主要结构元素。虽然每个企业都会有不同的要求，但预计下图所示的组织设计基础将适用于多种类型的组织，并可在其中实施。
3.2.2.2 关键领域
上图确定了架构管理的三个关键领域：开发、实施和部署。每个领域都是组织内一个或多个团体的责任，而企业连续体则支持架构在其生命周期内的所有活动和工件。开发责任、流程和结构与TOGAF ADM及其使用相关，而实施责任、流程和结构与TOGAF ADM的G阶段（见TOGAF标准——架构开发方法）相关。如前所述，架构治理框架是企业连续体的一部分，管理所有与架构本身和架构治理流程相关的内容。
3.2.2.3 运营效益
如上图所示，组织内架构的治理不仅直接控制和指导其开发和实施，还扩展到已实施架构的运营。TOGAF架构治理框架作为一种方法、一系列流程、一种文化导向和一套明确的职责，共同确保组织内架构的完整性和有效性。
3.3 架构治理实践
本节提供了有效实施架构治理的实用指南。
3.3.1 架构治理的关键成功因素
为确保架构治理的成功以及有效管理架构合同，必须考虑以下因素：
- 提交、采纳、重用、报告和退役架构政策、流程、角色、技能、组织结构和支持服务的最佳实践
- 支持架构治理流程和报告要求的组织责任和结构
- 集成工具和流程，以促进流程的程序性和文化性采纳
- 控制架构治理流程、豁免、合规性评估、SLA和OLA的标准
- 对所有与架构治理相关的信息、服务和流程的有效性、效率、保密性、完整性、可用性、合规性和可靠性的内部和外部要求
3.3.2 有效的架构治理策略要素
3.3.2.1 架构治理与企业政治
如果没有适当的高层支持和企业政治的一致性，强加的企业架构注定要失败。为了成功，企业架构必须反映组织的需求。如果企业架构师没有参与业务战略的开发，他们至少必须对其有基本的了解，并对组织面临的主要业务问题有所了解。他们甚至可能需要参与系统部署过程，并最终对技术架构实施产生的投资和产品选择决策负责。
架构治理策略中有三个重要元素，它们特别关系到架构在企业内的接受度和成功。尽管这些元素本身具有相关性和适用性，并且因此被单独描述，但它们也是任何有效的架构治理策略不可或缺的组成部分。
- 必须建立一个跨组织的架构委员会（见第4章），并得到高层管理的支持，以监督企业架构治理策略的实施
- 必须建立一套全面的架构原则（见TOGAF标准——ADM技术），以指导、通知和支持组织通过使用IT来实现其使命的方式
- 应采用架构合规性（见第6章）策略——具体措施（而不仅仅是政策声明）来确保架构合规性，包括项目影响评估、正式的架构合规性审查流程，并可能包括架构团队在产品采购中的参与
第4章： 架构委员会
本章提供了建立和运营企业架构委员会的指南。
4.1 角色
架构治理策略（见第3章）成功的关键要素之一是建立一个跨组织的架构委员会，以监督策略的实施。该机构应代表架构内的所有关键利益相关者，并通常由一组负责审查和维护总体架构的高级管理人员组成。架构委员会可能具有全球、区域或业务线范围。在较大的企业中，架构委员会通常至少由两个层级的组织代表组成：
- 本地（领域专家、直线责任）
- 全球（组织范围内的责任）
在这种情况下，每个委员会都将具有明确阐述的：
- 责任和决策能力
- 职权范围和权限限制
4.2 责任
架构委员会通常负责实现以下一个或多个目标：
- 为所有与架构相关的决策提供基础
- 确保子架构之间的一致性
- 为组件重用设定目标
- 使企业架构具有灵活性，以满足不断变化的业务需求，并利用新技术
- 强制执行架构合规性
- 提高组织内架构学科的成熟度水平
- 确保采用基于架构的开发方法
此外，从运营角度来看，架构委员会还应负责：
- 所有方面的架构合同监控和控制
- 定期开会
- 确保架构的有效和一致的管理和实施
- 解决已升级的歧义、问题或冲突
- 提供建议、指导和信息
- 确保架构合规性，并根据技术战略和目标授予豁免
- 在类似豁免被请求和授予时，考虑政策（时间表、SLA等）变更；例如，新的服务形式要求
- 确保所有与架构合同实施相关的信息在受控条件下发布，并可供授权方访问
- 验证报告的服务水平、成本节约等
从治理角度来看，架构委员会还负责：
- 制作可用的治理材料和活动
- 提供一种机制，通过共识和授权发布来正式接受和批准架构
- 提供一种基本控制机制，以确保架构的有效实施
- 建立和维护架构实施与企业架构中体现的架构战略和目标以及业务战略目标之间的联系
- 识别与架构的偏差，并通过豁免或政策更新规划重新调整活动
4.3 设立架构委员会
4.3.1 触发因素
架构委员会的设立通常由一个或多个以下事件的发生所触发：
- 新任首席信息官（CIO）
- 合并或收购
- 组织重组
- 考虑采用新的计算形式
- 认识到IT与业务之间的协调不佳
- 希望通过技术实现竞争优势
- 创建企业架构计划
- 重大业务变更或快速增长
- 对复杂、跨职能解决方案的需求
在许多公司中，架构规划工作的初步执行发起人是CIO（或其他高级管理人员）。然而，为了获得广泛的企业支持，一个赞助机构具有更大的影响力。这个赞助机构在此被称为架构委员会，但名称并不重要。无论名称如何，它都是一个负责审查和维护战略架构及其所有子架构的高层级团体。架构委员会是企业内架构的赞助机构，但架构委员会本身也需要企业最高层级的执行发起人。这种承诺必须贯穿规划过程，并持续到架构项目的维护阶段。在许多架构规划工作失败的公司中，一个显著的问题是缺乏高层管理人员的参与和鼓励。
架构委员会成员的另一个经常被忽视的来源是公司董事会。这些成员通常对业务和竞争有深入的了解。由于他们对业务愿景和目标有重大影响，他们可能成功地验证IT战略与业务目标的一致性。
4.3.2 委员会规模
架构委员会的建议成员人数为四到五人（且不超过十人）的永久成员。为了保持架构委员会的合理规模，同时确保随时间推移在企业范围内得到代表，架构委员会的成员资格可以轮换，给予不同的高级管理人员决策制定特权和责任。在任何情况下，由于一些架构委员会成员发现时间限制妨碍了长期积极参与，因此可能需要进行轮换。
组织可能使用代表性方式来设置其架构委员会，即每个委员会成员都被分配一组要代表的利益相关者。然后，委员会成员有责任与利益相关者会面，以了解他们对各种议程项目的看法。然而，架构委员会中必须存在一些连续性，以防止企业架构从一个想法集合转变为另一个想法集合。确保轮换与连续性的一种技术是为成员设定任期，并使任期在不同时间到期。
在架构规划工作之后的持续架构流程中，架构委员会可能需要重新授权。执行发起人将通常审查架构委员会的工作并评估其有效性；如有必要，将更新或改变架构合规性审查流程。
4.3.3 委员会结构
TOGAF架构治理框架（见第3.2节）提供了一个泛化的组织结构，将架构委员会置于企业内更广泛的治理结构的背景下。该结构确定了主要组织团体和职责，以及每个团体之间的关系。这是一种最佳实践结构，可能根据组织的形式和现有结构而发生变化。
必须考虑组织的大小、形式和IT功能的实施方式。这将为在整体治理环境的背景下设计架构委员会结构提供基础。特别是，必须考虑全球所有权和本地实施的概念，以及从所有实施架构的领域整合新概念和技术。
架构委员会的结构应反映组织的形式。所需的架构治理结构可能超出TOGAF架构治理框架（见第3.2节）中概述的泛化结构。组织可能需要定义IT治理流程、现有组织结构和能力的组合，这些通常包括以下类型的机构：
- 全球治理董事会
- 本地治理董事会
- 设计权威机构
- 工作组
4.4 架构委员会的运营
本节特别从治理角度描述了架构委员会的运营。
4.4.1 一般
架构委员会会议应在具有明确目标、内容范围和已定义行动的明确议程内进行。通常，委员会会议将与最佳实践保持一致，如COBIT框架（见第3.1.4.1节）中所述。这些会议将在以下方面提供关键指导：
- 支持制作高质量的治理材料和活动
- 提供一种机制，通过共识和授权发布来正式接受架构
- 提供一种基本控制机制，以确保架构的有效实施
- 建立和维护架构实施与企业（业务和IT）声明的战略和目标之间的联系
- 识别与合同的偏差，并通过豁免或政策更新规划重新调整活动
4.4.2 准备
每位参与者都将收到议程和任何支持性文件（例如，豁免请求、性能管理报告等），并应熟悉每个文件的内容。如果已向个人分配了行动，则该人员有责任报告这些行动的进展情况。
每位参与者必须确认其可用性和参加架构委员会会议的情况。
4.4.3 议程
本节概述了架构委员会会议议程的内容。每个议程项目仅根据其内容进行描述。
- 上次会议记录：包含上次架构委员会会议的详细信息，遵循标准的组织协议。
- 变更请求：此标题下的项目通常是修改架构、原则等的变更请求，但也可能包括与架构合同相关的业务控制；例如，确保对高级号码（如天气预报）的语音流量被阻止，并对某些网站的数据流量进行控制。任何变更请求都必须在商定的授权级别和参数内提出，这些参数由架构合同定义。
- 豁免：豁免用作请求在现有架构、合同、原则等之外的正常运营参数内进行变更的机制；例如，排除向子公司提供服务，因特定业务原因请求异常服务级别，为支持特定业务计划而部署非标准技术或产品。豁免在给定时间段内授予，并附有一组在豁免有效期内必须执行的服务和运营标准。豁免不是无限期授予的，而是用作确保服务级别和运营级别得到满足的同时，在其实施和时机上提供一定灵活性的机制。豁免的时间限制特性使其成为架构合规性活动的一个触发因素。
- 合规性评估：针对SLA、运营级别协议（OLAs）、成本目标和所需的架构刷新进行合规性评估。这些评估将根据架构治理框架中定义的标准进行审查，并被接受或拒绝。架构合规性评估报告将包括详细信息。
- 争议解决：通过架构合规性和豁免流程未解决的争议将在此处确定，以便采取进一步行动，并通过架构合规
- 架构战略和方向文档：这描述了架构战略、方向和优先级，并且仅由全球架构委员会制定。它应采用标准的架构文档形式。
- 分配的行动：这是对前一次架构委员会会议上分配的行动的报告。使用行动跟踪器来记录和保持委员会会议期间分配的所有行动的状态，并应至少包含以下信息：
- 参考编号
- 优先级
- 行动描述
- 行动负责人
- 行动细节
- 提出日期
- 到期日期
- 状态
- 类型
- 解决日期
- 合同文档管理：这是对架构文档的更新和变更进行正式接受的过程，以便继续发布。
- 任何其他业务（AOB）：描述未直接涵盖在上述任何一项下的问题。这些问题可能不在议程中描述，但应在会议开始时提出。所有支持性文档必须根据所有架构治理文档进行管理。
- 会议日程：应详细列出并公布所有会议日期。
第5章：架构合同
本章提供了定义和使用架构合同的指南。
5.1 角色
架构合同是开发合作伙伴和赞助人之间就架构的可交付成果、质量和适用性达成的联合协议。通过实施受治理的合同管理方法，将确保以下方面：
- 在组织内对与架构相关的所有活动进行持续监控，以检查其完整性、变更、决策和审计
- 遵守现有或正在开发的架构的原则、标准和要求
- 识别架构开发和实施各方面的风险，涵盖内部开发对接受的标准、政策、技术和产品的遵守情况，以及架构的运营方面，以便组织能够在有弹性的环境中继续开展业务
- 建立一套确保所有架构工件的开发和使用方面的责任、责任和纪律的过程和实践
- 对负责合同的治理组织有正式的了解，包括其权威级别和受该机构治理的架构范围
传统的架构合同是赞助者和架构功能或信息系统（IS）部门之间的协议。然而，越来越多的服务由系统集成商、应用程序提供商和服务提供商提供，这些服务通过架构功能或IS部门进行协调。因此，需要一份架构合同来建立所有参与架构开发和交付的各方之间的联合协议。
架构合同可能出现在TOGAF架构开发方法（ADM）的各个阶段；例如：
- 在TOGAF标准—架构开发方法的A阶段创建的《架构工作说明书》实际上是架构组织和企业架构（或IT治理功能）的赞助者之间的架构合同
- 一个或多个架构域（业务、数据、应用程序、技术）的开发，以及在某些情况下对企业架构的总体监督，可能外包给系统集成商、应用程序提供商和/或服务提供商。这些安排通常将受到架构合同的约束，该合同定义了开发架构的可交付成果、质量和适用性，以及架构开发合作伙伴之间将如何协同工作
- 在ADM的G阶段（实施治理）开始时，架构功能与负责实施在先前ADM阶段中定义的企业架构的功能之间（通常，这将是内部系统开发功能，或者是将工作外包给的主要承包商）
- 在ADM的G阶段正在“实施”的是整体企业架构。这通常将包括技术基础设施（来自D阶段），以及应用程序架构和数据架构（来自C阶段）中定义的企业范围或具有业务战略意义的企业应用程序和数据管理能力，因此它们在企业范围内具有重要性和可见性。然而，它通常不包括非战略性业务应用程序，业务部门将随后在已实施的技术基础设施上部署这些应用程序
- 在较大规模的实施中，实施项目计划中可能有一个架构合同对应一个实施团队
- 当最终架构定义文档可用时（在F阶段结束时），架构功能（或包含架构功能的IT治理功能）和业务用户（他们随后将在架构环境中构建和部署应用程序系统）之间将起草一份架构合同。在所有这些情况下
重要的是要记住，最终目标不仅仅是一个企业架构，而是一个动态的企业架构；即，一个允许灵活演变的架构，以响应不断变化的技术和业务驱动因素，而不会造成不必要的约束。架构合同对于实现动态企业架构至关重要，并且是治理实施的关键
典型的这三类架构合同的内容解释如下。
5.2 内容
5.2.1 架构工作说明书
《架构工作说明书》作为A阶段的交付成果而创建，实际上是架构组织和企业架构（或代表企业的IT治理功能）的赞助者之间的架构合同。《架构工作说明书》的典型内容如TOGAF标准—架构内容中所述。
5.2.2 架构设计与开发合作伙伴之间的合同
这是一份由合作伙伴组织（包括系统集成商、应用程序提供商和服务提供商）签署的意向书，旨在设计和开发企业架构或其重要部分。越来越多的情况下，一个或多个架构域（业务、数据、应用程序、技术）的开发可能会外包出去，而企业的架构功能则提供对企业架构的总体监督，以及协调和控制整个工作。在某些情况下，甚至这种监督角色也可能被外包出去，尽管大多数企业更倾向于将这一核心责任保留在内部。
无论外包安排的具体内容如何，这些安排本身都将受到架构合同的约束，该合同定义了开发架构的可交付成果、质量和适用性，以及架构开发合作伙伴之间将如何协同工作。典型的架构设计与开发合同内容包括：
- 引言和背景
- 协议的性质
- 架构的范围
- 架构和战略原则及要求
- 合规要求
- 架构开发和管理过程及角色
- 目标架构度量标准
- 已定义的可交付成果阶段
- 优先排序的联合工作计划
- 时间窗口
- 架构交付和业务指标
该合同的模板通常在ADM的初步阶段定义（如果尚未存在），而具体合同将在ADM的适当阶段定义，具体取决于正在外包的工作。
5.2.3 架构功能与业务利益相关者之间的合同
当实施和迁移计划已达成一致（在F阶段结束时），架构功能和业务利益相关者（他们随后将在架构环境中构建和部署架构业务解决方案）之间可能会起草一份架构合同。业务利益相关者的架构合同可能包括：
- 引言和背景
- 协议的性质
- 范围
- 战略要求
- 满足业务要求的架构可交付成果
- 合规要求
- 架构采用者
- 时间窗口
- 架构业务指标
- SLA
该合同也用于管理H阶段对企业架构的变更。
5.3 与架构治理的关系
在架构治理领域，ADM的G阶段产生的架构合同文件显得尤为突出，如第3章所述。在架构治理的上下文中，架构合同经常被用作推动架构变更的手段。为了确保架构合同的有效性和效率，可能需要将治理框架的以下方面引入G阶段：
- 简单的流程
- 以人为中心的权威
- 强大的沟通
- 及时响应和有效的升级流程
- 支持的组织结构
- 架构实施的状态跟踪
第6章：架构合规
本章提供了确保项目符合架构的指南。
6.1 引言
确保单个项目与企业架构的合规性是架构治理（见第3章）的一个重要方面。为此，企业内的IT治理功能通常会定义两个互补的过程：
-
架构功能将需要准备一系列项目架构；即，企业架构的项目特定视图，说明企业架构如何影响组织内的主要项目（见ADM的A至F阶段）
-
企业和IT治理功能将定义正式的架构合规审查流程（见第6.3节），以审查所有项目对企业架构的合规性
除了定义正式流程外，架构治理功能（见第3章）还可能规定，架构功能应超越架构定义和标准选择的作用，并参与到技术选择过程中，甚至参与到外部服务提供和产品采购所涉及的商业关系中。这有助于最大限度地减少对企业架构的误解机会，并最大限度地发挥集中商业谈判的价值。
6.2 术语：架构合规的含义
架构与实施之间的一个关键关系是“合规”、“一致”等术语的定义。虽然不同组织之间的术语使用可能有所不同，但图6-1中所示的合规级别概念在制定IT合规策略时应该很有用。
-
无关：实现与企业架构规范没有共同特征（因此不存在合规性问题）
-
一致：实现与企业架构规范有一些共同特征，并且这些共同特征是根据规范实现的。然而，企业架构规范中的一些特征未得到实现，而实现中包含一些企业架构规范未涵盖的特征
-
合规：企业架构规范中的一些特征未得到实现，但实现的所有特征都被企业架构规范涵盖，并且符合该规范
-
符合：企业架构规范中的所有特征都根据规范实现，但实现中包含一些不符合企业架构规范的额外特征
-
完全一致：企业架构规范与实现之间存在完全对应关系。所有指定特征都根据规范实现，并且没有实现任何不被企业架构规范涵盖的特征
-
不合规：在上述任何情况下，企业架构规范中的一些特征未按规范实现
“符合”一词意味着：
- 支持所述战略和未来方向
- 遵守所述标准（包括指定的语法和语义规则）
- 提供所述功能
- 遵守所述原则；例如：
- 尽可能开放和适当
- 尽可能重用组件构建块
6.3 架构合规审查
架构合规审查是对特定项目是否符合既定的架构标准、精神和业务目标的仔细审查。正式的此类审查流程通常构成企业架构合规策略的核心。
6.3.1 目的
架构合规审查的目标包括以下全部或部分目标：
-
最重要的是，在项目架构的早期阶段发现错误，从而减少后期生命周期中所需变更的成本和风险。这反过来意味着项目总时间缩短，并且业务能够更快地获得架构开发带来的底线利益
-
确保将最佳实践应用于架构工作
-
提供对企业架构对强制企业标准的合规性的概述
-
识别可能需要对标准进行修改的地方
-
识别当前特定于应用程序的服务，这些服务可能作为企业基础设施的一部分提供
-
为多个架构团队之间的协作、资源共享和其他协同制定策略
-
利用技术进步
-
向管理层传达项目的业务和技术准备状态
-
确定采购活动的关键标准；例如，在商用现货（COTS）产品请求信息（RFI）/请求建议书（RFP）文档中包含这些标准
-
向产品和服务提供商传达和沟通重要的架构差距
除了上述与质量保证相关的通用目标外，在某些特定情况下，进行架构合规审查还有额外的、更具政治性的动机：
-
架构合规审查可以是决定架构替代方案的一种好方法，因为参与审查的业务决策者通常可以根据什么对业务最有利来指导决策，而不是从技术上的更优雅或更吸引人方面来指导
-
架构合规审查的输出是向高级管理层提供的少数可衡量的成果之一，以帮助其进行决策
-
架构审查可以成为架构组织参与开发项目的一种方式，否则这些项目可能会在没有架构功能参与的情况下进行
-
架构审查可以迅速、积极地展示对企业业务社区的支持
-
架构与企业架构的合规性有助于确保IT项目与业务目标保持一致
-
架构师有时会被认为深陷技术基础设施之中，而远离核心业务
-
由于架构合规审查主要关注系统的关键风险区域，因此它通常突出系统的主要风险
-
对于开发和实施而言，符合架构是必需的，但不符合架构也提供了一种机制来突出：
-
需要解决的重新对齐领域
-
在合规过程中发现的、可考虑集成到架构中的领域
-
后者指出了架构对可能由不规范行为驱动的需求的持续变更和适应性，但也允许通过运营环境的快速变化来注册变更。通常，豁免（见第3.1.4节）将用于突出这些变更，并启动注册、监控和评估所需变更适宜性的流程。
6.3.2 时机
应考虑架构本身的开发情况来确定合规活动的时机。合规审查应在项目生命周期的适当里程碑或检查点举行。应包括以下具体检查点：
-
架构本身的开发（ADM合规性）
-
架构（们）的实施（架构合规性）
架构项目评估的时机应包括：
-
项目启动
-
初步设计
-
重大设计变更
-
临时性审查
架构合规审查通常针对的是业务需求和企业架构相对确定，且项目架构正在成型的时间点，远远早于项目完成。目的是在尽可能早的实际可行时间举行审查，此时仍有时间纠正任何重大错误或不足，但显然需要项目架构有显著进展，才能有东西可供审查。
标准项目生命周期中可能影响审查时机的其他部分输入也可能来自其他地方。
6.3.3 治理和个人场景
就架构合规审查的治理和进行方式以及参与人员而言，存在各种可能的场景：
-
对于较小规模的项目，审查流程可能只是项目架构师或项目负责人根据提供的清单向自己提出一系列问题，或许将这些答案整理成某种项目报告提交给管理层。进行此类流程的需求通常包含在整体企业范围内的治理政策中
-
如果待审查的项目到目前为止尚未涉及执业或全职架构师（例如，在应用程序级别项目中），审查的目的是利用企业架构功能的架构专业知识。在这种情况下，企业架构功能将组织、领导和进行审查，并有业务领域专家的参与。在这种情况下，审查不是取代架构师在项目中的
6.3.3 治理和人员场景
就架构合规性审查的治理和开展，以及参与人员而言，存在各种可能的场景：
- 对于规模较小的项目，审查过程可以简单地采取一系列问题的形式，这些问题由项目架构师或项目负责人自己提出，使用下面提供的检查表，或许将答案整理成某种项目报告提交给管理层。通常需要将此类过程纳入企业范围的治理政策中。
- 如果待审查的项目迄今为止尚未涉及实践或全职架构师（例如，在应用程序级别的项目中），审查的目的通常是引入企业架构功能的架构专业知识。在这种情况下，企业架构功能将组织、领导和进行审查，业务领域专家的参与。在这种情况下，审查不是项目架构师参与的替代品，但可以作为对他们参与的补充或指导。对于大型系统或系统集的分析，可能需要一个数据库来管理将产生的大量数据。
- 在大多数情况下，特别是在较大规模的项目中，架构职能将深度参与，甚至可能主导待评审的开发项目（这是TOGAF（开放组架构框架）中的典型场景）。在这种情况下，评审将由首席企业架构师负责协调，他将组建一个由业务和技术领域专家组成的评审团队，并将评审期间提出的问题及答案汇编成某种形式的报告。这些问题通常由业务和技术领域专家在评审过程中提出。另外，评审也可能由架构委员会或具有企业级职责的类似机构的代表来主导。
在所有情况下，架构合规性审查过程都需要得到高层管理的支持，并且通常将作为企业架构治理政策的一部分得到授权（见第3章）。通常，企业首席信息官（CIO）或企业架构委员会（见第4章）将授权对所有主要项目进行架构审查，并进行后续年度审查。
6.4 架构合规性审查过程
6.4.1 概述
架构合规性审查过程如下图所示。
注：在架构中获得合规性检查的另一种方法是通过模型中的可追溯性和“钻取”图。在这种技术中，企业架构师创建一个架构的顶层视图，解决方案架构师通过将其元素追溯到企业架构模型来进一步细化。这些细化可以通过所谓的“钻取”图进行管理，其中包含所有细化元素及其可追溯性。通过这种方式，可以使用工具（例如，使用脚本来检查企业架构元素是否都在解决方案架构中有细化）来审查和至少部分自动化合规性。
6.4.2 角色
过程中的主要角色如下表所示。
| 编号 | 角色 | 职责 | 备注 |
| 1 | 架构委员会 | 确保企业架构与企业整体业务需求一致。 | 赞助并监控架构活动。 |
| 2 | 项目负责人（或项目委员会） | 对整个项目负责。 | |
| 3 | 架构审查协调员 | 管理整个架构开发和审查过程。 | 更可能是面向业务而非技术。 |
| 4 | 首席架构师 | 确保架构在业务和技术上都是连贯的，并且是面向未来的。 | 适当的架构专家 |
| 5 | 架构师 | 首席企业架构师的助手之一。 | |
| 6 | 客户 | 确保业务需求得到清晰表达和理解。 | 管理将依赖于企业架构成功的那部分组织。 |
| 7 | 业务领域专家 | 确保满足业务需求的流程是合理的且被理解的。 | 了解业务领域如何运作；也可能是客户。 |
| 8 | 项目负责人 | 确保架构师对客户部门的流程有足够详细的了解。他们可以向业务领域专家或架构师提供输入。 | 属于客户组织、对架构要解决的业务需求有投入的成员。 |
6.4.3 步骤
过程中的主要步骤如下表所示。
| 编号 | 行动 | 备注 | 执行者 |
| 1 | 请求架构审查。 | 根据治理政策和程序授权。 | 任何对企业受影响业务领域感兴趣或有责任的人，无论是IT还是业务导向的。 |
| 2 | 确定负责的组织和相关项目负责人。 | 架构审查协调员 | |
| 3 | 确定首席企业架构师和其他架构师。 | 架构审查协调员 | |
| 4 | 确定审查范围。 | 确定其他涉及的业务部门/部门。了解系统在企业架构框架中的位置。 | 架构审查协调员 |
| 5 | 定制检查表。 | 以满足业务需求。 | 首席企业架构师 |
| 6 | 安排架构审查会议。 | 架构审查协调员与首席企业架构师协作 | |
| 7 | 对项目负责人进行面试 |
获取背景和技术信息：对于内部项目：面对面；对于COTS：面对面或通过RFP。 使用检查表。 |
首席企业架构师和/或架构师、项目负责人和客户 |
| 8 | 分析完成的检查表。 | 根据企业标准进行审查。识别并解决问题。确定建议。 | 首席企业架构师 |
| 9 | 准备架构合规性审查报告。 | 可能涉及支持人员。 | 首席企业架构师 |
| 10 | 汇报审查结果。 | 向客户汇报；向架构委员会汇报。 | 首席企业架构师 |
| 11 | 接受审查并签署。 | 客户和架构委员会。 | |
| 12 | 将评估报告/摘要发送给架构审查协调员。 | 首席企业架构师 |
6.5 架构合规性审查检查表
以下审查检查表提供了在进行架构合规性审查时可能使用的各种问题，这些问题涉及架构的各个方面。问题的组织包括系统工程、信息管理、安全性和系统管理的基本学科。提供的检查表包含太多问题，无法用于任何单一的审查：它们旨在根据特定项目有选择性地定制（参见第6.6节）。实际使用的检查表通常由领域专家开发/选择。预计这些检查表将由这些领域的兴趣小组每年更新。一些检查表包括激发问题的架构原则简述，以及查找答案时要考虑的内容简述。这些检查表的扩展旨在允许智能地重新表述问题，并让用户了解提出问题的原因。有时问题会以RFP中的形式编写，或者在与高级项目架构师合作时编写。更典型的是，它们以口头形式表达，作为与项目的访谈或工作环节的一部分。提供的检查表旨在用于单个架构项目，而不是业务域架构或多个项目的架构。（对更大范围的活动进行架构审查，跨越多个业务流程和系统项目，将涉及类似的过程，但检查表类别及其内容将有所不同。）
6.5.1 硬件和操作系统检查表
- 该项目的生命周期方法是什么？
- 该项目处于其生命周期的哪个阶段？
- 该项目已确定或分析了哪些关键问题，这些问题将推动对网络、服务器和最终用户设备的硬件和操作系统的评估？
- 哪些系统功能将涉及大量和/或高频数据传输？
- 系统设计如何影响或涉及最终用户设备？
- 使用量、数据存储和处理的数量和分布（区域和全球）是多少？
- 哪些应用程序与您的项目通过数据、应用程序服务等方面的相似性相关联？您的项目与数据的关联程度如何？
- 在系统关键元素的功能设计之前，已做出了哪些硬件和操作系统选择？
- 如果硬件和操作系统的决策是在项目控制之外做出的：项目对这些决策的依据有何了解？随着系统设计的发展，项目如何影响这些决策？
- 如果选择了一些非标准：不使用企业标准的基本业务和技术要求是什么？是否有业务案例支持？业务案例中的假设是否经过审查？
- 您评估硬件和操作系统的全生命周期成本的过程是什么？
- 企业财务管理如何参与全生命周期成本的评估？
- 您是否对供应商进行了财务分析？
- 您是否对任何供应商做出了承诺？
- 您是否认为只有一个供应商能满足您的要求？
6.5.2 业务应用程序
- 描述错误条件是如何在应用程序之间定义、引发和传播的组件。
- 描述各种方法定义和安排的一般模式应用模块。
- 描述在Java中如何定义和组织方法参数的一般模式各种应用模块。[in]、[in/out]、[out]参数是否总是在中指定相同的顺序？模块返回的布尔值是否具有一致的结果？
- 描述用于最小化客户端之间往返次数的方法服务器调用，特别是进程外调用，以及复杂数据结构涉及。
- 描述在主要系统组件之间传递的主要数据结构。
- 描述主要系统之间使用的主要通信协议组件。
- 描述各种系统组件之间使用的编组技术。描述所使用的任何专门的编组安排。
- 描述系统在多大程度上设计有有状态和无状态组件。
- 描述如何以及何时为有状态和无状态组件保存状态。
- 描述对象在创建、使用、销毁和重新使用方面的程度通过对象池。
- 描述系统在多大程度上依赖于线程或临界区编码。
- 描述在内部使用的做法和内部文件系统记录方法、方法参数和方法功能。
- 描述用于构建系统的代码审查过程。
- 描述用于测试系统组件的单元测试。
- 描述各种系统模块中包含的前置和后置条件测试。
- 描述系统中包含的断言测试。
- 组件是否支持它们需要支持的所有接口类型，还是某些关于哪些类型的组件将调用其他组件的假设语言绑定条款还是其他封送处理条款？
- 描述矩阵问题的大端或小端数据的范围需要跨不同平台处理。
- 描述数字或字符串是否需要在不同的平台上进行不同的处理。
- 描述软件是否需要检查浮点舍入误差。
- 描述时间和日期功能如何管理日期，以避免对日期的不当处理时间和日期计算或显示。
- 描述使用了什么工具或过程来测试系统的内存泄漏，可达性或一般鲁棒性。
- 描述系统服务软件的分层。描述一般数量主要系统组件之间的链接。系统是由许多点对点组成的接口或主要的消息传递主干是否被使用？
- 描述系统组件在多大程度上是松散耦合或紧密耦合的耦合。
- 在在共享资源方面，系统需要基础设施满足哪些要求库、对通信协议的支持、负载平衡、事务处理、系统监控、命名服务或其他基础结构服务？
- 描述系统和系统组件是如何为重构而设计的。
- 描述系统或系统组件如何依赖于通用消息传递基础架构与独特的点对点通信结构。
6.5.3 应用程序检查清单
6.5.3.1 基础设施（企业生产力）应用程序
- 是否存在企业标准基础设施应用程序产品未提供的功能需求？例如：
■ 协作
— 应用程序共享
— 视频会议
— 日历功能
— 电子邮件
■ 工作流管理
■ 发布/文字处理应用程序
— HTML
— SGML和XML
— 可移植文档格式
— 文档处理（专有格式）
— 桌面出版
■ 电子表格应用程序
■ 演示应用程序
— 商业演示
— 图像
— 动画
— 视频
— 声音
— 计算机辅助教学（CBT）
— 网络浏览器
■ 数据管理应用程序
— 数据库接口
— 文档管理
— 产品数据管理
— 数据仓库/数据集市
■ 项目管理应用程序
— 项目管理
— 项目可见性
2. 描述企业基础设施应用能力的业务要求标准产品无法满足这些要求。
6.5.3.2 业务应用程序
- 是否有支持一个或多个业务线应用程序的标准产品提供了所需的功能？例如：
■ 业务收购应用程序
— 销售和市场营销
■ 工程应用程序
— 计算机辅助设计
— 计算机辅助工程
— 数学和统计分析
■ 供应商管理应用程序
— 供应链管理
— 客户关系管理
■ 制造应用程序
— 企业资源规划（ERP）应用程序
— 制造执行系统
— 制造质量
— 制造过程工程
— 机器和自适应控制
■ 客户支持应用程序
— 航空物流支持
— 维修工程
■ 财务应用程序
■ 人力资源应用程序
■ 设施应用程序
■ 信息系统应用程序
— 系统工程
— 软件工程
— 网络开发工具
— 集成开发环境
— 生命周期类别
— 功能类别
— 特殊类别
■ 计算机辅助制造
■ 电子商务支持
■ 业务流程工程
— 统计质量控制
2. 描述不符合业务应用能力的流程要求标准产品。
6.5.3.3 应用集成方法
- 哪些集成点（业务流程/活动、应用程序、数据、计算环境）是该架构的目标吗？
- 将应用哪些应用程序集成技术（通用业务对象[对象请求代理（ORB）]、标准数据定义[XML等]、通用用户界面演示文稿/桌面）？
6.5.4 信息管理检查表
6.5.4.1 数据值
- 规范数据管理和使用的流程是什么？
- 哪些业务流程支持数据的输入和验证？数据的使用？
- 哪些业务行为对应数据的创建和修改？
- 删除数据对应哪些业务行为，是否被视为商业记录？
- 业务用户要求的数据质量要求是什么？
- 采取了哪些流程来支持数据引用完整性和/或规范化？
6.5.4.2 数据定义
- 购买的数据模型、数据定义、结构和托管选项是什么应用程序（COTS）？
- 定义和维护所有数据要求和设计的规则是什么信息系统的组成部分？
- 使用 使用什么可共享的存储库来捕获模型内容和支持信息数据信息？
- 用于以下目的的物理数据模型定义（从逻辑数据模型中派生）是什么设计数据库？
- 选择了哪些软件开发和数据管理工具？
- 已经确定哪些数据所有者负责共同数据定义，消除计划外的冗余，提供始终可靠、及时和准确
- 信息，并保护数据免遭滥用和破坏？
6.5.4.3 安全/保护
- 保护数据免受攻击的数据实体和属性访问规则是什么无意和未经授权的更改、披露和分发？
- 有什么数据保护机制可以保护数据免受未经授权的外部访问访问？
- 控制 控制外部来源数据访问的数据保护机制是什么
在企业内部临时居住？
6.5.4.4 托管、数据类型和共享
- 将唯一权威数据作为具有定义的数据源进行管理的原则是什么更新驻留在不同平台上的物理数据的规则？
- 管理 管理复制数据的纪律是什么，这些数据是从运营中衍生出来的唯一权威数据？
- 已确定哪一级数据服务器用于存储高或中等关键数据操作数据？
- 已确定哪一层数据服务器用于存储C类运行数据？
- 已确定使用哪一层数据服务器来存储决策支持数据包含在数据仓库中？
- 已经实施了哪些数据库管理系统（DBMS）？
6.5.4.5 公共服务
- 标准化分布式数据管理服务(例如，一致性检查、数据编辑、加密和事务管理）以及它们在哪里？
6.5.4.6 访问方法
- 标准文件、消息和数据管理的访问要求是什么?
- 决策支持数据的访问要求是什么？
- 数据存储和应用逻辑位置是什么？
- 使用什么查询语言？
6.5.5 安全检查表
- 安全意识：您是否确保公司安全政策和您所设计的指导方针是最新版本吗？你读过了吗？您了解所有相关的计算安全合规性和风险接受流程吗？(观众应列出所有相关政策和指南。）
- 识别/认证：绘制用户如何被识别的流程图应用程序以及应用程序如何验证用户是否是他们声称的人。向诊断人员提供支持文件，解释用户的流程应用程序/数据库服务器的接口，并返回给用户。你是否合规了解公司关于账户、密码等方面的政策。？
- 授权：提供从开始到结束的流程，显示用户如何请求访问应用程序，指出相关的安全控制措施，以及职责分离。这应该包括请求是如何被适当的批准的数据所有者，如何将用户置于适当的访问级别分类配置文件中，如何创建用户ID、密码和访问权限并将其提供给用户。还包括如何告知用户使用应用程序的相关责任，给定一份访问协议的副本，如何更改密码，向谁寻求帮助等。
- 访问控制：记录用户ID、密码和访问配置文件是如何添加、更改、删除和记录。文件应包括谁负责这些流程。
- 敏感信息保护：提供识别敏感数据的文件需要额外的保护。确定负责此数据的数据所有者以及用于保护此数据的存储、传输、打印和分发的过程。包括如何保护密码文件/字段。如何阻止用户查看别人的敏感信息？是否与外部各方签订了协议（合作伙伴、供应商、承包商等）关于信息保护？如果是这样，义务是什么？
- 审计追踪和审计日志：识别并记录集团账户所需的用户或应用程序支持，包括操作系统组帐户。识别和记录具有超级用户类型权限的个人帐户和/或角色，以及这些特权是，谁有权访问这些帐户，如何访问这些帐户受控、跟踪和记录，以及如何处理密码更改和分发，包括操作系统帐户。还要确定审计日志，谁可以读取审计日志，谁可以修改审核日志，谁可以删除审核日志，以及审核日志是如何处理的保护和储存。审计追踪中是否隐藏了用户 ID？
- 外部访问注意事项：应用程序是否仅供内部使用？如果没有，那么您是否符合公司外部访问要求？
6.5.6 系统管理检查表
- 必须分发的软件更改的频率是多少？
- 软件 软件分发使用什么工具？
- 生产 生产中是否允许多个软件和/或数据版本？
- 用户数据备份频率和预期恢复时间是多少？
- 用户帐户是如何创建和管理的？
- 系统许可证管理策略是什么？
- 需要哪些通用的系统管理工具？
- 需要哪些特定的应用程序管理工具？
- 需要哪些特定的服务管理工具？
- 如何接收和调度服务呼叫？
- 描述如何卸载系统。
- 描述可用于检查系统是否正确安装的过程或工具。
- 描述可用于监测健康状况和系统的性能。
- 描述可用于确定系统位置的工具或流程已安装。
- 描述哪些审计日志用于捕获系统历史，特别是在事件发生后。
- 描述系统向服务发送自己的错误消息的能力人员。
6.5.7 系统工程/总体架构检查清单
6.5.7.1 总体
- 您的系统需要与哪些其他应用程序和/或系统进行集成？
- 描述与每个系统的集成级别和策略。
- 用户群体的地理分布情况如何？
- 此系统对企业内部或外部的其他用户群体具有怎样的战略重要性？
- 为企业内部用户提供系统服务需要哪些计算资源？在企业外部使用企业计算资源时呢？在企业外部使用他们自己的资源时呢？
- 非原生交付环境下的用户如何访问您的应用程序和数据？
- 此应用程序的预期使用寿命是多久？
- 描述能够适应用户群体、存储数据和交付系统技术变化的设计。
- 用户群体的规模以及他们的预期性能水平如何？
- 您使用哪些性能和压力测试技术？
- 软件和数据组件的总体组织结构是怎样的？
- 总体服务和系统配置是怎样的？
- 软件和数据是如何配置并映射到服务和系统配置的？
- 此系统需要哪些专有技术（硬件和软件）？
- 描述如何随时间推移再现和重新部署软件的每个版本。
- 描述当前用户群体以及预计未来三至五年内该群体将如何变化。
- 描述当前用户群体的地理分布情况，以及预计未来三至五年内该群体将如何变化。
- 描述当前或未来有多少用户需要以移动方式使用应用程序或需要离线工作。
- 描述应用程序的一般功能、主要组件和主要数据流。
- 描述应用程序中包含的监控工具，以便监控应用程序的健康状况和性能。
- 描述系统的业务理由。
- 描述在选择系统开发语言时，相对于其他选项，在初始开发成本与长期维护成本之间的考量。
- 描述用于得出系统架构以及系统架构中产品选择阶段的系统分析过程。
- 除了原始客户外，还有谁可能使用或受益于使用此系统？
- 有多少比例的用户以浏览模式而非更新模式使用系统？
- 事务性请求的典型长度是多少？
- 您是否需要保证数据交付或更新，或者系统是否容忍故障？
- 系统的正常运行时间要求是什么？
- 描述系统架构遵守或不遵守标准的情况。
- 描述项目所使用的项目规划和分析方法。
6.5.7.2 处理器/服务器/客户端
- 描述客户端/服务器应用程序架构。
- 标注图示，以说明应用程序功能在哪里执行。
6.5.7.3 客户端
- 用户设备上是否执行了除呈现功能以外的其他功能？
- 描述提供的数据和处理帮助功能。
- 描述屏幕间的导航技术。
- 描述用户如何在此应用程序和其他应用程序之间导航。
- 用户设备如何启动此应用程序和其他应用程序？
- 是否存在应用程序间的数据和过程共享能力？如果存在，描述共享的内容以及使用的技术/技术方法。
- 描述传输到客户端的数据量。
- 支持应用程序所需的本地数据存储有哪些额外要求？
- 支持应用程序所需的本地软件存储/内存有哪些额外要求？
- 是否存在由其他应用程序要求或情况引起的已知硬件/软件冲突或容量限制，这些会影响应用程用户？
- 描述您的表示层的外观和感觉与其他现有应用程序的外观和感觉相比如何。
- 描述客户端需要支持异步和/或同步通信的程度。
- 描述系统的表示层如何与系统的其他计算层或数据传输层分离。
6.5.7.4 应用服务器
- 表示层和应用层是否可以在单独的处理器上运行？
- 应用层和数据访问层是否可以在单独的处理器上运行？
- 此应用程序是否可以独立于所有其他应用程序放置在应用服务器上？如果不能，解释其依赖关系。
- 是否可以轻松添加额外的并行应用服务器？如果可以，负载均衡机制是什么？
- 是否已测量应用程序生成的资源需求，其值是多少？如果是，是否已在应用程序级别和总体级别上确认了计划服务器的容量？
6.5.7.5 数据服务器
- 是否有其他应用程序必须共享数据服务器？如果是，请识别它们，并描述数据和数据访问要求。
- 是否已测量应用程序生成的资源需求，其值是多少？如果是，是否已在应用程序级别和总体级别上确认了计划服务器的容量？
6.5.7.6 COTS（如适用）
- 供应商是否实力雄厚且稳定？
- 供应商倒闭后，企业是否会获得源代码？
- 此软件是否已配置为企业使用？
- 是否存在任何特殊的A&D数据或过程会阻碍使用此软件？
—此软件目前是否可用？ -
它是否已被用于/演示过满足与企业相似的容量/可用性/服务级别要求？
—描述供应商过去的财务和市场份额历史。
6.5.8 系统工程/方法与工具检查清单
- 当前业务方式是否有指标？
- 系统所有者是否已创建将用于指导项目的评估标准？描述如何使用评估标准。
- 是否已研究现有架构以利用现有工作？描述发现和理解所使用的方法。架构是否会集成？如果是，解释将使用的方法。
- 描述项目中将使用的方法：
—定义业务战略
—定义需要改进的领域
—定义基线和目标业务流程
—定义过渡过程
—管理项目
—团队沟通
—知识管理、变更管理和配置管理
—软件开发
—参考标准和方向声明
—交付成果的质量保证
—设计评审和交付成果验收
—捕获指标 - 这些方法是否已记录并分发给每个团队成员？
- 团队成员对这些方法的熟悉程度如何？
- 有哪些流程来确保遵守这些方法？
- 描述为支持在整个项目期间和预期发布期间使用这些方法而建立的基础设施。
—如何提供咨询和故障排除？
—如何协调培训？
—如何融入和推广更改和增强功能？
—如何捕获和传播经验教训？
9. 项目中使用了哪些工具？（指定版本和平台）。团队成员对这些工具的熟悉程度如何？
10. 描述为支持在整个项目期间和预期发布期间使用这些工具而建立的基础设施。
—如何提供咨询和故障排除？
—如何协调培训？
—如何融入和推广更改和增强功能？
—如何捕获和传播经验教训？
11. 描述项目将如何促进其交付成果和交付内容的重用。
12. 项目实施后，架构设计是否会“存活”？描述将用于将更改重新融入架构设计的方法。
13. 是否已定义当前流程？
14. 问题是否已记录、评级并与当前流程相关联？如果没有，您如何知道您正在修复已损坏的东西？
15. 是否已识别并与当前流程相关联了现有/计划的流程改进活动？如果没有，您如何知道此活动不会与其他工作说明书冲突或重复？
16. 您是否有当前指标？您是否有预测指标？如果没有，您如何知道您正在改进某些东西？
17. 您将建立哪些流程来收集、评估和报告指标？
18. 新设计将对现有业务流程、组织和信息系统产生哪些影响？这些影响是否已记录并与所有者共享？
6.6 架构合规性审查指南
6.6.1 定制检查清单
■ 聚焦:
—高风险区域
—预期（和紧急）差异化因素
■ 对于清单中的每个问题，请理解：
—问题本身
—其背后的原则
—在回复中寻找什么
■ 询问领域专家的意见
■ 整理清单中的问题，以供您使用
■ 请记住，需要向架构委员会提供反馈
6.6.2 进行架构合规性审查
- 楚地了解征求审查意见的目的；并保持正轨交付所要求的东西。例如，他们通常想知道什么是对的，什么是错的系统正在进行架构设计；发展没有对错之分所使用的方法、他们自己的管理结构等。很容易偏离轨道讨论有趣且可能值得讨论的主题，而不是所征求的主题。如果你可以对技术方法进行阐述和洞察，但讨论不是审查后，自愿提供审查所需的必要信息。
- 如果在讨论过程中明显发现还有其他问题需要解决在所要求的审查范围之外的地址，将其与之后，会议主席。然后可以在以下方面制定解决这些问题的计划根据其严重程度。
- 保持“科学”。而不是：“我们喜欢看到大型数据库托管在ABC上，而不是XYZ。，例如：“与 XYZ 数据库环境相关的停机时间要长得多比 ABC 数据库环境中的要大。因此，我们不建议托管类型XYZ 环境中的 Mand Nsystems。"问“开放式”问题；即，不预设特定答案的问题。
- 那些寻求审查的人往往有“隐藏的议程”或有争议的问题，你或许一开始不会知道。在讨论中采取非人格化的方法可能有助于弥合意见分歧，而不是加剧分歧。
- 尊重被采访者。他们可能没有按照“它”的方式建立这个系统应该是“，但他们可能是在这种情况下尽其所能了他们被安置了。帮助练习成为你和主持人的学习经历。
- 评审应包括针对架构的详细评估活动，并应确保结果存储在企业连续体中
魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。
更多推荐
26
0- 0
已为社区贡献21条内容
所有评论(0)