企业架构研究总结（39）——TOGAF架构能力框架之架构委员会和架构合规性

3. 架构委员会

      正如前面所说，一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一。架构委员会应该可以表明全部主要干系人的需求，而且一般还须要对整个架构的审查及维护活动负有高级行政职责。一般来说，架构委员会须要对以下目标的达成进行负责：

• 子架构之间的一致性。
• 肯定可重用组件。
• 保证企业架构的灵活性：
• 知足不断变化的业务需求。
• 尽量的利用不断出现的新技术。
• 严格确保架构合规性。
• 改善组织中架构规程的成熟度水平。
• 确保采用以架构为基础的开发规程。
• 为全部关于架构变动的决策提供基础。
• 为超出范围的决策提供升级的能力。

      若是从执行的角度来看，架构委员会还须要承担以下责任：

• 有关架构合同的监督和控制的全部方面。
• 按期举行会议。
• 确保针对架构进行有效而且一致地管理和实现。
• 解析不清楚的地方，并对各类问题以及已经升级了的冲突进行解决。
• 提供各类建议、指导以及信息。
• 确保各类架构的合规性，并在确保与技术战略及目标一致的基础上授予豁免。
• 当类似的豁免被申请并被经过时，架构委员会须要考虑进行策略变动。
• 确保全部与架构合同的实现相关的信息在可控的条件下被发布，并可被通过受权的团体所得到。
• 对汇报的服务水平、成本节约等方面进行验证。

      若是从治理的角度来看，架构委员会还须要承担以下责任：

• 产生各类可用的治理材料和活动。
• 经过共识和被受权的发布来为架构的正式接受和批准提供一种机制。
• 为确保架构的有效实现而提供一个基本控制机制。
• 在架构的实现、包含在企业架构中的架构战略和目标，以及业务的战略目标之间创建关联，并对其进行维护。
• 为了经过豁免或策略更新来进行调整，架构委员会须要明确架构与计划开展的活动之间的差别。

3.1 架构委员会的创建

      一个架构委员会的创建每每受以下事件的触发：

• 新CIO的任命。
• 兼并或收购。
• 考虑采用一个新的计算形式。
• 认识到IT与业务的契合度不好。
• 渴望经过技术来达成竞争优点。
• 一个企业架构方案的建立。
• 重大的业务变动或业务的快速发展。
• 须要复杂且跨越诸多功能的解决方案。

      在不少公司中，最初的领导级架构赞助者一般都是CIO，然而为了在企业中得到广阔的支持，一个赞助组织的影响力每每超过某个我的，这样一个赞助组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来为战略架构及其子架构的审查和维护进行负责。虽然架构委员会是企业中架构的赞助者，企业架构委员会本身自己也须要得到企业高层的赞助和支持，而且这一支持须要贯彻整个规划过程，延伸到针对架构项目的维护之中。

      架构委员会的常驻人员规模不宜过大，按照TOGAF的建议，一个架构委员会的常驻人员规模应包含四至五人，或不超过十人。为了使架构委员会随着事件的推移而一直保持合理的规模，并同时确保其在企业范围内的表明性，架构委员会的成员须要采用轮换制，从而给予各个高级经理决策权和相关责任。除此以外，因为现实中的各类缘由这一轮换机制还有其存在的必要性，例如当有些架构委员会成员受时间所限而不能长期承担其职责时。虽然采用了轮换制，但为了确保架构委员会的决策不会变化无常，企业须要主动的采用某种机制来确保其核心理念的稳定，例如为成员设置任期，并将不一样成员的离退时间交错开来。

3.2 架构委员会的运行

      架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所进行的架构委员会会议，而且这些日程安排须要具备明确的目标、所涵盖的内容和通过定义的行为。架构委员会会议须要为以下几个方面提供指导：

• 对高质量的治理材料和活动的产生进行支持。
• 经过共识和被受权的发布来为架构的正式接受提供一个机制。
• 为确保有效的架构实现提供一个基本控制机制。
• 在架构的实现、包含在企业架构中的架构战略和目标以及业务的战略目标之间创建关联，并对其进行维护。
• 为经过豁免或策略更新来与合同进行从新校准而对合同和规划活动之间的差别进行明确。

      每一个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们须要在开会前对这些内容进行熟悉，而且被分配进行某项活动的与会人员还须要报告其执行进度。此外，每一个与会人员还必须确认其是否参加架构委员会会议。

      因而可知，会议的日程描述是有关整个会议内容的核心，TOGAF对于其内容项目作了以下建议：

• 前期会议纪要：之前的架构委员会会议的详细纪要。
• 变动请求：此条目之下的内容一般包含了针对架构、原则等内容进行修订的变动请求，此外也能够包含对于架构合同的业务控制（例如，确保针对某一付费号码的语音流量（例如天气预报）被禁止，以及对于某一特定网站进行访问的数据流量须要被控制）。任何一个变动请求的设置须要在制定者的受权范围以内，并采用在架构合同中已经定义好的参数。
• 豁免：豁免被用来做为一个对现存架构、合同和原则等方面内容进行更改的申请。豁免只会在必定的时间区间中以及定义明确的在整个豁免期间须要被贯彻的服务和运营条件下被承认。
• 合规性评估：合规性的评估是针对服务水平协议、运营水平协议、成本目标等方面而进行的。根据在架构治理框架中定义的条件标准，经过审查后，这些评估结果或者被接受亦或者被拒绝，而且架构合规性评估报告还应包含所描述的各个细节。
• 争议解决：通过架构合规性审查和豁免过程而依然未被解决的争议须要在这里被明确，从而为下一步的行动提供目标，而且这些内容须要被记录到架构合规性评估和豁免文档之中。
• 架构战略和方向文档：这里所描述的内容仅被全局架构委员会所制定，它包含了架构的战略、方向及其优先级顺序。
• 行动分配：这是一个关于前期架构委员会会议所分配行动状况的报告。在此报告中，一个行动跟踪记录被用来记录和保持全部在架构委员会会议中被分配的行动的状态，其内容至少应该包含以下几个方面：
• 参考材料
• 优先级
• 行动概述
• 行动所属者
• 行动详细描述
• 开始日
• 到期日
• 状态
• 类型
• 决议经过之日
• 合同文档管理：这是为架构文档的后续发布而对其进行的有关更新和改变的正式承认。
• 其余事项（AOB：Any Other Business）：关于上述内容所没有覆盖的问题的描述。这些内容也许不会被描述在会议日程之中，但应该在会议开始时被提出。
• 会议安排：全部会议的时间和内容安排应被详细描述，并公之于众。

4. 架构合规性

      针对架构合规性的审查是架构治理战略的核心环节，也是决定其可否成功的重要因素。架构合规性审查是针对各个具体项目与已经创建的架构标准、精神以及业务目标的相符合状况所进行的审议，而一个关于这些审议的正规流程正是企业的架构合规性策略的核心内容。经过架构合规性审查，企业能够达成以下几点（或部分）目标：

• 首先且最重要的目标是企业得以尽早在项目架构中发现错误，从而减小在整个生命周期的后期进行更改的风险和成本，而这也意味着总体的项目时间得以缩减，而且各项业务也可以尽早地得到架构所带来的底线收益（bottom-line benefit）。
• 确保将各类最佳实践应用到架构工做当中。
• 提供一份关于架构与强制性企业标准的符合度的概略。
• 明确标准自己须要进行修改的地方。
• 明确可以做为企业基础设施的组成部分，却在当前只为特定应用提供支持的各个服务。
• 将关于团队合做、资源共享以及其余可以跨越多个架构团队的协同增效方面的战略进行文档化。
• 充分利用技术所带来的先进性。
• 对项目的技术准备状态进行沟通。
• 肯定采购活动的关键标准。
• 明确重大的架构性差距，并就此与产品和服务供应商进行沟通。

      除了上面这些与质量保证有关的目标以外，架构合规性审查的进行还在特定状况下具备着倾向于以政治为导向的动机：

• 因为具备决策能力的人一般会参与到审查当中，并可以从对业务最优的角度进行决策指导，而不只仅注重技术的优劣，这使得架构合规性审查成为了一种在各类架构选择之间进行选择的好方法。
• 架构合规性审查的输出是为数很少的用来汇报给CIO，并辅助其决策制定的可测性交付物之一。
• 架构审查能够做为一条架构组织借以参与到开发项目之中的途径，不然各个开发项目的进行将会与企业的架构功能相脱节。
• 架构审查能够为企业业务团体给出快速且正面的支持：
• 企业架构以及架构合规性能够帮助确保各IT项目与业务目标的符合度。
• 架构师有时能够被视为深刻到技术基础设施之中而远离核心业务以外。
• 因为架构合规性审查倾向于将主要注意力放到一个系统的关键风险区域内，因此此审查常常能够为系统全部者凸显各类主要的风险。

4.1 架构合规性审查发生时点

      架构合规性审查并非一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，而且其具体的审查要点应包括：

• 架构开发自身的合规性，亦即对于架构开发方法的符合度。
• 架构实现的合规性，亦即各个实施项目与架构的符合度。

      针对架构项目审查的时点应包括：

• 项目启动
• 初步设计
• 主要设计变动时
• 其它特定时刻

4.2 架构合规性审查进行的情景归纳

      就架构合规性审查的进行、治理以及参与的人员来讲，TOGAF针对此审查的进行总结出了以下三种情景：

• 对于小规模的项目，这一审查流程能够只是由项目架构师或项目组长制定一系列问题（能够经过对后面将要列出的问题清单进行定制而得到），再将答案收录到某种形式的报告中，并对其进行管理。进行这样一个流程的需求一般要被包含在整个企业范围的IT治理策略中。
• 若是处于审查之下的项目并无一个全职的架构师的参与（例如，一个应用级的项目），那么就须要借助于企业中具备架构功能的组织的专业性架构能力了。这种状况下，企业架构功能组织将负责对这一审查进行组织、领导和执行，并保证各业务领域专家的参与。须要注意的是，这样的审查并非要取代架构师对于项目的参与，而是对架构师参与的一个有效的补充。此外，在这种情景下也许还须要引入一套数据库系统，从而对在大型系统或系统组的分析中所产生的大量数据进行管理。
• 对于大多数状况来讲，尤为是对于大型项目来讲，组织中具备架构功能的组织可能已经深刻地参与到（或领导）处于合规性审查之下的开发项目之中。在这种状况下，这一审查应该由主架构师来进行协调。主架构师须要组织一个包含业务和技术领域专家的团队，并将合规性审查中各个问题的答案编织成某种形式的报告。合规性审查中各个问题的制定须要由各个业务和技术领域专家一块儿来执行。除了由主架构师领导以外，架构合规性审查也能够由架构委员会的表明或其余在全企业范围内具备类似能力的组织来领导。

      在上面这些情景中，架构合规性审查的进行都须要高级管理层的支持，并一般被做为企业架构治理策略的一个重要部分来加以强制。通常来说，企业的CIO或企业架构委员会将对全部主要项目进行强制性审查，并在以后造成年度审查的惯例。

4.3 架构合规性审查流程

4.3.1 流程

      TOGAF对于架构合规性审查的流程作了以下图所示的总结：

 

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环境中”。
• 询问开放性问题。
• 在审查的征询过程当中常常会存在隐藏的日程或有争议的问题，而这些内容在前期是没法预知的，于是采用一个非个性化的方法来进行讨论将会弥合这些差距而不是加重他们。
• 尊重面谈的对象。他们可能不会采用合适的方法来构建系统，可是他们可能在其所处的环境中已经尽了最大的努力。
• 在练习中增加经验。
• 审查应该包括针对架构的详细评估活动，并确保其结果被存储到企业连续体之中。