怎么理解框架、架构和企业架构？

http://ea.zhoujingen.cn/110.html

 

作软件产品近二十多年了，“架构“真是一个重要而模糊的词，因范围太广，内容太深而很差理解。而要了解企业架构，那必然要先了解架构，因此今天我和你们来聊聊“架构”。

IEEE 1471架构

        IT 这个行业中的词汇许多都来源于传统行业，例如“精益””架构“”。“架构”这个词也来源于建筑学。在建筑建造出来或者产品加工出来以前，设计人员用图纸来描述本身的设计意图。如今你要给软件画个图纸，这个图纸会有哪些要素组成？

        在IEEE 1471中是这样描述架构元素及其关系的：

若是想要更多了解，你们能够本身上网查找一下这个图的讲解，在此我就很少说了。     

架构和框架

        架构常常和框架有点关联，容易混淆，因此在讲架构时必定得说说框架。

框架的使用：

• 在软件架构中能够不采用任何框架，可是没有使用框架的软件架构经常是不可想象的。这意味着，咱们放弃了前人积累的知识财富。
• 企业级应用中要考虑的因素太多，不使用框架几乎不可能使项目成功。
• 使用框架，意味着接受框架设计者的想象和思想，意味着使用固定的编程模式，意味着编写指定格式的类型，意味着无条件的接受框架提供的服务，意味着你将受限于框架的能力。一种正确的作法是，在使用任何框架前，应该先了解该框架对软件开发的种种约束，根据组织和项目的实际状况，权衡利弊后再作决策。
• 除非你和框架设计者同样，透彻了解它的创做思想以及创做细节。即使了解，你也可能会由于未来框架新版本的推出而产生问题。采用集成的方法来使用框架，而不是尝试去改变它。

框架和架构的区别：

• 架构是指软件的结构，以及结构元素之间的动态关系，而框架是架构的一个组成元素
• 从企业应用系统的角度来看，框架是编程的工具，而架构是目标
• 框架自己也具备架构，而架构能够不考虑使用框架
• 架构对于软件开发人员的约束是方向性的，它留有巨大的创造空间，而来自框架的约束是具体的、普遍的
• 框架为软件开发人员提供了丰富的服务，而架构只会对结构元素提出各类服务要求

BAPO之架构

        由于我以前作过好几年的管理软件以及开发平台，因此接着我说下在软件产品线工程方法中如何对架构进行说明的。

IEEE 1471是对通用架构的描述，FEF是一个产品线评估框架，里面有对架构的评估。Family Evaluation Framework (FEF) 是欧洲工业界和学术界通过六年时间从众多项目整理出来的一个评估框架，以下图，该评估框架有5个级别， 覆盖了软件工程的四个评估维度（商业、架构、流程和组织），每一个维度有三到四个方面，本篇将介绍一下架构维度，这是咱们业务和开发人员最应该关注的维度。

三个方面 

BAPO对架构着重从如下三个方面考虑：

1. Asset reuse level : 重用资产
2. Reference architecture: 参考架构，做为应用架构的基础架构
3. Variability management: 可变性管理

Level 1: 独立开发（Independent Development）

整体说明：只有针对单个系统的架构。

• Asset reuse level : 没有或者毫无系统性的重用
• Reference architecture: 没有软件产品线架构
• Variability management: 无论理可变性

Level 2: 标准基础设施（Standardised Infrastructure）

整体说明：重用集中在第三方基础设施。没有正式的可重用领域资产。

• Asset reuse level : 使用通用的第三方基础设施。
• Reference architecture: 产品线架构基于第三方基础设施，主要致力于使用这些基础设施
• Variability management: 有时会受到第三方基础设置提供的可变性限制，大部分可变性仍是由应用架构提供

Level 3: 软件平台(Software Platform)

整体说明：捕获了领域通用性并在平台中实现，全部应用能够共用一个参考架构，经过配置平台能够适用与多个不一样的产品，可是对可变性管理仍是没有很好的支持。

• Asset reuse level : 定义了多个通用资产，在平台和架构下进行有计划的重用。
• Reference architecture: 参考架构做为应用架构起点
• Variability management: 参考架构决定了核心资产支持应用开发须要进行哪些配置，有明确的应用生产计划。

Level 4: 可变性（Variant Products）

整体说明：在产品线中明确提出可变性管理，可以很好的进行进行领域共性和可变性管理

• Asset reuse level : 应用开发能够进行明确的可变性管理
• Reference architecture: 参考架构支持可变性管理，明确的代表使用参考架构如何支持应用架构的变化
• Variability management: 应用工程的可变性进行很好的统一管理

Level 5: 可配置（Configuring）

整体说明：参考架构占主导，只有少许的应用架构，更多的是使用建模、脚本、工具和配置从参考架构自动生成产品。

• Asset reuse level: 系统的规划和重用资产库
• Reference architecture: 参考架构彻底决定了应用架构，能够经过自动配置后生成应用
• Variability management: 变量彻底集成在架构中，变量被描述为模型，经过有语义的语言进行管理

架构定义泛滥和统一

        愈来愈多的人发现，表述一个系统架构的方法不仅一种，一个系统中也可能有不少种不一样的架构，并且对于什么在架构上意义重大的见解也会随着系统的生命周期而变化，因此会出现不少词汇：软件架构（softwarearchitectures）、系统架构（system architectures）、企业架构（enterprisearchitectures）、信息架构（Information）、应用架构（Application）、IT架构（ITarchitectures）、业务架构（Business architectures）、技术架构（Technologyarchitectures）、应用架构（Solution Architectures）、基础架构（InfrastructureArchitectures）、领域架构（DomainArchitectures）等。

    其中对于从软件开发出身的人来讲，要着重关注一下业务架构，因此我这里说下业务架构体系：业务架构体系是针对企事业信息管理系统中具备体系的、广泛性的问题而提供的通用解决方案，更确切的说，是基于业务导向和战略驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，好比业务架构体系认为一个信息系统必须由组织机构、业务流程、业务信息、业务功能、和业务语义等层次构成。

    这些架构有的还存在各自的社区力量，不一样架构之间可能还存在一些争斗，因此想要统一很难，而咱们须要作的就是先对对以上这些架构词汇所表明的知识进行学习，在掌握了基本概念之上再结合本身的实践和思考去逐步清晰架构的概念，整理出本身的理解。

我对架构的理解

     虽然架构的定义难以统一，但做为架构师来讲，咱们仍是但愿能在某些角度上达成相对统一的理解。《企业应用架构模式》认为架构定义自己很难统一，可是可以统一的内容有两点：

1. 最高层次的系统分解
2. 系统中不易改变的决定

    如下为我认为对架构还不错的一些简单说明，可供参考：

• 架构是一个约定，一个规则，一个你们都懂得遵照的共识
• 架构是一种主观上的东西，是专家级项目开发人员对系统设计的一些可共享的理解
• 架构一般指产品组成部分的大粒度的组成部分的设计，架构师在特定方法下，在经验和直接下进行系统、企业或者软件的分解，造成大粒度的组成元素。
• 一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，而且在必定环境和原则下进行设计和演变

• 架构是针对某种特定目标系统的具备体系性的、广泛性的问题而提供的通用的解决方案。
• 架构每每是对复杂系统的一种共性的体系抽象。
• 架构让咱们可以正确、合理地理解、设计和构建复杂的系统
• 复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。
• 架构是蓝图，是从总体到部分的最高层次的划分。架
• 构设计是声明性（declarative）的，而不考虑具体实现。架构是设计，可是设计不必定是架构。架构设计忽略元素内部的详细设计，这些元素的详细设计将由关注详细实现的设计人员来细化。
• 架构是关注点分离
• 架构是一种权衡

企业范围的架构

        架构是为软件产品服务的，而软件产品是由IT技术人员开发的，因此以前咱们谈到的架构基本上是这样的：

        IT 专家们已经习惯于在信息系统开发和维护项目中处理应用、数据、技术和其余解决方案架构形式。全部解决方案架构领域被看做是“技术性的”，由于它们的范围内包括各类技术元素，例如，软件、数据和 IT 基础架构。这些领域都是由技术人员来处理 —— 也就是那些具备系统工程、软件工程或 IT 管理背景的人。

        随着IT技术的发展，以及信息化水平的提升，在 90 年代业务架构做为单独的领域出现了，当时许多组织接受了业务架构师角色，也对业务架构框架中应该包含的组件的内容有了通常的共识：过程及信息、组织和绩效是相关联的。

后来你们基本接受在企业范围内的架构包括业务架构和解决方案架构两部分：

这两部分上接战略，下接项目实施，今后企业架构成为了企业的重要组成部分。

 IT架构还能够再细分为：应用架构、数据架构和技术架构