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个字,而且符合韵律。至于该如何(How-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,才能让其飞上天。

( 請繼續閱讀… )

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