| 写在前面
在数字化转型工作当中，我们经常会听到以下说法：
产品负责人说：现在的业务架构太复杂，需要仔细梳理下。
技术领导说：这个项目很复杂，需要做下系统架构方案评审。
研发经理说：这次秒杀活动访问量非常大，需要用到高并发架构方案。
一线研发说：互联网大厂都会用到微服务架构，我要学学微服务架构设计。
上面提到的架构到底是指什么？这些说法究竟是对还是错？其实上面的说法都是对的，只是采用的视角不一样。
| 架构的定义
关于“架构”，ISO/IEC 42010：2011给出了定义：一个系统在其环境中的基本概念或属性，体现在其元素、关系及其设计和演化的原则中。架构主要包含3个组成部分，如图所示。
延展：ISO/IEC所给出的这个定义，不仅仅适应于我们所探讨的“架构”，我们在思考和解构任何“复杂系统”时，都可以参考。
| 架构视点、视角、视图的概念定义
架构理论是面向复杂系统管理的方法论，复杂系统涉及多方利益相关者，如客户、产品经理、研发、销售、运营和管理层等。由于背景和认知差异，每个人看待系统的角度和方法都不尽相同。为控制复杂度，为不同角色设计特定的架构描述物。通过分类和定义，让每种架构描述都有其侧重点，让每个利益相关者能快速获取他们最关心的信息。
为了实现这一目的，我们首先需要理解架构“视点”、“视角”、“视图”的概念与关系。
在架构设计中，架构视点、视角和视图是三个相互关联且重要的概念，它们共同构成了对系统架构的全面理解和描述。
1. 架构视点（Architecture Viewpoint）
架构视点是指约束规定视图的展示内容，可以扩展成模板或模式的形式，从特定观众角度来构建其所能理解的视图。它起源于视图与视角架构框架，如“4+1”模型的扩展形式，主要适用于企业应用架构。
使用架构视点，能够反映出不同利益相关者的关注点，进而全面而有效地定义IT系统所需体现的架构视图。视点定义了一组用于创建视图的模式、模板和规范，包括视图范围、元素类型、受众、受众的专业技能、关注点的范围以及细节等级等内容。
2. 架构视角（Architectural Perspective）
架构视角是形成架构视图的立足点和对应的视野。它是一组架构活动、手段和指导，用于确保系统展现特定系列的相关质量属性，如性能、可靠性、安全性等。这些属性需要跨多个系统的架构视图来考虑。
架构视角补充了视点在描述系统质量属性方面的不足。通过架构视角，可以识别重要的质量属性，分析视图，并做出架构设计的决定来修改和改善视图。同时，它还提供了架构策略、问题和缺陷的说明，以及检查列表，帮助确保架构设计的全面性和质量。
3. 架构视图（Architecture View）
架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。它是构建和使用某视图的规约的描述，通常采用一个适当的模式或模版的形式。
根据关注点的不同，架构视图可以分为多种类型，如逻辑架构视图、物理架构视图、开发架构视图、运行架构视图等。每种视图都从不同的角度描述了系统的特定方面，共同构成了对系统架构的全面描述。
架构视图通过模型来进行表述，为不同的干系人根据各自针对架构的关注点而分别提供描述。由于角色和分工不同，软件架构是一个复杂的整体，而利用多重软件架构视图的方法，可以一次只围绕少数概念和技术展开，分别着重研究软件架构的不同方面，使问题得以清晰和简化，利于软件架构工程师完成架构设计工作。
4. 三者之间的关系
视点与视图：视点是定义视图内容的约束和规范，它决定了视图应该包含哪些内容以及如何展示这些内容。通过视点，可以构建出满足特定观众需求的架构视图。
视角与视图：视角是形成视图的立足点和对应的视野，它决定了从哪个角度或方面来观察系统并构建视图。不同的视角会产生不同的架构视图，从而全面反映系统的各个方面。
视点、视角与架构：视点和视角共同作用于架构视图的构建过程中，确保系统架构的全面性、有效性和质量属性。通过结合不同的视点和视角，可以构建出满足多种需求和目标的架构视图体系。
综上所述，架构视点、视角和视图是架构设计中不可或缺的三个概念，它们相互关联、相互作用，共同构成了对系统架构的全面描述和理解。
4A：
业务架构（BA，Business Architecture）
应用架构（AA，Application Architecture）
数据架构（DA，Data Architecture）
技术架构（TA，Technology Architecture）
关于4A之间的配合关系，我们可以结合多套理论知识体系及实践感悟，融合输出了业务架构(BA)与数据架构(DA)、应用架构(AA)、技术架构(TA)之间的基本协作关系图，如下图所示。
图中的各个要素用圆圈表示，各个要素之间的连线表示要素间的关系。该图主要表达了5点。
围绕业务对象(Business Object):典型的业务对象有“产品”“客户”“合作伙伴”“合同”“订单”等，企业的实际业务都是围绕这些业务对象展开的，相应的业务架构、数据架构、应用架构也应该围绕“业务对象”来设计，这也会有利于企业架构各组成部分的整体协同。业务对象可以根据实际情况分出不同层次，分别进行定义和描述。比如产品从大到小可分出3个层次，如“产品族”“产品组”“产品”;比如合同可分出两个层次，第一层是“合同”，第二层根据合同的不同特点可分解为“销售合同”“采购合同”等。
业务架构(BA)整体牵头：总的来说，数据、应用、技术等都是为业务服务的，要想让其他要素服务好业务，那么首先需要先说清楚业务。在这四者中，业务架构起到整体牵头的作用；否则，各干各的，无法真正实现基于业务的整体协同，实际效果会很差。
数据架构(DA)全局拉通：数据已经成为一个重要的生产要素，各个企业需要沉淀企业级数据资产并挖掘数据价值、赋能业务。数据，尤其是“主数据”，会贯穿多个业务单元、多个业务环节，起到全局拉通的作用。
应用架构(AA)合理呈现：应用架构的主要作用是呈现。把业务对象所涉及的相关业务活动，通过线上化的方式呈现给业务用户，以便更高效地执行业务活动。
技术架构(TA)有效支撑：在业务架构牵头之下，形成与业务架构协同的数据架构、应用架构之后，需要技术架构进行统一支撑。
| 关于TOGAF
说到企业架构，不得不提大名鼎鼎的TOGAF，其大量参考了政府机构的企业架构理论，沉淀出一套更加通用的企业架构方法论。目前80%的福布斯排行榜前50名的企业，以及60％的美国500强企业，都在使用TOGAF理论改善自身的IT架构。这里重点说下TOGAF的4种视图类型：业务架构，应用架构，数据架构，技术架构。
业务架构：定义了为实现企业的业务战略，企业将自身业务结构化表达为全面的、多维度的抽象模型，包括商业模式、价值流、业务能力、业务流程、组织架构，以及它们与战略、产品、策略、项目执行、利益干系人之间的关系。 应用架构：定义了企业中的应用系统的结构和行为，这些系统之间的关系，以及它们如何与业务流程对接。 数据架构：定义了企业如何收集、存储、管理和使用数据，涉及到数据模型、数据管理、数据集成和治理的设计和实施。 技术架构：定义IT基础设施和技术组件的结构，通过它们可以支撑起企业对业务、数据、应用服务的需求，它们包括但不限于硬件、可部署的软件包、网络、技术中间件、通信设施、运算设施等。
| 架构视图的核心概念
每种架构视图都包含一系列核心概念，通过这些概念可以层层剖析整个业务系统，系统化地理解和管理整体架构，确保各个层面的协调与一致。
业务架构：商业模式，价值流，业务能力，业务流程，组织架构。
应用架构：应用服务，应用结构，应用交互。
数据架构：数据模型，数据库技术。
技术架构：软件部署，技术组件、基础设施。
通过视点、视图与视角，我们可以分离关注点，将复杂问题进行拆解，让每个局部的复杂度控制在一个可以接受的范围。同时，团队有了统一的架构认知体系，进一步促成了业务标准化，通过分离不变点与变化点，提炼出可复用的业务组件，快速响应业务需求变化。
最后，分享华为架构设计方法论PPT：（部分节选，详情下载阅读）
资料下载链接
请复制链接或识别二维码下载...
华为架构涉及方法PDF下载链接：https://pan.baidu.com/s/1TK_a3ZDnZwpFknQyHeGa8w?pwd=3ayb
PPT源文件已收录星球：数字藏经阁，面向会员开放下载~识别以下二维码加入星球~
转发此文到400人大群，朋友圈保留一天，留言索取PPT文件
点击加入知识星球获取全部资料（定期更新）
免责声明
为知识付费：加入星球...
原文解读章节属于本公众号原创，享有内容版权。根据网络搜索下载编辑整理部分文章版权归原作者所有，方案展示章节PDF\PPT等来源于各文库类平台，源头无从查找，仅供读者学习、参考，禁止用于商业用途。如有错误或对于文中所使用的图片、文字、链接中所包含的软件\资料等，如有侵权，请联系我们处理。
