企业架构研究总结(39)-TOGAF架构能力框架之架构委员会和架构合规性

1、企业架构研究总结（企业架构研究总结（39）TOGAF 架构能力框架之架构委员会和架构合规性3. 合规性3. 架构委员会正如前面所说，一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一。架构委员会应该能够代表所有主要干系人的需求，并且通常还需要对整个架构的审查及维护活动负有高级行政职责。通常来讲，架构委员会需要对如下目标的达成进行负责：子架构之间的一致性。确定可重用组件。保证企业架构的灵活性：oo满足不断变化的业务需求。o尽可能的利用不断出现的新技术。严格确保架构合规性。改善组织中架构规程的成熟度水平。确保采用以架构为基础的开发规程。为所有关于架构变更的决策

2、提供基础。为超出范围的决策提供升级的能力。如果从执行的角度来看，架构委员会还需要承担如下责任：如果从执行的角度来看，架构委员会还需要承担如下责任：有关架构合同的监督和控制的所有方面。定期举行会议。确保针对架构进行有效并且一致地管理和实现。解析不清楚的地方，并对各种问题以及已经升级了的冲突进行解决。提供各种建议、指导以及信息。确保各种架构的合规性，并在确保与技术战略及目标一致的基础上授予豁免。当相似的豁免被申请并被通过时，架构委员会需要考虑进行策略变更。确保所有与架构合同的实现相关的信息在可控的条件下被发布，并可被经过授权的团体所获得。对汇报的服务水平、成本节约等方面进行验证。如果从治理的角度来

3、看，架构委员会还需要承担如下责任：产生各种可用的治理材料和活动。如果从治理的角度来看，架构委员会还需要承担如下责任：产生各种可用的治理材料和活动。通过共识和被授权的发布来为架构的正式接受和批准提供一种机制。为确保架构的有效实现而提供一个基本控制机制。在架构的实现、包含在企业架构中的架构战略和目标，以及业务的战略目标之间建立关联，并对其进行维护。为了通过豁免或策略更新来进行调整，架构委员会需要明确架构与计划开展的活动之间的差异。3.1 架构委员会的建立一个架构委员会的建立往往受如下事件的触发：CIO的任命。兼并或收购。考虑采用一个新的计算形式。IT与业务的契合度很差。渴望通过技术来达成竞争优势。

4、一个企业架构方案的创建。重大的业务变更或业务的快速发展。需要复杂且跨越诸多功能的解决方案。在很多公司中，最初的领导级架构赞助者通常都是 在很多公司中，最初的领导级架构赞助者通常都是 CIO，然而为了在企业中获得广阔的支持，一个赞助组织的影响力往往超过某个个人，这样一个赞助中获得广阔的支持，一个赞助组织的影响力往往超过某个个人，这样一个赞助组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来为战略架构及其子架构的审查和维护进行负责。虽然架构委员会是企业中架构为战略架构及其子架构的审查和维护进行负责。虽然架构委员会

5、是企业中架构的赞助者，企业架构委员会自己本身也需要获得企业高层的赞助和支持，并且的赞助者，企业架构委员会自己本身也需要获得企业高层的赞助和支持，并且这一支持需要贯彻整个规划过程，延伸到针对架构项目的维护之中。这一支持需要贯彻整个规划过程，延伸到针对架构项目的维护之中。TOGAF的建议，一个架构委员会的常驻人员规模应包含四至五人，或不超过十人。为了使架构委员会随着事件的推移而一直保持合理的规模，并同时确保其在企业范围内的代表性，架构委员会的成员需要采用轮换制，从而给予各个高级经理决策权和相关责任。除此之外，由于现实中的各种原因这一轮换机制还有其存在的必要性，例如当有些架构委员会成员受时间所限而不

6、能长期承担其职责时。虽然采用了轮换 制，但为了确保架构委员会的决策不会变化无常，企业需要主动的采用某种机制来确保其核心理念的稳定，例如为成员设置任期，并将不同成员的离退时间交错开来。3.2 架构委员会的运行架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所进行的架构委员会会议，并且这些日程安排需要具有明确的目标、所涵盖的内容和经过定义的行为。架构委员会会议需要为如下几个方面提供指导：对高质量的治理材料和活动的产生进行支持。通过共识和被授权的发布来为架构的正式接受提供一个机制。为确保有效的架构实现提供一个基本控制机制。

7、在架构的实现、包含在企业架构中的架构战略和目标以及业务的战略目标之间建立关联，并对其进行维护。为通过豁免或策略更新来与合同进行重新校准而对合同和规划活动之间的差异进行明确。每个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们需每个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们需要在开会前对这些内容进行熟悉，并且被分配进行某项活动的与会人员还需要要在开会前对这些内容进行熟悉，并且被分配进行某项活动的与会人员还需要报告其执行进度。此外，每个与会人员还必须确认其是否参加架构委员会会报告其执行进度。此外，每个与会人员还必须确认其是否参加架构委员会会议。议。由此可见，会议的日程描述

8、是有关整个会议内容的核心，TOGAF对于其内容项目做了如下建议：前期会议纪要：以前的架构委员会会议的详细纪要。变更请求：此条目之下的内容通常包含了针对架构、原则等内容进行修订的变更请求，此外也可以包含对于架构合同的业务控制（如，确保针对某一付费号码的语音流量（例如天气预报）以及对于某一特定网站进行访问的数据流量需要被控制）个变更请求的设置需要在制定者的授权范围之内，并采用在架构合同中已经定义好的参数。个豁免期间需要被贯彻的服务和运营条件下被认可。成本目标等方面而进行的。根据在架构治理框架中定义的条件标 构合规性评估报告还应包含所描述的各个细节。需要被记录到架构合规性评估和豁免文档之中。定，它包

9、含了架构的战略、方向及其优先级顺序。方面：oo参考材料o优先级o行动概述o行动所属者o行动详细描述o开始日o到期日oo状态o类型o决议通过之日合同文档管理：这是为架构文档的后续发布而对其进行的有关更新和改变的正式认可。和改变的正式认可。其他事项（AOB：Any Other Business）：关于上述内容所没有覆盖的问题的描述。这些内容也许不会被描述在会议日程之中，但应该在会议开始时被提出。会议安排：所有会议的时间和内容安排应被详细描述，并公之于众。4. 架构合规性4. 架构合规性针对架构合规性的审查是架构治理战略的核心环节，也是决定其能否成功的重要因素。架构合规性审查是针对各个具体项目与已经

10、建立的架构标准、精神以及业务目标的相符合情况所进行的审议，而一个关于这些审议的正规流程正是企业的架构合规性策略的核心内容。通过架构合规性审查，企业可以达成如下几点（或部分）目标：首先且最重要的目标是企业得以尽早在项目架构中发现错误，从而减少在整个生命周期的后期进行更改的风险和成本，而这也意味着整体的项目时间得以缩减，并且各项业务也能够尽早地获得架构所整体的项目时间得以缩减，并且各项业务也能够尽早地获得架构所带来的底线收益（带来的底线收益（bottom-line benefit）。确保将各种最佳实践应用到架构工作当中。提供一份关于架构与强制性企业标准的符合度的概略。明确标准本身需要进行修改的地方

11、。明确能够作为企业基础设施的组成部分，却在当前只为特定应用提供支持的各个服务。将关于团队合作、资源共享以及其他能够跨越多个架构团队的协同增效方面的战略进行文档化。充分利用技术所带来的先进性。对项目的技术准备状态进行沟通。确定采购活动的关键标准。明确重大的架构性差距，并就此与产品和服务供应商进行沟通。除了上面这些与质量保证有关的目标之外，架构合规性审查的进行还在特除了上面这些与质量保证有关的目标之外，架构合规性审查的进行还在特定情况下具有着倾向于以政治为导向的动机：定情况下具有着倾向于以政治为导向的动机：由于具有决策能力的人通常会参与到审查当中，并能够从对业务最优的角度进行决策指导，而不仅仅注重

12、技术的优劣，这使得架构合优的角度进行决策指导，而不仅仅注重技术的优劣，这使得架构合规性审查成为了一种在各种架构选择之间进行选择的好方法。规性审查成为了一种在各种架构选择之间进行选择的好方法。CIO，并辅助其决策制定的可测性交付物之一。架构审查可以作为一条架构组织借以参与到开发项目之中的途径，否则各个开发项目的进行将会与企业的架构功能相脱节。架构审查可以为企业业务团体给出快速且正面的支持：ooIT项目与业务目标的符合度。目标的符合度。o架构师有时可以被视为深入到技术基础设施之中而远离核心业务之外。oo由于架构合规性审查倾向于将主要注意力放到一个系统的关键风险区域内，所以此审查经常可以为系统所有者

13、凸显各种主要的风险。4.1 架构合规性审查发生时点架构合规性审查并不是一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，并且其具体的审查要点应包括：架构开发自身的合规性，亦即对于架构开发方法的符合度。4.1 架构合规性审查发生时点架构合规性审查并不是一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，并且其具体的审查要点应包括：架构开发自身的合规性，亦即对于架构开发方法的符合度。架构实现的合规性，亦即各个实施项目与架构的符合度。针对架构项目审查的时点应包括：项目启动初步设计主要设计变更时其它特定时刻4.2 架构合规性审查进行的情景概括就架构合规性审

14、查的进行、治理以及参与的人员来说，TOGAF针对此审查的进行总结出了如下三种情景：对于小规模的项目，这一审查流程可以只是由项目架构师或项目组长制定一系列问题（可以通过对后面将要列出的问题清单进行定制长制定一系列问题（可以通过对后面将要列出的问题清单进行定制而获得），再将答案收录到某种形式的报告中，并对其进行管理。而获得），再将答案收录到某种形式的报告中，并对其进行管理。进行这样一个流程的需求通常要被包含在整个企业范围的 进行这样一个流程的需求通常要被包含在整个企业范围的 IT 治理策略中。略中。如果处于审查之下的项目并没有一个全职的架构师的参与（例如，一个应用级的项目），那么就需要借助于企业中

15、具有架构功能的组织的专业性架构能力了。这种情况下，企业架构功能组织将负责对织的专业性架构能力了。这种情况下，企业架构功能组织将负责对这一审查进行组织、领导和执行，并保证各业务领域专家的参与。需要注意的是，这样的审查并不是要取代架构师对于项目的参与， 而是对架构师参与的一个有效的补充。此外，在这种情景下也许还需要引入一套数据库系统，从而对在大型系统或系统组的分析中所产生的大量数据进行管理。对于大多数情况来说，尤其是对于大型项目来说，组织中具有架构（或领导）处于合规性审查之下代表或其他在全企业范围内具有相似能力的组织来领导。在上面这些情景中，架构合规性审查的进行都需要高级管理层的支持，并在上面这些

16、情景中，架构合规性审查的进行都需要高级管理层的支持，并通常被作为企业架构治理策略的一个重要部分来加以强制。一般来讲，企业的通常被作为企业架构治理策略的一个重要部分来加以强制。一般来讲，企业的CIO CIO 或企业架构委员会将对所有主要项目进行强制性审查，并在之后形成年度审查的惯例。审查的惯例。4.3 架构合规性审查流程4.3.1 流程TOGAF对于架构合规性审查的流程做了如下图所示的总结：参与流程的各角色及职责角色职责备注架构委员会IT有业务目标进行支持赞助并监督架构活动项目组长为这个项目负责（或项目委员会）架构审查协调人管理整个架构的开发和审查流程更倾向于面向业务，而不是技术首席企业架构师确

17、保架构在技术上的连贯，并且是面向未来的一个 IT 架构专家架构师首席企业架构师的技术助理之一确保业务需求被清晰地描述和理客户解管理组织的一部分，该部分依赖于在架构中所描述的信息技术的成功实现和运用业务领域专家确保用于满足业务需求的流程是合理并能够被理解的了解业务领域的运作。可以通过客户来担当这一角色项目负责人确保架构师对于客户部门流程有着足够详细的理解，并能够为业务领域专家或架构师提供各种所需的输入能够为架构所要满足的业务需求提供输入的客户组织中的成员4.4 4.4 架构合规性审查问题参考列表架构合规性审查是针对各个项目与架构的符合度而进行的审议活动，而这架构合规性审查是针对各个项目与架构的符

18、合度而进行的审议活动，而这根据架构的各个方面提出了一系列备选问题，而负责问题向进行了阐述，从而使得相关人员可以按照各自情况编制出合适的问题）4.4.1 硬件和操作系统问题清单项目生命周期方法是什么？项目目前处在生命周期的哪个阶段？终端设备的硬件和操作系统进行评估的关键问题是什么？将要参与到大量和/或高频率数据传输中去的系统能力是什么？系统设计是如何影响或涉及到终端用户设备的？所进行的使用、数据存储和处理的数量及分布（地区性和全局性是什么？些？并且数据与项目的关联程度为何？统的选择是什么？是否关于硬件和操作系统的决策制定超出了项目的控制？oo项目对于那些决策的理由有什么样的认识？oo当系统设计成

19、型时，项目是如何影响那些决策的？是否选择了非标准化的内容？o是否选择了非标准化的内容？o不使用公司标准的关键业务和技术需求是什么？o是否被业务案例所支持？o在业务案例中的假设是否已被审查？用于评估硬件和操作系统的全生命周期成本的流程是什么？公司财务管理是如何被引入到生命周期成本评估中去的？是否进行了供应商的财务分析？是否对供应商提出了承诺？是否坚信需求仅被一个供应商所满足？4.4.2 4.4.2 软件服务和中间件问题清单描述错误条件是如何在应用组件之间被定义、产生和传播的。描述在各个应用模块中关于方法定义和排列的通用模式。描述在各个应用模块中关于方法参数定义和排列的通用模式。描述用来最小化服务

20、器和客户端之间调用次数的方法，这对于在进程间进行具有复杂数据结构的调用尤其重要。描述在主要系统组件之间进行传递的主要数据结构。描述在主要系统组件之间进行通信所采用的协议。描述在不同系统组件之间所使用的编组（marshaling）技术，并针对所使用的特定编组安排进行描述。描述系统在多大程度上设计有状态（stateful）和无状态（stateless）组件？针对有状态和无状态组件来描述如何以及何时进行状态保存。使用和销毁。描述系统依赖于线程或临界区代码的程度。文档。描述代码审查流程。描述用来测试系统组件的单元测试。描述包含在各种系统模块中的前置和后置条件测试。描述包含在系统中的断言测试。各个组件是

21、否具备了它需要支持的所有接口？亦或某些关于何种类（marshaling）方式来调用其它组件的假设是否被制定？处理。描述在不同平台上是否对数字和字符串的处理采用不同的方式。描述是否软件需要对浮点舍入误差进行检查。描述时间和数据是如何应对千年虫问题的。（reachability） 或一般鲁棒性（generalrobustness）来对系统进行测试的。描述系统服务软件的分层情况。描述主要系统组件之间的连接的一般数量。是否系统大量采用点对点方式进行联系，还是主要通过消息路由的方式？描述系统组件松耦合或紧耦合的程度。就共享库、通信协议支持、负载平衡、事务处理、系统监控、命名服务或其它基础服务来讲，系统对

22、于底层基础设施的需求是什么？描述系统和系统组件是如何通过设计来达成重构性的？描述相对于采用点对点的通信结构，系统或系统组件是如何依赖于通用消息基础设施的？4.4.3 应用问题清单4.4.3 应用问题清单基础设施应用o是否需要一些企业标准基础设施应用产品并没有提供的能力？例如：能力？例如：o团队协作方面：o应用共享o团队协作方面：o应用共享o视频会议o日程安排o电子邮件o工作流管理o出版/文字处理应用oHTMLooSGML XMLo可移植的文档格式o文档处理（专有格式）o桌面发布系统（Desktoppublishing）o电子表格应用o展示应用o电子表格应用o展示应用o业务展示o图片o动画o视频

23、o音响o基于计算机的培训系统（CBT：Computer-Based Trainning）oWeb浏览器o数据管理应用o数据库接口o文档管理o产品数据管理o数据仓库/集市oo项目管理应用o项目管理o项目管理o项目可见度（Programvisibility）管理o描述标准产品所不能满足的对于企业基础设施应用能力的业务需求。的业务需求。业务应用o业务应用o是否用于支持一条或多条业务线应用的标准产品提供了所需要的能力？例如：所需要的能力？例如：o业务采购应用：o销售和市场o工程应用o计算机辅助设计o业务采购应用：o销售和市场o工程应用o计算机辅助设计o计算机辅助工程o数学和统计分析o供应管理应用o供应

24、链管理o客户关系管理o生产应用o企业资源规划（ERP）应用o制造执行系统oo制造质量o制造工艺工程o机器和自适应控制o客户支持应用o航空物流支持oo客户支持应用o航空物流支持o维护工程o财务应用o人员应用o设施应用o信息系统应用o系统工程o软件工程oWeb开发工具o集成式开发环境o生命周期类别o功能类别o专业类别o计算机辅助生产o电子商务支持o业务流程工程oo统计质量控制oo描述标准产品所不能满足的对于业务应用能力的流程需求。求。应用集成方法应用集成方法o架构的目标集成点（业务流程/活动、应用、数据、计算环境）是什么？环境）是什么？o所采用的应用集成技术是什么（通用数据对象、标准数据定义（ST

25、EP、XML 等）、通用用户界面展示）？4.4.4 信息管理问题清单数据价值方面4.4.4 信息管理问题清单数据价值方面o用于对数据的管理和使用进行标准化的流程是什么？o用于支持数据录入和验证的业务流程是什么？数据的用处为何？o与数据的创建和修改相关的业务行为是什么？o与数据的删除相关的业务行为是什么？是否这些数据被认为是业务记录的一部分？o业务用户对于数据质量的需求是什么？o当前用于支持数据引用完整性和/或规范化的流程是什么？数据定义方面o所购买的应用的数据模型、数据定义、结构以及主机选项（项（hosting options）都是什么？oo用于定义和维护数据需求规则以及对信息系统中所有组件所

26、进行的设计是什么？o何种共享资源库被用来保存数据模型内容和数据的支持性信息？o用于设计数据库的物理数据模型定义是什么？o所选择的软件开发和数据管理工具是什么？o已明确的对如下事项进行负责的数据拥有者都有哪些？：o通用数据定义oo通用数据定义o计划外冗余的消除o稳定可靠性的提供o信息的及时性和准确性o防止数据被滥用和破坏安全/保护方面o为了防止数据被无意及未授权的更改、泄露和散布，对于数据实体及其属性的访问应该制定什么样的规则？于数据实体及其属性的访问应该制定什么样的规则？o用于保护数据免于被外界进行未授权访问的数据保护机制是什么？o采用何种机制来控制企业内部临时驻留性外部资源对于数据的访问？托

27、管、数据类型和共享方面程为何？这一逻辑数据源为贮存在不同平台上的物理数o程为何？这一逻辑数据源为贮存在不同平台上的物理数o用于将单一授权数据作为一个逻辑数据源进行管理的规据定义了更新规则。据定义了更新规则。o用于对复制数据进行管理的规程为何？这些复制数据来源于运行中的单一授权数据。o已经明确的用于储存高级或中级重要度的运行数据的层级数据服务器为何？oC类型运行数据的层级数据服务器为何？o已经明确的用于储存包含在一个数据仓库中的决策支持数据的层级数据服务器为何？o所实现的数据库管理系统为何？通用服务通用服务o标准化的分布式数据管理服务（例如，数据验证、一致性检查、数据编辑、加密以及事务管理）为何

28、？这些服性检查、数据编辑、加密以及事务管理）为何？这些服务存在于何处？务存在于何处？访问方法访问方法o对于标准文件、消息和数据管理的数据访问需求为何？o对于决策支持数据的访问需求为何？o数据存储库和应用逻辑位置为何？o采用何种查询语言？4.4.54.4.5 安全方面问题清单安全意识：oo是否已确保正在使用的公司安全策略和导则是最新的版本？本？o是否已经阅读了最新版本的公司安全策略和导则？o是否了解所有相关的计算安全合规性和风险接受流程？识别/认证：对于一个用户是如何被应用所识别，以及此应用是如何验证该用户确为其所声称那个人的过程流进行图形表述。对这一图验证该用户确为其所声称那个人的过程流进行图

29、形表述。对这一图形表述提供支持性文档，从而对用户界面和应用形表述提供支持性文档，从而对用户界面和应用/数据库服务器之间的交互流程进行解释。是否符合公司关于账户、密码等方面的策的交互流程进行解释。是否符合公司关于账户、密码等方面的策略？略？授权：提供一个流程来展示一个用户如何申请访问某个应用，从而指明了相关的安全控制以及责任的划分。这一流程应该包括：o申请是如何被适当的数据拥有者所批准？o申请是如何被适当的数据拥有者所批准？o用户是如何被归入到适当的访问级别分类设定档中的？o用户账号、密码和访问是如何建立的，并如何提供给用户的？o如何通知用户对于应用的使用责任？o如何变更密码？o应向谁请求帮助？

30、o其他。访问控制：记录用户的账户、密码和访问配置是如何被增加、更改、删除和记录的？这一文档还应该包括对这些流程进行负责的人改、删除和记录的？这一文档还应该包括对这些流程进行负责的人员。员。敏感信息保护：提供确定了需要额外保护的敏感数据的文档。明确对这些数据进行负责的数据拥有者，以及用来保护数据存储、传输、打印和分发的流程。这包括：o如何对密码文件或字段进行保护？o如何防止用户查看他人的敏感信息？o与外部团体之间是否具有着信息保护的协议？如果是，o如何对密码文件或字段进行保护？o如何防止用户查看他人的敏感信息？o与外部团体之间是否具有着信息保护的协议？如果是，具体责任和义务为何？审计跟踪和审计日

31、志：o明确并记录被多个用户或应用支持所需要的组账户。o明确并记录个人账户和/或具有超级用户权限的角色。o这些权限为何？o何人可以访问这些账户？o如何对这些账户的访问进行控制和跟踪，以及如何对其进行日志记录？o如何处理密码的变更和分发？o明确审计日志：o何人可以读取审计日志？o何人可以修改审计日志？o何人可以删除审计日志？o如何保护和存储审计日志？o用户账户在审计日志中是否记录不清？外部访问注意事项：oo是否应用只是内部使用？o如果不是内部使用，那么是否符合公司的外部访问需求？4.4.6 4.4.6 系统管理问题清单必须被分发出去的软件更新的频率为何？采用何种工具进行软件分发？是否在产品中允许使

32、用多个软件和/或数据版本？用户数据的备份频率以及期望的回复时间为何？如何对用户的账户进行创建和管理？系统授权的管理策略为何？需要采用何种通用系统管理工具？需要采用何种特定的服务管理工具？如何接受和发送服务调用？描述如何卸载系统。描述用于检查系统是否被正确安装的流程或工具。描述用于监督系统健康状况和性能的工具或仪器。描述用来确定系统被安装在何处的工具或流程。描述用于捕捉系统历史（特别是在一次意外发生之后）的审计日志的格式。描述系统将其错误消息发送给服务人员的能力。4.4.7 4.4.7 系统工程/整体架构问题清单一般性问题需要整合进来的其他应用和/或系统为何？描述集成度水平和战略。用户群的地理分

33、布为何？系统对于其他企业内外用户团体的战略重要性为何？们自有资产的用户提供系统服务？据？当前应用的平均寿命为何？技术的变化的设计。用户群的规模以及他们的期望性能水平为何？采用何种性能和压力测试技术？软件和数据组件的整体组织方式为何？整体的服务和系统配置为何？的？此系统需要何种专门的软硬件技术？重新部署的？的预期。对其变化的预期。行使用的用户数量。描述应用的通常行为、其主要组件以及主要的数据流。器。描述系统的业务缘由。择系统开发语言的理由。程。益？何？事务性的申请数量通常为多少？是否需要严格保障的数据传输或更新？系统是否容错？oo系统的正常工作时间需求为何？o描述系统架构符合或不符合标准的地方。

34、o描述运用在项目中的项目规划和分析方法。处理器/服务器处理器/服务器/客户端方面o描述客户/服务器应用架构。o通过标注图示来阐述执行应用功能的地方。客户端方面o除了展示之外用户设备是否还具有其他功能？o描绘数据和流程所提供的帮助功能。o描述“从屏到屏”的导航技术。o描述用户如何在此应用与其他应用之间进行导航。o如何从用户设备上对此应用以及其他应用进行启动？o是否具有应用之间的数据和流程共享能力？如果是，描绘所共享的内容，以及采用何种技术来实现共享。o描述传输到客户端上的数据量。o对于支持应用的本地缓存数据的额外需求是什么？o对于支持应用的本地软件存储/内存的额外需求是什么？o是否存在由其他应用

35、需求或会对用户产生影响的情况而导致的软硬件冲突或容量限制？o描述当前应用与其他现存应用之间展示层的感观效果的对比情况。oo描述客户端在多大程度上支持异步和/或同步通信。o描述系统的展示层是如何与其他计算或数据传输层相分离的。应用服务器方面o展示层和应用层是否可以运行在不同的处理器之上？应用服务器方面o展示层和应用层是否可以运行在不同的处理器之上？o应用层和数据访问层是否可以运行在不同的处理器之上？o是否此应用可以被放置到一个应用服务器之上，并独立于其他所有应用？如不可以，则需要解释这些应用之间的依赖关系。o是否可以比较容易地添加额外的平行应用服务器？如果可以，负载平衡机制为何？o是否应用的资源

36、需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？数据服务器方面o是否存在其他应用必须与当前应用共享数据服务器？如果是，则需要对这些应用进行明确，并描述其数据和数果是，则需要对这些应用进行明确，并描述其数据和数据访问需求。据访问需求。o是否应用的资源需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？商用现成品（COTS）方面oo厂商是否稳定？o当厂商消亡时企业是否会收到产品源代码？o是否软件按照企业的用途而进行了配置？o是否存在特有的架构和设计方面的数据或流程，从而阻碍了针对软件的使用？o是否此软件在当

37、前是可得的？o是否此软件在当前是可得的？o是否厂商使用或阐明的规模/可用性/服务水平与企业的需求相类似？需求相类似？oo描述厂商过往的财务和市场份额历史。4.4.8 系统工程4.4.8 系统工程/方法与工具问题清单是否具有对当前业务操作方法的评定指标？系统拥有者是否已经创建了用于指导当前项目的评估标准？如果有，则对如何使用这些评估标准进行描述。是否对于现存架构的研究已经完成，从而使得当前的工作成果能够得以被充分利用？描述在这一研究中所使用的发现和认识方法。是否现存的这些架构需要被整合？如果是，解释将会采用的方法。描述将会应用到项目中的方法：o用于定义业务战略的方法。o用于定义需要改善的领域的方法。o用于定义基线和目标业务流程的方法。o用于定义过渡流程的方法。oo用于管理项目的方法。o用于团队沟通的方法。o用于知识管理、变更管理和配置管理的方法。o用于软件开发的方法。o用于