By 高焕堂

misoo.tw@gmail.com

重要参考文章

  • <<智慧化潮流的敏捷顶层设计方法论>>

内容

  • 前言
  • 认识EA框架：以ToGAF为例
  • 认识SoS思维(视角)
  • 顶层设计方法与范例：以数字家庭为例
  • 结语：从顶层设计衔接到中层设计        

[-1-]   [-2-]   [-3-]

 

1. 前言

       智慧城市的范畴跨越了许多不同的业务区块(Business Area)、产业技术和专业知识，又深度依赖信息化技术。由于，各业务区块或产业(如数字家庭、医疗服务、公共交通、食品安全等)的信息化应用视角和深度并不尽相同，所以各业务区块(或产业)各有其独特视角的顶层设计(Top-Level Architecture Design)来呈现其特殊需求是常见的。在本文里，将针对数字家庭业务区块为范围，举例说明其顶层设计的技术与方法。


 图-1  数字家庭的情境(此图摘自weibo.com/cne)

       一般而言，智慧城市的顶层设计并非完全是<由上而下＞(Top-Down)进行规划的；而是偏向于＜从中间往上＞(Middle-Up)进行的。例如，常见步骤是：

Step-1. 各业务区块先分头(同时)进行顶层设计；例如，进行数字家庭、医疗服务、公交车三个产业(区块)的顶层设计蓝图。
Step-2. 将上述三份顶层设计蓝图，同时呈交给市政府。
Step-3. 市政府审核上述三份蓝图，仔细核对其未来可能重复投资的部分；然后展开协调。
Step-4. 市政府审核上述三份蓝图，仔细核对其可能违背互联互通的障碍部分；然后展开协调。
Step-5. 一旦协商成功，并修正蓝图了；上述三份蓝图就合并成为智慧城市顶层设计蓝图了。
Step-6. 基于此智慧城市顶层设计蓝图，再将其它区块的顶层设计蓝图逐一合并进来；智慧城市的顶层设计蓝图就会健康成长了。

       智慧城市的各业务区块深度依赖信息化系统来互联互通，所以各区块采用企业架构(Enterprise Architecture，简称EA)的系统框架方法来呈现其信息化系统架构，成为其区块顶层设计的核心，是一种有效的途径。 这个顶层设计就是上述Step-1所说的产业(区块)的顶层设计蓝图。例如，DoDAF和ToGAF都是流行的EA框架。
       在本文里，就基于SoS(System of Systems)视角，搭配DoDAF/ToGAF框架，来举例说明如何规划刚才Step-1所述的产业(区块)顶层设计蓝图。

2. 认识EA框架：以ToGAF为例

       起源于1995年美国DoD的TAFIM (Technical Architecture Framework for Information Management )。TAFIM是以信息化管理(Information Management)和技术架构(Technical Architecture)为主轴；其目的是让不同业务区块的系统(技术)架构设计产出的蓝图文件能够像中国秦汉随唐时期的<书同文、车同轨、诗同形＞，让各区块可以相互读懂对方的蓝图，以利于核对，消除信息孤岛和重复投资；并促进互联互通。所谓架构框架(Architecture Framework)就是规范架构文件的内容形式(What)，但是并不规范你如何(How-to)进行架构设计。例如，唐诗的七言绝句，只规范一首诗的形式(格式)必须4句各7个字，而且符合韵律。至于该如何(Ｈow-to)去创作一首诗，它并不规范，人人自己选择How-to。
       国际标准机构The Open Group基于TAFIM而制定了ToGAF框架。不过，它又另外制定了ADM(Architecture Development Method)方法，提供一套迭代(Iterative)式开发流程，来规范您如何(How-to)设计、评估、并建立有效的架构设计(蓝图)。此ADM开发方法，就如下图所示：


 图-2  ToGAF的ADM开发方法 

       ADM包含了9阶段的迭代式流程。将它对应到我们的战略、战术概念，如下图：


 图-3  ADM方法与战略、战术概念的对应

       顶层设计是以愿景(Vision)而中心，而设计出策略(战略)性的规范。如下图所示：


图-4  从SoS视角来思考业务架构和系统架构

       上图是从SoS(System of System)视角来构思策略(战略)层级的架构设计。在下一节里，会详细介绍这SoS的概念、视角和内涵。从SoS视角而观之，业务架构与系统架构两者其实是一体的两面，如太极图的两仪。如下图5所示：


 图-5  业务架构和系统架构两者是一体的两面

       基于SoS概念和业务合作观点；可规划出这业务区块里的许多组织单位之间的业务合作(Collaboration)关系，就成为顶层设计(蓝图)里的业务观点(Operational View)了。同理，基于SoS概念和系统互动观点；可规划出这业务区块里的许多系统单元之间的信息互动(Interaction)关系，就成为顶层设计(蓝图)里的系统观点(System View)了。接着，再基于SoS概念和网络通信观点；可规划出网络通信机制如何支撑系统单元之间的信息互动，就成为顶层设计(蓝图)里的通信观点(Communication View)了。
       然后，将上述三个观点，依循EA框架(如DoDAF或ToGAF)的规范描述出来，整合而成的架构设计文档，就成为这业务区块的顶层设计(蓝图)了。如下图所示：


图-6  规划出符合EA规范的顶层设计蓝图

       针对各业务区块而进行各自的顶层设计。这些区块性的顶层设计只是手段，其目的是要产出各自的蓝图，然后汇合、审核、协调而融合成一个整体的智慧城市顶层设计蓝图。一旦整体城市的顶层设计出炉了，就能回头来修正各业务区块的顶层设计，让各区块顶层设计都不要违背城是顶层设计。于是，上下两层(组织层与系统层)和谐兼容的顶层设计，总合起来才是真正完整的智慧城市顶层设计了。

3. 认识SoS思维(视角)

3.1  SoS思维的特性

       所谓SoS思维(或视角)，就是基于SoS之概念(Concept)而去看待我们周遭的复杂系统。依据Krygiel, A.J.对SoS的定义：

「一群不同的系统相互连结起来，而产生个别所无法达成的整体效果。」
(A set of different systems so connected or related as to produce results unachievable by the individual systems alone.)

       一个SoS有发挥其特有功能和效果，必须仰赖小系统之间互相协调与合作。尤其小系统之间的信息交换是发挥SoS整体效果之基础。SoS的特性包括：个别系统都能独立运作与管理、可分布于各地方、可各自成长，但是一旦连结起来，就会呈现出整体的特殊效果。兹说明如下：

  • Operational Independence (运作独立性) – 个别系统一旦脱离了整体之后，它具有独立运作之能力。
  • Managerial Independence(管理独立性) – 个别系统具有自治能力，它的独立行为与整体行为并无关联。
  • Evolutionary Development(持续演化性) – 在运作过程中，它会不断地修正其功能、行为和目标。
  • Emergent Behavior(整合而涌现之行为) — 一旦连结起来，就会呈现出来的整体行为。例如飞机，所有个别系统都正常运作时，整个SoS系统(即飞机)能飞，但是个别系统都不能飞。
  • Geographic Distribution(异地分散性) — 分布于各地方，但会互相沟通与合作。

3.2 　SoS思维的比喻

       俗语说：「横看成岭侧成峰」，一个复杂系统若以不同角度去看它，可能会看到许多不同的SoS。例如去看一个篮子里的三个鸡蛋时，至少有两个不同观点：

观点1. 如果每一颗鸡蛋都是一个系统，则三颗鸡蛋可能组成一个SoS系统；这是鸡蛋观点下的SoS系统。
观点2. 每一颗鸡蛋里面都有一颗蛋黄，则三颗蛋黄可能组成另一个SoS系统；这是蛋黄观点下的SoS系统。

       由于两着蕴含着密切的关系，所以在顶层设计图里，就将两项观点并列在一起，如下图：


 图-7  鸡蛋观点与蛋黄观点之SoS

       当我们习惯于以SoS思维来观察一个复杂系统时，你自然而然会基于多重观点(Multiple View)而观察到多个不一样的SoS系统。然而这只是观点的变换而已，事实(三个鸡蛋)并有改变，套用 爱因斯坦 相对论 里的「对称性」概念，我们可以说，上述的两个观点是对称的，两者背后蕴含有不变的本质，其紧密连系着这两个观点。
       这样分成两种SoS的优点是：无论是鸡蛋观点，或蛋黄观点，都属于整体观；也就是两种SoS的规划者心中都有三颗鸡蛋。 这样可避免将三个鸡蛋(小系统)各自规划、设计和建置，而产生信息孤岛的严重问题。其主要原因是，各小系统(单颗鸡蛋)开发者对整体的假设(因为看不到整体，所以只能猜测)都不相同，没有以整体为依归(With the whole in mind)，当然很难搭配出和谐的SoS了。所以，我们采取SoS思维而进行如上图7的分解法，则能确保其整体观，对于建构内涵多样化的智慧城市是极为重要的。
       现在，就将上述的一颗鸡蛋对应到一个<组织单位>，并将一颗蛋黄对应到各组织单位内部的<系统单元>，就得出三个观点的架构设计，如下图所示：


图-8  这就是上图6的顶层设计蓝图了

       其中的组织单位(即鸡蛋角色)又称为<业务单元>(Operational Node)，简称OPN；而系统单元(System Node, 即蛋黄角色)则简称为SYN。从组织层面而观之，看到组织层SoS，依循EA框架而叙述之，成为顶层设计的业务观点部分。从IT系统层面而观之，看到系统层SoS，依循EA框架而叙述之，成为顶层设计的系统观点部分。同样地，从网络通信层面而观之，看到通信层SoS，依循EA框架而叙述之，成为顶层设计的通信观点部分。
       这三部分统整起来，就是一个业务区块的顶层设计蓝图了。针对各业务区块而进行各自的顶层设计，然后汇合、审核、协调而融合成一个整体的智慧城市顶层设计蓝图。在上一节里已经说明过，一旦整体城市的顶层设计出炉了，就能回头来修正各业务区块的顶层设计，让各区块顶层设计都不要违背城是顶层设计。于是，上下两层和谐兼容的顶层设计，总合起来才是真正完整的智慧城市顶层设计了。

3.3  SoS思维的举例：数字家庭

       有其整体系统(大S)之任务(例如飞机的想飞)，为了达成这个任务，就必须各组件(即小S)之间能够合作无间。以此观之，顶层设计的特性是：

       ◎ 目的：漂亮完成整体之任务(Mission)
       ◎ 手段：规划组件(单位)间之美好合作(Collaboration)
       ◎ 状态：让SoS成为一个有机体，整体必须和谐(Harmony)

       例如，智慧城市就是一个大系统(即大S)，而城市里的<数字家庭>、<智能公交车>、<智能小区>等各都是一个小系统(即小S)。这些小S就像飞机的零件系统(如机翼、轮胎等)；而智慧城市就是大S(飞机)，其整体任务就是：想飞。那么，我们的顶层设计任务就是去规划这群小S之间的互相合作(Collaboration)关系，包括：

  • 该进行那些合作? 各项合作的任务是什么?
  • 各项合作需要哪些小S参与? 谁是主导者?
  • 合作过程中，需要哪些信息交换? 需要那些IT资源?
  • 等等

       在本小节里，兹举＜数字家庭业务区块>为例，来说明其组织层SoS、系统层SoS；以及其对应的三项观点：业务观点、系统观点和通信观点。等到下一节里，将会进一步详细说明此三项观点的内涵。

       基于SoS思维来看<数字家庭业务区块＞，首先看到组织层SoS，其包含许多<业务单元>(Operational Node，简称OPN)；例如，家庭本身是一个OPN，就称为<家庭OPN>。此外，与这业务区块相关的，还有<个人OPN>、<医院OPN>、<公交车OPN>和<小区OPN>等。如下图所示：


图-9  数字家庭(业务区块)的组织层SoS

       也许你会问到，不是要规划数字家庭吗? 为什么要含括家庭之外的医院、公交车呢? 答案是：信息化的家庭，必须随时与外界互联互通，才能提供良好的家庭服务。例如，<家庭OPN>必须请求<公交车OPN>的协助，才能获取自家门前的公交车站牌的最新车辆到站时间。所以，顶层设计必须规划这些相关OPN之间的合作情境，以便确保多方OPN之间可以互联互通。
       依据上图7的鸡蛋比喻，各个OPN(即鸡蛋角色)可能内含一个或多个<系统单元>(System Node，简称SYN)，于是可看出数字家庭业务区块的系统层SoS，如下图所示：


 图-10  数字家庭的系统层SoS

       愈是深度信息化，这些OPN愈是仰赖SYN来通信。所以，系统层SoS的目标是要去支撑和实现组织层SoS的信息交换。换句话说，OPN之间的通信(或信息交换)，其实是透过SYN之间的信息交换来完成的。OPN之间通信的规划是需求，而SYN之间的信息交换，则是来实践该需求。所以，系统层SoS必须确实支撑组织层SoS的通信需求，才是一个融洽和谐的顶层设计。如下图所示：


图-11  数字家庭顶层设计的三项观点

       所谓数字家庭业务区块的顶层设计，就是以数字家庭OPN为主导的SoS，让其它相关的OPN来协助数字家庭OPN来实现数字家庭业务区块的各项服务。数字家庭OPN为机头，带动其它OPN(如机翼等)一起实践整体任务(如飞上天)。能够实现这项目标的架构设计蓝图，就称为数字家庭(业务区块)的顶层设计了。然而，OPN之间的通信，是透过SYN之间的合作来完成的。所以，必须规划一个系统层SoS来支撑上述以数字家庭OPN为主导的组织层SoS，才能让其飞上天。