1987 年，软件架构作为一门独立学科，尚处于萌芽阶段，多数开发者仅凭经验摸索前行，陈宇和团队虽然凭借丰富的开发经验，成功打造过多个项目，但在架构设计方法论的理论层面，尚未形成体系。
初次向秦奕阐述机场信息化系统构思时，陈宇采用了目前比较流行的结构化分析与设计方法，借助早期面向对象思想，将系统模块化分层，再佐以大篇幅自然语言文档。
这些方法确实能剖析系统部分特性，比如结构化分析能帮助系统开发者梳理业务流程，运用面向对象思想能帮助开发者进行数据封装与操作。
可在面对机场信息化系统这种规模庞大、结构复杂，且涉及多部门协同、实时数据交互的项目时，这些设计工具的弊端很快就暴露无遗，系统各模块间的动态交互、性能瓶颈，以及长远的运维需求，都难以通过这些方法全面展现。
秦奕作为几十年后重生回来的人，自然不允许陈宇继续用这些无法将系统全貌描述清楚的方法来设计。
前世比较成熟且主流的软件系统架构设计方法论是视点与视角方法论体系，这个体系以 1995 年计算机专家菲利普提出的 4 + 1 视图模型为发端，其首次运用如逻辑视图、进程视图等多个视图来描述系统，为后续 “视点与视角” 方法埋下灵感的种子。
在 90 年代末，全球最大的非营利性专业技术学会电气和电子工程师协会，简称 IEEE，基于菲利普的这套体系着手制定架构描述框架，最后在 2000 年发布了 IEEE 1471 标准框架，这个框架强调通过基于视点的视图，满足不同利益相关者的需求。
IEEE 1471 标准为这一体系的广泛传播奠定了基础。
此后，架构师们在 Ibm 等企业的大型系统项目中积累了丰富的系统架构经验，他们发现，传统的视图无法应对复杂系统的多维度需求，于是开始整合 “视点” 与 “视角” 的概念。
2005 年，尼克和伍德斯合着的《Software Systems Architecture: working with Stakeholders Using Viewpoints and perspectives》第一版问世，他们在这本书中正式提出 “视点与视角” 这一方法论。
后续 2011 年发布的 ISo\/IEc\/IEEE ，基于 IEEE 1471，吸收了“视点与视角”思想，将其纳入国际标准，作为架构描述的推荐实践，Ibm、微软等企业纷纷采用这一方法，用于云计算平台、金融核心系统等复杂系统的架构设计，有效解决了多团队协作的难题。
秦奕深知，只有引入这套方法论，才能精准构建机场信息化系统，打造出经得起时间考验的系统。
“视点与视角方法论？”陈宇听到这个陌生又内涵丰富的词，一时之间不太能明白其中的关键。
“对的。”秦奕详细解释道，“这个方法论的核心思想有两个，其中视点是针对特定利益相关者的关注点定义架构描述的模板和内容。”
“像业务人员主要关注流程，而开发者更关注模块，我们就可以定义一个业务架构来和业务人员沟通系统的功能特点，而用一个开发架构来与开发者讨论如何开发这个系统。”
“视角则是跨所有视点的通用关注点，需要在每个视点设计中同步考虑，一般来说一个系统设计中我们主要需要考虑的就是性能和安全视角。”
陈宇听后，点了点头：“那按你之前对信息化系统利益相关者的分析，涉及业务人员、系统管理者、运维团队、开发团队，这些都能作为视点？每个视点都会衍生出相关架构？”
“对的！” 秦奕继续说道，“不过，架构和利益相关者并非一一对应。有些利益相关者关注的内容较多，比如开发团队，既关注系统代码如何开发，也关注数据在系统中的流转，这就需要两个视图。”
“在我看来，从视点出发，机场运行控制中心可分为业务、逻辑、物理、部署、开发、数据这几个架构；从视角出发，有运行、安全这两个架构，而每一个架构通常都会回应一个核心问题。”
“业务架构要回答系统解决什么业务问题，为此，最终要产出对应的业务流程图和领域模型。业务流程图能直观展示业务流程，领域模型则梳理业务涉及的关键概念和关系。”
“逻辑架构反映系统由哪些组件组成，我们得为机场运行控制中心确定组件图和接口定义，让各个组件的功能和交互一目了然。”
“物理架构要明确系统部署在哪些硬件上，得出服务器清单、网络拓扑图。部署架构解决如何将软件映射到硬件。数据架构探究数据如何存储和流动，借助实体关系图、数据流图来呈现。”
“ ER 图？”陈宇听到这个名词又有点不太理解。
秦奕解释了一下：“实体关系图是漂亮国华裔计算机科学家陈品善在 1976 年提出的概念，这个图像能直观展示数据对象，也就是实体，以及实体间的关系，在数据架构设计里，是极为关键的工具。”
“就拿我们的机场运行控制中心来说，航班、旅客、工作人员，这些都是实体。”
说着，秦奕拿起笔，在草稿纸上勾勒起来。“比如航班，包含航班号、起降时间、出发地、目的地等属性；旅客有姓名、身份证号、联系方式；工作人员则有工号、姓名、岗位。这些属性，都要在实体关系图里体现出来。”
“再看实体间的关系。一位旅客能预订多个航班，一个航班也会搭载多位旅客，这就是多对多的关系。而一个工作人员，只隶属于一个岗位，一个岗位却能有多个工作人员，这是一对多的关系。”
“通过实体关系图，把这些关系清晰描绘出来，我们就能更好地设计数据库表结构，确保数据存储和查询高效、准确。”
陈宇一边听，一边盯着草稿纸上的草图，若有所思：“这么说，借助实体关系图，就能搭建起符合机场业务的数据架构，让数据在系统里有序流动？”
“没错。” 秦奕点头肯定，“有了清晰的实体关系图，数据架构的设计就有了基础，后续的开发、运维工作也能更加顺利，我们在构建机场信息化系统时，一定要充分发挥 ER 图的作用。”
“明白。”陈宇应道。
秦奕继续说明道：“运行架构展示系统运行时如何交互，通过时序图、状态机图体现。安全架构则要防御威胁和漏洞，形成安全策略文档、渗透测试报告。开发架构关注如何组织代码和构建系统，要有模块划分文档、cI\/cd 流水线设计。”
“业务流程图应该是主要从我们收集到的业务人员那边的需求整合出来吧？”陈宇说道，“那我理解我之前设计的这个架构图就是业务架构。”
秦奕微微点头：“你之前设计的架构图有业务架构的影子，但按照视点与视角方法论，咱们还得进一步完善。不仅要更精准地梳理业务流程，还要深入挖掘业务背后的逻辑，结合其他架构，打造出全面、高效的机场信息化系统架构。”