TOGAF架构能力框架之架构委员会和架构合规性

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