By 高焕堂

misoo.tw@gmail.com
       

重要参考文章

内容

  • 什么是MCS模式(Pattern)
  • 从SoS视角领悟MSC模式
  • 以xMCS模式凸显SoS的主角
  • 应用于顶层设计<系统架构>上
  • 衔接到中层设计的<EIT造形>
  • 在敏捷迭代过程中的角色

前言

       在高焕堂老师提出的<敏捷顶层设计方法>里,其核心是<三一框架>,就是:

            一个EIT软件造形、一个MCS系统模式、加一层设计(中层设计)

       依据此三一框架,您可以建立您自己的顶层设计模式,选择您自己的开发工具,进而建立产出高质量的顶层架构设计。在本文里,将要介绍其中的重要元素:MCS系统(架构)设计模式。

 

1. 什么是MCS模式(Pattern)

       在互联网上,有许多云服务的供应端(Cloud Provider),简称云端;也有众多的云服务消费端(Cloud Consumer),简称终端。如下图所示:

图-1  典型的云&端系统架构

       在这种架构里,只有两项元素:云端(C)和终端(T)。如下图:


图-2  云&端架构的两项元素

       随着智能终端(如手机和平板)和物联网概念的流行,终端(T)又逐渐细分为两项:移动终端(Mobile)和感知终端(Sensor)。于是,总共含有三个元素:云端、移动终端和感知终端。通称为MCS系统架构模式。如下图所示:


图-3  MCS系统模式的三项元素

       其中,物联网比较偏重于感知端的数据采集,透过网络传输到云端去处理。如下图:


图-4  物联网的两项主要元素

       至于移动互联网,则比较偏重于移动应用,透过网络和云端来建立移动终端(或个人)之间的连结等等。如下图:


图-5  移动互联网的两项主要元素

       于是,Cloud、Mobile和Sensor成为现今的<云&端>系统架构里的基本元素。如下图:


图-6  MCS系统模式的基本元素

       有了这三项元素,再加上一些组合规律,就形成一个系统架构模式了。我们就称之为:MCS系统架构模式(System Architecture Pattern);简称为:MCS系统模式。

2. 从SoS视角领悟MCS模式

       基于SoS(System of Systems)的概念而观之,在当今的产业里,无论是云计算、物联网、移动互联网或车联网等,都是一种SoS。例如,下图-7所示的SoS系统就涵盖了<数字家庭>和<医疗健康>等不同的业务区块。


图-7  跨越不同区块的SoS系统

       此图是MCS模式的扩充型,从传统的视频播放功能来看,智能TV是属于终端。如果从家庭的信息推送角度来看,它可以是一朵<家庭云>(Family Cloud),属于云端。所以是MCS系统模式的扩充型,我们可称之为:xMCS系统模式。这里的”x”代表了这个智能电视新角色,含有亦云亦端的混合性角色。随着城市智能化的发展,这些SoS会逐渐成长,整合更多的小系统,持续扩大其规模和服务功能。如下图:


图-8  SoS系统的成长:城市智慧化的扩大发展

不仅仅是范围的持续扩大,无论是数字家庭或智慧城市,也会持续往深度发展。例如下图:


图-9  SoS系统的成长:城市智慧化的生根发展

从上述的图-7、图-8和图-9里,我特别偏重于<数字家庭区块>。于图-8里,往外延伸到车联网区块,以及延伸到医院的传统HIS系统。于图-9里,则延伸到家庭内部的各项感知型家电设备。所以,我们称上述从图-7到图-9是:基于<数字家庭区块>视角的SoS系统架构图。

3.  以xMCS模式凸显SoS的主角

       在上述的图-7、图-8和图-9里,除了偏重于<数字家庭区块>之外,我还特别凸显了智能TV是位于中心点,它扮演数字家庭区块的SoS服务功能的主角地位;它是在SoS里的小系统之间相互合作(Collaboration)过程中的领头羊。例如下图-10所示:


图-10  凸显TV是此SoS服务功能里的主角地位

       这建立了<云端(C)、电视(T)、移动(M))>三层组合的新型SoS服务模式;让股票分析师能在家里的智能TV里,执行他自己的应用软件,从家外的股票云平台取得股票数据,在家里分析之后,从智能电视将分析建议信息推送到手机的微信画面上。这也是基于<xMCS模式>的SoS系统架构。于是,就将”xMCS”名称里的”x”,改为”T”;就成为:<TMCS系统模式>了。


图-11  凸显TV是主角的TMCS系统模式

这里的TMCS模式是凸显了智能TV为主角,这是如何决定的呢? 其依据为:

  • 我现在正进行<数字家庭业务区块>的顶层设计或实践开发。例如,上图-10里,虽然是关于金融股票的分析业务,但仍归于数字家庭业务区块。
  • 我想把主要的业务逻辑和App软件安装于<智能TV>里。例如,上图-10里,股票分析师自己专业的知识,写成了App软件,安装于自己家中的<智能TV>里执行。虽然股票信息来自窗外的股票信息云平台,但是自己App我计算出来的专业股市分析情报,则摆在自己家里的TV里;在推送到客户手机里。也就是因为分析师的活动是在于家庭内,所以将上图-10的业务归于<数字家庭业务区块>。此外,App软件的执行和专业数据储存都是在智能TV之内,所以此业务幕后SoS的主角归于<智能TV>。

以此类推,人人都可以依据自己所选择的业务区块,以及自己所选择的<主角>来建立其系统架构模式,并给一个自己喜欢的(模式)名称。例如下图:


图-12  人人都可以命名自己的模式名称 

       兹以HMCS模式为例,从名称看来就知道,在业务架构层面,这是关于<医院健康区块>的业务;而在系统架构层面,则以<HIS系统>为领头羊(主角)。同理,从VMCS模式名称来看,可知道在业务架构层面,这是关于<车联网区块>的业务;而在系统架构层面,则以<车载(Vehicle)系统>为领头羊(主角)。于是,我们将上图-6的MCS模式的三个元素,增添了一个,成为四个元素,如下图所示:


图-13  TMCS模式里的4项元素

       在智慧城市的任何一个业务区块,在其业务架构(Operational View)层面,都有自己的商业模式、获利策略、业务功能、以及产品或服务等。但是,在幕后的系统架构(System View)里,任何系统几乎都可以归类到上图里的4项元素。值得留意的是,这项模式只明确规范了元素种类,并未明确规范这些元素之间的沟通(或通信)途径。所以,在不同的应用情境里,可能各有不同的通信途径,如下图所示:


图-14  TMCS模式并没有规范元素之间的组合规则

       刚才提到了,在这xMCS模式(如TMCS模式)里,只规范了元素种类,并未规范元素之间组合结构;而是让各区块架构师依据不同应用情境而设计出其特定的组合结构,如下图所示:


图-15  由区块架构师决定<M>与<C>之间是否要直接通信

       这种模式只规范元素种类名称,试图成为不同业务区块的系统架构设计者心中的共同概念(Concept)或词汇(Vocabulary),以促进系统之间的互通性。也就是,透过共同术语来理解别人的系统架构设计,激发自己的创新设计。这种模式,并不能直接套用,而只是提供人们举一反三、继续创新的思考模版,这通称为思考性模式(Thinking Pattern)。反之,像本文档也会提到的<EIT软件造形>,它除了对元素种类做了规范之外,还明确规范了元素之间的组合规律;所以可以拿来套用,并直接落实为代码,就称为之静态设计模式(Static Design Pattern)。
       除了上述的股票分析功能之外,还可以依循TMCS模式的引导,而设计出更多花样的业务功能;如下图-16所示。从”TMCS”名称即可知道这个系统架构是以<智能TV>为中心,由它扮演主角,带领其它配角来完成这SoS系统的任务。从图-16可以看到,这系统包含1个<T>元素、一个<C>元素、一个<M>元素和两个<S>元素。


图-16  基于一致的模式(即TMCS)而设计出更多业务功能

       上述的图-13和图-14是TMCS系统模式的结构;而图-15和图-16则是依循TMCS模式而设计出来的<数字家庭区块>的两项增值业务的系统架构。接下来,我们来看个车联网区块的例子。首先,架构师想到基本的MCS系统模式,然后选择车载(Vehicle)系统为主角,得到了一个新的模式:VMCS系统模式。如下图所示:


图-17  VMCS系统模式的结构

基于这个VMCS系统模式,架构师就来设计出<车联网区块>的<汽车定位>增值业务的系统架构设计。如下图所示:


图-18  车联网区块的<VHMC模式>系统架构

       在医疗区块里,也能建立PMCS模式,并设计一个系统架构,如下图:


图-19  医疗健康区块的<PHMC模式>系统架构

       此系统的功能是:医院的病房里有人体健康状况检测传感器(Sensor),检测数据立即传送到护士手里的平板电脑屏幕上。平板电脑会与医院信息系统(HIS, Hospital Information System)通信,取得必要的信息,例如随时向取得有关医生的手机的目前IP,然后发送最新信息到医生的手机上。于是设计出上图-19的系统架构,其中的平板和手机都是属于移动<M>元素种类的,如下图:


图-20  上图-19里的系统组成元素

       为了更明确表达出:此架构是以护士手里的平板(Pad)电脑为中心,由它扮演主角,带领其它配角来完成这SoS系统的任务。于是,将平板电脑提升到中心位置,如下图:


图-21  PMCS系统模式

       于是,就称上图-19是依循<PMCS模式>而设计的系统架构。从图-20改画成为图-21的目的是:让人们能一目了然看出来这是以平板电脑(Pad)为主角的SoS系统。一旦整个智慧城市各系统都能采取像图-21所示的表达方式,就能大幅促进各设计或开发团队之间的沟通了。

4.  应用于顶层设计的<系统架构>上

       前面提过了,在当今的产业里,无论是云计算、物联网、移动互联网或车联网等,都是一种SoS系统。基于SoS概念来看待这些系统时,xMCS模式非常有助于建立顶层设计里的系统架构。如下图:


图-22  xMCS模式应用于系统架构设计上

       使用高焕堂老师设计的xMCS系统模式,定义了系统架构层级的共同概念(Concept)和词汇,以秦代”书同文”途径来创造顶层设计的<简洁性>;进而提升团队之间的共识(Shared Understanding),建立出系统互联互通的基础。当我们以MCS模式去构思,系统架构层有了一致性的思维;则系统架构图,就呈现出既简单又能互相理解的架构文件了。这项简化的设计动作,通称为减法设计。其简化效果如下图所示:


图-23  xMCS模式促进书同文,建立互联互通的基础

       基于此图的MCS系统模式,就在EA框架里,详细说明图中系统元素之间的信息交换协议、数据交换格式、数据量、传输速率等规格。于是,产出了EA的系统架构文件。

5.  衔接到中层设计的<EIT造形>

5.1  减法设计

       顶层设计包含三个面向:业务架构、系统架构和通信架构。在上层的业务架构里,各个业务区块的术语或词汇(如医疗区块的MRI、DICOM等词汇、以及博弈游戏的Payback、ROR等术语)。往下一层就是系统架构,在这系统架构层里,无论各个业务区块的IT系统,都能归类成三种元素:就是Cloud、Mobile和Sensor。
       这种词汇上的”减法设计”,不仅仅非常有助于系统层面的相互沟通,促进信息共享之外,还能提升系统建置过程中的系统模块(Module)的复用性(Reusability)。如下图-25所示。从上而下,经过两个层级的减法设计,如下图-25所示。


图-24  xMCS模式和EIT造形接力进行减法设计

这两层的减法设计就是:

  • 从<业务架构层>到<系统架构层>的减法设计

       此时采取<xMCS系统模式>来协助减法设计,让业务架构层面的千变万化面貌下,能取得系统设计层面”书同文”,基于共同的概念和术语(如<M>、<C>和<S>等元素种类名称),来减化复杂性,提升系统的互通性。

  • 从<系统架构层>到<中层设计>的减法设计

       此时采取<EIT软件造形>来协助减法设计,让系统架构里的互通接口规范部分,能落实微软件代码,并取得软件接口设计上的”诗同形”,就像唐诗三百首一样,据有共同的造形(Form),却能包容无限意境的诗人心灵感触。

       为什么要透过两层的减法设计来支撑顶层设计的目标(即互联互通性)呢? 而不是去设计一个业务层面的共同平台呢? 主要的理由是:智慧城市包含众多不同的业务区块,各区块的系统大多已经发展一段时间了,并非重新兴建,而且会持续成长与发展。所以,业务架构层面的百花齐放是城市蓬勃发展的必然性,其本质就是复杂的(Complex)。此外,城市会持续发展下去,顶层设计必须非常专注城市发展的未来性,由于未来环境变会的不可预期性,其本质就是多变的(Changeable)。
       君不见,城市里的建筑物外观也是百花齐放的,也是数千年来持续演化和发展的。人们不会寻求去统一这些建筑物的外貌,因为外貌的复杂性和多变性是本质性(Essential)的。因为这个城市所处的外在环境(如自然环境、经济市场环境等)也是复杂多变的。
       然而,我们可以看到,无论是教堂、学校、仓库、四合院、客栈等建筑物,虽然外貌都不一样,但其屋檐下的栋梁、砖块、水泥、门窗、卡榫接口的设计概念和造形却是极为一致。这就是中层设计的来源,藉由中层设计的一致化简单造形,来包容上层外貌的复杂性和多变性。因此,我们设计了xMCS系统模式和EIT软件造形,其效益如下:

  • 基于中间层造形的包容性,支撑上层业务的多样性,促进城市发展的未来性。
  • 基于中间层设计概念一致化,促进不同区块、系统、及设计者之间的互通性。
  • 基于中间层的模块的复用性,促进不同区块、不同系统、不同设计者采用更优质、更受检验的模块,大幅提升城市建置的质量。

5.2  衔接到<EIT造形>

       经过了xMCS模式的减法设计之后,在系统架构层里面,人们获得一致的概念和词汇,有如秦朝时代,迈向”书同文”的境界;如上图-23所示。
       由于EIT造形的内容是软件代码了,已经到达很明确规范(电脑才能执行)地步了,包括元素本身的形式,以及元素之间的组合形式(就如同,一个H原子内部的质子、中子和电子的结构);此外还包括EIT造形外部的组合形式(就如同,两个H原子与一个O原子结合成为一个水分子),都明确定义了。它比上层的xMSC模式具有更明确的形式定义(不仅是规范),就称之为”造形”。所以,xMSC模式比较抽象,只是给人看、引发人们去创造的思考性模式(Thinking Pattern);而EIT则是具像到电脑可执行的软件(代码)造形(Software Form)。
       经过了EIT造形的减法设计之后,在中层设计里面,人们获得一致的概念和组合形式,有如唐朝时代,迈向”诗同形”的境界。如下图所示:


图-25  EIT造形促进诗同形,确保互联互通的可实现性

       这图以EIT软件造形来实现xMCS模式里元素之间的互联互通的关键部分:接口(Interface)。由于EIT是软件造形,它能有效包装实体的通信接口,透过软件来转换信息格式,再转交由另一个实体层通信接口传输给对方。如下图-28所示。如此,包容了新、旧的实体层通信协议和设备。换句话说,除了促进互联互通的效益之外,又包容过去、现在和未来的通信协议,保护了过去的投资;还包容了标准的、不标准的通信协议和设备,提升了持续发展的未来性。于是,得出一个可既简单又可执行的中层设计。


图-26  以EIT造形包容新、旧的通信协议

       于是,得出了从顶层设计衔接到中层设计的途径。虽然增加了一项中层设计,但是这些都是<顶层设计阶段>所涵盖的范围。如下图所示:


图-27  顶层设计阶段各层级的设计内涵

也许你会问道,为什么要独立出一项<中层设计>呢? 将它合并到顶层设计,是不是也可以呢? 理由很多,其中最主要的是:中层设计是位于顶层与实践层之间,本来顶层只做设计,并不产出代码;而实践层的重要任务之一是以软件来整合硬件和通信,产出软件代码是它的核心任务。双方非常互补;但缺乏交集;而中层设计是双方的交集部分。在时间轴上,它虽然属于<顶层设计阶段>的工作范围;但其产出的软件代码,却是要做为实践开发阶段的基础;也就是实践阶段进行敏捷迭代过程的单纯起点,在敏捷开发概念里,称为:简单方案(Simple Solution)。 

6.  在敏捷迭代过程中的角色

       在顶层设计阶段,依循敏捷途径,以测试驱动(TDD, Test-Driven Development)引导出持续地反馈(Feedback)与迭代(Iteration)的中层设计(即软件接口开发)过程。如下图-28所示。


图-28  顶层设计阶段的敏捷迭代过程(产出中层设计) 

       在图-28里,经由敏捷TDD机制来执行接口软件,实际检测信息交换的所需的软硬整合设备,以及相关通信机制。产出电脑可执行的软件接口控制代码,就是中层设计的作品了。在这个迭代过程中,可使用高焕堂老师设计的xMCS系统模式,定义了系统架构层级的共同概念(Concept)和词汇,以秦代”书同文”途径来创造顶层设计的<简洁性>;进而提升团队之间的共识(Shared Understanding),建立出系统互联互通的基础。基于xMCS模式所创造的简洁性,就可针对各系统之间互联互通的接口部分,以明确的软件代码来定义之;以唐代”诗同形”途径来提升顶层设计(和中层设计)的<明确性>。才能有效检验顶层设计的<可实现性>。

~ end ~