委员会架构图 委员会结构的含义

3.

4.3.2 参与流程的各角色及职责

角色	职责	备注
架构委员会	确保IT架构的一致性，并能对所有业务目标进行支持	赞助并监督架构活动
项目组长 （或项目委员会）	为这个项目负责
架构审查协调人	管理整个架构的开发和审查流程	更倾向于面向业务，而不是技术
首席企业架构师	确保架构在技术上的连贯，并且是面向未来的	一个IT架构专家
架构师	首席企业架构师的技术助理之一
客户	确保业务需求被清晰地描述和理解	管理组织的一部分，该部分依赖于在架构中所描述的信息技术的成功实现和运用
业务领域专家	确保用于满足业务需求的流程是合理并能够被理解的	了解业务领域的运作。可以通过客户来担当这一角色
项目负责人	确保架构师对于客户部门流程有着足够详细的理解，并能够为业务领域专家或架构师提供各种所需的输入	能够为架构所要满足的业务需求提供输入的客户组织中的成员

4.4 架构合规性审查问题参考列表

      架构合规性审查是针对各个项目与架构的符合度而进行的审议活动，而这一活动的具体实施需要围绕着一份问题清单来进行的。为了帮助这一份问题清单的制定，TOGAF根据架构的各个方面提出了一系列备选问题，而负责问题清单开发的领域专家可以根据所审查架构的特性在这些备选问题中进行选择和定制。需要注意的是，这里所列出的问题并不适用于针对业务领域架构或跨越多个项目的架构的审查。针对这些架构的审查的流程虽然相似，但是其所使用的问题清单的类别和内容将会有所不同。（有些问题并不是以提问的形式出现，而是通过简短的描述来对引发问题的缘由，以及答案中所应包含的内容方向进行了阐述，从而使得相关人员可以按照各自情况编制出合适的问题）

4.4.1 硬件和操作系统问题清单

• 项目生命周期方法是什么？
• 项目目前处在生命周期的哪个阶段？
• 已经被明确的或被用作分析的，在项目中用来对网络、服务器以及终端设备的硬件和操作系统进行评估的关键问题是什么？
• 将要参与到大量和/或高频率数据传输中去的系统能力是什么？
• 系统设计是如何影响或涉及到终端用户设备的？
• 所进行的使用、数据存储和处理的数量及分布（地区性和全局性）是什么？
• 通过对比数据、应用服务等方面的相似性，应用与项目的关联有哪些？并且数据与项目的关联程度为何？
• 在系统关键元素的功能性设计之前就已经做出的关于硬件和操作系统的选择是什么？
• 是否关于硬件和操作系统的决策制定超出了项目的控制？

• 项目对于那些决策的理由有什么样的认识？
• 当系统设计成型时，项目是如何影响那些决策的？

• 是否选择了非标准化的内容？
• 不使用公司标准的关键业务和技术需求是什么？
• 是否被业务案例所支持？
• 在业务案例中的假设是否已被审查？
• 用于评估硬件和操作系统的全生命周期成本的流程是什么？
• 公司财务管理是如何被引入到生命周期成本评估中去的？
• 是否进行了供应商的财务分析？
• 是否对供应商提出了承诺？
• 是否坚信需求仅被一个供应商所满足？

4.4.2 软件服务和中间件问题清单

• 描述错误条件是如何在应用组件之间被定义、产生和传播的。
• 描述在各个应用模块中关于方法定义和排列的通用模式。
• 描述在各个应用模块中关于方法参数定义和排列的通用模式。
• 描述用来最小化服务器和客户端之间调用次数的方法，这对于在进程间进行具有复杂数据结构的调用尤其重要。
• 描述在主要系统组件之间进行传递的主要数据结构。
• 描述在主要系统组件之间进行通信所采用的协议。
• 描述在不同系统组件之间所使用的编组（marshaling）技术，并针对所使用的特定编组安排进行描述。
• 描述系统在多大程度上设计有状态（stateful）和无状态（stateless）组件？
• 针对有状态和无状态组件来描述如何以及何时进行状态保存。
• 相比于对象池中对象的重用，描述在什么范围内对对象进行创建、使用和销毁。
• 描述系统依赖于线程或临界区代码的程度。
• 描述在系统内部用来记录方法、方法参数和方法功能的方式和内部文档。
• 描述代码审查流程。
• 描述用来测试系统组件的单元测试。
• 描述包含在各种系统模块中的前置和后置条件测试。
• 描述包含在系统中的断言测试。
• 各个组件是否具备了它需要支持的所有接口？亦或某些关于何种类型组件采用语言绑定或其它形式的编组（marshaling）方式来调用其它组件的假设是否被制定？
• 描述在何种程度上对跨平台的大字节或小字节数据格式问题进行了处理。
• 描述在不同平台上是否对数字和字符串的处理采用不同的方式。
• 描述是否软件需要对浮点舍入误差进行检查。
• 描述时间和数据是如何应对千年虫问题的。
• 描述何种工具和流程被用来就内存泄漏、可达性（reachability）或一般鲁棒性（general robustness）来对系统进行测试的。
• 描述系统服务软件的分层情况。描述主要系统组件之间的连接的一般数量。是否系统大量采用点对点方式进行联系，还是主要通过消息路由的方式？
• 描述系统组件松耦合或紧耦合的程度。
• 就共享库、通信协议支持、负载平衡、事务处理、系统监控、命名服务或其它基础服务来讲，系统对于底层基础设施的需求是什么？
• 描述系统和系统组件是如何通过设计来达成重构性的？
• 描述相对于采用点对点的通信结构，系统或系统组件是如何依赖于通用消息基础设施的？

4.4.3 应用问题清单

• 基础设施应用

• 是否需要一些企业标准基础设施应用产品并没有提供的能力？例如：

• 团队协作方面：

• 应用共享
• 视频会议
• 日程安排
• 电子邮件

• 工作流管理
• 出版/文字处理应用

• HTML
• SGML和XML
• 可移植的文档格式
• 文档处理（专有格式）
• 桌面发布系统（Desktop publishing）

• 电子表格应用
• 展示应用

• 业务展示
• 图片
• 动画
• 视频
• 音响
• 基于计算机的培训系统（CBT：Computer-Based Trainning）
• Web浏览器

• 数据管理应用

• 数据库接口
• 文档管理
• 产品数据管理
• 数据仓库/集市

• 项目管理应用

• 项目管理
• 项目可见度（Program visibility）管理

• 描述标准产品所不能满足的对于企业基础设施应用能力的业务需求。

• 业务应用
• 是否用于支持一条或多条业务线应用的标准产品提供了所需要的能力？例如：
• 业务采购应用：
• 销售和市场
• 工程应用
• 计算机辅助设计
• 计算机辅助工程
• 数学和统计分析
• 供应管理应用
• 供应链管理
• 客户关系管理
• 生产应用
• 企业资源规划（ERP）应用
• 制造执行系统
• 制造质量
• 制造工艺工程
• 机器和自适应控制
• 客户支持应用
• 航空物流支持
• 维护工程
• 财务应用
• 人员应用
• 设施应用
• 信息系统应用
• 系统工程
• 软件工程
• Web开发工具
• 集成式开发环境
• 生命周期类别
• 功能类别
• 专业类别
• 计算机辅助生产
• 电子商务支持
• 业务流程工程
• 统计质量控制
• 描述标准产品所不能满足的对于业务应用能力的流程需求。
• 应用集成方法
• 架构的目标集成点（业务流程/活动、应用、数据、计算环境）是什么？
• 所采用的应用集成技术是什么（通用数据对象、标准数据定义（STEP、XML等）、通用用户界面展示）？

4.4.4 信息管理问题清单

• 数据价值方面

• 用于对数据的管理和使用进行标准化的流程是什么？
• 用于支持数据录入和验证的业务流程是什么？数据的用处为何？
• 与数据的创建和修改相关的业务行为是什么？
• 与数据的删除相关的业务行为是什么？是否这些数据被认为是业务记录的一部分？
• 业务用户对于数据质量的需求是什么？
• 当前用于支持数据引用完整性和/或规范化的流程是什么？

• 数据定义方面
• 所购买的应用的数据模型、数据定义、结构以及主机选项（hosting options）都是什么？
• 用于定义和维护数据需求规则以及对信息系统中所有组件所进行的设计是什么？
• 何种共享资源库被用来保存数据模型内容和数据的支持性信息？
• 用于设计数据库的物理数据模型定义是什么？
• 所选择的软件开发和数据管理工具是什么？
• 已明确的对如下事项进行负责的数据拥有者都有哪些？：
• 通用数据定义
• 计划外冗余的消除
• 稳定可靠性的提供
• 信息的及时性和准确性
• 防止数据被滥用和破坏
• 安全/保护方面
• 为了防止数据被无意及未授权的更改、泄露和散布，对于数据实体及其属性的访问应该制定什么样的规则？
• 用于保护数据免于被外界进行未授权访问的数据保护机制是什么？
• 采用何种机制来控制企业内部临时驻留性外部资源对于数据的访问？
• 托管、数据类型和共享方面
• 用于将单一授权数据作为一个逻辑数据源进行管理的规程为何？这一逻辑数据源为贮存在不同平台上的物理数据定义了更新规则。
• 用于对复制数据进行管理的规程为何？这些复制数据来源于运行中的单一授权数据。
• 已经明确的用于储存高级或中级重要度的运行数据的层级数据服务器为何？
• 已经明确的用于储存C类型运行数据的层级数据服务器为何？
• 已经明确的用于储存包含在一个数据仓库中的决策支持数据的层级数据服务器为何？
• 所实现的数据库管理系统为何？
• 通用服务
• 标准化的分布式数据管理服务（例如，数据验证、一致性检查、数据编辑、加密以及事务管理）为何？这些服务存在于何处？
• 访问方法
• 对于标准文件、消息和数据管理的数据访问需求为何？
• 对于决策支持数据的访问需求为何？
• 数据存储库和应用逻辑位置为何？
• 采用何种查询语言？

4.4.5 安全方面问题清单

• 安全意识：

• 是否已确保正在使用的公司安全策略和导则是最新的版本？
• 是否已经阅读了最新版本的公司安全策略和导则？
• 是否了解所有相关的计算安全合规性和风险接受流程？

• 识别/认证：对于一个用户是如何被应用所识别，以及此应用是如何验证该用户确为其所声称那个人的过程流进行图形表述。对这一图形表述提供支持性文档，从而对用户界面和应用/数据库服务器之间的交互流程进行解释。是否符合公司关于账户、密码等方面的策略？
• 授权：提供一个流程来展示一个用户如何申请访问某个应用，从而指明了相关的安全控制以及责任的划分。这一流程应该包括：
• 申请是如何被适当的数据拥有者所批准？
• 用户是如何被归入到适当的访问级别分类设定档中的？
• 用户账号、密码和访问是如何建立的，并如何提供给用户的？
• 如何通知用户对于应用的使用责任？
• 如何变更密码？
• 应向谁请求帮助？
• 其他。
• 访问控制：记录用户的账户、密码和访问配置是如何被增加、更改、删除和记录的？这一文档还应该包括对这些流程进行负责的人员。
• 敏感信息保护：提供确定了需要额外保护的敏感数据的文档。明确对这些数据进行负责的数据拥有者，以及用来保护数据存储、传输、打印和分发的流程。这包括：
• 如何对密码文件或字段进行保护？
• 如何防止用户查看他人的敏感信息？
• 与外部团体之间是否具有着信息保护的协议？如果是，具体责任和义务为何？
• 审计跟踪和审计日志：
• 明确并记录被多个用户或应用支持所需要的组账户。
• 明确并记录个人账户和/或具有超级用户权限的角色。
• 这些权限为何？
• 何人可以访问这些账户？
• 如何对这些账户的访问进行控制和跟踪，以及如何对其进行日志记录？
• 如何处理密码的变更和分发？
• 明确审计日志：
• 何人可以读取审计日志？
• 何人可以修改审计日志？
• 何人可以删除审计日志？
• 如何保护和存储审计日志？
• 用户账户在审计日志中是否记录不清？
• 外部访问注意事项：
• 是否应用只是内部使用？
• 如果不是内部使用，那么是否符合公司的外部访问需求？

4.4.6 系统管理问题清单

• 必须被分发出去的软件更新的频率为何？
• 采用何种工具进行软件分发？
• 是否在产品中允许使用多个软件和/或数据版本？
• 用户数据的备份频率以及期望的回复时间为何？
• 如何对用户的账户进行创建和管理？
• 系统授权的管理策略为何？
• 需要采用何种通用系统管理工具？
• 需要采用何种特定的服务管理工具？
• 如何接受和发送服务调用？
• 描述如何卸载系统。
• 描述用于检查系统是否被正确安装的流程或工具。
• 描述用于监督系统健康状况和性能的工具或仪器。
• 描述用来确定系统被安装在何处的工具或流程。
• 描述用于捕捉系统历史（特别是在一次意外发生之后）的审计日志的格式。
• 描述系统将其错误消息发送给服务人员的能力。

4.4.7 系统工程/整体架构问题清单

• 一般性问题

• 需要整合进来的其他应用和/或系统为何？
• 描述集成度水平和战略。
• 用户群的地理分布为何？
• 系统对于其他企业内外用户团体的战略重要性为何？
• 需要什么样的计算资源来为企业内的用户、处于企业外并使用企业计算资产的用户，以及处于企业外并使用他们自有资产的用户提供系统服务？
• 处于本地交付环境之外的用户如何访问企业的应用和数据？
• 当前应用的平均寿命为何？
• 描述用于适应来源于用户群、存储的数据以及交付系统技术的变化的设计。
• 用户群的规模以及他们的期望性能水平为何？
• 采用何种性能和压力测试技术？
• 软件和数据组件的整体组织方式为何？
• 整体的服务和系统配置为何？
• 软件与数据是如何被配置和映射到服务及系统配置之上的？
• 此系统需要何种专门的软硬件技术？
• 描述每个版本的软件是如何随着时间的推移而被重制和重新部署的？
• 描述当前的用户群，以及在之后的三到五年中对其变化的预期。
• 描述当前的用户群地理分布，以及在之后的三到五年中对其变化的预期。
• 描述在当前或未来需要通过移动或离线方式来对应用进行使用的用户数量。
• 描述应用的通常行为、其主要组件以及主要的数据流。
• 描述包含在应用中并用于监督其健康和性能状况的仪器。
• 描述系统的业务缘由。
• 从初始开发成本对比长期维护成本的角度出发，描述选择系统开发语言的理由。
• 描述用于产生系统架构及其产品选择阶段的系统分析流程。
• 除了原来的客户之外还有谁会通过对此系统的使用而获益？
• 通过浏览模式和更新模式来使用此系统的用户比例为何？
• 事务性的申请数量通常为多少？
• 是否需要严格保障的数据传输或更新？系统是否容错？
• 系统的正常工作时间需求为何？
• 描述系统架构符合或不符合标准的地方。
• 描述运用在项目中的项目规划和分析方法。

• 处理器/服务器/客户端方面
• 描述客户/服务器应用架构。
• 通过标注图示来阐述执行应用功能的地方。
• 客户端方面
• 除了展示之外用户设备是否还具有其他功能？
• 描绘数据和流程所提供的帮助功能。
• 描述“从屏到屏”的导航技术。
• 描述用户如何在此应用与其他应用之间进行导航。
• 如何从用户设备上对此应用以及其他应用进行启动？
• 是否具有应用之间的数据和流程共享能力？如果是，描绘所共享的内容，以及采用何种技术来实现共享。
• 描述传输到客户端上的数据量。
• 对于支持应用的本地缓存数据的额外需求是什么？
• 对于支持应用的本地软件存储/内存的额外需求是什么？
• 是否存在由其他应用需求或会对用户产生影响的情况而导致的软硬件冲突或容量限制？
• 描述当前应用与其他现存应用之间展示层的感观效果的对比情况。
• 描述客户端在多大程度上支持异步和/或同步通信。
• 描述系统的展示层是如何与其他计算或数据传输层相分离的。
• 应用服务器方面
• 展示层和应用层是否可以运行在不同的处理器之上？
• 应用层和数据访问层是否可以运行在不同的处理器之上？
• 是否此应用可以被放置到一个应用服务器之上，并独立于其他所有应用？如不可以，则需要解释这些应用之间的依赖关系。
• 是否可以比较容易地添加额外的平行应用服务器？如果可以，负载平衡机制为何？
• 是否应用的资源需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？
• 数据服务器方面
• 是否存在其他应用必须与当前应用共享数据服务器？如果是，则需要对这些应用进行明确，并描述其数据和数据访问需求。
• 是否应用的资源需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？
• 商用现成品（COTS）方面
• 厂商是否稳定？
• 当厂商消亡时企业是否会收到产品源代码？
• 是否软件按照企业的用途而进行了配置？
• 是否存在特有的架构和设计方面的数据或流程，从而阻碍了针对软件的使用？
• 是否此软件在当前是可得的？
• 是否厂商使用或阐明的规模/可用性/服务水平与企业的需求相类似？
• 描述厂商过往的财务和市场份额历史。

4.4.8 系统工程/方法与工具问题清单

• 是否具有对当前业务操作方法的评定指标？
• 系统拥有者是否已经创建了用于指导当前项目的评估标准？如果有，则对如何使用这些评估标准进行描述。
• 是否对于现存架构的研究已经完成，从而使得当前的工作成果能够得以被充分利用？描述在这一研究中所使用的发现和认识方法。是否现存的这些架构需要被整合？如果是，解释将会采用的方法。
• 描述将会应用到项目中的方法：

• 用于定义业务战略的方法。
• 用于定义需要改善的领域的方法。
• 用于定义基线和目标业务流程的方法。
• 用于定义过渡流程的方法。
• 用于管理项目的方法。
• 用于团队沟通的方法。
• 用于知识管理、变更管理和配置管理的方法。
• 用于软件开发的方法。
• 用于引用标准和方向说明的方法。
• 用于交付物的质量保证的方法。
• 用于设计审查和交付验收的方法。
• 用于达成指标的方法。

• 是否各个方法已被记录，并被分发给了每个团队成员？
• 团队成员在多大程度上熟悉这些方法？
• 采用何种流程来确保方法执行的符合性？
• 描绘当前所采用的用于支持方法使用的基础设施。
• 如何提供咨询和故障排除？
• 如何协调安排培训？
• 如何合并和关联各种变更和改进？
• 如何获取经验教训，并对其进行沟通？
• 关于项目所采用的工具为何？（指定版本和平台）。团队成员对这些工具的熟悉度为何？
• 描绘当前所采用的用于支持此工具使用的基础设施。
• 如何提供咨询和故障排除？
• 如何协调安排培训？
• 如何合并和关联各种变更和改进？
• 如何获取经验教训，并对其进行沟通？
• 描述项目如何促进对其交付物及所交付内容的重用。
• 在项目实现后此架构设计是否还会存续？描述用来将变更合并入此架构设计的方法。
• 当前流程是否被定义？
• 是否各种问题已经被记录和评定，并与当前流程关联起来？如果没有，那又如何得知已经出现问题的地方正在被修正？
• 是否现存或规划的流程改善活动已被明确，并与当前流程关联起来？如果没有，那又如何知道此活动与其他工作说明书中的内容不会发生冲突或相互冗余？
• 当前是否存在各种评估指标？当前是否存在预测指标？如果没有，那又如何得知获得了改善？
• 采用何种流程来收集、评估和汇报各种指标？
• 新的设计对于现存业务流程、组织结构和信息系统有什么样的影响？是否这些影响已经被记录到文档之中，并与其他干系人进行共享？

4.5 架构合规性审查实践导则

4.5.1 裁剪和定制问题清单导则

• 关注于：

• 高风险区域。
• 预期的（突发的）差异。

• 对于清单中的每条问题，需要理解：
• 问题本身的含义。
• 问题背后的原则。
• 在回应中需要寻找什么样的内容。
• 寻求领域专家的意见。
• 根据自身需要对清单中的问题进行修补。
• 时刻牢记需要架构委员会的反馈。

4.5.2 架构合规性审查执行导则

• 理解审查的目标，并始终保持在正确的轨道之上对提出的问题提供适合的交付物。例如，人们通常希望了解正在架构的系统的对错之处，而不是希望了解诸如所采用的开发方法是否正确、管理组织结构是否合理等这些方面，因而在审查中就会经常偏离主题。
• 随着审查讨论的进行，其他一些需要被解决的问题将会逐渐显现，而且这些问题还常常会超出当前审查的范围。在这种情况下，我们需要在此次审查会后对其进行处理，并依照这些问题的重要性来制定一份用于解决这些问题的计划。
• 保持科学的态度。与其说“我们期望看到大型数据库放置在ABC之上而不放在XYZ”，我们更应该说“XYZ数据库环境之下的停机时间远远超过在ABC数据库环境之中的状况。因此我们不推荐将M和N系统放置到XYZ环境中”。
• 询问开放性问题。
• 在审查的征询过程中经常会存在隐藏的日程或有争议的问题，而这些内容在前期是无法预知的，因而采用一个非个性化的方法来进行讨论将会弥合这些差距而不是加剧他们。
• 尊重面谈的对象。他们可能不会采用合适的方法来构建系统，但是他们可能在其所处的环境中已经尽了最大的努力。
• 在练习中增长经验。
• 审查应该包括针对架构的详细评估活动，并确保其结果被存储到企业连续体之中。