智慧城市的<敏捷顶层设计方法>
作者：高煥堂 2013/03/22
misoo.tw@gmail.com
术语说明：顶层架构设计文件、中层设计、EIT软件造形、业务区块、SoS(System of Systems)、
MCS系统模式、AHP决策分析方法、敏捷(Agile)开发、架构的分层(Layering)、信息孤岛。
简介
这是由高焕堂老师所提出的顶层设计(Top-level Design, or Hi-level Design)方法论。适用于智慧城市、数字家庭，以及大型SoS(System of Systems)系统设计，例如公共交通、旅游休闲、医疗健康等不同业务区块的顶层设计；并促进不同业务区块或系统之间的互联互通、信息共享、并避免信息孤岛。欢迎各界先进专家批评指教，也欢迎广泛使用，不必付费。
1. 目标：互联互通、信息共享、避免信息孤岛
为了支持此目标，兹设计出一种顶层设计方法，如图-1a所示。
图-1a 高焕堂老师提出的<敏捷顶层设计方法>
与顶层设计的攸关的人员是：老板、设计团队、外界的专家、用户。本方法让攸关人员(Stakeholder)一起来贡献经验和知识，创造高质量的顶层设计，包括：老板提供愿景、设计团队提出架构、外界专家提供决策评核准则、用户提供需求测试。如图-1b所示。
图-1b 高焕堂老师提出的<敏捷顶层设计方法>
针对此图所示的方法，兹从不同面向来说明如下：
1.1 架构(Architecture)：基于EA和SoS原理
此方法是基于企业架构(EA, Enterprise Architecture)框架和SoS(System of System)的原理而设计出来的。其设计文件包括愿景叙述、业务架构、系统架构等顶层架构设计文件和中层设计。其产出顺序如图-1所示。
1.2 过程(Process)：基于敏捷开发(Agile Development)原则
此方法的顶层设计过程是基于当今最流行的敏捷(Agile)开发原则。以敏捷的测试来带动设计团队进行迭代(Iterative)过程。以测试结果的反馈(Feedback)激发各参与人员(Stakeholder)的反思、讨论与重构设计，让顶层设计止于至善。图-1里的循环圆圈，就表示其迭代过程。
1.3 决策分析(Decision Analysis)：基于AHP方法
采用AHP决策分析方法(常与EA框架搭配)，来评估顶层设计里的重要决策。以确保设计决策的<最佳性>。这表示于图-1里最右边的小圆圈。
1.4 需求检验(Requirement Test)：基于TDD方法
以敏捷的<测试驱动开发>(TDD, Test-Driven Development)来带动整个设计团队进行迭代过程。这迭代过程，会不断重构顶层设计，来满足用户的功能性需求。这表示于图-1里最左边的红色圆形。
1.5 中层设计(Mid-layer Design)：基于EIT软件造形
这个中层设计是此方法里最独特的部分。其特性如下：
- 基于高焕堂设计的EIT软件造形。
- EIT造形以软件代码(Code)实践上层系统架构的互联互通接口设计(Interface Design)。
- 这造形的软件代码，做为TDD测试的对象。
- 如果EIT造形的代码没有通过TDD检验，就会发出反馈来驱动一次新的迭代循环，驱动设计团队重构顶层设计。
- 当EIT造形代码通过了TDD检验，就表示该接口设计是电脑可执行的，也确保了顶层设计里的互联互通(接口)设计是具有<可实现性>的。
1.6 减法设计：善用MCS模式和EIT造形
使用高焕堂老师设计的MCS系统模式，定义了系统架构层级的共同概念(Concept)和词汇，以秦代”书同文”途径来创造顶层设计的<简洁性>；进而提升团队之间的共识(Shared Understanding)，建立出系统互联互通的基础。
基于MCS系统模式所创造的简洁性，就可针对各系统之间互联互通的接口部分，以明确的EIT软件造形来定义之；以唐代”诗同形”途径来提升顶层设计(和中层设计)的<明确性>。才能有效检验顶层设计的<可实现性>。
MCS是一种系统模式，给与人们共同的基本术语去描各自的系统架构；这些多样化的系统架构包括了云计算(Cloud Computing)、SOA(Service-Oriented Architecture)、物联网(Internet of Thing)等，皆能以MCS模式来构思这些多样化系统架构之间的互联互通。
1.7 加法设计：无限创新
有了愿景和架构的指引，让人们的思考连结到更多的未知(Unknown)新事物。基于减法设计，让人们更有勇气面对复杂。透过迭代和反馈的去芜存菁，让人们更具有信心去经营未来、捕捉新机会。因此，激发出更多的新型商业模式和策略。
2. 架构的设计步骤：举例说明
由于本文的篇幅限制，于此仅介绍顶层设计的架构的分层(Layering)和设计步骤，就不特别说明各步骤的详细工作内涵和细节文件了。
2.1 业务架构：商业创新
从图-1所示，说明了业务架构是基于愿景(Vision)而激发的创新业务，使用EA框架而产出的业务架构设计文件或蓝图(属于顶层架构设计文件的一部分)。例如有一个新型业务，如图-2所示。
图-2 创新业务之例：在家服务的股市分析
基于这项创新业务模式，使用EA框架来规划其详细的架构，并产出业务架构设计文件。一旦完成了，就进入下一步骤，进行<系统架构设计>任务。
2.2 系统架构：运用MCS模式
建立TMCS系统模式
在本方法里，建议运用xMCS模式来思考系统结构，此模式如图-3所示。
图-3 TMCS模式定义了4种元素
基于这4种元素来构思系统架构，将其标示如图-4所示。
图-4 以TMCS模式来构思上述的创新业务
基于此图，可以延续上一节的EA业务架构，进入到EA的系统架构设计。
建立系统架构
一旦各个系统都以MCS系统模式去构思，系统架构层有了一致性的思维；则系统架构图，就呈现出既简单又能互相理解的架构文件了。这项简化的设计动作，通称为减法设计。其简化效果如图-5所示。
图-5 xMCS模式促进书同文，建立互联互通的基础
基于此图的MCS系统模式，就在EA框架里，详细说明图中系统元素之间的信息交换协议、数据交换格式、数据量、传输速率等规格。于是，产出了EA的系统架构文件(属于顶层架构设计文件的一部分)。
2.3 中层设计：采用EIT造形
两层减法设计
在本方法里，有两层减法设计。这两层的减法设计就是：
◆ 从<业务架构层>到<系统架构层>的减法设计
此时采取<xMCS系统模式>来协助减法设计，让业务架构层面的千变万化面貌下，能取得系统设计层面”书同文”，基于共同的概念和术语(如<M>、<C>和<S>等元素种类名称)，来减化复杂性，提升系统的互通性。
◆ 从<系统架构层>到<中层设计>的减法设计
此时采取<EIT软件造形>来协助减法设计，让系统架构里的互通接口规范部分，能落实微软件代码，并取得软件接口设计上的”诗同形”，就像唐诗三百首一样，据有共同的造形(Form)，却能包容无限意境的诗人心灵感触。
图-6 xMCS模式和EIT造形接力进行减法设计
为什么要透过两层的减法设计来支撑顶层设计的目标呢? 而不是去设计一个业务层面的共同平台呢? 主要的理由是：各业务区块的系统大多已经发展一段时间了，并非重新兴建，而且会持续成长与发展。所以，业务架构层面的百花齐放是智慧城市、数字家庭，以及大型SoS系统蓬勃发展的必然性，其本质就是复杂的(Complex)。此外，城市、家庭、及系统会持续发展下去，顶层设计必须非常专注，其发展的未来性，由于未来环境变会的不可预期性，其本质就是多变的(Changeable)。
君不见，城市里的建筑物外观也是百花齐放的，也是数千年来持续演化和发展的。人们不会寻求去统一这些建筑物的外貌，因为外貌的复杂性和多变性是本质性(Essential)的。因为城市、家庭、及系统所处的外在环境(如自然环境、经济市场环境等)也是复杂多变的。
然而，我们可以看到，无论是教堂、学校、仓库、四合院、客栈等建筑物，虽然外貌都不一样，但其屋檐下的栋梁、砖块、水泥、门窗、卡榫接口的设计概念和造形却是极为一致。这就是中层设计的来源，藉由中层设计的一致化简单造形，来包容上层外貌的复杂性和多变性。因此，我们设计了xMCS系统模式和EIT软件造形，其效益如下:
- 基于中间层造形的包容性，支撑上层业务的多样性，促进城市发展的未来性。
- 基于中层设计概念一致化，促进不同区块、系统、及设计者之间的互通性。
- 基于中间层的模块的复用性，促进不同区块、不同系统、不同设计者采用更优质、更受检验的模块，大幅提升城市建置的质量。
以EIT造形实现互联互通的接口设计
接续上图里的系统架构设计。以EIT软件造形形来实现上图里xMCS模式里元素之间的互联互通的关键部分：接口(Interface)。就得出中层设计里的接口定义(软件代码)。如图-7所示。
图-7 EIT造形促进诗同形，确保互联互通的可实现性
由于EIT造形的内容是软件代码了，已经到达很明确规范(电脑才能执行)地步了，包括元素本身的形式，以及元素之间的组合形式(就如同，一个H原子内部的质子、中子和电子的结构)；此外还包括EIT造形外部的组合形式(就如同，两个H原子与一个O原子结合成为一个水分子)，都明确定义了。它比上层的xMSC模式具有更明确的形式定义(不仅是规范)，就称之为”造形”。所以，xMSC模式比较抽象，只是给人看、引发人们去创造的思考性模式(Thinking Pattern)；而EIT则是具像到电脑可执行的软件(代码)造形(Software Form)。经过了EIT造形的减法设计之后，在中层设计里面，人们获得一致的概念和组合形式，有如唐朝时代，迈向”诗同形”的境界。
以EIT造形封装通信机制
由于EIT是软件造形，它能有效包装实体的通信接口，透过软件来转换信息格式，再转交由另一个实体层通信接口传输给对方。如此，包容了新、旧的实体层通信协议和设备。换句话说，除了促进互联互通的效益之外，又包容过去、现在和未来的通信协议，保护了过去的投资；还包容了标准的、不标准的通信协议和设备，提升了持续发展的未来性。于是，得出一个可既简单又可执行的中层设计。如图-8所示。
图-8 以EIT造形包容新、旧的通信协议
可继续运用EIT软件造形来实现更多的互联互通的接口设计，如图-9所示。
图-9 持续运用EIT造形，落实系统的各个接口
于是，得出了从顶层设计衔接到中层设计的途径。
2.4 完成一回迭代(Iteration)的设计
虽然增加了一项中层设计，但是这些都是顶层设计阶段所涵盖的范围。如下图：
图-10 顶层设计阶段各层级的设计内涵
也许你会问道，为什么要独立出一项中层设计呢? 将它合并到顶层设计，是不是也可以呢? 理由很多，其中最主要的是：中层设计是位于顶层与实践层之间，本来顶层只做设计，并不产出代码；而实践层的重要任务之一是以软件来整合硬件和通信，产出软件代码是它的核心任务。双方非常互补；但缺乏交集；而中层设计是双方的交集部分。在时间轴上，整个过程共分为两大阶段：<顶层设计阶段>和<实践开发阶段>。中层设计是在<顶层设计阶段>所完成的，属于<顶层设计阶段>的工作范围。到了<实践开发阶段>，我们将会拿中层设计所产出的软件代码(即EIT造形的内涵)，来做为实践开发阶段的基础；也就是实践阶段进行敏捷迭代过程的单纯起点，在敏捷开发概念里，称为：简单方案(Simple Solution)。
通常，人们会认为上图-9的三个步骤就已经完成了顶层设计，其实不然。因为从事实务经验中发现，常常会走到了中层设计步骤时，才发现业务模式可以有更多的创新，因为需要重新变更上层的业务架构设计。因此，需要像敏捷(Agile)开发一样，采取迭代(Iterative)模式。如图-11所示。
图-11 顶层设计阶段也需要迭代
所以顶层设计也需要迭代，于是我们采用敏捷的TDD来带动图-10里的迭代过程，来检验顶层设计、持续迭代，并不断重构顶层设计。
3. 展开敏捷过程：检验顶层设计
敏捷TDD所带动的迭代过程，其基本机制如图-12所示。
图-12 基本的敏捷迭代机制
如果将上图-12的迭代机制，整合到上图-11，就成为图-13所示了。
图-13 顶层设计的敏捷迭代机制
于是，以敏捷方法来检验中程设计里的EIT代码，如果有错误，就反馈给中层设计人员，必要时就进一步反馈给更上层的业务架构规划者，甚至调整高层愿景，这就是迭代&反馈的效益。
这项敏捷TDD机制，是本方法的重要检验机制；它是为了提升顶层设计的<可实现性>，也就是检验顶层设计的互联互通规范能落实为实际的IT系统。除了TDD的检验机制之外，本方法里还采用AHP分析方法来评选顶层设计中的重要决策，这可确保顶层设计的决策<最佳性>。在下一节里将说明之。
4. <敏捷大迭代>驱动<AHP小迭代>
本方法里，采用AHP决策分析方法来评选顶层设计中的许多重要决策，这可确保顶层设计的<最佳性>。顶层架构设计是要规划一个城市、家庭或大型系统的未来发展情境，其涵盖了各项未来投资，让城市、家庭或其它系统从现况(As-is)逐渐成长、演进，迈向未来(To-be)的美好情境。那么，我们又如何选择最好的决策、评估最好的投资、实践最美好未来呢? 除了顶层设计人员的主观评估之外，我们还需要仰赖定量、定性的分析方法和工具来协助评选出最好的设计决策和投资方案。
然而，在AHP里并没有涉及深层的通信接口的检验，有时候经由AHP评选出来的最佳决策，落实到中层设计时，却无法通过敏捷TDD的检验，表示不具有<可实现性>，于是透过敏捷迭代(称为大迭代)去驱动AHP的重新评选(称为小迭代)；如图-14所示。
图-14 敏捷TDD迭代驱动了AHP迭代
大家都知道顶层<设计>必须能流畅地<实践>才发挥其价值。然而，如何达到这种美好境界呢? 本方法采用敏捷TDD和AHP决策分析方法双重迭代机制，来协助顶层设计达到最佳性和可实现性。所谓可实现性，就是顶层设计最核心的<互联互通>规划，将来实际投资建置系统时，真的能顺利而流畅地对接起来。
5. 衔接到实践层的传统敏捷开发
5.1 实践层的敏捷迭代过程
到了<实件开发阶段>，中层设计人员也会参与实践阶段的敏捷TDD迭代&反馈过程，协助实践开发人员来活用EIT造形，将较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑等；包容到EIT造形的接口定义里；落实了顶层设计的互联互通要求。如图-15所示。
图-15 实践阶段的TDD迭代过程(产出软硬整合系统或模块)
在这实践阶段的敏捷迭代过程里，以中层设计的产出代码为基础(Simple Solution)，展开迭代过程。这个中层设计里的EIT造形就是软件<集装箱>，实践层的开发人员可以将实践层级的软件代码直接添加到中层设计的EIT造形里。而且能设计EIT造形幕后的形形色色软件代码，来处理实践层级的细节计算。所以，中层设计里的EIT造形的创意组合结构，能顺利成为实践层的基础架构，一方面作为实践阶段敏捷迭代过程的起始点；另一方面，基于这个基础架构，实践层的架构师可以增添较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑；成为软硬整合的系统架构。愈大规模的SoS系统开发，其中层设计就愈重要；而造形则扮演核心角色。因为它为上、中、下层人员开创设计概念的一致性(Conceptual integrity)，让他们获得一致的共识(Shared understanding)。
5.2 各系统的深度软硬整合开发
以深度软硬整合开发来支持各系统的独特性、普遍性和可靠性。为了实践各业务区块顶层设计的独特性，实践层必须仰赖深度软硬整合来达成；因为只透过单独软件或内容的特殊化，已经不足以支撑移动互联网时代的个性化需求了。尤其在开源开放的平台上(如Android)，其产品多样性、市场普及和高度竞争；无论您是软硬件厂商、内容媒体业者、或是电信运营商等，都会积极将软硬件特性整合到自己的产品和(增值)业务上，藉由软硬整合手段来表达其创意和独特性。
同时，移动终端系统平台版本的不一致性(俗称碎片化)、软硬件产品的百花齐放；在产品运行环境上，您也会让自己的系统(产品)或业务能完美跨(软硬件)平台，获得<普遍性>，是降低成本和迅速扩大市场的不二法门。因之，无论您是产品(或业务)的企划者、开发者或经营者，都会积极关注于软硬整合和跨平台相关议题上，力求在市场竞争上的独特性和普遍性。
图-16 软硬整合系统(产品)的主要特性
俗语说：欲速则不达。在力求上述的独特性和普遍性时，其生产过程往往是环环相扣的，如果关键环节不可靠，将会功亏一篑。于是，就需要精致的测试环境来检验产品的结构、效能和安全等，力求其可靠性。一旦，您的产品兼具了独特性、普遍性和可靠性，并取得用户感情的回馈，就能日益提升用户体验了。也许您会觉得要兼顾独特性、普遍性和可靠性是一件难度很高的事情。其实它们都是一个有机体的诸多面貌而已，只要切入其核心、关注其基因(gene)；并且领悟它、淬练它，就能顺利兼而得之、一劳永逸了。
由于深度软硬整合开发产品的多样性，是当今智能移动终端时代的最大特征。无论您所做的是软硬整合、跨平台或测试，其实都围绕着SoS(System of System)的组合创新思想。所谓SoS思维就如同设计飞机，如何将一群不会飞的配件(Part)加以巧妙的组合，让其整体(Whole)能飞上天空。于是，大家都能体会到，一架飞机就是一群 {whole, interface, part} 基本结构单位的巧妙重复组合而已。于此，笔者将这个基本单位称为EIT造形(Form)；它在本文所介绍的”方法论”里，扮演了重要角色。
6. 结语
本篇文章的目标是：简洁地叙述高焕堂提出的<敏捷顶层设计方法>。快速说明其两阶段的敏捷迭代过程，以及阐述各步骤的工作要点。
如果您需要更详细的相关文章，可来信索取：misoo.tw@gmail.com。于此，加以归纳说明这两阶段敏捷过程的基本思维和用意；如下的叙述：
两阶段敏捷的基本思维
在顶层设计阶段，中层设计人员与顶层设计人员，会一起合作，相对上，顶层设计人员偏于战略，而中层设计人员偏于战术。战略人员会协助战术人员，来寻觅与制定战术。这项战略与战术的融合，也必须表现于计划书的一致性。换句话说，Top-down型的顶层设计，必须与Bottom-up型的中层设计，两者必须进一步整合，也进一步检验战略与战术的融合程度。如下图所示：
图-17 中层设计属于顶层设计阶段
至于，双方如何整合呢? 在本文里，提出了一个美好的途径：就是如图-13所示，将顶层设计与中层设计纳入到敏捷TDD驱动的迭代&反馈过程中。依据敏捷开发的实务经验显示，这种敏捷过程自然会带动所有参与人员的良好沟通与合作。
到了实件开发阶段，中层设计人员也会参与实践阶段的敏捷TDD迭代&反馈过程，协助实践开发人员来活用EIT造形，将较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑等；包容到EIT造形的接口定义里；落实了顶层设计的互联互通要求。如下图：
图-18 中层设计+EIT造形+两阶段敏捷过程
以上归纳了本方法的两阶性敏捷TDD迭代过程，能大幅提升了顶层设计的可实现性，并让实践开发更为顺畅完成，则无论是城市、家庭或其它复杂系统的美好景象就在眼前了。
本方法的基本概念
最后，再厘清本方法的基本概念：
- 顶层设计是要支持投资决策；而不是去支持建置一个大型IT系统。
- 顶层设计关注的是各业务区块之间的 “互通性“(interoperability)；而不是追求稳定、可靠、不变的“共同性“(Commonality)。所以顶层设计不是去设计<中间件>(Middleware)。
- 顶层设计并非完全是<由上而下＞(Top-Down)进行的；而是＜从中间往上＞(Middle-Up)的。
- 由于顶层设计攸关现今决策的质量，以及攸关未来投资的成败。因此，如何确保顶层设计的质量(即最佳性和可实现性)，是非常重要的。所以建议采用AHP决策分析法来确保顶层设计的<最佳性>。
- 建立一个新层级：中层设计。基于<中层设计 + EIT软件造形>的两阶性敏捷TDD迭代过程，大幅提升了顶层设计的<可实现性>。
- 敏捷思维的核心是：以跌代(Iterative)过程带动反馈；以反馈促进沟通(与合作)。这项思维非常适合于顶层设计，持续地带动整个系统(如家庭、城市或公共交通等)的创新和未来发展性。
- 本方法分为两大阶段：<敏捷顶层设计>与<敏捷实践开发>。两阶段之间，能透过中层设计来做无缝隙的衔接。◆
