架构在研发项目中的应用 推荐

架构这个词对从事IT工作的人来说一点都不寞生，但是在实际项目中，如何理解不同阶段的架构，如何建立架构，如何使架构为我们的目标服务，并不好把握。

谈信息系统的架构，要从企业架构的起源说起企业架构（EA Enterprise Architecture）， EA概念产生于1987年，在IBM的一个内部刊物上发表的一篇文章"A Framework for Information Systems Architecture" by J.A. Zachman，概念的提出是为了应对日益复杂的IT系统以及高投资、低回报的问题。随着企业架构的不断进化，企业架构理论越来越与战略和业务相融合，逐步形成了企业战略、业务架构、信息架构、IT架构等四个层次。

那如何定义企业架构呢？

企业架构就是企业中架构的远景。你可以在此设立目标：如业务战略目标需求，通过业务的架构（业务流程、工作流、交易和协同工作），应用的架构（系统、服务以及功能化的用户案例），数据的架构（数据、业务对象、交换的格式、安全性和隐私性），技术的架构（软件、硬件、服务器、操作系统、网络），可以得出不同项目的分析，你可以在最下端来追踪影响、做出决和察看项目结果。 （http://xiaojg.spaces.live.com/blog/cns!820C63A54759569D!975.entry）

企业架构（EnterpriseArchitecture:EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响。从这个定义至少可以看到重要的两点，其一是业务、信息、技术和应用的融合；其二是EA包括了业务和IT两个重要的方面，是从全局考虑业务和IT的集成。企业架构是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术基础架构共同构成。（http://www.uml.org.cn/qiyexinxi/200907314.asp）

从上面所述可以得出，当我们考虑架构时，都是在考虑企业架构的一部分，但是视角不同，结果不同，这一点是不能忘记的。就如同零件的俯视图、左视图、右视图，虽然看到的不一样，但是描述的是一样东西，相互之间要避免冲突，而不能单纯的在一个视图来考虑。企业架构的几个视图比较机械零件来讲，更为复杂，目前阶段共识的分为业务架构、信息架构、应用架构、技术架构。木子的图很能说明问题：





（http://www.uml.org.cn/qiyexinxi/200907314.asp）

个人理解上面更多的是从最终用户的角度来说明，而从研发的角度，为了给客户提供实现战略目标的信息化系统，我们需要更多一步认识几个架构的关系及研发过程。在实际研发中，我们可能还会听到其他的架构名词，比如软件架构、系统架构，从一定程度中来讲，这两个可以认为是应用架构的一部分或者其前身，但感觉明确其概念对我们的研发有一定帮助。

下面按顺序描述一下我对业务架构、软件架构、系统架构、应用架构、技术架构、信息架构的理解，分别从其定义、制定业务架构时的输入来谈一下我的看法。

一、业务架构

定义：也即公司的业务点的组织架构图，业务点通过流程来贯通，这个贯通图与业务点组成了业务架构。一个公司之所以能存在，就是因为它能通过它的业务流程为它的客户产出产品或服务，随着技术的发展，很多企业认识到，业务规则也成为企业核心资产之一；业务数据、业务流程与业务规则一同形成了企业业务的核心资产，基于这些资产，企业向外向内提供一系统业务服务，根据服务对象的不同，性质的不同，业务也会被分门别类，形成个业务的业务架构，通过对架构的解读，企业实现战略目标，同时也思考业务的进一步优化所在。

作用：呈现企业业务能力、为优化提供依据、为信息系统研发奠定基础是核心所在；

范围：以满足企业战略目标为指南、主要描述提供的业务、实际提供的创造价值的服务描述为主；

过程输入：企业战略、具体的商业应用、企业现状（人、财、物、信息）、原有业务架构（如有）、用户需求、业务流程、业务规则、业务集、业务数据集

生成阶段：需求分析阶段

二、软件架构

定义：软件研发过程中必不可少，明确整个企业应用中的软件组成，相互间的关系等等；通过软件架构，企业向外提供业务架构中明确的业务，实现内部的表单传递与信息共享，理清各个部分的责任范围；其是横向层次、广度上的描述，主要是应用层面的划分，不探究各个部分的底层实现。

作用：明确企业信息系统的软件组成、企业的业务流程的具体执行单位、为软件的开发时的边界确定、接口设计提供依据；

过程输入：业务架构、企业规章制度、企业组织架构、企业职工的岗位职责、用户需求、业务流程、业务规则、业务集、业务数据集

生成阶段：概要设计

三、系统架构

定义：现代成熟企业都会建设一些应用系统来支持日常业务，那么支持这些业务活动的应用系统合在一起就形成了应用系统架构。在某种程度上与上面提到的软件架构相同，这里区分点在与纵向上的考虑，会涉及到数据采集层、存储层、应用层的区分。“在《Rational 统一过程实践者指南》（RUP）认为，系统架构为：1.系统中最重要的组成部分和它们的接口，以及做出的创建、购买或是重用这些组成部分的决定；2.描述这些组成部分在运作时如何交互来实现系统中最重要的脚本；3.实现并测试系统架构的原型，以验证架构是否可行、是否化解了重大风险，以及验证它是否打到了重要的质量指标：性能、可扩展性和成本等。”在系统架构考虑时，需要加入非功能性需求，比如本身维护的需求，参考ISO/IEC9126，分别从服务对象、系统目标、系统环境三个角度对系统架构8个非功能性特性进行分析，即开放性、扩展性、适应性、安全性、高性能、高可用、可管理、易用性、可靠性。

作用：明确系统的总体设计思路，为系统详设提供依据；同时与软件架构的设计会产生互相反馈的效果；比如在考虑非功能需求时，对功能需求的规划调整就应该反应到软件架构上来。明确软件架构中的各个点的实现层次，为软件的开发时的边界确定、接口设计提供依据；

输入：业务架构、软件架构、企业规章制度、企业组织架构、企业职工的岗位职责、用户需求、业务流程、业务规则、业务集、业务数据集、非功能性特性

生成阶段：概要设计

四、应用架构

定义：应用系统要能正常运行，必然离不开服务器、操作系统、中间件、网络环境等基础技术环境的支持。企业信息系统运营的支撑，通过合理部署硬件设备，采用合理的基础软件，比如虚拟化存储、网络服务等，集成各软件部分，实现企业信息的流动与共享，达到提供企业服务的目标；可能涉及到有应用分布图或部署方案、系统硬件配置图、系统网络拓扑图等等；

作用：基于业务应用的基本特性，为开发和测试提供了依据，明确集成软件、流程建模和工作流工具、配置管理软件、发布软件及应用开发方法论。其更多的强调的系统的应用，包括基础与外界交互，比如虚拟存储技术、流程管理技术，为我们了解系统与外界的交互提供了模型基础。

输入：系统架构、集成工具、外部系统、底层软件等

生成阶段：概要设计

五、技术架构

定义：系统研发的支撑，明确如何采用信息化发展的成果。研过过程中要开发出软件系统，必然需要相应技术的支撑，这些底层的基础环境形成了技术架构。目前从Portal、业务建模、工作流、规则、安全审计到存储、开发平台都有较多选择，企业采用何种方案，就是技术架构需要考虑的事情。

作用：明确开发平台、开发语言、运行平台等，为各层的开发明确了技能需求，为团队的建设提供了依据

输入：需求分析报告、系统架构、应用架构、软件架构、当前计算机发展现状

输出：各层用到的框架、技术等

生成阶段：概设后期或详设前期

六、信息架构

定义：信息的组织方式，业务流程、业务规则、业务数据的相互关系都是要其内容。“现代社会是信息社会，所有的活动都伴随着信息的传递，企业的活动也不例外，在业务流程中，通常是以某种表证单据作为业务活动的输入，又产出另外一种表证单据，这些表证单据即是概念层次上的信息；若要开发一个应用系统，弄清楚应用系统中所要管理的对象是进行需求分析重要内容，这里通常称做“业务实体”，业务实体即逻辑层次的信息；在应用系统运行起来后，应用系统中所管理的数据，通常是保存在数据库表中，这些物理上存在的数据即物理信息。概念层次的表证单据到逻辑层次的业务实体，再到物理层次的实际数据，合在一起称做信息架构。”其包括：信息的分类、数据集、数据元、数据字典的设计，建模、存储、展现都是其一部分。

作用：信息架构是整个企业架构的基础，除了各个软件系统互联互通必须要基于其上以外，数据库的设计也同样是以其为基础。

输入：用户需求、业务流程、务规则、业务集、业务数据集、系统架构、软件架构、技术架构

生成阶段：概设整个周期