当我们说“架构”的时候，你想到的是什么？

程序员听到“架构”的时候，想到的是SSH、SSM三层架构，或者是SOA架构，或者是微服务架构等。

人力资源专业人员听到架构的时候想到可能是企业组织架构。

几乎每个行业专业都会对架构有特定行业的理解和认识，如昨天的文章荐读：《GB/T 8566-2022/ISO/IEC/IEEE：系统与软件工程生存周期过程》国家标准解读，只有当我面写标准的时候，才会追本溯源的问？什么是架构？当我们说架构的时候，或者为架构争吵的时候，有没有在一个维度上讨论？关于“架构”一词，业界有一个国际标准：ISO/IEC/IEEE 42010《软件与系统工程-架构体系》。

所以当我们谈架构的时候，应该有一个对于架构的普遍理解，或者说有一个关于“架构”的上下文。

在《ISO/IEC/IEEE 42010》标准中，定义了架构的解释和架构的上下文。

（1）架构：

    一个系统在其所处环境中的（系统的）基础概念或属性，其内容包括它的元素、关系和它的设计和演进的原则。

《GB/T 8566-2022/ISO/IEC/IEEE：系统与软件工程生存周期过程》对架构的定义也来源于此。

简单的说：架构 = 元素 + 元素关系 & 设计演进原则

无论4A架构，还是分层分域架构，都是对元素维度的不同方面和粒度的梳理，元素和元素之间的关系则需要基于设计原则，这是一种对架构的高度抽象概括，单纯的说概念可能感触并不多，那么可以结合架构上下文来讨论。

（2）架构的上下文

    架构是系统的展示。

我们经常说架构是组织的反映，有什么样的组织就有什么样的架构，从这个层面上讲，架构不是做出来的，架构说明是组织的展示，脱离开组织单纯讲架构也是一种耍流氓，所以很多企业抄华为的4A架构没法抄，所谓千企千面，每个企业也要根据自身实际情况进行架构的TOBE设计。

在《ISO/IEC/IEEE 42010》标准中，对系统也做了明确的定义：“系统是人工制造的，可由在此列出的一个或多个事物构成：硬件、软件、数据、人、过程（例如为用户提供服务的过程）、规程（例如操作指令）、设施、材料和自然发生的实体”。简化一点描述可以理解成为“软件产品和服务”（software products and services）

而企业的“系统”位于一个环境中。环境决定了整个生命周期中施加于系统的所有影响，包括系统在环境中，与环境的交互。这里的“环境”和我们口语表达中的“企业组织”相似。

一个系统的环境中可以包含其他系统。同一系统可以通过几种不同的架构来理解（例如，在不同环境中进行考虑时，可以使用不同的架构视角对同一系统进行架构说明）。

一个架构可以通过几种不同的架构说明来表达（例如，当采用不同的架构框架时，同样一个数据架构，华为的数据架构理解与其他公司也不相同，Togaf的数据架构和埃森哲的数据架构也不尽相同）。

相同的架构可以表征多个系统（例如，公用一个共同架构的系统系列）。

我们日常所说的“架构”或者“架构设计”或者4A架构，实际上是架构设计的输出物。在《ISO/IEC/IEEE 42010》标准中，架构是抽象的，由概念和属性组成，而架构说明是一种工作产品，也就是架构工作的输出物。

所以当我们谈架构的时候，我们谈的是图中的哪一块？

参考：《ISO/IEC/IEEE 42010》

 下载地址：