随着机场规模的不断扩大，运营复杂度日益增加，涉及的部门和机构众多，包括空管部门、地服公司、航空公司、海关、气象局等。
为了保障机场的安全、高效运行，协调各参与方的工作，机场引入了服务等级协议也就是 SLA 管理机制，通过制定详细的 SLA，明确各方的责任、服务标准、响应时间和数据交互规范，确保机场运营的各个环节能够紧密衔接。
“这就像是大家共同遵守的‘游戏规则’，只有这样，机场运营才能有条不紊。” 秦奕一边说着，一边翻看着收集来的资料。
陈宇点了点头，回应道：“没错，秦总我觉得可以先从内部部门入手，明确他们的职责和服务标准。”
于是，两人首先将目光投向了空管部门。
秦奕手指在键盘上快速敲击，调出机场信息化系统的相关架构图然后说道：“在信息化系统已经搭建得较为完善的时候，空管部门的航班雷达数据，理应通过专门的数据接口，借助信息化设备直接同步至控制中心系统。”
“这既能提升数据传输效率，还能减少人为干预导致的误差，要是遇到重大空域调整，依旧得提前 1 小时，通过加密数据通道，向控制中心发送经过数字签名的正式文件。”
陈宇一边记录，一边补充：“一旦做出航班延误或备降的决策，空管部门需在 15 分钟内，通过信息化系统内置的即时通讯模块，向控制中心推送通知，要是控制中心这边没有回应，理应用电话设备再次进行通知。”
“要是雷达数据传输出现异常中断，塔台需在 30 分钟内启动备用数据链路，并在 1 小时内，安排技术人员赶赴控制中心，协助恢复数据同步。”
在陆续梳理完地服公司和消防与医疗部门等内部部门的 SLA 之后，两人开始研究外部机构的协同规则。
秦奕说道：“航空公司对航班计划和动态信息了如指掌，计划变更要通过 AFtN 电报提前 2 小时通知，格式得符合 IcAo 标准。临时备降航班信息，要在着陆前 30 分钟电话通报，后续补发书面确认。”
“要是航空公司误报机型信息，导致停机位冲突，得承担全部廊桥维修费用。”
谈到海关和边检部门，陈宇表示：“国际航班停靠后，海关要在 45 分钟内完成旅客清关。要是延误超时，得书面说明原因，还要补偿机场额外的地服成本。双方每天通过加盖电子公章的电子清单，交换航班计划。”
为了确保通信和数据交换的顺畅，他们还制定了通信与数据交换规则。
“通信方式得按优先级排序，信息化系统内的即时通讯模块用于航班状态变更和应急事件，AFtN 电报传递航班计划等结构化信息，电子文档用于书面确认和清单交换。” 秦奕强调，“绝对禁止使用未加密的民用对讲机，传递敏感信息。”
为了监督 SLA 的执行，他们还建立了监督机制和冲突解决办法。
“机场运行控制中心操作员要在系统内记录每次 SLA 事件，系统会自动保存即时通讯模块的聊天记录，保存周期为 30 天备查。” 秦奕说道，“每月首个周一召开 SLA 合规会议，各部门通过线上论坛系统参会，并提交电子报告，有争议的事项投票表决。”
陈宇点头赞同：“要是发生违约争议，由机场总经理、国家空管部门代表和航空公司协会组成三方委员会裁定责任，赔偿以人工工时成本为基准计算。”
随后，他们对业务架构核心领域展开设计。
在航班运行管理领域，他们设计了航班计划引擎、动态监控看板等功能组件，规划了空管雷达数据到预警通知的数据流。
“关于业务领域数据流这部分我这里有点疑问。”陈宇说道，“我们除了业务架构之外，还有一个数据架构，数据架构里面应该主要就是处理数据流动的问题，这两个架构的数据流差别在哪里呢？”
“数据流确实是数据架构的核心内容，但在业务架构中提及数据流，体现了?业务与数据的双向驱动关系。”秦奕详细地给陈宇介绍了下两种架构下面数据流的不同关注点。
“我理解一下。”陈宇若有所思地回应道，“从业务架构的角度来看，数据流就像是业务流程的脉络，清晰地展示了数据如何在业务环节中流动，从而驱动业务目标的实现。”
“就像航班动态数据流，从雷达采集数据，传输到机场运行控制中心，再流向航空公司，这一过程直接支撑了航班准点率这一关键业务目标。要是脱离了数据流的描述，我们很难理解业务流程背后的数据支撑逻辑。”
秦奕赞同道：“没错。业务架构中的数据流，是站在业务活动的层面，回答‘为什么需要这些数据，以及这些数据如何服务于业务’的问题。”
“举个例子，当我们讨论旅客流量数据流从安检闸机流向机场运行控制中心系统，再到商业区时，我们关注的是如何根据旅客流量，合理调配服务资源，提升旅客体验，这背后反映的是业务目标对数据的需求，而不是数据本身的技术实现细节。”
随后，秦奕转向数据架构的内容，介绍道：“数据架构中的数据流，定位则完全不同。它关注的是数据在技术层面的实现，包括数据的存储、传输和处理的技术规范。”
“比如，空管系统通过一定的方式发送航班状态消息，要怎么才能保证这个消息不漏发也不重发，这描述的是数据如何在技术系统中流动，使用的是什么技术和数据格式，数据架构更像是一个技术蓝图，为数据的流转提供了技术支撑。”
陈宇一边记录，一边分析：“这么看来，业务架构中的数据流是从业务需求出发，自上而下地梳理数据的流向；而数据架构中的数据流，则是从技术实现出发，自下而上地构建数据的传输和处理体系。两者虽然关注点不同，但紧密关联。”
陈宇提出：“航班计划引擎要能处理长期和临时航班计划，检测时刻冲突，这对保障航班计划的合理性很关键。” 秦奕点头认可，并补充：“动态监控看板要整合多方数据，让航班位置和状态一目了然。”
两人又讨论了一阵，陈宇对不同架构里数据流的定位有了更清晰的认识，然后秦奕又跟他讨论了一下资源调度，应急指挥，?数据决策各领域的具体设计内容。
在业务架构整体跨领域的数据流方面，他们也确定了航班数据实体、资源数据实体等关键数据实体，规划了从输入层到处理层再到输出层的端到端数据流。
经过一番努力，业务架构的价值逐渐清晰，秦奕和陈宇看着设计成果，心中充满成就感，他们知道，距离打造出全面、高效的机场信息化系统，又近了一步。
不过业务系统只是整个架构设计的第一阶段，后续秦奕和陈宇还需要基于目前业务架构中梳理好的各个核心业务能力开始进一步设计逻辑架构、物理架构、部署架构、开发架构和数据架构等一系列内容。