怎么区别软件架构、系统架构、解决方案架构、企业架构？

图片

Hello 大家好，我是人月聊 IT。今天准备聊下我们经常谈到的企业架构，软件架构，解决方案架构之间的区别和联系。

这个也是我经常被他人问到的问题，包括我在前面也写过一些相关的文章类说。类似企业架构和软件架构之间的区别关联和映射关系等。今天，我准备把这些内容系统地整合一下，用大白话和大家聊聊，希望能帮大家彻底理清它们的脉络。

可以讲，要理解它们的区别，我们不能死抠定义，而是要看它们各自要解决的问题、站的视角以及关注的范围。我一直觉得，任何技术或方法论，最终都是为了解决问题而生的，抓住了它要解决的问题，本质也就清楚了。

图片

image

企业架构：顶层设计，如同城市规划

首先我们来说说企业架构（Enterprise Architecture，简称EA）。这个概念是“最大”的，也是站位最高的。我经常打一个比方，企业架构就像是做城市规划。一个城市的市长和规划局，他们要考虑的不是某栋楼怎么盖，而是整个城市的布局，比如哪里是商业区，哪里是住宅区，哪里是工业区，道路怎么连接，地铁怎么规划，水电煤气这些基础设施怎么覆盖全局。他们的目标是让整个城市能够健康、有序、可持续地发展。

企业架构师操心的就是类似的事情。他不关心某个具体系统的代码是用Java还是Python写的，他关心的是整个企业的“业务”和“IT”如何更好地协同，支撑企业的战略目标。简单来说，企业架构要回答的是“我们这家公司未来几年的IT蓝图应该是什么样子？”这个问题。

在我之前写的《数字化转型底层方法论-读现代企业架构白皮书》和《企业架构和IT规划咨询核心逻辑》等文章里都提到过，企业架构的核心是业务驱动IT。它包括我们常说的四大架构：

• 业务架构（BA）：梳理和定义企业的业务模式、组织结构和业务流程。
• 数据架构（DA）：描述企业核心的数据资产，如主数据、数据模型和数据流。
• 应用架构（AA）：规划需要哪些应用系统来支撑业务，以及系统之间的关系。
• 技术架构（TA）：定义支撑应用系统运行所需的技术标准、平台和基础设施。

图片

image

你看，企业架构的关注点是全局的、战略性的。它的产出不是具体的代码或详细设计，而是一系列的蓝图、原则和规范。比如，它会规定“所有新系统都必须基于公司的PaaS平台构建”、“客户数据必须通过主数据系统进行统一管理”等等。它的目的是避免重复建设和信息孤岛，让整个企业的IT投资更有效率，更有价值。所以说，企业架构是一种治理工具，它确保我们所有的IT活动，都是朝着一个统一的方向前进，而不是各搞一套，最后变成一堆烟囱式的系统，难以协同。

系统架构/软件架构：单体设计，如同盖一栋楼

如果说企业架构是城市规划，那么系统架构（System Architecture）或软件架构（Software Architecture）就是具体某栋楼的设计图纸。这两者在我看来，区别不大，很多时候可以互换使用，软件架构更偏重于软件本身，而系统架构可能还会包含一些硬件和网络部署的考虑，但核心都是关注一个“独立的系统”。

当城市规划局把一块地批下来，说这里要盖个商场，那接下来建筑师就要登场了。建筑师需要根据商场的功能需求（比如要有电影院、超市、餐厅），以及各种约束（比如抗震等级、消防规范、成本预算），来设计这栋楼的结构、水电管线、功能分区等等。这就是系统架构师或软件架构师干的活。

在我写的《一文讲解业务系统软件架构设计核心内容和逻辑》中，我详细讲过，软件架构设计主要关注两方面：

• 功能性架构：如何实现业务需求，比如模块怎么划分，流程怎么流转。
• 非功能性架构：如何保证系统的性能、安全性、可扩展性、可靠性等，也就是我们常说的“质量属性”。

图片

image

为了做好设计，架构师会用到很多工具和方法，比如经典的“4+1”视图模型（逻辑视图、开发视图、进程视图、物理视图，以及用例视图），通过不同的视角来完整地描述一个系统的架构。产出物就是详细的架构设计文档，包括模块划分图、分层架构图、接口定义、关键技术选型等，这些文档会直接指导后续的开发团队进行编码实现。

所以，系统/软件架构的视角是具体的、技术性的。它是在企业架构定下的大框架内进行的精细化设计。城市规划（企业架构）说这块地要建商场，建筑师（系统架构师）就负责把这个商场设计好，但他不能说我不想建商场，我想建个化工厂，这就违背了顶层规划。

软件系统架构（Software/System Architecture），则聚焦于单个、具体的软件系统或应用的内部构造和实现。 它定义了软件系统的主要组件、这些组件之间的关系（如接口、依赖）以及指导其设计和演进的原则与规范。如果说EA是城市规划，那么软件架构就是单体建筑（比如一座办公楼或一个住宅小区）的设计图纸，详细规定了建筑的结构、材料、功能布局、水电管线等。

图片

在我看来，当我们谈论一个具体项目的"系统架构"或"软件架构"时，往往指的就是这个层面。经典的4+1视图模型（逻辑视图、开发视图、过程视图、物理视图，以及用例视图作为中心驱动）就是描述软件架构的一种常用方法。

企业架构和软件架构之间的区别和联系

尽管EA和软件系统架构的关注点不同，但它们之间并非割裂，而是存在着紧密的层级和指导关系。

首先，EA为软件系统架构提供了战略输入和顶层约束。 企业架构中的应用架构部分，会描绘出企业需要哪些应用系统来支撑业务运作，这些系统之间大致的交互关系是怎样的，以及它们应该遵循哪些技术标准和原则。这就好比城市规划规定了某个地块可以建造商业楼宇，并给出了限高、容积率等指标。那么，具体到这座商业楼宇（软件系统）的设计时，就必须在这些宏观指导下进行。

我一直强调"业务驱动IT"，EA正是这一理念的集中体现。它确保我们开发的每一个软件系统都不是孤立的技术产物，而是服务于企业整体战略目标的有机组成部分。软件系统架构师在设计具体系统时，需要理解并遵循企业架构给出的方向和蓝图。

其次，软件系统架构是EA中应用架构和技术架构的具体落地和细化。 EA规划出的应用蓝图，最终需要通过一个个具体的软件项目来实现。例如，EA可能规划需要一个"客户关系管理平台"，而这个平台的软件架构则会详细定义其模块（如销售自动化、服务管理、营销活动）、技术选型（如采用微服务架构、选择特定的数据库和中间件）、接口设计等。可以说，没有具体的软件系统架构实践，EA就容易沦为空中楼阁。

最后，企业架构中的4A架构和软件架构中的4+1视图有明显的对应关系。对于企业架构思想融入到软件架构中，即真正对软件架构层面的工作进一步整合，减少在系统分析过程中从现实业务层面来抽象IT层面的脱节。改变传统软件架构仅仅考虑实现层面和技术层面的问题。对于引入方法和具体内容，还是从软件架构的一些核心内容来谈。

图片

对于传统的RUP方法强调用例驱动，架构为核心。对于用例驱动在架构层面首先有全局的用例模型，很多时候我们没有考虑如何真正建立全局用例模型，而结合业务建模可以看到仍然是流程分析，子流程，业务功能逐级展开后形成全局用例模型，那么全局用例模型就不简单是用例图能够涵盖的，全局用例模型通过流程驱动真正融为一个整体。

再回来看逻辑视图，对于逻辑视图现在我们更喜欢基于领域模型的方式来分析逻辑视图，对于逻辑视图建议仍然是不要一下进入到具体的类图和类关系图层面，而更加重要的还是理清楚核心的业务对象模型和对象间依赖，关联关系。可以从用例建模中识别核心业务对象并进行对象建模，形成核心的逻辑视图。

用例视图偏动态的流程和业务功能，而逻辑视图偏静态的业务对象和数据模型。这是架构设计关注的两个核心内容，在这个完成后带来另外一个问题即组件如何划分？可以讲我们现在进行架构设计划分组件的时候往往并没有深入的去考虑这个问题，只是给出高内聚松耦合的大原则。这也是在模块划分我一直考虑需要引入传统的类似CRUD矩阵分析等方法的原因。

对于组件的划分，从原来的流程和数据两条线再来分析组件划分方法可以看到，可以根据大的业务流程阶段，子流程来划分组件，不通的阶段或子流程划分为不同的组件，如供应商协同，招投标，合同管理，采购管理等。也可以根据核心的业务对象来划分不同的组件，如采购订单对应采购管理，合同对应合同管理，请购单对应请购管理等。不论是哪种方法最终要达到的目的都是减少组件间的交互和接口，很多时候组件划分工作不是一次就完成的而是需要通过反复的迭代，比如为了减少集成接口可能将某个业务功能从组件A移动到组件B等。对于组件划分的分析包括了组件划分完成后组件和组件间的接口和集成分析，组件和数据间的关系和CRUD分析，系统级流程在多组件间的协同和交互模拟等。而这可以看到正是开发视图和进程视图要解决的问题。

前面这些都分析完成后，自然引入集成架构和集成视图的概念，即组件划分完成后需要考虑组件间有哪些接口，接口识别仍然是前面跨组件系统分析交互点，接口识别清楚后可以画出完整的系统内组件集成架构。跨组件业务协同流程等。这些内容仍然都是架构设计的核心，否则分解到每个组件设计的时候出现只见树木不见森林的情况。不清楚组件在整个系统中的具体位置。

这些都清楚后才应该过渡到物理视图层面，物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点；我们希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

从前面整个分析设计可以看到基本没有谈到技术框架，架构分层模型等内容，也再一次说明了架构设计重点在功能性架构和核心领域逻辑，而不是一开始就陷入到分层技术架构模型中。只有把前面的内容都搞清楚了才能给更好的考虑如何建立业务系统本身需要依赖的技术平台。

在我看来，引入企业架构的思想，能够极大地提升软件架构设计的系统性和前瞻性，避免传统软件架构往往只关注具体实现和技术细节，而与业务需求脱节的弊病。

区别：视角、范围与关注点

图片

理解了联系之后，我们再来看看EA与软件系统架构的主要区别，这能帮助我们更清晰地把握各自的定位和职责。

一个很形象的比喻是，企业架构关注的是"森林"的健康与生态平衡，而软件系统架构关注的是"树木"的茁壮成长。 我们既要确保森林的可持续发展（EA），也要保证每一棵树都能汲取养分、抵御风雨（软件系统架构）。

在我早期的文章中，曾提到过："为了区分高层架构(包括多个应用的总体架构）和底层架构（针对单个业务系统的架构），前者采用企业架构中的应用架构这个词，后者采用系统架构这个词以进行区分。" 这也从一个侧面反映了两者在层级和粒度上的差异。

总而言之，企业架构（EA）与软件系统架构是既有区别又紧密联系的两个概念。EA从企业整体战略出发，提供顶层设计和指导原则，确保IT与业务的协同；而软件系统架构则在EA的框架下，专注于单个系统的设计与实现，确保系统能够高效、可靠地满足业务需求。

一个成功的IT体系离不开这两个层面的有效配合。缺乏清晰的EA指引，软件系统很容易各自为战，形成新的"竖井"和"孤岛"，难以发挥整体效能；而没有扎实的软件系统架构能力，再宏伟的EA蓝图也难以落地生根。

在IT行业，如果你原来是一个软件系统的架构师，那么应该逐步抽象提升你的企业架构规划设计能力，能够让你跳出单个系统视角具备企业级的业务和战略驱动的架构思维能力；反之，如果你原来是要给EA企业架构规划师，那么更应该熟悉下软件工程和单个IT系统的面向对象分析和设计，这样可以让你的EA架构规划更加具备可落地的实际操作性。

我们既要有"抬头看路"的企业架构思维，理解业务、洞察全局；也要有"低头拉车"的软件架构能力，精通技术、关注细节。只有这样，我们才能真正利用架构的力量，为企业创造持续的价值。

解决方案架构：解决特定问题，如同做一个片区规划

最后我们来谈谈解决方案架构（Solution Architecture）。这个概念在我的文章里没有直接定义，但我在《从售前解决方案谈思维逻辑》和《对IT项目售前解决方案制作的一些思考》里，其实已经把它的本质讲清楚了。解决方案架构，顾名思义，是为了解决一个特定的业务问题而提出的“一揽子方案”。

它介于企业架构和系统架构之间。我们还用城市规划的例子来比喻。现在，城市里有一片老城区，交通拥堵、设施陈旧，市民怨声载道。市政府决定要改造这片区域，解决这些问题。这时候就需要一个“老城改造解决方案”。这个方案可能涉及到拆除一些旧楼（下线老系统）、新建一些道路（构建新的集成链路）、引入新的公共设施如学校和医院（上线新系统）、改造地下管网（优化基础设施）等等。

这个“老城改造解决方案”就是解决方案架构。它不是规划整个城市，也不是设计某一栋楼，而是聚焦于一个特定的问题域，整合各种资源和能力，给出一个能落地的、完整的答案。

图片

image

解决方案架构师通常更贴近业务和客户。他需要深刻理解业务痛点，然后从企业现有的系统（应用架构）、可用的技术（技术架构）以及需要新建的系统能力中，进行选择、组合和设计，形成一个既能满足业务需求，又符合企业架构规范，同时在技术上可行的方案。它可能涉及多个系统架构的协同工作。

可以讲，解决方案架构更像一个“战术”层面的架构，它要确保我们打赢一场具体的“战役”。比如，我们要上线一个电商平台，这个“电商解决方案”就需要考虑如何整合已有的CRM系统、ERP系统，如何新建商品中心、订单中心，如何利用云平台的技术来保证高并发等等。它把企业架构的宏观战略，转化为了可以指导多个系统架构设计的具体行动计划。

总结：不同视角，不同职责

好了，聊到这里，我们再来总结一下这几个架构的区别：

• 企业架构：站位最高，是战略家，如同做城市规划，关注的是整个企业的业务与IT的长期协同发展，确保方向正确。
• 解决方案架构：承上启下，是战术家，如同做片区改造，关注的是如何整合资源解决特定的业务问题，确保战役能打赢。
• 系统/软件架构：最为具体，是建筑师，如同盖一栋楼，关注的是单个系统的内部设计和实现，确保楼能盖得又快又好。

这三者形成了一个从宏观到微观的完整体系。企业架构定义了“做什么”（What），解决方案架构定义了“怎么做”（How），而系统架构则负责把“怎么做”具体落地实现。它们不是相互孤立的，而是一个层层分解、相互衔接的关系。一个优秀的企业，需要这几种角色各司其职，紧密配合，才能让IT真正成为业务发展的强大引擎。

希望今天的分享，能让你对这些“架构”有一个更清晰的认识。