关于企业架构、软件工程等相关内容，基本在行业内工作一段时间都能解释出各自的理解，网络资料更是知识爆炸，看似哪一种都对，其实相对都是个人理解，算不上严谨。

上周工作中涉及架构的企业标准编制审查，对严谨性提出了很高的要求，

查阅了一些资料，找了国家标准和国际标准两项。国家标准：《GB/T 8566-2022/ISO/IEC/IEEE》和国际标准：《ISO/IEC/IEEE 42010》。

本期推荐：

国家标准：GB/T 8566-2022/ISO/IEC/IEEE《系统与软件工程软件生存周期过程》。

在GB/T 8566-2022/ISO/IEC/IEEE中对“架构”定义的标准定义是：(系统)在其环境中的一些基本概念或性质,体现在其元素关系,以及设计与演进原则中。

GB/T 8566-2022/ISO/IEC/IEEE对软件系统的描述也做了高度的概括。

体现出来的就是元素和元素之间的关系，这种元素之间的关系可以分成不同的视角展示。GB/T 8566-2022/ISO/IEC/IEEE更关注的软件系统，软件系统与其系统元素全集之间的关系通常可以用表示元素间关系的层级结构来描述。

分解是某些软件活动中的一种方法，系统元素以平面（非层次）描述的方式布局。

在系统元素的全集得到确切定义之前，一个预期的系统元素本身有可能需要被看作一个系统，以这种方式，将合适的系统生存周期过程递归地应用，用以将其结构分解到可理解的和可管理的系统元素能够实施（创建、调整获取或重用）的程度。也就是说元素可以到原子级。

软件生存周期过程体系和信管知识体系如出一辙，项目管理方面内容在此不在赘述，关于架构部分确在技术过程组中，有架构定义过程和设计定义过程。

其中架构定义过程：

目的是产生系统架构备选方案,选择构建利益相关方关注且满足系统需求的一个或多个备选方案，并用一组一致的视图进行表达。

通常使用架构定义过程与业务或使命分析过程、系统/软件需求定义过程、设计定义过程以及利益相关方需要和需求定义过程的迭代，以便对需要解决的问题达成协商一致的理解并确定出满意的解决方案。

架构定义过程的结果被广泛使用于整个生存周期过程。架构定义可以应用于多个抽象层次，突出在该层次决策所必需的相关细节。

设计定义过程：

目的是提供有关系统及其元素的足够详细的数据和信息，以便使实施与系统架构模型和视图所定义的架构实体相一致。

设计活动通常与系统/软件需求定义过程和架构定义过程中的活动进行迭代。设计定义通常迭代地和增量地应用于开发详细的设计，包括软件元素、接口、数据库和用户文档。软件设计通常与软件实施、集成、验证和确认同时进行。

架构定义过程和设计定义过程组成了GB/T 8566-2022/ISO/IEC/IEEE的系统设计体系。

和前面架构元素结合起来看，架构定义中可以结合业务、应用、数据、技术、安全等5A架构展开，也可以选择利益相关方展开不同颗粒度的元素关系描述，即展示多个抽象层次

设计定义可以看做是架构定义的更一步细化，细化到软件层面，展示软件元素如接口之间的关系，如软件层面的软件架构（SSH、SSM、SOA、微服务等）应在此按照技术框架视图展示，接口集成关系按照集成关系展示、数据库设计按照数据视图展示，也是在详细设计阶段的不同视图。

在国内实际软件工程项目工作中，技术过程一般包含概要设计和详细设计，架构定义和架构设计也隐约对应了两个设计交付物。

参考：《GB/T 8566-2022/ISO/IEC/IEEE》

下载地址：