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

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

做软件产品近二十多年了，“架构“真是一个重要而模糊的词，因范围太广，内容太深而不好理解。而要了解企业架构，那必然要先了解架构，所以今天我和大家来聊聊“架构”。

IEEE 1471架构

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

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

如果想要更多了解，大家可以自己上网查找一下这个图的讲解，在此我就不多说了。

架构和框架

架构经常和框架有点关联，容易混淆，所以在讲架构时一定得说说框架。

框架的使用：

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

框架和架构的区别：

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

BAPO之架构

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

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

三个方面

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

Asset reuse level : 重用资产
Reference architecture: 参考架构，作为应用架构的基础架构
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）等。

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

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

我对架构的理解

虽然架构的定义难以统一，但作为架构师来说，我们还是希望能在某些角度上达成相对统一的理解。《企业应用架构模式》认为架构定义本身很难统一，但是能够统一的内容有两点：

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

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

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

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