By 高焕堂
重要参考文章
内容
- 什么是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 ~
