作者：高煥堂

重要参考文章

内容

  • 顶层设计是什么? 不是什么?
  • 什么是架构分层(Layering)呢?
  • 高复先教授建议的<架构分层>模式
  • 我建议的<架构分层>模式

 

 1.     顶层设计是什么? 不是什么?

要点

  • 顶层设计是要支持投资决策；而不是去支持建置一个大型IT系统。
  • 顶层设计关注的是“互通“(Inter-operationality)；而不是稳定、可靠、不变的“共同性“(Commonality)。所以顶层设计不是去设计<中间件>(Middleware)。
  • 智慧城市的顶层设计并非完全是<由上而下＞(Top-Down)进行的；而是＜从中间往上＞(Middle-Up)的。
  • 我建议采用AHP决策分析法来确保顶层设计的<最佳性>
  • 我独创了一个新的层级：中层设计。这个<中层设计>是行业型软件接口定义层，用意在于使用软件开发的TDD分法来检验顶层设计里的<接口>部分，为互联互通做优先的测试；提升顶层设计的<可实现性>。
  • 基于<中层设计+EIT造形>的两阶性敏捷TDD迭代过程，大幅提升了顶层设计的可实现性，让实践开发更为顺畅完成；一旦顺利成功，就实现愿景、梦想成真了，美好智慧城市就在眼前了。

详细说明：

  • 顶层设计并不是要开发一个全新的大型软件系统；而是厘清To-be架构与现有系统(As-is)架构之间的落差；这项落差就是未来投资的标的。所以顶层设计是攸关现在的决策，要决定未来城市投资的目标。顶层设计是要支持投资决策；而不是去支持建置一个大型IT系统。
  • 顶层设计的内容就涵盖了：目前决策、未来投资和To-be架构。那么，我们又如何选择最好的决策、评估最好的投资、实践最美好城市呢? 除了顶层设计人员的主观评估之外，我们还需要仰赖定量、定性的分析方法和工具来协助评选出最好的设计决策和投资方案。
  • 由于顶层设计是要支持投资决策；而不是去支持建置一个大型IT系统。所以顶层设计常常会使用AHP层次分析法来评选最佳的投资方案。
  • AHP是一项非常著名的决策分析工具；而且是最常与顶层设计EA框架相互搭配的。例如，如何确知某个设计或投资方案适合于该智慧城市呢? 就可用AHP来评估这项适用性。AHP是个很有趣又很有用的东西，它提供一个有效的方法去进行复杂的决策，无论在一般生活、商业或学术研究上，有很精采应用。
  • 顶层设计关注的是”互通”(Inter-operationality)；而不是稳定、可靠、不变的”共同性”(Commonality)。所以顶层设计不是去设计<中间件>(Middleware)。
  • 顶层设计关注的是”互通性”；而不是”共通性”。所以接口(Interface)的规范是核心；顶层业务接口，加上中层的软件接口，来包容底层互联网&通信协议和技术的多变，则是顶层&中层设计的重心。
  • 顶层设计并不是设计共通性部分。智慧城市涵盖不同的业务区块，例如数字家庭、医疗服务、公共交通、食品安全等。各业务区块各有其独特性的顶层设计来呈现其优势及特色。就像我们常常看到不同的建筑物各有不同的整体设计，例如学校、四合院、教堂、医院、仓库等都各有其顶层设计(即整体设计)。
  • 亦即，智慧城市的范畴跨越了许多不同的业务区块(Business Area)、产业技术和专业知识，又深度依赖信息化技术。由于，各业务区块或产业(如数字家庭、医疗服务、公共交通、食品安全等)的信息化应用视角和深度并不尽相同，所以各业务区块(或产业)各有其独特视角的顶层设计来呈现其特殊需求。
  • 智慧城市的顶层设计并非完全是<由上而下＞(Top-Down)进行的；而是＜从中间往上＞(Middle-Up)的。其步骤是：1)各业务区块先分头进行顶层设计。2)将各份顶层设计蓝图，呈交市政府。3)市政府核对其可能重复投资的部分；以及违背互联互通的部分；然后展开协调和修正。5)合并成为智慧城市顶层设计蓝图了。
  • 依具EA(Enterprise Architecture)框架(如MoDAF)的原则，从专业知识最集中的位置出发是最适当的。例如，城市公共交通，专业知识密集于公交车BU ，就从它出发；只是其起点，即使方向不尽然正确，反正会往上(UP)再返回修正；往上UP时会把最新专业知识带上去，实现<战术引导战略>。
  • 智能城市的各业务区块深度依赖信息化系统来互联互通，所以各区块采用企业架构(Enterprise Architecture，简称EA)的系统框架方法来呈现其信息化系统架构，成为其区块顶层设计的核心，是一种有效的途径。
  • 要建造一个智慧城市，谁都知道要切分成许多块。理由是：切分为许多区块部分(Part)，分而治之，是合理的做法。但是如何确保城市的整体(Whole)和谐状态呢? 其中，最基本的要求就是：这些区块部分之间要分工合作，也就是互联互通(Inter-Operationality)，避免掉入一个城市却处处是信息孤岛的窘境。
  • 切分为多个区块，只是为了分而治之而已，并没有其它用意。不同的区块，攸关不同的专业知识或能力，通常会由不同的人员或业务单位(Business Unit，简称BU)来担任或执行有关的业务功能(Business Function)。
  • 亦即，针对各业务区块而进行各自的顶层设计。这些区块性顶层设计只是手段，其目的是要产出各自的蓝图，然后汇合、审核、协调而融合成一个整体的智慧城市顶层设计蓝图。一旦整体城市的顶层设计出炉了，就能回头来修正各业务区块的顶层设计，让各区块顶层设计都不要违背城是顶层设计。
  • 由于顶层设计攸关现今决策的质量，以及攸关未来投资的成败。因此，如何确保顶层设计的质量(即最佳性和可实现性)，是非常重要的。在本文档里，我建议采用AHP决策分析法来确保顶层设计的<最佳性>。

 2.   什么是架构分层(Layering)呢?

       俗语说：分层负责。也就是说，对于复杂的事物，将其切分为多个层级(Layer)，然后分而治之。这是人类面对大型而复杂的系统时，能提高人们的治(管)理能力的常见途径。一般而言，上层比较应用化、特殊化；而下层就比较实体化、通用化。例如，教堂、学校、旅馆、厨房等建筑物，在其外观上、使用功能层级(即应用层)上都是不一样的(即特殊化)；然而从实体的建材层级(即实体层)上，像砖块、门窗等常常是一样的(通用化)。再如，谷歌移动终端的Android平台，其分层架构，如下图-1所示。
       其中，最上层是接近人的应用软件；而最下层就接近硬件的Linux操作系统。兹拿应用软件(Applications)和应用框架(Application Framework)两者来做比较，前者比较特殊化；而后者比较通用化。再拿应用框架与程序库(Libraries)两者来做比较，前者比较特殊化；而后者比较通用化。


 图-1  Android软件平台的分层架构

       由于上下层的抽象度不同，各层的模块(Module)或小系统(Subsystem)之间的信息沟通协议(Protocol)上的抽象度也不同。因此，可以分层订定其规范(Specification)，并且上层的规范，由下层来实现(Implementation)之。

3.    高复先教授建议的<架构分层>模式

       于2012/05/25日举行的“2012中国物联网应用需求与产业对接大会”上，中国系统工程学会信息系统工程专业委员会的 高复先教授在其演讲中，建议采用James Martin创立的信息工程方法论(IEM，Information Engineering Methodology)里的分层模式。(请参阅：http://www.e-gov.org.cn/xinxihua/news008/201206/131669.html )。

在高教授演讲里，他提到了：

“IEM信息工程方法论认为，大型信息系统建设应有四个层次的工作：高层构思，即业务领导和高管层提出系统建设的总体要求和发展愿景；业务域分析，即按相关的业务域（职能域）进行需求分析和业务建模；接下来，是系统设计和建造的中下层工作。这就是面向对象信息工程(OOIE)的“金字塔模型”，该模型的上两层，就是总体设计层，是以信息工程方法论（IEM）为指导的主要工作；下两层属于软件工程方法论(SEM)的工作，即通常的系统设计和建造工作。本文引言说的顶层设计三要素，在这里正是强调方法论的作用，强调顶层工作不要与中层(系统设计)、下层(建造)的工作相混淆。”

这IEM方法将架构切分为四层：


    图-2  IEM的分层架构

       这里的业务域分析就是针对特定的<业务区块>进行商业模式、领域知识、工作流程分析，及进行系统接口设计。这是特定业务区块的顶层设计。任何业务区块都可能是由多个小系统所组合而成的大系统(System of systems, 简称SoS)。所以系统接口设计也是很重要的，它是实现系统之间互联互通的关键机制。

4.    我建议的<架构分层>模式

4.1  基于SoS(System of System)思维

       我将上一节里所介绍IEM方法，进一步扩充到SoS思维，特别关注于各业务区块(或系统)之间的信息交换(Information Exchange)。这些信息交换的规范，将成为系统接口(Interface)设计的依据，也将是实现系统之间互联互通的关键机制。于是得到下图：


图-3  我把IEM分层架构加以扩充

       基于SoS概念和业务合作观点；可规划出这业务区块里的组织单位之间的业务合作(Collaboration)关系，就成为顶层设计里的业务观点(Operational View)。同理基于SoS概念和系统互动观点；可规划出这业务区块里的许多系统单元之间的信息互动(Interaction)关系，就成为顶层设计里的系统观点(System View)了。
       在本文档里，我将上图里的<高层构思>称为：愿景(Vision)；将上图里的<业务域>称为：业务区块；将<系统设计>称为：实践层设计；将<建造工作>称为：开发实践。于是，得到下图：


图-4  修正为本文档使用的术语

       那么，我来谈谈这图里的顶层设计(偏于战略)与实践层设计(偏于战术)之间，应该如何衔接起来，才不会让战略与战术脱节。一旦战略和战术脱节了，战略(即顶层设计)可能就变成挂在墙壁上的口号了。于是，我独创了一个新的层级，称为：中层设计。在下一节里，将会详述之。

4.2  我新创了一个层级：中层设计

       顶层设计偏于决策前的工作，来让现今决策能具有未来性。实践层设计是决策后(决定投资)的工作。由于时间的切割，使得实践层设计&开发实践阶段的敏捷迭代(Iteration)机制无法覆盖到顶层设计。那么，又如何能让敏捷的TDD(Test-Driven Development)能用来检验顶层设计的<可实现性>呢? 基于这项理由，我提出了<中层设计>，来解决此问题。
       由于顶层设计攸关现今决策的质量，以及攸关未来投资的成败。因此，如何确保顶层设计的质量(即最佳性和可实现性)，是非常重要的。在本文档里，我建议采用AHP决策分析法来确保顶层设计的<最佳性>。关于AHP的概念和用法，请您参阅我的文章：<<D01_顶层架构设计与未来投资决策分析>>。
       有了AHP来协助顶层设计达到最佳性；接着，又如何确保顶层设计的<可实现性>呢? 所谓可实现性，就是顶层设计最核心的<互联互通>规划，将来实际投资建置系统时，真的能顺利而流畅地对接起来。
       这种<设计>与<实践>的双方契合问题，就是典型的战略与战术的契合问题了。大家都知道顶层<设计>必须能流畅地<实践>才发挥其价值。然而，如何达到这种美好境界呢? 在一般的软件开发项目中，有一种非常有效的方法，称为：敏捷开发(Agile Development)。在本文档里，我有一篇文章介绍敏捷开发的概念和原则；请您参阅我的文章：<<C02_认识_敏捷顶层设计&敏捷实践_的整合模式>>。
       依循敏捷途径，以测试驱动(Test-Driven)引导出持续地反馈(Feedback)与迭代(Iteration)的软件开发过程。如下图：


图-5  敏捷开发的TDD迭代过程

       相对上，<愿景&设计>是战略；<软件代码开发>是战术。在迭代过程中，依据需求来测试软件，并反馈回到设计；以战术(战果)的反馈来修正战略，再以新战略进一步指导战术，不断调整宝贵的战略资源，聚焦于会赢的战术上，让战术的效益极大化，就是敏捷TDD机制的特色。如此，让<设计>与<实践>的双方契合；让设计能流畅地实践，发挥了设计的高度价值。


    图-6  TDD迭代过程无法涵盖顶层设计

       前面提过了，顶层设计偏于决策前的工作，来让现今决策能具有未来性。实践层设计是决策后(决定投资)的工作。由于两者时间先后不一致，两者之间有时间间隙，使得实践层设计&开发实践阶段的敏捷迭代(Iteration)机制无法覆盖到顶层设计。于是，一个巨大的难题出现了：如何确保顶层设计的<可实现性>呢?
       于是，我独创了一个新的层级：中层设计。这个<中层设计>是行业型软件接口定义层，用意在于使用软件开发的TDD(Test-Driven Development)分法来检验顶层设计里的<接口>部分，为互联互通做优先的测试；提升顶层设计的可落地性。
       在顶层设计阶段，依循敏捷途径，以测试驱动(Test-Driven)引导出持续地反馈(Feedback)与迭代(Iteration)的中层设计(即软件接口开发)过程。如下图-7所示。在图-7里，经由敏捷TDD机制来执行接口软件，实际检测信息交换的所需的软硬整合设备，以及相关通信机制。产出计算机可执行的软件接口控制代码，就是中层设计的作品了。


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

       到了将来实际投资开发段，上述中程设计所产出的软件接口代码，就交付给实践层设计团队，结合其实践层设计，一起参与实践阶段的敏捷TDD迭代过程，如下图：


图-8  实践阶段的TDD迭代过程(产出软硬整合系统或模块)

       由于智慧城市顶层设计必须具备未来性，此时敏捷思维里的迭代、反馈与沟通(合作)，是城市设计过程中必须具备的<敏捷性>。敏捷顶层架构设计与敏捷实践开发，其实是可以分阶段，并且能透过中层设计来做无缝隙的衔接(如上图-7和图-8)。
       因此，我提出的<架构分层>模式，共含有三个层级(Layer)，如下图所示：


 图-9  高焕堂提出的架构分层模式

       敏捷思维的核心是：以跌代(Iterative)过程带动反馈；以反馈促进沟通(与合作)。这项思维非常适合于顶层设计，持续地带动城市的创新和未来发展性。基于这种思维层面的一致性，也就很容易(透过中层设计)将传统软件开发的敏捷思维和原则扩大到智慧城市的顶层设计。大幅提升了顶层设计的可实现性。

4.3  <中层设计>结合我设计的<EIT造形>

       敏捷开发过程的主要概念是：1) 最简方案(Simplest solutions)；2)迭代过程(Iterative process)；3)重构(Re-factoring)；4)持续整合(Continuous integration)
       其中的第一项：最简方案，就是从一个足够好的简单起点出发，进快启动迭代&反馈过程。为了满足实践阶段的迭代过程的要求，我独创了一个超级简单的软件造形，称为：EIT造形。一方面，它能完全表达中层设计的软件接口结构，能立即落实为代码，让顶层设计阶段能尽快展开敏捷迭代过程，并能产出计算机可执行的接口定义代码。另一方面，此EIT造形既足够表达顶层的互联互通的接口定义，又非常简单。刚好满足敏捷的<足够好又简单>的起点要求。此EIT造形如下：


      图-10  高焕堂设计的EIT软件造形

       关于EIT造形，请您参阅我的文章：<<B02_认识简法设计与EIT软件造形>>和<<B01_智能电视&数字家庭&智慧城市的三位一体中层设计>>。 一旦中层设计与EIT造形结合之后，其整体架构就如下图所示：


     图-11  高焕堂设计的<中层设计+EIT造形>

       EIT造形是软件<集装箱>，实践层的开发人员可以将实践层级的软件代码直接添加到中层设计的EIT造形里。而且能设计EIT造形幕后的形形色色软件代码，来处理实践层级的细节计算。所以，中层设计里的EIT造形的创意组合结构，能顺利成为实践层的主架构(Architecture)。基于这个主架构，实践层的架构师可以增添较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑；成为软硬整合的系统架构。
       愈大规模的SoS系统开发，其中层设计就愈重要；而造形则扮演核心角色。因为它为上、中、下层人员开创设计概念的一致性(Conceptual integrity)，让他们获得一致的共识(Shared understanding)。

5.    结语

       在我的文章：<<B01_智能电视&数字家庭&智慧城市的三位一体中层设计>>里，曾经说明了，在顶层设计阶段，中层设计人员与顶层设计人员，会一起合作，相对上，顶层设计人员偏于战略，而中层设计人员偏于战术。战略人员会协助战术人员，来寻觅与制定战术。这项战略与战术的融合，也必须表现于计划书的一致性。换句话说，Top-down型的顶层设计，必须与Bottom-up型的中层设计，两者必须进一步整合，也进一步检验战略与战术的融合程度。如下图所示：

 
       图-12  中层设计参与顶层设计阶段

       至于，双方如何整合呢? 在本文里，提出了一个美好的途径：就是如图-7所示，将顶层设计与中层设计纳入到敏捷TDD驱动的迭代&反馈过程中。依据敏捷开发的实务经验显示，这种敏捷过程自然会带动所有参与人员的良好沟通与合作。
       到了实件开发阶段，中层设计人员也会参与实践阶段的敏捷TDD迭代&反馈过程，协助实践开发人员来活用EIT造形，将较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑等；包容到EIT造形的接口定义里；落实了顶层设计的互联互通要求。如下图：


图-13  中层设计+EIT造形+两阶段敏捷过程

       以上说明了，基于<中层设计+EIT造形>的两阶性敏捷TDD迭代过程，大幅提升了顶层设计的可实现性，让实践开发更为顺畅完成；一旦顺利成功，就实现愿景、梦想成真了，美好智慧城市就在眼前了。

PS.

2011年5月到台北郊區山洞閉關思考之後，我從Android手機領域踏上了智能電視和家庭之路；2013年1月到今天的在台北家閉關寫作；我將踏上智慧城市領域。三個月來寫了300頁關於<移動終端、數字家庭&智慧城市>整體設計模式。願與大家分享，有興趣者可來信索取：misoo.tw@gmail.com 。附圖為2011閉關的山洞。

  

 

~ end ~