12. 信息系统架构设计理论与实践

发表于 分类于

1 信息系统架构基本概念及发展

信息系统架构（ISA）是一个体系结构，它反映了一个政府、企业或事业单位的各个组成部分之间的关系，以及信息系统与相关业务、信息系统和技术之间的关系。

1.1 信息系统架构的概述

信息系统架构是对某类特定内容的信息进行统筹、规划、设计、安排等一系列有机处理过程的一个操作对象，由信息建筑师来加以设计结构、决定组织方式以及归类，并让使用者与用户容易寻找与管理的一项艺术与科学。

1.2 信息系统架构的发展

信息系统架构的发展经历了从无架构到有架构的演变过程，架构师在项目中扮演着重要的角色，负责架构的设计和演化。

1.3 信息系统架构的定义

信息系统架构仍在不断发展中，目前还没有形成一个统一、公认的定义。以下是几个较权威的定义：

  • 定义1：软件或计算机系统的信息系统架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
  • 定义2：信息系统架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。
  • 定义3：信息系统架构是指一个系统的基础组织，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。

架构是对系统的抽象，它通过描述元素、元素之间的关系来反映这种抽象。架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的内容。

架构设计时必须考虑硬件特性和网络特性，因此，信息系统架构与系统架构师二者间的区别其实不大。架构设计时在软件方面的选择性较之硬件方面，其自由度大得多。因此，使用“信息系统架构”这一术语，也表明架构设计师通常将架构的重点放在软件部分。

2 信息系统架构

2.1 架构风格

信息系统架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

2.2 信息系统架构分类

信息系统架构可分为物理结构与逻辑结构两种。

2.2.1 信息系统物理结构

按照信息系统硬件在空间上的拓扑结构，其物理结构一般分为集中式与分布式两大类：

  • 集中式结构：物理资源在空间上集中配置。
  • 分布式结构：物理资源在空间上分散配置。

2.2.2 信息系统逻辑结构

信息系统的逻辑结构是其功能综合体和概念性框架。逻辑结构是指信息系统各种功能子系统的综合。

信息系统逻辑结构的分类包括：

  1. 横向综合
  2. 纵向综合
  3. 纵横综合

2.2.3 信息系统架构的一般原理

信息系统架构的一般原理强调了信息系统架构在适应变化中的重要性。以下是该原理的关键点：

  1. 信息系统架构的复杂性
    • 信息系统架构比计算机体系结构、网络体系结构和数据库体系结构更为复杂，因为它不仅包含这些元素，还涉及大量人为因素。
  2. 信息系统架构的目标
    • 信息系统架构旨在全面考虑企业的战略、业务、组织、管理和技术，建立多维度分层次的、集成的开放式体系结构，提供灵活有效的实现方法。
  3. 信息系统架构的适应性
    • 信息系统需要具备较强的适应性，以应对环境变化，确保在环境变化时系统变化能力最小，同时不影响企业的正常运转。
  4. 信息系统架构的组成
    • 信息系统架构包含两个基本部分：组成成分和成分之间的关系。在环境变化时，架构中的关系可能变化较大，而成分变化较小。
  5. 信息系统架构的稳定性
    • 架构设计需确保在环境变化时，稳定部分支持变化部分，以实现系统的稳定性和适应性。
  6. 信息系统架构的重组
    • 通过重组，信息系统能够适应环境变化，具备一定的适应能力，这是信息系统架构的基本原理。

这些原理指导信息系统架构的设计和演化，确保系统在不断变化的环境中保持稳定和有效。

2.2.4 信息系统常用 4 种架构模式

信息系统架构模式是指信息系统中常用的结构模式，可以应用在系统设计时参考。

2.2.4.1 单机应用模式 (Standalone)
  • 描述：最简单的软件结构，运行在一台物理机器上的独立应用程序。
  • 特点：适用于小型或单用户系统。
2.2.4.2 客户机/服务器 (Client/Server) 模式
  • 描述：基于 TCP/IP 协议的进程间通信模式，客户端与服务器进行交互。
  • 特点：适用于需要集中处理和数据管理的应用。

三层C/S结构

  • 描述：分为表示层、业务逻辑层和数据层。
  • 特点：适用于需要复杂业务逻辑处理的应用。

MVC 模式

  • 描述：模型-视图-控制器模式，分为模型、视图和控制器。
  • 特点：有助于分离关注点，提高代码的可维护性。
2.2.4.3 面向服务架构 (SOA) 模式
  • 描述：基于服务的架构，强调服务的独立性和互操作性。
  • 特点：适用于需要高度模块化和互操作性的应用。

Web Service

  • 描述：基于Web服务的应用，强调服务的互操作性。
  • 特点：适用于需要网络互操作性的应用。
2.2.4.4 企业数据交换总线
  • 描述：企业应用间数据交换的公共通道。
  • 特点：适用于需要跨系统数据交换的应用。

这些架构模式和框架为企业信息系统的设计和实施提供了指导和参考。

2.2.5 企业信息系统的总体框架

信息系统的架构（Information System Architecture, ISA）是企业中具有丰富内涵和作用的体系结构。ISA 模型是多维度、分层次、高度集成化的模型，需要考虑企业中的四个方面：战略系统、业务系统、应用系统和信息基础设施。

2.2.5.1 战略系统

战略系统处于第一层，其功能与战略管理层次的功能相似，一方面向业务系统提出重组的要求。另一方面向应用系统提出集成的要求。

2.2.5.2 业务系统

业务系统处于第二层，属于战术管理层，业务系统在业务处理流程的优化上对企业进行管理和业务控制，应用系统则为这种控制提供计算机实现的手段，并提高企业的运行效率。

2.2.5.3 应用系统

应用系统即应用软件系统，指信息系统中的应用软件部分。软件按其与计算机硬件和用户的关系，可以分为系统软件、支持性软件和应用软件，它们具有层次性关系。

2.2.5.4 企业信息基础设施

企业信息基础设施（Enterprise Information Infrastructure, EII）是指根据企业当前业务和可见的发展趋势，及对信息采集、处理、存储和流通的要求，构筑由信息设备、通信网络、数据库、系统软件和支持性软件等组成的环境。企业信息基础设施由三部分组成：

  • 技术基础设施：由计算机、网络、系统软件、支持性软件、数据交换协议等组成。
  • 信息资源设施：由数据与信息本身、数据交换的形式与标准、信息处理方法等组成。
  • 管理基础设施：企业中信息系统部门的组织结构、信息资源设施管理人员的分工、企业信息基础设施的管理方法与规章制度等。

这些组成部分共同构成了企业信息系统的总体框架，为企业提供了全面的信息化解决方案。

3 信息系统架构设计方法

3.1 ADM 架构开发方法

3.1.1 TOGAF 概述

TOGAF (The Open Group Architecture Framework, TOGAF) 是一种开放式企业架构开发标准，它为架构、方法论和企业架构专业人员之间的沟通提供一致性保障。

3.1.2 ADM 架构开发方法

ADM (Architecture Development Method, ADM) 为开发企业架构所需要执行各个步骤以及它们之间的关系进行详细的定义。
ADM 是一种架构开发方法，分为准备阶段、架构愿景阶段、业务架构阶段和信息架构阶段。

3.1.2.1 ADM 的架构开发阶段

TOGAF 中最为著名的一个 ADM 架构开发的全生命周期模型将 ADM 全生命周期划分为准备、需求管理、架构愿望、业务架构、信息系统架构(应用和数据)、技术架构、
机会和解决方案、迁移规划、实施治理、架构变更管理等十个阶段，这十个阶段是反复迭代的过程。

3.1.2.2 ADM 方法各阶段的活动

每个阶段都需要根据原始业务需求对设计结果进行确认。

3.1.2.3 ADM 方法的详细说明

以下将重点从目标、 步骤 、 输入和输出几个方面对 ADM 环中的每个阶段进行了分析和描述。

3.1.2.3.1 准备阶段
  • 目标：对企业架构活动的背景和环境进行审查
  • 输入：TOGAF 架构框架资料等
  • 步骤：
    • 确定治理和支持框架
    • 定义架构原则
    • 选择架构工件和工具
    • 落实相关架构工件
  • 输出：企业架构的组织框架
3.1.2.3.2 架构愿景阶段
  • 目标：创建架构愿景
  • 输入：业务原则、业务目标和驱动力
  • 步骤：
    • 获取愿景和业务需求
    • 制定架构开发周期
    • 定义架构原则
    • 定义架构工件
    • 定义架构工件
    • 定义业务转型的准备情况
    • 评估业务转型的准备情况
    • 输出：架构愿景阶段的工件
3.1.2.3.3 业务架构阶段
  • 目标：描述业务架构
  • 输入：架构工作要求书、业务原则等
  • 步骤：
    • 描述业务架构
    • 开发业务架构
    • 执行差距分析
    • 选择和开发架构组件
    • 确定与架构相关的业务需求
    • 确定与架构相关的人员和技术
    • 输出：业务架构工件
3.1.2.3.4 信息架构阶段

信息系统架构设计阶段活动的详细说明(数据架构)

  • 目标：定义信息架构
  • 输入：业务需求书、业务目标等
  • 步骤：
    • 定义主要的信息类型和处理的应用系统
    • 确定数据架构设计和应用架构设计
    • 定义业务运行所需的数据源和数据类型
    • 定义组件
    • 执行差距分析
    • 评估整个架构的影响
    • 输出：信息架构工件

信息系统架构设计阶段活动的详细说明(应用架构)

  • 目标：定义处理数据并支持业务运行所需的各种应用系统
  • 输入：业务需求书、业务目标等
  • 步骤：
    • 选择参考模型、视角和工具
    • 开发基线应用架构
    • 开发目标应用架构
    • 定义组件
    • 确定业务交互需求
    • 定义应用的约束
    • 定义应用的工件
    • 确定应用的工件
    • 输出：应用架构工件
3.1.2.3.5 技术架构阶段
  • 目标：定义技术架构。
  • 输入：架构工作要求书、技术需求等。
  • 步骤：
    • 选择参考模型、视角和工具
    • 开发基线技术架构
    • 开发目标技术架构
    • 定义技术需求
    • 定义技术组件
    • 确定技术约束
    • 评估技术需求
    • 定义技术工件
    • 确定技术工件
    • 输出：技术架构工件。
3.1.2.3.6 阶段E-机会及解决方案

这是第一个直接关注实施的阶段，该阶段主要描述确定目标架构交付物（项目、程序或文件）的过程。

3.1.2.3.7 阶段F-迁移规划

该阶段通过制订一个详细的实现和迁移计划完成从基线架构向目标架构的转变。

3.1.2.3.8 阶段G-实施治理

该阶段定义了实施项目的架构约束，提供项目构建的架构监督，产生一个架构契约。

3.1.2.3.9 阶段H-架构变更管理。

该阶段确保能够以一种可控制的方式对架构的改变进行管理。

3.1.2.3.10 需求管理

架构需求管理适用于 ADM 的所有阶段，这是一个动态的过程，完成对企业需求的识别、存储并把它们插入或取出相应的 ADM 阶段。需求管理是 ADM 流程的中心。处理需求变化的能力对于 ADM 过程是非常重要的，架构通过其天然处理不确定性和变化的能力在涉众诉求之间架起桥梁并交付一个可实践的解决方案。

3.1.2.3.11 建立架构活动的范围。

ADM 方法不能够确定架构活动的范围，这必须由企业自己确定。需要限定架构活动范围的原因与以下因素有关：

  • 创建架构的团队所具备的组织权力；
  • 需要在架构中实现的目标和干系人的诉求；
  • 可利用的人、资金以及其他资源。

选定的架构活动范围理论上应该支持企业中的架构师高效地完成治理和整合工作。这需要一套一致的“架构分区”,确保架构师不会从事重复劳动或冲突的活动。这同样需要定义重用和多个架构分区间的服从关系。

可以从下面四个维度对架构活动范围的限定。

  1. 企业范围或焦点
  2. 架构领域
  3. 详述垂直范围或级别
  4. 时间周期

3.2 信息化总体架构方法

3.2.1 信息化的一般概念

  • 信息化的概念起源于20世纪60年代的日本，首先是由日本学者梅榎俊夫提出来。信息化是指培育、发展以智能化工具为代表的新的生产力并使之造福于社会的历次过程。
  • 信息化生产力是迄今人类最先进的生产力，它要求具有先进的生产关系和上层建筑将随之改变。
  • 信息化建设指品牌利用现代信息技术来支撑品牌管理的手段和过程。
  • 信息化特征主要体现以下 6 种特征：1易用性、2健壮性、3平台化、灵活性、拓展性、4安全性、5门户化、整合性、6移动性。

3.2.2 信息化工程建设方法

3.2.2.1 信息化架构模式
  • 信息化工程建模方法一般有两种模式：数据导向架构、流程导向架构。
  • 数据导向架构关注数据对象本身，流程导向架构关注数据对象之间的关系。
  • SOA 本身就是关键方法和技术，关注端到端流程整合，以及架构对流程变化的适应度。
3.2.2.2 系统架构设计过程

系统架构设计过程包括：系统规划、系统分析、系统设计、系统实施、系统运行和维护。

  1. 系统规划阶段的任务是对企业的环境、目标、现行系统的状况进行初步调查，确定信息系统的发展战略，对建设新系统的需求做出分析和预测。
  2. 系统分析阶段的任务是根据系统设计任务书所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑功能要求。
  3. 系统设计阶段的任务是根据系统说明书中规定的功能要求，考虑实际条件，具体设计实现逻辑模型的技术方案，包括系统概要设计和详细设计两个阶段。
  4. 系统实施阶段是将设计的系统付诸实施的阶段，包括计算机设备的购置、安装和调试，程序的编写和调试，人员培训、数据文件转换、系统测试与转换等。
  5. 系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规格对系统进行必要的修改，评价系统的工作质量和经济效益。
3.2.2.3 信息化工程总体规划的方法论

信息化工程总体规划的方法论包括：关键成功因素法（CSF）、战略目标集转化法（SST）、企业系统规划法（BSP）等。

  • 关键成功因素法：识别影响系统目标实现的关键成功因素，确定系统开发的优先次序。
  • 战略目标集转化法：将战略目标转化为管理信息系统的战略目标。
  • 企业系统规划法：通过自上而下地识别系统目标、企业过程和数据，然后对数据进行分析，自下而上地设计信息系统。

4 信息系统架构案例分析

4.1 价值驱动的体系结构——连接产品策略与体系结构

4.1.1 价值模型概述

  • 价值模型概述：开发有目的的系统，其目的是为其利益相关者创造价值。
  • 价值模型核心特征：价值期望值、反作用力、变革催化剂。
  • 价值期望值：特定功能的需求，包括内容、满意度、实用性。
  • 反作用力：实现期望值的难度。
  • 变革催化剂：导致期望值变化的事件。

反作用力和变革催化剂称为限制因素，把这三个统称为价值驱动因素。

4.1.2 体系结构挑战

  • 识别限制因素：影响期望值的因素。
  • 评估影响程度：简单、中、高等级。
  • 制定策略：优化期望值，识别反作用力和催化剂。

总之，体系结构策略就是帆船的舵和龙骨，可以确定方向和稳定性。它应该是简短的高标准方向的陈述，必须能够被所有利益相关者所理解，并应在系统的整个生存期内保持相对稳定。

4.1.3 结论

价值模型有助于了解和传达关于价值来源的重要信息。它解决一些重要问题，如价值如何流动，期望值和外部因素中存在的相似性和区别，系统要实现这些价值有哪些子集、架构师分解系统产生一般影响的力，特定于某些背景的力和预计随着时间的推移而变化的力，以实现这些期望值。

价值模型和软件体系结构的联系是明确而又合乎逻辑的，可以用以下几点来表述：

  1. 软件密集型产品和服务的存在是为了提供价值。
  2. 价值是一个标准，它融合了对边际效用理解和诸多不同目标之间的相对重要性。
  3. 价值存在于多个层面，其中某些层面包含了目标系统，并将其作为一个价值提供者。
  4. 该层次结构中高于软件层面的价值模型可以导致其下层价值模型发生变化。这是制定系统演化原则的一个重要依据。
  5. 对于每一个价值值，价值模型都是同类的。暴露于不同环境条件的价值背景具有不同的期望值。
  6. 对于满足不同价值背景需要，系统的开发赞助商有着不同的优先级。
  7. 体系结构挑战是由环境因素自某一背景中对期望的影响引起的。
  8. 体系结构方法试图通过首先克服最高优先级体系结构挑战来实现价值的最大化。
  9. 体系结构策略是通过总结共同规则、政策和组织原则、操作、变化和演变从最高优先级体系结构方法综合得出的。

4.2 Web 服务在 HL7 上的运用-Web 服务基础实践框架

Health Level Seven(HL7) 是美国国家标准化协会 (ANSI) 认可的标准化开发组织中的一个，它正在全世界保健行业里运行着 (Level Seven引用了开放系统互连模型OSI 的最高层——应用层)。

4.2.1 HL7 模型概念

参考信息模型

HL73.0 版本基于参考信息模型（RIM）。RIM 包括：病例模型、信息模型、交互模型、消息模型和实现信息说明书。

消息结构

  • HL7 应用层软件之间的交互行为通过消息交换完成。
  • HL7 消息封装在 wrappers 内，通过 XML 描述。

交互

一次 HL7 交互就是信息特殊转移过程中的一次联合，一个触发事件就开始了消息的转移，应用软件进行接收和发送消息。

应用程序角色

HL7 里的每一个应用属于一个具体的应用程序角色。

Storyboard 描述应用程序角色、交互作用和信息交换。

4.2.2 体系结构

应用、web 服务下层结构、传输

4.2.3 开发 HL7 Web 服务适配器

步骤概述

  • 消息和数据类型的设计：设计可交换的消息、数据类型以及XSD表单。
  • 适配器模式的选择：选择适配器结构模式以适应HL7通信模式。
  • HL7 Web服务契约的开发：创建契约，用标准语言描述Web服务。
  • 产生Web服务Stub和代理的实现：一旦WSDL契约完成，创建Web服务Stub和代理服务器。
  • 开发适配器业务逻辑：添加逻辑支持适配器功能。

4.2.4 案例研究

  • 医疗信息系统（HIS）和实验室信息系统（LIS）之间的交互。
  • HIS 由两个子系统组成，LIS 由 Web 服务和业务逻辑组成。
  • 通信模式：发送消息负载“一附有确认信息一立即”。

图示展示了HL7 Web服务信息交换流程。

  • 客户机与医疗信息系统 HIS 通过业务逻辑、适配器和服务 Stub 进行交互。
  • 适配器负责将 HL7 消息转换为 SOAP 消息，并通过 Web 服务代理进行传输。
  • 实验室信息系统 LIS 接收 SOAP 消息，并通过适配器将其转换回 HL7 消息。

4.2.5 结论

  • HL7 用于协同工作创建的基层结构。
  • RIM 获得具体领域的信息模型，自动产生 XML 表单定义（XSD）。
  • 从理论到实践，HL7 并没有告诉我们如何构建和设计一个应用程序，而是当Web服务被调用时，本文提供的参考体系结构是一个相应的出发点。

4.3 以服务为中心的企业整合

4.3.1 案例背景

  • 航空公司信息系统运行多年，包括多个系统如订票系统、航班调度系统等。
  • 系统间信息共享不足，技术人员依赖流程图和代码理解系统。
  • 以 Ramp Control 系统为例探索以服务为中心的企业集成道路。

4.3.2 业务环境分析

  • 在航空业中，Ramp Coordination 指飞机从降落到起飞过程中的业务活动协调过程。
  • Ramp Coordination 流程因航班类型不同而异，包括 short turn around、arrival only、departure only 等。

4.3.3 服务建模

  • 推荐使用业务建模（Component Business Model）和面向服务的建模和架构（Service-Oriented Model and Architecture）两种方法。
  • Ramp Coordination 相关的服务模块和Ramp Coordination 流程相关的两个业务组件：Ramp Control 和 Ramp Coordination。
    1. Ramp Control：负责航班相关的业务活动。
    2. Ramp Coordination：负责航班相关信息的管理。

4.3.4 IT 环境分析

  • 现有系统包括多个大型信息系统，如订票系统、航班调度系统等。
  • 系统间接口复杂，信息交互类型和数据格式多样。

4.3.5 高层架构设计

根据需求和设计阶段的业务模型和现有IT环境调研结果，设计高层架构。

4.3.6 结论

  • 通过案例讲解了以服务为中心的企业集成的主要步骤和技术。
  • 随着技术不断发展，以服务为中心的企业集成方案将更简单高效。