信息技术服务 咨询设计 第2部分 规划设计方法指南

PAGE49FORMTEXT信息技术服务咨询设计FORMTEXT第2部分：规划设计指南目  次目次 I前言 II引言 III信息技术服务咨询设计第2部分：规划设计指南 11范围 12规范性引用文件 13术语 14体系结构 24.1参考模型 24.2组成要素 24.3生命周期 35内容框架 45.1业务架构 45.2IT战略 65.3总体信息架构规划 65.4应用系统架构规划 85.5IT基础设施架构规划 115.6IT管控模式设计 165.7实施规划 176技术要求 186.1步骤和技术 186.2能力要求 426.3工具建议 437评估 447.1对规划设计方法的评估 447.2对供方的规划设计咨询服务能力的评估 457.3对咨询服务效果的评估 46附录A（资料性附录） 48A.1概述 48A 49A 49参考文献 50——第1部分：咨询通用要求；——第2部分：通用标准和数据规范；——第3部分：知识库管理规范；——第4部分：规划设计方法指南；——第5部分：信息化工程监理规范。信息技术服务咨询设计第2部分：规划设计指南范围指南的目标使用对象：IT规划设计咨询服务供方、需方、第三方，以及对IT规划设计方法有兴趣的组织及个人指南希望达到的目的：帮助IT规划设计咨询服务供方、需方、第三方提升IT规划设计咨询服务质量，优化IT规划设计咨询服务成本，强化IT规划设计咨询服务效能，降低IT规划设计咨询服务风险；帮助对IT规划设计方法有兴趣的组织及个人：全面理解和掌握IT规划设计咨询服务的内容和标准化知识，以及实施IT规划设计咨询服务的方法，从而提升组织能力和个人技能规范性引用文件下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。术语注：可参考ISO/IECPDTR15026-1软件系统工程-系统和软件保证-第1部分：概念与词汇，以及ISO/IECFCD24765软件系统工程词汇咨询consulting按照需方的要求，通过一定的方法开展调研，提出解决疑难问题的建议和方案。3.2信息技术咨询informationtechnologyconsulting以信息技术为手段，提升组织绩效，实现业务战略和目标的专业建议。3.3咨询服务consultingservice咨询服务提供方与需方签订合同，负责对其所提出的业务和技术性课题提供建议或解决方案的智力服务。3.4（信息技术）咨询服务(informationtechnology)consultingservice咨询服务提供方在信息资源开发利用、工程建设、人员培训、管理体系建设、技术支撑等方面向需方提供的管理或技术咨询评估服务。3.5流程process整合资源，推动将输入转换为输出的相互关联或相互作用的有序活动。3.6管理诊断managementdiagnose识别需方业务和IT现状，明确管理问题和规划方向的过程。3.7规划设计programanddesign结合信息技术应用现状、发展趋势及应用需求提出长期战略和目标，并设计信息技术服务架构。3.8实施治理implementationgovernance将规划设计付诸实施的过程。3.9架构architecture描述系统构成要素及相互关系，指导信息系统设计和完善的原则。体系结构参考模型图4.1咨询设计参考模型图组成要素人与组织（引用《咨询通用要求》4.2之e人员）提供咨询服务的专业人员，包括)人员的管理、岗位、技能、知识等。流程（引用《咨询通用要求》4.2之d流程）提供系统建设咨询所需建立的服务流程，包括前期准备、项目启动、管理诊断、规划设计、实施治理等。内容框架咨询设计给需方提供的服务内容。咨询设计应包括以下内容。a)业务架构（业务战略、运营模式及业务流程、业务服务组件）b)IT战略c)应用架构（应用服务组件）d)数据架构e)技术平台架构（技术平台组件）f)实施计划g)IT组织与管理（IT治理）技术方法（引用《咨询通用要求》4.2之f方法）在提供咨询服务过程中运用的咨询架构和方法，包括咨询规划、架构设计、架构实施、咨询评价等。生命周期预备阶段组建项目团队，明确任务，编制工作计划；召开项目启动会，达成宣传、培训和统一认识的效果；并运用资料分析、内部访谈等方式对需方各职能及业务板块的经营管理现状进行深入调研。分析阶段在深入调研的基础上，对需方的战略、业务和IT现状进行综合分析，为下一步的规划奠定基础。a)战略理解：明晰需方的战略和文化，了解管理现状；b)业务分析：对核心业务流程进行分析；c) IT现状分析：对IT战略、组织、人员、基础设施和系统应用的现状进行分析。规划阶段根据战略理解、业务分析和IT现状分析的结果，完成IT战略规划、应用规划、数据规划、技术平台规划，以及IT组织与管理体系规划等。a) IT战略规划：规划IT战略目标和战略实施步骤，以指导后续IT规划的搭建；b)应用规划：规划应用系统功能，分析应用系统间的集成关系；c) 数据规划：制定编码与名称规范，规划数据的采集、处理、存储和管理；d)技术平台规划：规划软件支撑平台、硬件支撑平台和安全保障体系；e) IT组织与管理体系规划：通过IT治理模式、IT管理组织和流程的优化，并辅以IT管理制度，支撑IT战略的实现。实施计划制定系统实施总体规划，并分阶段分系统详细描述实施规划，并做出资源投入、风险/收益分析和系统选型建议。项目治理（引用《咨询通用要求》5.6实施治理）规范信息系统建设中供方提供的咨询内容，包括实施策略、技术路线、进度计划、工程造价、方案选型、服务评审等。a)进行关键点分析，确定实施策略；b)确保项目实施与需方已有技术融合；c)确保项目实施满足进度要求；d)确定工程概算，满足造价要求；e)创建、开发并监控进度计划的实施，提供必要的资源；f)提出方案实施反馈建议并进行服务合规性审查。内容框架业务架构战略理解供方对需方原景、使命、目标、发展战略的准确理解，是规划设计方向正确的基础。业务与流程分析1、供方对需方的业务构成、经营模式、管理模式、业务扩张计划等有准确理解，分析IT建设着力点，厘清对信息化要求与含义。2、供方应对需方的核心业务和管理模型对需方的IT需求展开分析。3、建议以价值链的方法识别核心管理流程，梳理与最佳实践进行对比，以识别关键业务的改进机会和IT需求。例：一个家电企业的价值链：利利润利润企业基础设施人员招聘、培训自动化系统的设计元件设计、产品设计总装线设计、检测程序、能源管理信息系统开发市场研究销售支持和技术文献服务手册和程序运输服务原材料、其它部件能源、耗材电力/电子部件计算机服务、运输服务中介机构服务物资供应、出差和津贴备用件、出差和津贴进货材料搬运进货质检、部件检查和交货部件装配总装调节和质检设备利用率订单处理货运广告促销销售队伍服务信誉备用件系统人力资源准备技术开发采购内部后勤生产经营外部后勤市场和销售服务IT现状评估与差距分析供方应对需方IT现状从四个方面进行评估并分析差距：1、组织流程IT组织功能定位IT组织管控模式IT人员构成及技能IT服务支持水平2、信息管理信息规范标准信息管理流程信息质量水平信息安全管理3、应用系统现有应用系统清单现有应用系统功能应用体系的整合度应用系统的回报率4、IT基础实施网络架构体系网络安全管理设备技术标准基础设施能力数据备份管理IT战略企业战略对信息化的总体要求。通过现状分析阶段，总结企业发展战略对信息化的要求。信息化愿景和使命描述企业信息化的愿意和使命。信息化建设目标根据企业战略周期，提出企业信息化建设的总体目标和具体目标。1）信息建设总体目标2）信息建设具体目标a) 组织与流程：描述信息化支持需方的运营管理与变革、信息管理效率、IT运营支持等方面的具体目标。b) 信息管理：对信息资源的认识，信息管理的保障机制，信息标准化的规范、制度与流程。c) 应用系统：关键管理领域的应用系统建设目标，系统间的集成协同目标，数据整合目标。d) 基础设施：IT技术标准和架构建设，关键基础设施的建设目标及管理流程，网络、数据中心、安全管理。信息化建设指导原则为支持需方业务发展战略，实现经营目标，有力推进信息化建设，保障信息化建设的贯彻落实，应确定信息化建设的基本原则，以在建设过程中统一遵循。如：“统一规划、分步实施、集中平台、统一管理”；“集中化、标准化、集成化、可扩展”。总体信息架构规划明确需方信息架构规划，是进行需方应用架构规划的基础，将提高需方总体信息管理水平。明确信息需求根据需方管控和业务运营职能的要求，识别业务运营、管理控制、决策分析所需的内外部信息。同时为业务运营、管理控制和决策分析提供信息目标指引。信息分析归类对所需的企业内外部信息资源从结构、管理属性进行归类，并分析不同类别信息之间的主要关系。同时为应用体系的规划，应用系统间集成方式提供指导。主要分类：A、决策与管理支持类：1） 战略绩效信息：宏观环境信息、战略绩效流程与制度、战略规划信息、行业信息、新业务信息、计划及预算信息、关键指标信息、运营监控信息、绩效考核信息等。2） 财务管理信息：政策与核算制度信息、财务管理流程、财务指标信息、固定资产管理信息、资金管理信息、预算管理信息、财务报表信息、核算与分析信息、税务信息等。3） 人力资源信息：人力资源规划信息、人力资源流程与制度、人力资源政策信息、员工基本信息、员工绩效考核信息、员工培训与发展信息、管理层人员信息、人才市场信息等。4） 安全管理信息：安全政策与制度、安全管理流程、安全管理监控信息、安全管理运行信息、安全风险信息等。5）内控与风险管理信息：内控流程与制度、审计流程与制度、 外部监管信息、重大决策文件、高层会议记录信息、内控风险指标体系、审计计划信息、审计报告信息、内控报告信息、风险预警信息、内控风险分析信息、风险处理信息等。6） IT管理信息：IT战略规划信息、IT管理与服务流程、IT资产管理信息、IT技术标准、IT信息标准、IT服务标准信息等。B、业务运营类：1） 客户服务信息：客户服务流程与规范、客户基础信息、客户服务过程信息、客户投诉信息、客户行为分析信息等；2）市场信息：流程与制度、需求信息、规划信息、公共关系信息等；3）采购信息4）外部后勤信息5）生产经营信息6）内部后勤信息信息架构规划A、管理支持信息架构1)描述核心管理信息之间相互支持和依赖关系2)描述核心管理信息之间的有效整合3)描述管理支持信息与业务运营信息之间的关系。4) 管理支持信息架构设计。应以战略绩效信息为核心，实现需方战略的有效传导，支持需方对各级组织的合理有效管理。B、业务运营信息架构1)描述业务运营信息之间相互支持和依赖关系2)描述业务运营信息之间的有效整合3)描述业务运营信息与管理支持信息之间的关系。4) 业务运营信息架构设计。应以关键管理对象信息为纽带，实现业务运营信息的集成管理，支持关键管理对象的全生命周期管理的实现，支持需方业务发展与战略实现。C、需方各层级组织对信息管控重点1) 决策层：实现需方关键管理职能管理信息纵向、横向贯通，提高信息传输效率和准确性，保证决策层管理意志的贯彻；整理、汇总、抽取运营数据，为决策层提供战略经营决策支持。2) 管理层：在需方统一信息架构和标准下，制定信息架构和标准，对内部运营与管理中的关键管理与业务运营信息进行控制、分析、反馈；按照决策层管理要求，提供准确及时的经营与管理信息。3) 操作层：根据统一的信息架构和标准要求，结合自身业务需求，为各类业务运营管理提供信息支持，提高业务运作效率，降低成本；按照管理要求，提供准确及时的经营与管理信息。信息标准和流程制定高层次的信息资源架构以及收集整理信息的主要内容，明确集团层面主要的信息标准规范，信息架构和主要流程的关系。同时，为信息集成标准建立，应用系统选择提供基础。A、统一制定信息标准和管理规范按照信息架构要求，对所有分类信息，统一制定信息标准和管理规范。如：《统一的关键业绩指标评估体系》、《统一组织结构信息管理标准》、《统一财务科目与编码标准》、《统一客户基本信息管理标准》等。B、信息管理标准制定的保障体系信息管理标准的制定，应通过组织和流程加以保障，以规范信息的生成、存储、共享。C、信息管理标准的内容1）数据编码标准化：建立主数据编码结构，为各类信息定义业务规则和编码规则。2）数据项名称标准化：建立数据项名称结构，并分配名称，保证所有系统能够共享。3）数据字典的建立：系统地管理企业数据编码、数据项名称、数据库位置。4）单据报表格式设计：依照信息的分类组成、数据编码、数据项目标准名称、业务规则和流程要求，定义单据内容和格式；根据信息收集和分析要求，定义报表格式。应用系统架构规划应用系统架构规划根据对需方的业务分析，并结合需方信息架构规划管理需求，规划需方的信息系统。并描绘需方整体应用系统架构图。示例1：企业总部示例2：产业集团应用系统部署方案应用系统部署主要回答应用系统在需方内部如何分布的问题。即采用集中式、分布式或多少套应用安装来满足未来的应用需求。1、应用部署方案应用部署方案是针对某一具体应用而言的，是指采用一套还是多套应用安装来满足需方的业务需求。每套应用安装拥有独立的数据库和应用模块，多套应用安装之间的业务应用范围不相互交叉根据需方的管控需要，应用系统的部署方案要从逻辑集中和物理集中两方面去论述和考虑。逻辑全集中：需方各层级应用系统整体上集中在一个数据库环境中。物理全集中：需方应用系统运行在一套计算机服务器上。系统通过多组织架构、工作流技术和安全规则等功能，支持需方实现在一套系统中数据的统一存储，同时组织内各成员单位各自进行业务处理、互不干扰。云计算模式：需方应用系统部署在一个或多个虚拟机上。部署可以分为完全集中、板块集中、区域集团等模式。2、部署方案比选的因素技术因素：方案在当前技术水平条件下是否可行功能性：功能上是否满足新奥集团管控和业务的需求，是否遵循了最佳实践业务流程：每个方案对业务流程完善的要求如何变革管理：每个方案对新奥集团整体组织结构和燃气控股组织结构的影响参考案例：参照当前类似规模企业的现状和行业发展趋势实施难度：实施的时间、风险、复杂性（信息规范及整合难度、维护难度：方案对长期维护的影响及系统的灵活性如何成本：包括硬件投资、系统实施、系统维护、系统开发、系统可扩展性3、针对规划的应用系统选择部署方案针对每一个应用系统，要从以下方面进行更详细的比较，以设计适合需方业务发展和管理需要的系统部署方案和分布模式：1）管理功能的实现数据完整性数据实时性信息检索查询报表统一性系统间数据交换与接口2）对组织和变革的支持业务支持：是否有利于组织推行管控标准化、流程模板，业务协作和信息交换。对组织和流程重组支持：每个方案对业务流程完善的要求如何组织各业务单元的灵活性的支持业内最佳实践与案例参考3）系统架构、实施、运维管理网络要求系统维护系统管理实施难度：实施的时间、风险、复杂性（信息规范及整合难度）4）总拥有成本硬件投资软件许可开发成本实施成本维护成本应用系统集成方案需方业务应用的规模和复杂性，决定着是否需要实现跨业务跨系统的整合和应用系统集成。1)应用系统的集成包括以下层面：流程整合信息服务整合交互服务整合应用连接数据集成2)应用系统集成的方法 系统点对点接口：网状结构。在应用系统不多时易于实现，但随着应用系统的增多，结构维护的难度将大幅提高。EAI方法：星形结构。SOA方法：总线结构。应用系统遵循相关行业标准：如《财经信息技术-企业资源计划数据接口标准》、《WebService协议》。3)应用系统集成的设计思想：构件化双耦合应用系统功能定义根据应用系统架构规划，确业主要业务模块。并对每一个业务模块进行功能定义。功能定义应包含以下内容：实施效益建设思路业务流程变革及工作习惯岗位设置及职责的变化其他考虑（如基础数据整理、历史数据迁移、系统切换等）就每一个业务模块，定义主要功能其他系统配合IT基础设施架构规划基础架构影响因素应用架构提出对技术架构的需求外部技术变革和创新行业技术特点基础架构的关键领域信息技术标准技术架构基础平台数据中心网络备分与灾难恢复信息安全设计原则高可靠性高可用性可扩展性原则安全性原则开放和标准的原则可管理性原则系统部署的网络成本控制原则基础平台规划1、 服务器集群2、 服务器虚拟化3、 集群存储架构4、 存储虚拟化5、 云计算数据中心规划1、标准数据中心建设是相对标准的工程，以下是部分我国数据中心建设标准：《电子计算机机房设计规范》（GB50174-93）《计算站场地技术要求》（GB2887-89）《计算站场地安全技术》（GB9361-88）《计算机机房用活动地板的技术要求》（GB6650-86）《电子计算机机房施工及验收规范》（SJ/T30003）2、选址与布局数据中心地点和位置直接影响其安全和可管理行，应满足未来3-5年的要求。选址需要考虑的因素包括：地势、楼层、建筑规格、配套设施、周边环境等。参考数据中心平面布局模型。3、建筑规格承重地面承重水平是数据中心建设的重要指标，根据GB2887-89的要求，数据中心地板应能承受高于500kg/m2的重量。通常使用的数据中心地板承重能力是800-1000kg/m2。如果未来有特殊的要求，数据中心的地板可以进行部分的加固，这是一种常用的做法。高度根据GB2887-89标准要求，数据中心的高度应达到2.5-3.2米。实际情况通常要高于这个标准。一些先进的数据中心采用4.5米的层高。地板绝缘和防静电足够的空间用于安置电力、数据线路和空调足够的承重能力墙和窗户低导热率抗鼠和虫害隔离噪音防火防尘4、配套设施供电安全和监控消防空调防雷网络规划网络结构与覆盖网络应用与管理灾备体系规划1、分析评估灾难分析：偶然事件可能性、安全措施有效性、弱点、资产价值、潜在损失等。业务风险分析：明确关键流程、运营中断的损失、阀值定义、可容忍的运营中断等。当前业务环境分析：关键流程的资源和资产链、当前恢复能力、差异分析。2、设计实施容灾策略制定：灾备级别定义，可接受的恢复时间，zhu步消除短中长期差异容灾方案设计：技术、组织、运营。容灾方案实施：功能性及非功能性的实现。3、管理维护业务连续性流程设计容灾恢复方案管理信息安全1、信息安全的策略是围绕保护、检测和响应的生命周期开展的。2、信息安全的保障：安全技术、工具，管理制度，人员组织。 3、业务安全的保障：管理制度、安全检查、权限分散、设置职权、账户管理、密码管理。 4、安全风险级别定义。IT管控模式设计IT组织设计1）IT组织在需方中的定位2）IT组织的功能a）规划规划与政策b）管理需求管理架构管理投资管理服务管理c）运营应用系统开发与部署应用系统运营维护数据中心运营网络运营支持服务3） IT治理：流程及实现 a)IT治理组织信息化领导委员会各层级IT领导小组IT专家组IT管控领域b) IT政策与规划IT服务管理IT架构管理业务需求管理IT投资管理4） 需方各层级IT组织的关系与分工 a）组织模式：分散式、共享式5） IT组织的绩效管理及KPIa） 利润中心：对中心的利润、产品利润、客户利润和运营流程负责。KPI：Profit。b）服务中心：为需方内部提供有效率服务，对服务中心成本负责。KPI：成本范围。 c）成本中心：对中心预算和支持高质量流程负责。KPI：预算达成率。6）IT组织的架构及职能a ）IT组织架构b） 岗位能力要求规划与架构管理规范岗位项目经理IT投资与行政基础设施运营维护业务需求管理技术专家应用系统建设c） IT组织人员编制IT核心流程设计1）一级流程IT规划与政策制定IT架构管理IT投资管理业务需求管理应用系统开发部署管理IT服务管理应用系统运维管理数据中心运营管理网络运营管理支持服务管理实施规划总体实施策略1） 项目规划：基于对需方的信息化现状及展望的分析，进行项目规划。一般分为五类：IT组织建设IT基础设计建设核心系统建设运营支持系统建设信息支持系统建设2）项目划分：规划每一个具体项目，提出建设目标，并对项目内容进行概述。 3）项目优先级确定：项目利益分析：对利益进行打分。项目所需资源与能力项目之间的依赖关系项目风险分析：对风险进行打分。项目风险收益矩阵：按照高收益风险比、中收益风险比、低收益风险比进行分类，收益风险比较高的，应优先考虑实施。还应考虑项目所需资源和项目之间的依赖关系。 4）信息化项目建设路径确定按照项目利益、风险缝隙，并考虑项目所需资源，以及项目之间的依赖关系，确定信息化建设路径。项目实施策略详细描述针对每一个项目，确定以要素：项目负责人建设目标项目描述实施策略风险控制试点与推广计划WBS分解：确定主要工作、工作量、工作计划。信息化资源投入分析对硬件、系统软件、应用软件的投入实施投入运维投入技术要求按生命周期划分（预备阶段、业务分析、数据规划、应用规划、技术平台规划、实施计划制定、项目治理。。。）不同阶段的步骤、具体可使用或可参考技术、对人员的能力要求、工具建议等步骤和技术现状分析与评估规划准备本阶段步骤如下：1、确定规划项目管理人员（建议具体管理人员由IT领导担任，同时邀请业务领导作为架构项目的最高管理人员，体现“一把手工程”）；2、 由规划项目具体管理人员，组建业务、应用、数据、技术架构组，确定其内部人员；3、根据需要，可选择外部单位的某领域架构师，协助某领域架构工作。本步骤输出物包括：《规划项目组织结构和人员列表》,可纳入《规划工作说明书》组织、方法和流程准备定义规划原则原则是指明和支持组织完成其任务或目标的一般性规则和指引，一旦确定后在较长一段时间内很少改动。根据不同的组织，可以在以下三个水平层次上确定原则：1、 企业原则这是一个企业进行决策的基础，以及指导组织如何完成其任务。企业层次的原则在政府及非营利性组织中最为常见，在商业组织中它作协调分散型组织决策的一种方式。企业原则是成功架构实施治理策略的关键因素。2、 信息技术原则信息技术原则为整个企业的所有信息技术资源与资产的开发和应用提供指引。信息技术原则的制定是为了使信息环境更加高效和低成本。3、 架构原则架构原则是IT原则中关于架构方面的一个子集。它体现的是嵌入在企业架构中的精神与意念，是跨企业的共识。架构原则可以被进一步细分为以下两个方面。——架构流程治理原则，关于企业架构的开发、维护和使用方面的原则。——架构实施治理原则，关于设计开发信息系统方面的首要原则及指南。这些原则形成一个层次结构，即IT原则是由企业层次的原则所决定的，而架构原则由这两个较高层次的原则（企业原则和IT原则）共同决定的。架构原则由总体IT原则及企业层次的原则所决定。选择这些原则的目的是为了确保IT战略与企业战略与愿景保持一致。架构原则的开发特别受到以下这些方面的影响：1、企业使命和计划：企业的使命、计划以及组织基础结构。2、 企业战略性措施：企业的特点——包括优势、弱点、机遇及威胁和其现在整个企业范围下的措施。（如流程改进和质量管理）3、 外部约束：市场因素（上市时间需求和客户期望等）和现存及潜在的法律法规。4、 现有系统与技术：企业已开发的信息资源，包括系统文档、设备详细目录、网络配置图、政策及程序。5、 计算机产业趋势：关于计算机及通信技术的使用、可用性和成本的预测，包括来源可靠性以及现在使用中的最佳实践。判定原则适当与否的五个标准：1、 易懂性：原则的根本的含义能快速被组织中的个体所掌握和理解。原则的目的是明确、毫不含糊的，以便将各种有意或无意的冲突减到最少。2、 健壮性：支持高质量的架构及计划的制定，确保政策与标准的确立。每一个原则都应被充分且精确地定义，以确保在复杂、有潜在争议的情况下（应用适当的原则）支持决策的制定。3、 完整性：完整定义涉及组织信息与技术管理的每一个潜在的重要原则。原则应该涉及可能遇到的所有情况。4、 一致性：一致性要求一个原则可以用其他原则宽松解释。一组原则的表述要做到均衡解释，以避免原则间的相互矛盾。原则说明中的每个词都需要仔细推敲，以确保其一致且灵活的解释。5、 稳定性：原则在一段时间内是稳定的，但也要能适应变化。可以建立一个修正的过程以满足原则确定后添加、删除和变更的需要。具体的架构原则，可根据企业的实际情况和项目的实际情况进行选择。本步骤的输出物包括：《规划原则目录》，可纳入《规划工作说明书》裁减规划方法在本步骤中，要确定规划方法中哪些内容需要裁剪，考虑是否需要：1、 技术裁剪：架构从事者应尽量地使用能够为整个企业普遍理解的技术。裁剪过程应产生一套经一致同意的技术，用于架构内容的描述。2、 流程裁剪：流程裁剪则能够取消组织中那些已经在其它地方执行过的任务，添加组织特定的任务（如特定的检查点）并调整规划流程使之对应于外部流程框架及对接点。需要处理的关键对接点包括：——与（项目和服务）组合管理流程的链接——与项目生命周期的链接——与运营移交流程的链接（包括配置管理、变更管理以及服务管理）3、 内容裁剪：对内容结构和分类方法的裁剪允许采用第三方的内容框架，并允许对框架进行定制以支持组织特定需求。对于较大型企业来说，架构往往比较复杂，他们的整个业务框架是由一些相互连结的单独的企业组合起来的，因此需要适配架构方法以适应这一点。在这种情况下，可以采用以下几种不同的规划和集成方法（也可以是多种方法的组合）：——自顶向下的规划和开发–将整个互连的元企业作为一个单个的实体。——开发“通用”或“参考”的架构，代表组织的典型企业而不是确切的某个企业，随后单个企业进行适配从而产生一个符合特定企业关注的架构“实例”。——复制–为某个企业开发一个特定的架构，作为一个概念验证来实施，然后将其作为一种“参考架构”以供其他企业模仿。本阶段步骤如下：1、确定大型企业架构的规划和集成方法；2、对内容框架进行裁剪；3、对流程步骤进行裁剪；4、对技术描述进行裁剪。本步骤的输出物包括：《规划流程说明》,可纳入《规划工作说明书》定义术语为规范企业架构的描述，并尽可能与业务人员达成一致的理解，参照附录中架构术语参考，制定本项目的架构术语。本步骤的输出物包括：《架构术语定义》,可纳入《规划工作说明书》选择规划工具成功的企业架构团队通常能够利用他们的架构成熟度等级、团队/组织能力、目标或焦点来协调他们的架构工具。如果企业内的不同组织处于不同的架构成熟度等级，拥有不同的目标或焦点（如企业架构、业务架构、技术架构），那么单一工具就很难去满足所有组织的需要。在解决企业架构师目前在这个方面所面临的问题时，附录提供了一组被提议的评价准则来选择各种架构工具以开发所需的各种架构模型和视图。本阶段输出物包括：架构工具的使用选择结论,可纳入《规划工作说明书》确定规划目标、范围和愿景确认利益相关者关注确认关键利益相关者以及他们的关注和目的。这个阶段旨在确认利益相关者关注、问题和文化因素，以设计如何表述与沟通方式。本阶段输出物包括：《利益相关者关注点分析矩阵》,可纳入《规划工作说明书》确认业务目标、业务驱动力确认组织的业务目标和战略驱动力，并获得公司管理层的认可。假如这些已经在企业范围内其他的地方被定义了，则确保现有的定义是最新的。本阶段输出物包括：《业务驱动及目标》定义规划范围定义当前架构和目标架构的边界，并且理解当前和目标是不需要在相同的细节等级上进行描述的。很多情况下，当前描述是在更高的抽象层级上进行的，这样做就有了更多的时间可以用来指明目标的细节。特别地，需要定义以下内容：企业涉及范围的广度要求的细节等级覆盖的特定的架构域（业务、数据、应用、技术）来自原有项目可供使用的资产：——企业范围内在以前的规划中创建的资产——行业中可用的其他资产（其他框架、系统模型、纵向产业模型等）本阶段输出物包括：《规划工作说明书》中的架构范围制定规划愿景基于利益相关者关注、业务能力需求、范围、约束与原则，创建一个当前和目标架构的高层视图。架构愿景需要覆盖已确认的项目范围那样的广度。本步骤从业务、信息系统与技术的角度，产生首个、最高层次的当前和目标环境定义。本阶段输出物包括：《架构愿景图》,可纳入《规划工作说明书》编制项目工作计划本阶段步骤将包括：1、评估资源需求及其以规定的时间尺度完成工作的能力。2、 为提出的开发估算资源需求、开发一个路线图和进度表，并把这些记录在架构工作声明中3、通过企业架构团队讨论，定义本次架构项目中的绩效度量标准4、 开发企业特定的架构沟通计划，表述企业架构师将在何时何地以何种方式与利益相关者间就企业架构开发成果的进展进行沟通。5、评审计划并与架构项目发起人达成一致6、获得架构项目发起人的签署同意并开始进行下一阶段本阶段输出物包括：《架构项目工作计划》,可纳入《规划工作说明书》业务分析业务分析的目的业务分析的目的是理解企业业务战略与管理问题，找出影响企业发展的关键问题，确保企业IT规划与企业战略和经营目标相符合，制订与企业业务战略高度匹配的IT战略，关键活动包括：了解该企业业务环境特别是行业环境、竞争对手，并鉴别可能的竞争者；审视该企业当前的业务战略，以及构成公司竞争地位所做的权衡和取舍；确定企业内部能力和关键业务流程；以业界最优秀的实例为标杆，评估企业当前的关键流程。评估当前IT资源与环境；分析IT技术发展趋势与相关行业先进实践；定义未来IT远景。以下是业务分析阶段工作的步骤描述。选取参考模型以及工具首先，根据业务驱动力、利益相关者以及利益相关者的关注点，从已知的架构框架或者原有架构项目中选取相关的业务参考模型。接着，确认出适于记录、建模和分析的工具和技术。根据所定的复杂程度等级的不同，这些工具可以仅仅是简单的Office文档与电子数据表，也可以包含较为复杂的建模工具与技术，如活动模型、业务流程模型、用例模型等等。确定总体分析流程可以综合运用以下一种或多种技术来分析业务： 经营环境分析：包括业态发展现状和趋势分析、政策/法规/社会/科技/等关键因素分析、标杆分析、企业内部分析等。 结构化分析：确认架构范围里的关键业务功能，然后将这些功能映射到业务中的组织单元。用例分析：施动者和组织之间的业务层面的功能分解，可以确认一项功能中的施动者，并能够分解为支持/交付此功能能力的服务。 流程建模：流程建模过程中的功能或业务服务的分解可以确认出此流程中的元素，并能够确认较低层的业务服务或功能。流程优化：运用价值链模版解析客户经营特点和关键问题，通过流程优化找到客户关键问题并给出解决问题的途径，对组织、流程、信息化实现提出建设性意见。 流程保障：分析组织结构/职能/考核方式/跨部门组织协作的瓶颈，找出管理制度和考核方式对制度的影响和改进方向。业务分解所需的等级和严格化因不同的企业而异，对于同一企业内部也是如此。因此，架构师应该综合考虑企业的目标、目的、范围以及企业架构产出的目的，以此来决定分解的等级。确认所需的目录此类目录包含了业务核心元素的清单，其本质是一种分层结构，记录了元素的分解以及相关元素之间的分解。目录构成了开发矩阵与视图的原始素材，同时它还充当一项关键资源，用于组合管理业务和IT能力。在业务架构中，应该考虑开发以下目录：组织/施动者目录驱动力/目录/目的目录角色目录业务服务/功能目录位置目录流程/事件/控制/产品目录契约/测度目录确认所需的矩阵矩阵能够展示相关模型实体之间的核心联系。矩阵构成了视图开发的原始素材，同时，它还是一项关键资源，用以进行影响评估并作为差距分析的一部分。在一项业务架构中，应该考虑开发以下矩阵：业务交互矩阵（展示了组织和施动者之间的依赖关系与信息交换）施动者/角色矩阵（展示了每个施动者所担任的角色）确认所需的图图能够根据利益相关者的需求，从一系列不同的角度展现业务架构信息。在业务架构开发中应该考虑以下的图：业务轨迹图（结合应用架构）业务服务/信息图功能分解图目标/目的/服务图用例图组织分解图流程图事件图确认业务架构制品的开发顺序确认需要收集的需求类型当业务架构目录、矩阵与图都已开发完成时，为完成架构建模，我们还需要使以业务为中心的需求正式化，这些需求将用于实现目标架构。它们可以与业务相关，或提供对数据架构、应用架构以及技术架构的需求输入。在本步骤中，架构师应该确认出必须在架构实现中达成的需求类型，包括：功能需求非功能需求假定约束领域特定的业务架构原则政策标准指引规格在很多情况下，架构定义不会给出关于解决方案的详细需求或全面需求（因为这些可以通过使用一般的需求管理方法得到更好的解决）。本阶段输出物包括：《业务架构项目工作策略》,可纳入《业务架构详稿》描述当前业务架构开发现有业务架构的当前描述。本阶段输出物包括：《当前业务架构说明》,可纳入《业务架构详稿》描述目标业务架构开发业务架构的目标描述，使之能够充分地支持架构愿景。目标架构所定义的范围与细节等级是由目标架构愿景的业务元素的相关性以及架构描述是否存在的情况决定的。如果范围允许的话，可以从以前架构项目中取出并确认相关的业务架构元素，用于开发业务架构的目标描述。本阶段输出物包括：《目标业务架构说明》,可纳入《业务架构详稿》执行差距分析确认当前与目标之间的差距：--创建差距矩阵--确认延用下来的元素，将其分为改变的与未改变的两类--确认移除的元素--确认新的元素--确认差距并将其分为需要开发与需要采购两类本阶段输出物包括：《业务架构差距分析》,可纳入《业务架构详稿》分析可能产生的影响业务架构一旦得到确定，架构团队就应该着手去理解这一架构所产生的广泛影响或可能的结果。具体来说，在这一阶段，就应该检查架构景观中其他架构制品，确认出：本业务架构对预先存在的架构产生了影响吗？最近是否进行过影响业务架构的变更呢？组织的其他领域有没有可能综合利用这一业务架构的工作成果呢？本业务架构会影响其他的项目（包括那些规划中的项目以及当前进展中的项目）吗？本业务架构会被其他项目（包括那些规划中的项目以及当前进展中的项目）影响吗？本阶段输出物包括：《业务架构影响分析》,可纳入《业务架构详稿》进行正式的利益相关者评审对照业务架构，检查架构项目与架构工作声明的动机，查看它是否符合支持其他架构域中后续工作的目的。最终确定业务架构本阶段步骤如下：1、为每一个元素选定标准，尽量地重用参考模型中的元素2、用文档的形式充分地记录每一个元素的信息3、 对照业务目标，对总体架构进行最终的复核；以文档的形式记录架构文档中元素决策的全部依据4、编写最终的需求跟踪报告5、最终确定所有的业务架构工作产品本阶段输出物包括：《业务架构详稿》评估当前IT资源与环境本阶段的目的是清查和评估现有的信息技术能力(应用、系统、网络、技能、流程)对业务的支撑情况，分析并找出差距。本阶段的输出物包括：《IT资源与环境评估报告》分析IT技术发展趋势与相关行业先进实践本阶段的目的是分析未来IT技术的发展趋势，研究行业最佳实践，吸收成功经验，为制定前瞻性IT战略提供的信息支撑。本阶段的输出物包括：《IT技术发展趋势与行业最佳实践研究报告》定义未来IT远景通过对企业业务战略和核心业务流程的理解和分析，企业IT资源与环境的评估及IT发展趋势的研究，制定符合企业业务发展战略的IT远景规划。本阶段的输出物包括：《企业IT远景规划报告》业务分析阶段输出汇总1、业务架构定义文档，包括有：--当前业务架构，版本1.0（详细的）--目标业务架构，版本1.0（详细的），包括：组织结构–确认业务位置并建立其与组织单位的联系业务目标和目的–企业的以及每个组织单位的 业务功能–一个详细且递归的步骤，包含一系列连续的分解，将主要功能领域分解为子功能业务服务–企业和每个企业单元向其内部和外部的消费者提供的服务业务流程，包括测度标准和交付物业务施动者和角色业务数据描述组织和功能相互的关系–以矩阵的形式将业务功能与组织单元联系起来信息化建设风险及系统上线充分必要条件以及应对措施。2、架构需求规格草案，包括以下业务架构需求：--差距分析结果--更新的业务需求3、IT现状评估与战略报告整体规划与架构设计数据架构设计数据架构阶段的目的本阶段的目的是定义支持业务所需的主要的数据类型和数据源。需要特别注意的一点是，这项工作与数据库的设计无关。本阶段的目标是定义与企业相关的数据实体，而并非设计物理的或逻辑的存储系统。（但是，可能描述与现有文件和数据库的联系，并说明某些需要改进的重要领域。）数据架构的关键考虑事项数据管理当一个企业选择进行大范围的架构转换时，首先理解和解决数据管理问题是很重要的。一个结构化的综合数据管理方法能使数据得到有效地利用从而发挥其竞争优势。需要考虑的事项包括：清晰地定义哪些应用构件将起到企业主数据的记录系统或参考系统的作用需要所有应用构件，包括软件包共同采用的企业级标准清晰理解业务功能、流程和服务是如何利用数据实体的清晰理解企业数据实体是如何以及在什么地方被创建、存储、传输和报告的支持应用间信息交换需求所需的数据转换复杂度和级别支持与企业的客户和供应商进行数据整合的软件需求有哪些？（例如，数据迁移中ETL工具的运用，评价数据质量的数据分析工具等）数据迁移当需要替换一个现有的应用时，一项非常重要的工作就是将数据迁移到新的应用中。数据架构应该确认数据迁移需求，并提供关于转换、移除、净化级别的指示。这些级别都是以某种满足目标应用需求以及约束的格式表示数据所需。其目的就在于当将数据迁入目标应用时，目标应用获得是高质量的数据。另一关键的考虑事项为，确保建立一个企业范围的公共数据定义以支持转换。数据治理数据治理的考虑事项如下：结构：企业是否具有必要的组织结构以及标准实体，以管理数据实体的变更。 管理系统：企业应该有必要的管理系统以及数据相关的计划，以在数据实体整个生命周期中进行治理。人员：企业完成数据实体的变更所需的相关的技能以及角色。如果企业缺少这样的资源和技能，就应该考虑获取这样的关键技能或通过一个明确的学习计划，培训现有内部资源以满足需求。以下将分步描述数据架构的步骤。选择参考模型、观点和工具首先，应该评审和验证（必要时生成）一系列数据原则。这些原则通常会成为一套总体的架构原则的组成部分。然后，根据业务驱动力、利益相关者、利益相关者的关注点以及业务架构，选取相关的数据架构资源（参考模型、模式等）。进而，确认出适于记录、建模和分析的工具和技术。需要补充的是，根据所需复杂程度等级的不同，这些工具可以仅仅是简单的文档与电子数据表，也可以包含较为复杂的建模工具与技术，比如数据管理模型、数据模型等。数据建模技术的范例有：实体-关系图类图对象角色建模确定总体建模流程数据模型的范例包括：ARTS的零售业数据模型Energistics的石油技术工业数据模型确认所需的目录组织的数据清单被记录作为数据实体的目录。目录的本质上是一种分层架构，可以用来正确记录（capture）元模型实体的分解与其他相关模型实体的分解（例如，逻辑数据实体→物理数据实体）。在业务架构阶段中，需要创建业务服务/信息图，用以展示主要的业务服务所需要的关键数据实体。这是数据架构成功的先决条件。当数据需求统一到一个数据实体的目录时，就可以精化数据清单，实现语义一致性并消除差距和重叠。在一项数据架构中，应该考虑开发以下目录：数据实体/数据构件目录确认所需的矩阵矩阵展现了相关模型实体之间的核心关系。矩阵构成了开发图的原始素材，另外，它还是一项关键资源，用以进行影响评估。现阶段也要开始理解如何创建、维护、转换数据，以及如何将数据传递给其他应用或被其他应用所使用。记录下那些明显的差距，如从未被应用创建的实体或创建了但从未使用过的数据，以备之后的差距分析使用。合理化的数据清单能够用于更新和精化架构图。该图展示了数据是如何与架构其他方面联系在一起的。在一项数据架构中，应该考虑开发以下矩阵：数据实体/业务功能（展示哪些数据支持何种功能，何种功能拥有哪些数据）业务服务/信息（在业务架构阶段中开发）系统/数据（在应用架构和数据架构阶段中开发）确认所需的图图能够根据利益相关者的需求，从一系列不同的角度（视点）展现数据架构的信息。当完成数据实体的精化后，就可以产生展示实体与其属性之间关系的图。需要仔细评估建模的细节等级。一些物理系统数据模型的细节级别是非常详细的；而其他的数据模型仅有建模的核心实体。不是所有的数据模型都像应用软件一样被一直地修改与扩充以保持着最新的状态。在所提供的细节等级上取得一种平衡是很重要的（例如，重建现有的详细系统物理数据模式，或者展现高层的流程图与数据需求，突显这两个极端的视图）。在一项数据架构中，应该考虑开发以下的图：类图数据分布图数据生命周期图数据安全图数据迁移图类层次图确认数据架构制品的开发顺序确认需要收集的需求类型当数据架构目录、矩阵、图都已开发完成时，为完成架构建模，我们还需要使以数据为中心（data-focused）的需求正式化，这些需求将最终用于实现目标架构。在本步骤中，架构约定应该确定各种需求的类型，这些类型的需求都应该在架构实现中达成。需求的类型包括有：功能需求非功能需求假定约束领域特定数据架构原则政策标准指引规格说明书本阶段输出物包括：《数据架构工作策略》,可纳入《数据架构详稿》开发当前数据架构描述开发现有数据架构的当前描述。本阶段输出物包括：《当前数据架构说明》,可纳入《数据架构详稿》开发目标数据架构描述开发数据架构目标描述，使之能够充分地支持架构愿景和目标业务架构。目标架构描述所定义的范围与细节等级，是由实现目标架构的数据元素的相关性以及架构描述是否存在的情况决定的。开发目标数据架构描述的推荐流程如下：从现有的业务架构和应用架构素材中收集数据相关的模型通过建立数据与业务服务、业务功能、访问权限和应用软件的联系，更新与开发贯穿整个架构的矩阵通过检查创建数据、分发数据、迁移数据、确保数据安全、存储数据的方式，详细描述数据架构视图。本阶段输出物包括：《目标数据架构说明》,可纳入《数据架构详稿》执行差距分析确认当前与目标之间的差距：创建差距矩阵确认延用的数据实体，将其分为改变的与未改变的两类确认移除的数据实体确认新的数据实体确认差距并将其分为需要开发的与需要采购的两类分析对架构景观产生的影响当数据架构最终确定时，架构团队就应该着手去理解这一架构所产生的广泛影响或可能的结果。具体来说，在本阶段，就应该检查架构景观中其他架构制品，以确认：本数据架构对预先存在的架构产生了影响吗？最近是否进行过影响数据架构的变更呢？组织中其他领域有没有可能综合利用本数据架构的产品呢？本数据架构会影响其他项目吗（包括规划中的项目以及当前进展中的项目）？本数据架构会被其他项目所影响吗（包括规划中的项目以及当前进展中的项目）？本阶段输出物包括：《数据架构影响性分析》,可纳入《数据架构详稿》进行正式的利益相关者的评审对照提议的数据架构，检查架构项目与架构工作声明的动机。通过进行影响分析，确认出业务与应用架构（如业务实践）为适应数据架构变更而需要随之变更的领域（例如，对格式或流程的变更，对应用系统的变更或对数据库的变更。确认出应用架构（如果是此处生成的）为适应数据架构的变更而需要随之变更的领域（或确认对即将设计的应用架构的约束）。确认对即将设计的技术架构的约束，在需要时精化所提议的数据架构。最终确定数据架构1、为每一数据实体选定标准，尽量地重用那些来自参考模型的数据实体2、用文档的形式充分地记录每一数据实体的信息3、 对照业务目标，对总体架构进行最终的复核；以文档的形式记录架构文档中数据实体决策的全部依据4、编写最终的需求跟踪报告5、最终确定所有工作产品，如差距分析报告数据架构阶段输出汇总1、架构定义文档，包括：——当前数据架构，版本1.0——目标数据架构，版本1.0——业务数据模型——逻辑数据模型——数据管理流程模型——数据实体/业务功能矩阵2、架构需求规范草案，包括以下数据架构需求：——差距分析结果——数据互操作性需求——对即将设计的技术架构的约束——更新的业务需求（如果合适的话）——更新的应用需求（如果合适的话）3、充分必要条件评估及完善要求应用架构设计应用架构阶段的目的本阶段的目的是定义数据处理和业务支持中所需的应用系统的主要类型。需要特别注意的一点是，这项工作所关注的并不是应用系统的设计。其目标是定义与企业相关的应用系统类型，并定义这些应用所需完成的工作，从而管理数据并向企业里的人员和计算机施动者提供信息。以下是应用架构阶段工作的步骤描述。选取参考模型以及工具首先，应该评审和验证（或者必要时生成）一系列应用原则。这些原则通常会组成总体架构原则的一部分。然后，根据业务驱动力、利益相关者以及利益相关者的关注点，从已知的架构框架或者原有架构项目中选取相关的应用架构资源（参考模型、模式，等等）。进而，确认出适于记录、建模和分析的工具和技术。值得一提的是，根据所需的复杂程度等级的不同，这些工具可以仅仅是简单的文档或电子数据表，也可以包含较为复杂的建模工具与技术。另外，可以考虑使用独立于平台的业务逻辑描述。例如，OMG的模型驱动架构（MDA）提供了一种为应用架构建模的方法，此方法使得基础平台和实现技术进行变更时，业务逻辑不会受到影响。确定总体建模流程应用模型的范例有：电信管理论坛（TMF）––所开发的与电信行业相关的详细应用模型对象管理群组（OMG）----拥有许多纵向的领域任务组，开发了与卫生保健、交通、金融等特定的纵向领域相关的软件模型。确认所需的目录在一项应用架构中，应该考虑开发以下目录：应用组合目录接口目录确认所需的矩阵在一项应用架构中，应该考虑开发以下矩阵：系统/组织矩阵角色/系统矩阵应用交互矩阵系统/功能矩阵确认所需的图在应用架构开发中应该考虑如下的图：应用通信图应用和用户位置图企业可管理性图流程/系统实现图应用迁移图软件分配图软件工程图确认应用架构制品的开发顺序确认需要收集的需求类型当应用架构目录、矩阵与图都开发完成之后，为完成架构建模，我们需要使以应用为中心的需求正式化，这些需求将用于实现目标架构。在本步骤中，架构师应该确认出必须在架构实现中达成的需求类型，包括：功能需求非功能需求假定约束领域特定的业务架构原则政策标准指引规格本阶段输出物包括：《应用架构项目工作策略》,可纳入《应用架构详稿》描述当前应用架构开发现有应用架构的当前描述。本阶段输出物包括：《当前应用架构说明》,可纳入《应用架构详稿》描述目标应用架构开发应用架构的目标描述，使之能够充分地支持架构愿景。目标架构所定义的范围与细节等级是由目标架构愿景的业务元素的相关性以及架构描述是否存在的情况决定的。如果范围允许的话，可以从以前架构项目中取出并确认相关的应用架构元素，用于开发应用架构的目标描述。开发目标应用架构的推荐流程如下： 了解关于所需的应用与应用构件的列表；根据当前应用组合，去理解需求有哪些，以及业务架构的范围是什么确认出逻辑应用和最适当的物理应用系统通过建立应用与业务服务、业务功能、数据、流程之间的联系，开发贯穿整个架构的矩阵 通过检查应用是如何运作的——如何记录集成、迁移、开发与运营的关注点，来详细说明一系列应用架构视图 分解所需的等级和严格化因不同的企业而异，对于同一企业内部也是如此。因此，架构师应该综合考虑企业的目标、目的、范围以及企业架构产出的目的，以此来决定分解的等级。对粒度等级的确定应该达到足以确认差距与候选工作包的范围的程度。本阶段输出物包括：《应用架构说明》,可纳入《应用架构详稿》执行差距分析确认当前与目标之间的差距：--创建差距矩阵--确认延用下来的元素，将其分为改变的与未改变的两类--确认移除的元素--确认新的元素--确认差距并将其分为需要开发与需要采购两类本阶段输出物包括：《应用架构差距分析》,可纳入《应用架构详稿》析可能产生的影响应用架构一旦得到确定，架构团队就应该着手去理解这一架构所产生的广泛影响或可能的结果。具体来说，在这一阶段，就应该检查架构景观中其他架构制品，确认出：本应用架构对预先存在的架构产生了影响吗？最近是否进行过影响应用架构的变更呢？组织的其他领域有没有可能综合利用这一应用架构的工作成果呢？本应用架构会影响其他的项目（包括那些规划中的项目以及当前进展中的项目）吗？本应用架构会被其他项目（包括那些规划中的项目以及当前进展中的项目）影响吗？本阶段输出物包括：《应用架构影响分析》,可纳入《应用架构详稿》进行正式的利益相关者评审对照应用架构，检查架构项目与架构工作声明的动机，查看它是否符合支持其他架构域中后续工作的目的。最终确定应用架构本阶段步骤如下：1、为每一个元素选定标准，尽量地重用参考模型中的元素2、用文档的形式充分地记录每一个元素的信息3、 对照业务目标，对总体架构进行最终的复核；以文档的形式记录架构文档中元素决策的全部依据4、编写最终的需求跟踪报告5、最终确定所有的应用架构工作产品本阶段输出物包括：《应用架构详稿》用架构阶段输出汇总1、应用架构定义文档，包括有：--当前应用架构，版本1.0（详细的）--目标应用架构，版本1.0（详细的），包括：--流程系统模型--位置系统模型--时间系统模型--人员系统模型2、架构需求规格草案，包括以下业务架构需求：--差距分析结果--应用的互操作性需求--对即将设计的技术架构的约束--更新的业务需求（如果合适的话）--更新的数据需求（如果合适的话）4、充分必要条件评估及完善要求技术架构设计技术架构的目的技术架构阶段的目的是，将应用架构阶段所定义的应用构件映射到一系列技术构件上去。这些技术构件包括软件构件和硬件构件，它们可以来自于市场或者在组织中装配到技术平台之上。由于技术架构定义的是架构解决方案的物理实现，因而它同具体实现与迁移规划有着紧密的联系。同时，技术架构还定义了技术组合的当前视图（例如，当前的视图）与目标视图，详细描述了通往目标架构的路线图，并在路线图中标识出关键的工作包。可以说，技术架构完善了整个架构的信息集合，因此它支持对特定迁移场景的成本评估。选取参考模型，视点以及工具首先，应该评审和验证一系列技术原则，这些原则通常会成为一套总体的架构原则的组成部分。。然后，根据业务驱动力、利益相关者以及利益相关者的关注点，从架构储藏库中选取相关的技术架构资源（参考模型、模式，等等）接着，选取相关的技术架构视点，使得架构师能够通过这些视点展现利益相关者所关注的问题是如何在技术架构中得以妥善解决的。进而，结合所选视点，确认出适于记录、建模和分析的工具和技术。需要补充的是，根据所需复杂程度等级的不同，这些工具可以仅仅是简单的文档与电子数据表，也可以包含较为复杂的建模工具与技术。确定总体建模流程首先，对于每一个视点，都应使用所选取的工具与方法，选择相应的模型以支持所需的特定视图。同时，必须确保这些模型覆盖了所有利益相关者的关注点。如果没有完全覆盖的话，就需要创建新的模型，或者是扩大现有的模型（见上文）来处理它们。开发技术架构的流程包含以下步骤：定义一套平台服务与逻辑技术构件（包括标准）的分类法确认技术部署的相关位置编写一份物理清单，详列所部署的技术，并将其抽象上升到分类法中。审查应用与业务对技术的需求判断这些技术是否能恰当地满足新的需求（例如，它是否能满足功能性需求与非功能性需求）精化分类法产品选取（包括独立的产品）确定所选技术的配置确定影响：影响的范围和成本能力规划安装/治理/迁移的影响在规划的早期阶段，某些围绕服务粒度与服务边界的决策已暗含了对技术构件与服务平台的要求。一般来说，受到这些决策影响的技术架构领域包括以下方面： 性能:服务的粒度会影响平台服务的需求。粗粒度的服务包含了数项功能性需求与可能不断变化的非功能性需求，因此，应该考虑到平台的性能。另外，有时粗粒度的服务所包含的信息，要比提出服务请求的系统所要求的多。 可维护性:如果服务的粒度过粗，那么对该服务引入变更将会变得十分困难，并且会影响到对服务的维护以及对提供服务的服务平台的维护 位置与延迟:服务之间可能需要通过远程连接进行交互，加之服务间通信存在固有的延迟。因此，在划定服务边界以及确定服务粒度时，应该充分考虑平台/位置对这些服务间通信的影响。 可用性:服务调用常常会遭遇网络故障或服务实效的情况。因此，在分解服务与定义服务粒度时，需要重点考虑通信的高可用性。在技术架构阶段中，当我们需要重用现有的产品，添加能力增量或者将产品选择决策作为项目启动过程中一项约束条件时，产品选择流程就应运而生了。如果产品选择活动偏离了现有的标准，包含有重要的产出或者产生了广泛的影响，那么这一活动就应该被标识为一项机会，留到“机会与解决方案”阶段来处理。确认所需的目录在技术架构阶段中，应该依照如下步骤创建技术目录：基于现有的技术目录以及在应用架构阶段中对应用的分析，收集当前使用中的产品信息，并编制成产品列表。如果现有的产品不能满足应用架构中所确认的需求，就应该使用市场上那些能够满足其功能需求与规定标准的可用产品来扩展产品列表如果技术标准当前可用，就应该将其应用于技术构件目录，以获得关于技术标准一致性的当前视图在技术架构中，应该考虑开发以下目录：技术标准技术组合确认所需的矩阵在一项技术架构中，应该考虑开发以下矩阵：系统/技术矩阵确认所需的图在技术架构中，应该考虑开发以下的图：环境与位置图平台分解图处理图网络计算/硬件图通信工程图确认需要收集的需求类型当技术架构目录、矩阵、图都已开发完成时，为完成架构建模，我们还需要使以数据为中心（data-focused）的需求正式化，这些需求将最终用于实现目标架构。在本步骤中，架构约定应该确定各种需求的类型，这些类型的需求都应该在架构实现中达成。需求的类型包括有：功能需求非功能需求假定约束领域特定的技术架构原则政策标准指引规格说明书开发当前技术架构的描述开发现有技术架构的当前描述，以更好地支持目标技术架构。开发对目标技术架构的描述开发技术架构的目标描述，使之能够充分地支持架构愿景、目标业务架构与目标信息系统架构。目标架构描述所定义的范围与细节等级，是由实现目标架构的技术元素的相关性以及架构描述是否存在的情况决定的。执行差距分析首先，验证架构模型，确保其内部的一致性与精确性。接着，记录对视点的有关变更并写入文档。最后，确认当前与目标之间的差距：创建差距矩阵确认延用的构建块，将其分为改变的与未改变的两类确认移除的构建块确认新的构建块确认差距并将其分为需要开发的与需要采购的两类分析对架构景观产生的影响技术架构一旦得到最终确定，架构团队就应该着手去理解这一架构所产生的广泛影响或可能的结果。具体来说，在本阶段，就应该检查架构景观中其他架构制品，确认出：本技术架构对预先存在的架构产生了影响吗？最近是否进行过影响技术架构的变更呢？组织中其他领域有没有可能综合利用本技术架构的产品呢？本技术架构会影响其他项目吗（包括规划中的项目以及当前进展中的项目）？本技术架构会被其他项目所影响吗（包括规划中的项目以及当前进展中的项目）？进行正式的利益相关者评审对照提议的技术架构，检查架构项目与架构工作声明的动机，查看它是否符合支持其他架构域中后续工作的目的。在需要的情况下，可以对提议的技术架构进行精化。最终确定技术架构为每一个构建块选定标准，尽量地重用那些来自架构储藏库中参考模型的构建块用文档的形式充分地记录每一个构建块的信息 对照业务目标，对总体架构进行最终的复核；以文档的形式记录架构文档中构建块决策的全部依据编写最终的需求跟踪报告 编写架构储藏库中最终的架构映射文档；从所选构建块中，确认出那些也许需要重用的块，然后通过架构储藏库发布它们。最终确定所有的工作产品，如差距分析报告。.9 输出本阶段的输出有：架构愿景阶段交付物的精化与更新版本，包括有：——架构工作声明（需要时进行更新）——已验证的技术原则，或新的技术原则（如果是这一阶段产生的） 架构定义文档草案，包括：——目标技术架构，版本1.0（详细的），包括：——技术构件以及它们与信息系统的联系——技术平台以及它们的分解，展现了用以实现特定技术“栈”的技术组合。——环境和位置——将所需技术分到不同计算环境中的归类——技术构件的预期处理负载与负载分布——物理（网络）通信——硬件及网络规范——当前技术架构，版本1.0（详细的）（如果合适的话）——对应于所选视点的视图，这些视点用于解决关键利益相关者的关注点 架构需求规范草案，包含如下技术架构需求：——差距分析结果——自B阶段到C阶段的需求输出——更新的技术需求架构路线图的技术架构构件实施计划明确总体实施战略评审并合并自业务分析阶段至技术规划阶段的差距分析结果合并及整合业务、信息系统与技术架构（自业务分析阶段至技术规划阶段创建的）的差距分析结果，并根据潜在的解决方案/机会与相互依赖关系来评估它们包含的内容。评审来自每一个架构阶段的差距分析结果，并把这些结果合并成一份长清单，这份清单将会作为工作分解结构（WBS）的基础。阐明高层次的实施与迁移策略创建一个整体的解决方案策略来指导目标架构的实施并构建过渡架构。第一项活动是确定整体的策略方法以实施解决方案与/或开拓机会。往新架构范式的迁移行动将需要一种不同的策略来升级现有的IT基础设施。应该根据对先前识别的风险所做的分析来阐明一种适当的策略方法。下一步，确定一种方法来实施上面所选择的整体策略指导，从而解决并减轻在合并的差距、解决方案、依赖性整合矩阵中识别的风险。在任何情况下，由于方法的含义相当重要，因此需要高层级的业务与技术保持一致。例如，一种战略性的投资就长期而言是会带来很高的利润的，而在短期看来却会对股票的价格造成非常不利的影响，这就需要进行适当的沟通。输出本阶段的输出是：能力评估，它包括：——企业架构成熟度概要——转换就绪状态报告过渡架构，版本1.0，它包括：——合并的差距，解决方案与依赖的评估——风险记录，版本1.0——影响分析—项目清单——依赖分析报告——实施因素评估与推导矩阵实施与迁移计划，版本0.1，包括高层级的实施与迁移战略制定详细的项目阶段计划本阶段的目的是完成详细的实施与迁移计划；确切地说包括：确保实施与迁移计划能有效地配合企业中正在使用的各种不同的管理框架通过赋予商业价值，并进行成本/业务分析，从而区分所有工作包、项目和构建块的优先次序按照已达成一致的实施方法，完成架构愿景与架构定义文档与相关的利益相关者共同确认E阶段中所定义的过渡架构创建、发展与监控详细的实施和迁移计划，使其为实现E阶段所定义的过渡架构提供必需的资源。估算资源需求，项目时限及可用性/交付载体为每一项目及项目增量确定所需的资源与时间，并为项目提供初步的成本估算。成本应该拆分为资金（用以创建能力）、运营与维护（用以经营和维持能力）。注意到，当第一个增量交付到运营管理组织时，就必须着手进行运营与维护投资，因此，必须从一开始就弄清，这两种类型的投资来源（是否负担得起）。这种问题的典型例子就是软件维护的成本以及与更新相关的成本（包括所做的某些专门定制的软件修改）。成本应该包括所有的能力开支，如业务过程开发、互操作性需求、培训、新员工、设备等等。需要牢记的是，创建项目时应该精化实际成本的估算。通过依赖关系，确认机会——与交付新的或更好的能力相关的成本能否被将淘汰的现有系统的维护费用所抵消，因为这种维护可能消耗掉数量与之不相称的资源。这一点应该明确注释。将所需资源分配给每一活动，并在项目增量与项目级别上进行总计。生成架构实施路线图（按时间顺序）及迁移计划本步骤生成实施与迁移计划的顺序与细节。分层架构的一项主要创新在于它专注于增量的业务价值的持续交付，并允许通过创建适时的过渡架构而适机地利用新技术。这一敏捷性与灵活性的代价是需要紧密地协调重要的并发活动。通常情况下，会有三到四个过渡架构接受着并行的管理，即交付、构建、设计与规划。没有任何一个企业架构或支持计划拥有无数的细节，因为无论是从业务事件还是从技术演化的角度看，这些细节的大部分都经不住时间的考验。确切地说，它将随着时间朝着目标状态演化，并受到一系列不断趋同的架构状态的指引。这些状态适机地向战略上所定义的目标架构不断推进。同时，随着企业的自文档化进程，增强的内容、可重用的资源、不断增加的细节，使得企业架构与架构储藏库的内容变得日渐丰富起来。架构规划的主要特点在于，存在有大量的活动并发进行，因而实施与迁移计划就成为了将这些制品粘在一起的“胶水”。计划中的多数细节都已收集完成，因而本步骤中需要做的就是使用已批准的组合/项目规划与管理技巧，将这些细节整合到一起。输出本阶段的输出有：实施与迁移计划，版本1.0最终的架构定义文档最终的架构需求规格说明书最终的架构路线图最终的过渡架构可重用的架构构建块项目实施中架构方面的架构工作要求（如果有的话）项目实施的架构契约（标准）实施治理模型由所吸取的教训产生的变更请求IT治理实施治理本阶段的目的是：阐明每一实施项目的理由治理与管理涵盖总体实施过程与部署过程的架构契约在实施与部署解决方案期间，履行适当的治理职能确保实施项目与其他项目依从于所定义的架构确保解决方案计划依照所定的工作计划成功地部署，确保所部署的解决方案依从于目标架构动员支持工作以延长所部署的解决方案的未来工作寿命。执行企业架构一致性评审评审正在进行的实施治理以及每一构建块的架构一致性进行开发后的评审关闭部署项目中的开发部分执行实施后期评审并关闭实施进行实施后评审发布评审报告并关闭项目当解决方案都完全地部署一次时，本阶段正式关闭。输出本阶段的输出有：架构契约(签署的)，这是已实现的依从架构的架构所推荐的一致性评估依从架构的（architecture-compliant）解决方案包括：——已实现的依从架构的系统——包含内容的（populated）架构储藏库——架构一致性建议与分配——关于于服务交付需求的建议——关于绩效度量标准的建议——服务级协议（SLAs）——实施后更新的架构愿景——实施后更新的架构定义文档——实施后更新的过渡架构——实施解决方案中的业务运营模型与IT运营模型架构变更管理—对业务/技术变更进行控制本阶段的目的是：确保当前架构持续的适用于目的评估架构性能并为变更作出推荐评估前序阶段所设定的框架和原则的变更为本阶段完成的新企业架构当前设立架构变更管理流程从架构与当前的运营中取得最大的业务价值运营治理框架变更管理的方法，它旨在支持一个动态的企业架构。这一方法会将所需的架构变更分成如下三类：精简变更：一个精简变更通常可以由变更管理技术来执行。 增量变更：一个增量变更可以由变更管理技术来执行，也可以要求进行部分重构建，这取决于变更的种类（见16.2.3节的指引）。可重构建变更：一个可重构建变更要求将整个架构重新放置于架构开发周期中。例如： 如果变更对于业务策略的影响非常大，那么就需要重新执行整个企业架构——这就是一种重构建的方法 如果出现了新的技术或标准，那么就需要更新技术架构，而不用更新整个企业架构——这就是增量变更 如果变更在基础设施的层级上——例如，10个系统减少或变更为1个系统——也许这不会改变物理层上的架构，但是它会改变技术架构的当前描述。这将成为由变更管理技术处理的精简变更。特别地，如果出现一下情况，一个更新的周期（部分或完整重构建）可能是必要的：基础架构需要重对齐到业务策略需要对架构部署中使用的构件与指引产生重大的变更 产品架构中使用的重要标准产生了变更，此变更对终端用户产生重大的影响；例如，可监管的变更。提供架构变更管理分析对架构变更管理进行分析：分析性能使用服务管理进行企业架构性能评审评估变更请求与报告以确保满足期望价值实现和客户的期望服务级别协议（SLA）执行企业架构性能差距分析确保变更管理请求遵循企业的架构治理与框架激活流程以实现变更激活架构流程以实现变更：产生一个新的架构工作要求以及一个投资请求确保此阶段中实现的任何变更都以文档的形式记录于架构储藏库中输出本阶段的输出有：架构更新（为维护变更）架构框架与原则产生的变更（为维护变更）新的架构工作要求，将其移至另一个周期中（为主要的变更）架构工作声明（按需更新）架构契约（按需更新）一致性评估（按需更新）能力要求IT规划是