By 高焕堂

misoo.tw@gmail.com

 重要参考文章

 

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(异地分散性)：分布于各地方，但会互相沟通与合作。

2.　SoS概念与架构设计

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

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

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


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

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


图-2  SoS整体架构包含三个观点

       其中的组织单位(即鸡蛋角色)又称为<业务单元>(Operational Node)，简称OPN；而系统单元(System Node, 即蛋黄角色)则简称为SYN。从组织层面而观之，看到组织层SoS的架构设计，成为整体架构的业务观点部分。从IT系统层面而观之，看到系统层SoS的架构设计，成为整体架构系统观点部分。同样地，从网络通信层面而观之，看到通信层SoS的架构设计，成为整体架构的通信观点部分。这三部分统整起来，就是一个整体系统的架构设计蓝图了。如图-3所示。


图-3  基于SoS思维的架构设计

3.　SoS系统的范例

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

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

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

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

3.1 范例一

       例如图-3所示。这SoS是由<云端、家庭、移动终端)>三层组合的新型产品及服务模式。例如，让股票分析师、外语老师能在家里的智能电视里，执行他自己的应用软件，从家外的股票云平台取得股票数据，在家里分析之后，从智能电视将分析建议信息推送到手机的画面上。


图-4  在家工作股票分析师业务

       在智能家庭平台的建置中，开放智能家庭的标准软件接口，与当今的新兴移动互联网应用业务(如微信、Line等)紧密衔接，让智能家庭摆脱过去的被动接收信息，改变为主动推送信息到家人、社区等。以移动互联网对接的需求带动本产业的整体发展。试想，      让这些师字辈的智能型人物，在最温暖、最熟悉的客厅里跑自己的Android App，产生自己的智能数据，推送到自己的学生，获取收入。这是智能电视(家庭)的美好服务和商机。在自己的家里，跑自己的App，处理自己的数据，做自己的饭，泡自己的茶，服务自己的online客户。乃人生一大乐事也。

3.2 范例二

       此SoS系统范例的功能是：医院的病房里有人体健康状况检测传感器(Sensor)，检测数据立即传送到护士手里的平板电脑屏幕上。平板电脑会与医院信息系统(HIS, Hospital Information System)通信，取得必要的信息，例如随时向取得有关医生的手机的目前IP，然后发送最新信息到医生的手机上。如图-4所示。


图-5  医疗病房信息的实时推送系统

4.　SoS三个面向的关系

       前面提到了，图2里组织单位(即鸡蛋角色)又称为<业务单元>(Operational Node)，简称OPN；而系统单元(System Node, 即蛋黄角色)则简称为SYN。其中，组织层SoS里的OPN之间信息交换，大多会委托SYN来实现。例如，<家庭OPN>向<医院OPN>索取健康检测解析图表的信息交换，其实现方式是家人藉由<智能电视SYN>经由互联网向医院里的<云平台SYN>进行查询的。所以，系统层SoS是要去实践业务层SoS里OPN之间的信息交换。愈深度信息化的行业区块，其OPN之间的信息交换，愈是仰赖SYN来实现；对系统SoS的功能需求愈多，必要的投资也愈多。当这样的系统层SoS变得复杂了，因而整体架构设计里的系统架构(观点)和通信架构(观点)内涵也会愈复杂而多样化。
       从图-2和图-3可以看到，除了业务架构之外，还有一个通信架构。通信架构的必备职责之一是：支撑系统架构的任务。SYN之间的数据交换，大多需要经由通信单元的连结和传递。通讯单元(CN: Communication Node)之间的连结(Link)及数据传递(Data Transmit)格式及效能。
       由于通信封包的层级很多，通信结点(CN)的颗粒度的选择，常常因架构设计团队而不同。例如，智能家庭业务领域的架构设计团队选择的CN颗粒度，可能与公交车业务领域的架构设计团队所选择的CN颗粒度，并不相同。这项问题有各种化解途径。例如，事先订定一个样板，让各团队参考之；或事先约定；或者等到呈送到上级领导审核时，再来协商调整等等。

5.　结语

       基于SoS概念和业务合作观点(Operational View)了；可规划出此商业服务里各攸关组织单位之间的业务合作(Collaboration)关系，就成为整体架构设计(蓝图)里的业务观点了。同理，基于SoS概念和系统互动观点；可规划出此商业服务里各系统单元之间的信息互动(Interaction)关系，就成为整体架构设计里的系统观点(System View)了。接着，再基于SoS概念和网络通信观点；可规划出网络通信机制如何支撑系统单元之间的信息互动，就成为整体架构设计里的通信观点(Communication View)了。然后，依循上述三个观点，将架构的规范描述出来，整合而成的架构设计文档，就成为这商业服务的整体架构设计(蓝图)了。◆

~ end ~