作者简介
Gavin，程序员、软件架构师、企业架构师，关注智能制造。
本文是专栏《智能制造系统架构》中的文章，其它文章请参阅入坑智能制造系统架构。
原文链接：https://blog.csdn.net/gavinchen1985/article/details/113801942
什么是系统架构？
所谓系统架构，其主要任务就是通过分析系统属性来设计系统结构。
ISO/IEC 42010: 2011中，架构的定义为：一个系统在其所处环境中所具备的各种基本概念和属性，具体体现为其所包含的各个元素、他们之间的关系以及架构的设计和演进原则之中
其中架构的对象是“系统”，泛指一群有关联的个体，系统可以一个企业，部门，也可以是个应用或者服务。关于系统架构定义，应注意：
每个系统都有一个架构
架构由架构元素以及相互之间的关系构成
系统是为了满足利益相关者（stakeholder）的需求要构建的
利益相关者都有自己的关注点（concerns）
架构由架构文档描述
架构文档描述了一系列的架构视角(architectural perspective)
每个视角都解决并且对应到利益相关者的关注点。
系统架构中核心概念的关系如下图所示：
系统架构的对象可能是一个服务、一个应用、一个部门、一个工厂、一个集团、甚至一个行业。而系统架构的复杂性因系统规模而异，系统规模越大，系统架构越复杂。因此，在系统架构设计时，首先要明确架构设计的对象。对象不同，架构设计的粒度、方法和侧重点也就不同。在IT领域，常将系统架构分为三个层级，分别是企业架构、解决方案架构和应用架构。三者的区别在于：
企业架构（公司级）：通过架构治理和指导规范保证IT技术策略和执行计划与公司愿景及业务目标一致。企业架构也会推动在公司范围内跨IT项目的技术整合、复用和综合效益。
解决方案架构（业务单元级）：对特定的业务单元定义IT系统，业务流程和可复用的服务，横跨业务架构和技术架构。
软件架构（软件系统级）：定义信息系统结构，包括定义子系统组件及其内部关系，以及与外部系统的关联关系。
三个层级，层级越高，内容越抽象，工作的内容偏治理；层级越低，内容越具体，工作内容偏实现。但在实际操作中，这三种架构并非界限分明，也并非所有的企业都有相应的岗位对应这三级架构。如果公司规模不大，或者IT管理复杂度不高，可能会由一人同时兼任企业架构和解决方案架构的角色，甚至三级架构都由一人承担。这都取决于公司的规模和管理的重点。
但从方法论上讲，企业架构和应用系统架构各自都由相对成熟的框架和方法。
企业架构
企业架构对企业构成要素的结构和关系进行模型化描述，用途是指导企业经营管理活动的策划、分析和信息系统开发。
一个企业架构（EA, Enterprise Architecture）具有三个方面的含义：
EA是一个描述工具：EA为组织中的所有干系人提供了一种描述手段（模板），使其可以对组织中的业务、信息系统及其之间关系按照各自的视角进行描述。而且由于使用统一的语言进行描述，所有干系人之间也有了无障碍沟通的基础，而这也正是EA最重要的用处。
EA是一个知识库：EA为组织中所有参与者所提供的针对企业架构各方面的描述提供了一个分类管理、便于访问的知识库和信息资源库。
EA是一个系统过程：为了使组织内信息技术与业务的需求、变化相适应，EA提供了一套实施准则和管理策略。
企业架构最早由IBM的John Zachman提出，通过信息、流程、网络、人员、时间、基本原理6个视角构建用于分析企业的模型，称为Zachman框架。此外还有TOGAF、NAF、DoDAF、MoDAF。其中最著名的是The Open Group发表的TOGAF架构框架。TOGAF将架构定义为一个系统的正式描述，或指导系统实施的组件层级详细计划。包含组件结构、组件之间相互关系，以及对这些组件的设计和随时间演进的治理原则和指南。
企业架构包括业务架构和IT架构。业务架构描述企业是如何组织结构的，以及交付业务愿景所需的功能性能力。从企业业务和管理的不同维度构建模型，包括战略绩效、运营模式、流程体系、组织架构、资源匹配、空间布局等。IT架构从从企业信息化实现的维度构建模型，目的是描绘信息系统的蓝图。IT架构又分为数据架构、应用架构和技术架构。
软件架构
软件架构的目的是设计软件系统的顶层结构。在软件架构设计中，架构师把系统设计的需求、约束和架构方面关心的问题转化为结构。然后用这些结构来指导项目开发运维。软件架构设计主要考虑三方面因素：
系统功能：在设计一个软件架构时，至少需要考虑主要功能。主要功能通常被定义为实现业务目标，促进系统开发的关键功能。其他主要功能的标准也可以是意味着技术难度更高或者需要许多架构元素的互相作用。
质量属性：质量属性是系统外部可见的、非功能性的属性，例如性能、安全性或者可伸缩性等。
外部约束：指约束架构设计的来自方方面面的约束性需求。包括业务环境因素、使用环境因素、构建环境因素和技术环境因素。
一般情况下为了实现一个质量属性或者外部约束而在某些结构上所做的变化将对其他的质量属性产生负面影响。这些取舍是每个领域里每一个架构师无法改变的事实。因此，软件架构师的工作不是找一个最佳的解决方案，而是找到一个令人满意的方案——通过搜索一个也许很大的设计方案和决策的空间来找到一个可以接受的解决方案。
应用架构设计的管理本身是内嵌于项目管理流程里的，不管是采用瀑布模型抑或是敏捷模型，都需要考虑架构设计的环节。同时业界也定义了一些架构文档规范来定义架构设计在各个阶段应该产出什么样的交付物。常用的架构视图模板有IBM的RUP定义的4+1视图，或者C4视图，还有侧重业务流程分析的BPMN和侧重模型设计的UML，都是业界常用的设计模板规范。同时也可以参考arc42，作为架构文档模板。
但在不同的项目管理流程中，架构设计的内容和要求也有所不同。比如在瀑布模型中，架构设计是设计阶段重要的交付物，所以架构设计文档会写的比较全面细致。目前常用的架构模板也都是在瀑布模型的管理流程中定义出来的。而在敏捷模型中，迭代开发意味着前期开发目标和关注点会不完整，所以也不会在前期作全面完整的设计。同时“注重可用的软件，胜于详尽的文档”这个原则往往会给开发人员一个错觉，就是我不必编写设计文档，我要优先编写代码。
但需要说明的是，“注重可用的软件”并不意味着没有文档（包括架构相关的文档），这仅仅意味着只有满足当前迭代目标的文档。这意味着创建的工作产品应该尽可能少，但要充分。当编写一个软件架构的文档时，通过充分考虑利益相关者的需求来决定您想要表达的东西。倘若架构的利益相关者是团队成员或者维护人员，您还必须适当地注意您所创建的任何工作软件的维护，要确保在适当的地方保持它们最新且相互一致。
参考资料
https://www.cnblogs.com/zscyun/archive/2013/04/25/3042144.html
Software Systems Architecture, 2nd. 中文版 《软件系统架构》