高老师的架构设计_隽语集(BB_0901)

前言：架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构；亦即，追求<与众不同>的特质。你属于哪一派呢?   

    许多人认为架构设计要基于用户的需求(Requirements)，然而当用户需求不稳定而多变时，又该如何下手做设计呢? 答案是：以问题(Problem)和愿景(Vision)为出发点，"设计"出初期架构(Simple Solution)，展开敏捷迭代过程。在愿景指引下，探索复杂谜题(问题)，而减法设计出"简单"的Solution。 

  

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。 

目录：請看目錄  

欢迎访问 =>高老师的ADT技术论坛

高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练 

ee                                                                                 ee

<<看上一集-------看下一集>>

 

[#901]深圳本来就是全球最佳的 {软硬结合、端云整合、IT+设计} 肥沃之地，如果能藉由Android潮流而抓住机运，就能从微利而转变成大利了。

 

[#902]从"虚实相依"的原则来看微信；OTT影响了运营商原来所处的虚实相依状态，但是微信目前偏于虚，影响力道还不足。然而，从产业发展趋势来看，Android的开源开放，给与各行业重新调整虚实相依的脚步；我认为：包括物联网、智慧城市在内，都不宜只停留在"物和网"的实体层思维上。

 

[#903]更多议题；硬硬结合销售(大小配件整合销售)是商机，SZ是全球最大的配件研发&生产城市。硬硬结合销售需要有大市场的主件；最近<数字家庭产业联盟>与我，正想在SZ建立这样的舞台。以智能TV为主配件，主配件具备了，家庭内能与TV搭配的小配件，就有大商机。

 

[#904]@让您成为杰出架构师 架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构；亦即，追求<与众不同>的特质。你属于哪一派呢? 更多新思维：http://t.cn/8Fo3z3r

 

[#905]许多人认为架构设计要基于用户的需求(Requirements)，然而当用户需求不稳定而多变时，又该如何下手做设计呢? 答案是：以问题(Problem)和愿景(Vision)为出发点，"设计"出初期架构(Simple Solution)，展开敏捷迭代过程。在愿景指引下，探索复杂谜题(问题)，而减法设计出"简单"的Solution。

 

[#906]敏捷开发为何那么依赖架构师呢? 我认为敏捷迭代的背后有个架构设计迭代来支撑。例如，敏捷迭代的起点：simple solution就来自架构设计迭代的产出物(如附图)。了解这之后，你就不会觉得simple solution很神秘了。

 

[#907]架构师的创意是上帝给人的基因 //朵儿丛子:感觉像女人一生的演变 //高焕堂:兹用个比喻，架构的主人是愿景(Vision)，架构的生母是问题(Problem)，架构的养母是现实(Reality or Constraint)，架构的养份是设计师的创意(Creativity)，架构的外貌是代码(Code)，架构的情人是需求(Requirement)。

 

[#908]为什么，抽象思维派架构设计与敏捷开发比较难以搭配呢? 理由是：抽象思维派架构设计，致力于抽象出稳定、可靠、不变的共同性架构；做为应用发展的基础。但是，这样的稳定架构不是迅速可得，不是"足够好"而已，已经违背敏捷的Simple Solution的要求了，不易迅速推动敏捷迭代。

 

[#909]在敏捷开发里，稳定、可靠、不变的共同性架构是持续减验与调教(重构)的结果；而且随着外在需求的变化，而重新调教出新的稳定结构和状态；其稳定是动态平衡中的稳定，而不是真的万变不离其宗的"宗"。动态平衡的稳定，并不是不变的稳定。

 

[#910]组合创新派以"组合"为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构，迅速取得动态的稳定。由于接口只有定义没有代码，即使是Facade模式或EIT造形来表达接口，也是很简单、容易获得，所以比较符合敏捷所要的Simple Solution。

 

[#911]随着Android版图，于2011年从手机开始扩大到电视、车载系统之后，如今成为数字家庭的主流平台；随之将继续迈入物联网、智能城市领域。Android已经不仅仅是用来写写单机的应用了。Android-based的大型系统整合，如同 OTT一般，即将成为主流。Android需要新的架构设计思维，以及PM、测试都需要扩大格局。

 

#912]@让您成为杰出架构师#从程序员到架构师之路# 谷歌的副总Marissa Mayer提倡："创意爱上限制"(Creativity loves Constraint)；她说："Innovation is born from the interaction between constraint and vision." (创新来自愿景与限制的互动)。更多新思维：http://t.cn/8Fo3z3r

 

[#913]近年来，美国著名的史坦福大学大力推行"设计思考"(Design Thinking)，例如<<The Design of Business>>一书就应用于商业上。

 

[#914]"Innovation is born from the interaction between constraint and vision." (创新来自愿景与限制的互动)。这可对映到另一个说法："Architecture comes from the mapping from the vision to the reality"。架构就是创意的表示。

 

[#915]移动云_曹文斌:个人认为在Android上做TDD受限于单次部署时间的延长可能会带来开发效率的降低。

 

[#916]@让您成为杰出架构师#架构与敏捷的完美组合# 其组合的关键在于对架构的核心的掌握。架构设计的核心任务就是"整合"，整合的目的就是要实现整体的"和谐"及其"独特功能"。于是，架构设计的核心工作就是"接口"设计。而架构与敏捷完美结合之秘诀就是：每回敏捷的迭代，都让其接口落实为代码，交给TDD来触发反馈。

 

[#917]#顶层设计# 以智能家庭为例，Android已经成为平台的主控者，这种Android-based系统涵盖物联网(如NFC)、云计算和移动手机(及不移动TV)各层面。于是对开发者而言，面临的挑战是：系统整合、软硬结合、跨芯片(和通信)平台、内容(信息)共享的需求。我们真的需要<Android + 软件工程>。

 

[#918]#顶层设计# 许多人把顶层设计翻译为Top-layer Design，然后把系统架构、网络通信架构归于底层设计。其实这是很大的误解!! 顶层设计应翻译为Hi-level Design才对。是指投资决策前的规划，相对的Low-level Design是指项目发包后，实际建置时的细节设计。两者是前后关系，不是上下关系。

 

[#919]#顶层设计# 顶层设计翻译为Top-layer Design，其实这是很大的误解!! 正却应该是：Hi-level Design，它是指投资决策前的规划，它涵盖了上层业务架构、中层系统架构和底层通信架构，但仅仅是架构性的设计；而不是细节设计。更多新思维：http://t.cn/8Fo3HIo

 

[#920]我曾经做了一个比喻：架构的主人是愿景(Vision)，架构的生母是问题(Problem)，架构的养母是现实(Reality or Constraint)，架构的养份是设计师的创意(Creativity)，架构的外貌是代码(Code)，架构的情人是需求(Requirement)，架构的岁月是迭代(Iteration)。更多新思维：http://t.cn/8Fo3z3r

 

[#921]传统Waterfall开发，属于演绎逻辑(左图)：从需求可演绎出来代码和架构。现在的敏捷开发，属于朔因逻辑：架构和代码都不是纯然从需求演绎出来，而是假定-否证的逻辑。这是<从程序员到架构师之路>幕后的哲学。

 

[#922]@让您成为杰出架构师#从程序员到架构师之路# 谷歌的副总Marissa Mayer提倡："创意爱上限制"(Creativity loves Constraint)；她说："Innovation is born from the interaction between constraint and vision." (创新来自愿景与限制的互动)。更多新思维：http://t.cn/8Fo3z3r

 

[#923]在软件开发上，关于"架构设计"往往比较重视"架构"而不是"设计"，因此对于设计思考、设计技术并不太重视；这样会影响到智能终端设计的优劣，因为具有设计思考的人员只能当"美工"化妆UI而已。于是导致，没有设计的架构，化妆效果有限。

 

[#924]个别孤岛的用户体验，即使都不断提升，客厅的整体用户体验却往下滑；因为个别部分(Part)的总合常常不会等于整体(Whole)；反而像一架飞机，个别都不会飞，整体却能飞上天空。

 

[#925]@让您成为杰出架构师开源顶层框架可支持数字家庭整体产业的创新型商业模式。例如，由秦皇岛数字加停产业联盟所提倡的新型商业模式："硬硬结合销售、软硬结合开发"。就是基于"开源顶层框架"来支撑整体产业的"智能电视(主件) + 家用医疗健康小配件 + 医疗云服务" 的整合营销策略。更多新思维：http://t.cn/8Fo3z3r

 

[#926]其中，值得特别留意的是：什么是"本质"呢? 华人很喜欢谈本质，其意义偏于"恒久不变的"核心部分，也就是万变不离其宗的"宗"。这与洋人所谈的"Essential"略有不同，洋人长谈的"Essential"偏向于"不可或缺"的部分。其微妙差异在于：有些易变部分可能是不可或缺的。

 

[#927]华人的"本质"偏于抽象思维，把万变的部分去掉，抽(像)出其万变不离其宗的"宗"。洋人的"Essential"偏于减法思维，把多余的部分去掉，留下"不可或缺"的部分。例如，大家都知道j软件是复杂(善变)的，所以复杂是软件所"不可或缺"的一环。所以洋人Brook才说："The complexity of software is essential."

 

[#928]<<为什么一个家庭会有那么多的机顶盒、电视棒、Dongle呢? >> 家庭里的客厅本来是高雅设计的。随着智能化、数字化，硬件厂商一直处处做加法，把客厅变成了设备的集装箱。为什么没有人来做减法设计呢? 如果您能让客厅恢复简单、可爱的静地，很可能有机会成为数字家庭产业的赢家呢!

 

[#929]<师字辈>(如股票分析师、拳师)可以在家里的 Android TV上执行自己的App，向云端取得信息，然后由App处理，运行自己专业独创的分析算法，并定时推送给自己的客户。在家工作，可避免堵车、节省能源、又提升家庭温暖和亲子互动，百利而无一害，必然受欢迎。

 

[#930]"秦皇岛数字家庭产业联盟"正开发家庭"师字辈"(如股票分析师、拳师)的行业型API，师字辈专家在家里的TV上执行自己的App，向云端取得信息，然后由App处理，运行自己专业独创的分析算法，并定时推送给自己的客户。API幕后就是数字家庭的"开源顶层框架"。

 

[#931]"硬硬结合销售、软硬结合开发" 商业模式。 苹果iPhone手机有数百种硬件配件，单单外套(Cover)收入都高于App。TV身为家庭信息中心，只要基于顶层框架API和软硬结合软件，就能基于通用USB+Dongle模式来困绑众多家用小配件，一起销售。这就是"秦皇岛数字家庭产业联盟"提出的产业新销售模式。

 

[#932]@让您成为杰出架构师#架构与敏捷的完美组合# 其组合的关键在于对架构的核心的掌握。架构设计的核心任务就是"整合"，整合的目的就是要实现整体的"和谐"及其"独特功能"。于是，架构设计的核心工作就是"接口"设计。而架构与敏捷完美结合之秘诀就是：每回敏捷的迭代，都让其接口落实为代码，交给TDD来触发反馈。

 

[#933]数字家庭的"开源顶层框架"，可以支持Native App，也能支持HTML5 App。在位阶上接近PhoneGap。但是PhoneGap内涵的大多是平台性插件；而"开源顶层框架"则内涵众多行业型的插件，拥有丰富的专业领域知识，支撑行业型的API，来与智能城市的其它行业区块对接。

 

[#934]开源平台和开放服务api，横向和纵向延伸，企业服务营销平台搭建同样适合这模式，平台解决的企业和外部的沟通渠道，服务api承载的是行业管理，咨询服务。

 

[#935]数字家庭的"开源顶层框架"，可以支持Native App，也能支持HTML5 App。在位阶上接近PhoneGap。但是PhoneGap内涵的大多是平台性插件；而"开源顶层框架"则内涵众多行业型的插件，拥有丰富的专业领域知识，支撑行业型的API，来与智能城市的其它行业区块对接。

 

[#936]"开源顶层框架"的接口(Interface)分为三类型：1) API，支持行业型App开发；2) SI，即是SoS(System of Systems)的接口，支持与智能城市其它行业区块的横向互联互通；3)PI，即是插件接口，提供与底层平台插件，以及行业知识插件的对接，进行纵向的系统整合。

 

[#937]"开源顶层框架" 以软件模块来支持和整合底层的各种硬件和(无线)通信途径；例如，支持NFC+WiFi、NFC+Bluetooth等的多样化组合。以支持TV/STB与手机的互动和有关<云+TV+Mobile+Sensor>整合的商业模式。数字家庭除了以往音视频内容的消费终端之外，在智慧城市里，家庭是非常重要的信息化活动场所。

 

[#938]将"架构设计"与"敏捷"两者做完美的组合，这本身就是一项完美的架构设计；而我这项组合工作也是经历多次敏捷迭代的，才得以成功的历程。

 

[#939]@让您成为杰出架构师#设计思考与造形# "抽象型"架构师，喜欢单纯做减法设计，得到简单的事物。"组合型"架构师，是为了创新功能(加法设计)，而采取减法设计来实现之；得到整合(可能简单、也可能复杂)的事物。更多新思维：http://t.cn/8Fo3z3r

 

[#940]许多架构师喜欢"抽象型"的架构设计；而我喜欢"组合型"的架构设计。前者目标是：抽象出稳定、可靠、不变的共同性结构。后者目标是：组合出新结构、支持独特性功能；例如，将一群不会飞的零件，组合成为会飞的飞机。

 

[#941]"组合型"架构设计，其过程比较像设计师，比较不像科学家。因为常常发现组合不起来的困境，就必须去创造一些新东西来介接搭桥。例如，我就创造了EIT造形和中层设计，才能实现完美的组合。于是，EIT造形和中层设计成为我的创新作品，也让我这项完美组合具有"独特性"。

 

[#942]@让您成为杰出架构师#设计思考与造形# 为什么我喜欢谈造形(Form)呢? 回想我第一回到韩国时，有感于韩国建筑物(实体)都是当地材料所造的；其造形是唐宋中国来的，而显现出中华风格、文化的输出。更多新思维：http://t.cn/8Fo3z3r

 

[#943]许多人常常问我：做造形又不能卖钱，如何赚钱? 其实这不是问题，君不见，唐代盛世王朝，其输出造形特别多。愈多造形国力愈强，国力愈强造形愈多。再看，欧美发明了一个软件产业人人知晓的软件造形：类别(class)，其软件实力和经济收益非常高。所以，我一直不主张国人只写App，而应重视造形的创新。

 

[#944]许多人常常问我：做造形又不能卖钱，如何赚钱? 这不是问题，兹举个例子，IBM发明了Database的E-R model数据库造形，不断成为IBM和Oracle公司扩充市场版图的利器。

 

[#945]Class是一个非常简单的造形，在1980年代横扫整个软件产业，改变了主要语言，这就是面向对象(Object-Oriented Programming)的潮流，至今的主流的Java语言也是OO的。洋人热衷于开发造形，国人则热中于(造形的)应用。造形带动潮流，称为时尚、风格。

 

[#946]为什么在IT产业里，软件开发者被称为"码农"；而UI设计者被称为"美工"呢? 其实也不是没道理的，道理是：都是拿别人创作的造形来套用，做出能卖钱的App。别人创作(造形)，我们使用；别人造车，我们开车；被称司机(而不是称师傅)也算合理。

 

[#947]"减法设计"思维，古代的"容易"是包容改变的意思，并非舍弃改变之意。如此，化繁为简，提升人们掌握复杂的能力。逐渐地，国人喜欢抽象(Abstraction)，抽出万变不离其宗的"不变"，来掌握简单。这就违背了"容易"的标的了。

 

[#948]数字家庭或智能城市幕后的系统架构到底分为几层(Layer)呢? 人人想法都不同。最常见的想法是两层：网络通信层和业务应用层；这认为互联互通是网络通信层的事，应力求[#949]订定通信标准。另一种想法是三层：通信层、软件框架层和应用层；这认为互联互通是框架层的事，应力求包容通信协议的多样化。您的想法呢?

 

[#950]强大的文化中国应该输出造形，而不是输出实体物(如冰箱)。最近，我的EIT造形最近也输出到日本和印度尼西亚。

 

[#951]插上200多元RMB的电视棒就能跑Android股票分析的App，透过家中的WiFi能取得窗外云端的股市最新情报；处理运算之后，透过家中的WiFi 推送到自己的客户手机中。比买一台PC或平板便宜多了，何乐不为呢? 买一个大屏只用来当影视播放器，太奢侈了。

 

[#952]@让您成为杰出架构师 #架构与敏捷的完美组合# Android进入家庭，掌控家庭智能设备的软件OS层，早已成为定局了。最佳对策是：水涨船高，在Android之上，建立一个"开源顶层框架"，并订定"开放行业型API"，并有效实践跨(Android)平台(例如善用高老师的EIT造形)，强力掌握行业型App。更多新思维：

 

[#953]智能TV与智能手机之间还有许多想象空间，TV不仅仅是影视播放器，手机不仅仅是TV的遥控器。为什么手机要"控制"TV呢? 当TV贴上一张NFC Tag时，手机和TV可以"亲亲"(嘴)相亲相爱，而不是谁控制谁了。从此公主王子过着幸福快乐的家庭生活，永浴爱河。

 

[#954]如果Fred George架构师所设计出来的Simple solution(architecture)是一颗钻石的话，那么实践的代码，就是这颗钻石(内在)的外貌。迭代过程如同女大十八变，内在梦想(Vision)依旧，外貌动人(改变了Stakeholders的需求)。

 

[#955]<秦皇岛数字家庭产业联盟>正积极开发家庭<师字辈>(如股票分析师、拳师)的行业型软件框架API，支持以智能TV为中心的家庭专业服务应用(如附图)，并透过OTT型式将专业信息推送到移动终端的画面(如微信、Line)上。未来将进一步将该软件框架平台开放给产业，成为行业型开源开放平台。

 

[#956]<<大约15年前，RFID技术先驱凯文•阿什顿(Kevin Ashton)创造了“物联网”(IoT)一词，他相信物联网能改变我们所处的这个世界，因为“如果我们拥有能够感知一切的电脑存在，那么我们就能够感知一切事物”。>>

 

[#957]@让您成为杰出架构师#架构与敏捷的完美组合# { Android + 敏捷 = ???? } 当Android开发团队遇上敏捷方法，两者会不会真的来电、携手同行呢? 有人认为敏捷的TDD会让Android开发效率变慢...等等，您认为呢? 更多新思维：http://t.cn/8Fo3HIo

 

[#958]回复宇宙教父: 所以，不要用"古典的抽象" 角度去看"容易"，它只是很简单地把复杂包装起来而已。就像集装箱把杂物包装起来，容易运输和管理而已。

 

[#959]@让您成为杰出架构师 组合创新派以"组合"为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。例如，软件层的Socket接口可以是较稳定的，此接口的实现类内涵可变动，包括Socket接口在通信层的实践通信协议(如Zigbee、蓝芽等)都是可重构、可变动的。

 

[#960]数字家庭设备的"模块化"一直都是物联网领域的理想境界，可是模块化非常依赖无线通信的统一与标准化。理论上，通信的统一是有利于模块化的大量制造和降低成本。然而，理想归理想，标准化等于给了小公司进入市场削价竞争的机会，市场老大谁愿意呢?

 

[#961]回复小笨熊ZJ: 把通信协议包容于两端的软件基类里，提供软件接口(如Socket)，而两端逻辑模块则写在两端的子类里，调用基类的Socket接口就行了。未来通信协议改变了，两端的基类内容更改即可，Socket接口不变。

 

[#962]为什么，我积极把敏捷开发(Agile)带进Android世界呢? 因为Android已经跨越单机开发，迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智能家庭，以及新兴的智能城市领域。Android的项目日益扩大、复杂化。我们需要加入新潮的软件工程、新一代的架构设计思维和模式。

 

[#963]@让您成为杰出架构师#架构与敏捷的完美组合# { Android + 敏捷 = ???? } 当Android开发团队遇上敏捷方法，两者会不会真的来电、携手同行呢? 有人认为敏捷的TDD会让Android开发效率变慢...等等，您认为呢? 更多新思维：http://t.cn/8Fo3HIo

 

[#964]为什么敏捷开发与Android是个好的搭配呢? 理由之一是：Android有完善的测试框架，有利于建立TDD测试机制来推动迭代过程。理由之二是：Android平台架构是一个[#965]多层框架体系，框架内涵是代码，满足敏捷原则：”各项架构设计决策都必须迅速落实为代码”； 有利于让敏捷方法漂亮地”落地”在Android平台上。

 

[#966]{ Android + 敏捷 = ???? } 当Android开发团队遇上敏捷方法，会如何呢? 这是我最近4个月来，主要的思考议题之一，我发现必须调整幕后的架构设计方法，从原来的大家熟悉的"抽象思维派"设计，改以"组合创新派"设计；从此王子、公主过着幸福快乐的日子，你相信吗?

 

[#967]@让您成为杰出架构师 #架构与敏捷的完美组合# 敏捷可以让架构更完美、更具有可落地性；架构可以让敏捷的影响幅度更大，促进沟通与合作人群范围更大、效果更大。两者结合，美不胜收。更多新思维：http://t.cn/8Fo3HIo

 

[#968]如果你想知道我是如何将<开发、架构与敏捷>三者组合起来的，就必须理解这图理的两种不同的推理逻辑。

 

[#969]请留意，朔因逻辑(右图)是<假定-否证>的逻辑，而不是"实证"逻辑，这是初入们架构师最常误解的地方。所以，敏捷的TDD主要任务不是来证实你的架构和代码，而是来否证，并将被否定的部分反馈回去给架构师和开发者，而带动一次新的迭代。

 

[#970]刚才有粉丝提到：＂android+敏捷不太好，在移动项目中会碰到太多问题＂。这可以另一种说法更合理：因为Android与敏捷融合得不完美(不太好），所以在移动项目中会碰到太多问题。你觉得呢？

 

[#971]史坦福大学 马丁教授在其著名的("The Design of Business")一书里写到："限制(constraint)迫使你运用创意，它让你聚精会神、厘清思路。" 这(限制)和敏捷的TDD角色是一样的。

 

[#972]在一个企业(或公司)里，程序员、架构师和高层经里三者之间有着"战术引导战略"的重要关系。经理与架构师之间是：战略-战术关系；而架构师与程序员之间也是：战略-战术关系。敏捷方法，让"战术引导战略"的机制实际运行起来，例如TDD对代码(战术效果)检验的反馈，带动了架构的重构(战略调整)。

 

[#973]也许您会问道，为什么我们积极把敏捷开发(Agile)带进Android世界呢? 因为Android已经跨越单机开发，迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智能家庭，以及新兴的智慧城市领域。Android的项目日益扩大、复杂化。我们需要加入新潮的软件工程、新一代的架构设计思维和模式。

 

[#974]在我最近三个多月来，思考如何实现<Android + 敏捷>的最佳组合，其中还有一项"敏捷"的收获：高老师学会了划 "蛇板"，在Android尚未敏捷起来之前，高老师自己先敏捷起来。找个时间拍个视频来与粉丝们分享"蛇板"之乐。

 

[#975]洋人的肯德基炸鸡餐厅，厨师做"分"，就是庖丁解鸡(切分成鸡腿、鸡翅等)；而柜台的工读生做"合"，就是组合成半鸡、全鸡、套餐等。华人的全聚德烤鸭餐厅，你知道谁做"分"吗? 谁做"合"吗? 两种餐厅的架构设计与分工模式有何关系呢? 他们属于哪一派呢?

 

[#976]@让您成为杰出架构师#创新&敏捷的架构设计# 传统上，关于"架构设计"往往比较重视"架构"而不是"设计"，因此对于设计思考、设计技术并不太重视；这常常导致：没有设计的架构。更多新思维：http://t.cn/8Fo3HIo

 

[#977]比尔盖兹(Bill Gates)曾说："愿景是免费的东西。因此，不论是以什么方式、什么形式提出来，都不算是一项竞争优势。"(Vision is free. And it's therefore not a competitive advantage in any way, shape or form.)。然而，当它搭配上策略和战术之后，却成为竞争优势的核心。

 

[#978]关于顶层设计的涵义一直见仁见智，然而基于我曾经从事DoDAF架构设计实务经验来看，我认为在智慧城市领域的顶层设计，应该是指：Top-level Design 或 High-level Design。然而许多人误解为：Top-layer Design，或Top-tier Design。

 

[#979]Top-level Design与Low-level Design之间的差异；意味着不同的决策(Decision-Making)阶段的区别。其中，Top-level Design偏于投资决策前的(高阶)设计阶段，做为政府立项投资决策的评估依据；而Bottom-level Design则偏于决策后(已经立项了)的实践考虑的细节设计阶段。这两阶段是有时间上的落差的。

 

[#980]抽象派：抽象出稳定、可靠、不变的共同性架构。 组合派：增添一个"合"元素，组合出具体独特性的创新架构。 "合"元素的影响：以"组合"为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。

 

[#981]把敏捷开发(Agile)带进Android世界!! Android已经跨越单机开发，迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智能家庭，以及新兴的智慧城市领域。Android的项目日益扩大、复杂化。我们需要加入新潮的软件工程、新一代的架构设计思维和模式。

 

[#982]创新组合派的创意主要来自设计思考(Design Thinking)模式，就是：溯因(Abductive)逻辑思考。无论是移动应用、物联网等都涉及愈来愈多的系统组合或整合。而软件开发(如敏捷方法)，愈来愈仰赖架构设计，所以架构师们亟需要去学习和领悟创意型的架构设计模式。

 

[#983]创新组合派：愿景是起点，创新组合是目标，需求用来检验；所以又称为Test-Driven架构设计方法。

 

[#984]国脉微物联：<<智慧城市是21世纪城市发展的最终目标>> 这句话有冻结城市未来(Frozen the future of city)之嫌，创造永续发展，给与城市更多"不设计"的空间，是更好的顶层设计。

 

[#986]@让您成为杰出架构师#创新&敏捷的架构设计# 架构设计造形(如EIT造形)的<简单性>，提升了人们拥有面对软件复杂多变的能力；唯有熟谙此道，才能创造架构和产品的<未来性>，才能掌握未来意想不到的机会。更多新思维：http://t.cn/8Fo3HIo

 

[#987]像Skype、微信、Line等是(移动)互联网的OTT产品，是在"网络通信层"之上，再建立一个"软件整合层"(简称OTT层)。相对上，"网络层"就像陆地上的火车、汽车道路；而"OTT层"就像天空上的飞机航线。

 

[#988]我主张推展物联网OTT，因为把物"联"起来之外，还要把"人"联起来。例如，数字家庭(物联网)的OTT 联结到社交OTT(如微信、Line等)，从物联网原来的"监控"视角，转移到"温馨关怀"的视角。

 

[#990]相对上，Skype、Line、微信等OTT是属于"移动型"的OTT；而家庭物联网上的OTT，则是"不移动型"OTT。两种OTT互相衔接，让物联网+人联网，创造更多的商业模式。

 

[#991]由于架构设计有两个基本技艺：抽象与组合。因此衍生两个不同的架构设计流派。1)抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)创新组合派：致力于组合出具体独特性的创新架构；亦即，追求<与众不同>的特质。

 

[#992]从{分vs.合} 看架构设计。洋人的肯德基炸鸡餐厅，厨师做"分"，就是庖丁解鸡(切分成鸡腿、鸡翅等)；而柜台的工读生做"合"，就是组合成半鸡、全鸡、套餐等。华人的全聚德烤鸭餐厅，你知道谁做"分"吗? 谁做"合"吗? 两种餐厅的设计与分工模式有何关系呢?

 

[#993]<创新组合派>最传神的隐喻是，谷歌公司副总Marissa Mayer所提倡的： “创意爱上限制”(Creativity loves Constraint)。

 

[#994]<<架构师如何更具创造力呢? >> 完成性假设是乐观的，意在激发人们脑海里的观想(Visualization)能力，像爱迪生发明灯泡、莱特兄弟发明飞机等，都是先把所要发明的事物化为有形，激发乐观的信心和想象，成为人类进化动力。

 

[#995]回复张汤_: <简单化的形式是否可理解为抽象后的模型>，简单化是设计出来的，抽象只是诸多设计思考之一，这是国人常常混淆的地方，要明辨之；国人善于抽象，但却不擅长设计!!

 

[#996]减法设计有两个主要途径：抽象与组合(封装)。因此衍生两个不同的架构设计流派：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构；亦即，追求<与众不同>的特质。

 

[#997]@让您成为杰出架构师 #设计思考：有效减法设计# 什么是减法设计呢? 减法设计的最基本手艺是：删除与包装(隐藏)。删除就是伟大的雕刻师 罗丹所说的：把不要的部分去掉。对于没被删除的，人们又不必直接关注(pay attention)的部分，使用障眼法将它移开视线。更多新思维：http://t.cn/8Fo3z3r

 

[#998]洋人常说：The complexity of software is essential. 而华人则说：软件的大道至简。有人认为软件的本质(道)是至简的；有人认为软件的本质(Essence)是复杂的。您比较认同何者呢?

 

[#999]硬件厂商一直处处做加法，把客厅变成了设备的集装箱。一个小小的数字家庭，将会有愈来愈多的信息孤岛。愈大的厂商拥有愈大的岛，但还是孤岛。欲实现互联互通、信息共享，只好开始做减法：继续硬件作加法(不要求硬件&通信标准化)，力求以开源开放软件平台上作减法设计。

 

[#1000]roadonroad:加法和集装箱的说法很有意思，其原因在于个性的演化和不确定，而减法的原因通常缘于各类产品间的功能重叠或绑定关联，这需要有一套开放的架构来保证松耦合基础上的随需而变。 

 

[#1001]架构设计就是设计，设计就是层复杂到简单的过程；所以架构设计就是做减法。做减法的目的就是要给人们透过简单来叫出复杂的满足感。简单让人不会害怕复杂，有勇气面对未来环境的复杂多变，然后走出自己的个性和出路。

 

[#1002]减法设计的主要手艺是：把不必要的部分去掉。什么是"不必要"的部分呢? 就是"非本质性"(unessential)的部分。

 

[#1003]我认为，物联网领域人们最大的思维视角，局限于通信设备和数据传输；少了软件抽象层的视角；因为硬件设备没有抽象层的概念，但是软件的确有抽象模块，真正的代码并不抽象；我认为，这个视角可以化解许多物联网、数字家庭、智能城市项目的难题。

 

[#1004]@让您成为杰出架构师#有效减法设计#从物联网角度来看数字家庭和智能城市，最大的视角局限在于，人人都争先恐后作加法，加法出了问题时，唯一的减法设计就是：无线通信统一和标准化。然而，这项"唯一"的方法又如同乌托邦梦境。解决此困境之路是：以上层软件框架和接口来做有效的减法设计。更多新思维：http://t.cn/8Fo3z3r

 

[#1005]在物联网的架构里，最常见的是分为三层：感知层、传输层和处理层。这个"层"的英文偏于"Tier"，而不是"Layer"。也就说，上述的三层，其实是底层(Bottom Layer)里的3个Tier。我建议，在物联网的架构里，至少要在建立Middle-layer和Top-layer才是健康的物联网概念(Conceptual )架构和系统(System)架构。

 

[#1006]在物联网的架构里，如果缺乏Middle-layer和Top-layer层架构，一个智慧城市就像只有木板床，而无弹簧床，各种创新业务将如同浮沙建塔，非常难以落到实处。

 

[#1007]@让您成为杰出架构师 #设计思考：有效减法设计# 亦即，追求<与众不同>的特质。你属于哪一派呢? 架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构。更多新思维：http://t.cn/8Fo3z3r

 

[#1008]从"Essence"(本质)这个字看物联网的思维局限。天下物本质上就是多样化的，IOT想把天下物组合于网络上，是加法设计，物物通信的多样化也是本质性的，也只能加法、不能减法。英文的Essence是不可或缺之意；过度要求通信统一(减法)会伤害物物通信的本质(不可或缺的多样化)；所以另寻他途做减法设计。

 

[#1009]我认为，数字家庭里的设备"模块化"本来就是正确的方向。模块化是做"分"的动作，是一种厂商的减法设计。问题是：对于家庭主人而言，如合将多个简化的东东组"合"起来呢? 这是加法问题了。于是家庭主人需要有效的减法设计来支撑这个烦人的加法问题。于是，许多人又回到"订定通信标准"的乌托邦减法思路了。

 

[#1010]不只是在应用面，例如系统面的HTML5本身也需要做减法设计。为了帮App做减法(UI一致性)，HTML5和浏览器本身被迫一直在功能上做加法，来吸收智能化的多样性。因为本身过度做加法，伤害了效能本质。基于此，在去年北京HTML5开发者大会上，我就提出：HTML5追求高度跨平台，是不合理的"理想"。

 

[#1011]#设计思考：有效减法设计# 亦即，追求<与众不同>的特质。你属于哪一派呢? 架构设计的主要流派有二：1) 抽象思维派：致力于抽象出稳定、可靠、不变的共同性架构；亦即，追求<万变不离其宗>的宗。2)组合创新派：致力于组合出具体独特性的创新架构。更多新思维：http://t.cn/8Fo3z3r

 

[#1013]<<智慧城市设计焦点在于智慧，而不在于城市>> Why? 未来的社会、科技、经济环境的变化，都是不可预测的，所以我们需要”智慧地”去做决策，让现在的决策具有未来性，而不是去替未来做决策，以免过度设计(Over-Design)城市的未来，反而”冻结”了城市的未来(Frozen Future)。

 

[#1014]@让您成为杰出架构师 <<如何化解数字家庭的信息孤岛问题>> 数字家庭是智慧城市里的重要业务区块，但信息孤岛情况处处可见，可做为城镇智慧化之路的借镜。数字家庭的信息孤岛，也就是智慧城市的信息孤岛；那么又如何预防或化解这种日益扩大的鸿沟呢? 更多新思维：http://t.cn/8Fo3z3r

 

[#1015]使用高焕堂老师设计的xMCS系统模式，定义了系统架构层级的共同概念(Concept)和词汇，以秦代”书同文”途径来创造顶层设计的<简洁性>；进而提升团队之间的共识(Shared Understanding)，建立出系统互联互通的基础。

 

[#1016]基于xMCS模式所创造的简洁性，就可针对各系统之间互联互通的接口部分，以明确的软件代码来定义之；以唐代”诗同形”途径来提升顶层设计(和中层设计)的<明确性>。才能有效检验顶层设计的<可实现性>。

 

[#1017]目前对于互联互通的标准思维，偏于网络标准，还停留在基础的减法设计层面，就像秦国"书同文、车同轨"阶段。在面对更复杂的智慧城市时，我们需要更高境界的减法设计，就像唐代的"诗同形"。诗同形既不局限李白、杜甫的创意情境，又能互联互通，不亦美哉!!

 

[#1018]秦国达到<力大>，唐朝达到 <力与美>。

 

[#1019]过度的标准化，可能会规范道内涵，而排斥别的内涵；这不是最佳的减法设计。例如，SOA的SOAP/Web Service就是一个例子，很容易局限了多样化的发展(产生排他性)，因而也限制了标准本身的发展。所以减法设计时，要仔细分辨形式(Form)与内涵的不同。

 

[#1020]非常可惜的是，愈多厂商提供各自<用户体验良好>的解决方案时，信息孤岛问题(即信息共享的鸿沟)就愈严重。想化解这个问题，首先必须了解到，透过网络标准和内容标准的制定做法，是不够的、无能为力的。

 

[#1021]<<解决方法：软件平台开源、接口开放>> 以行业型软件框架为平台，建立于OS和中间件之上，成为智能化数自家庭的<顶层设计>。基于行业的领域知识(如老龄健康、幼儿学习等专业知识)，建立一致化的顶层应用框架(Framework)，以开源开放的形式，持续汇集各方专家的共识；然后定订出行业型软件接口。

 

[#1022]@让您成为杰出架构师#架构师思维演练# <<自己发展OS操作系统?>> 操作系统是一个轿子，谁都做得出好轿子，但不一定人人都能乘轿子。如果自己做轿子，不能乘轿子，却去抬轿子(因为没人来抬轿)，就没意义了。更多新思维：http://t.cn/8Fo3z3r

 

[#1023]也借镜于日本。一位日本电子业者提到1980年代成功开发了TRON操作系统：<日本开发TRON是为了反制大量来自美国的技术，但iTRON从未进军全球市场，也没有日本厂商因为押宝iTRON而赚大钱；后来iTRON的结局是只被应用在日本厂商制造、在日本市场销售的产品。>

 

[#1024]工信部3月初的研究报告白皮书指出：「我国行动操作系统的研发太依赖 Android 。」 除了自己发展OS之外，我一直主张采取<跨平台>策略，更容易成功。在OS和中间件之上建立一层"行业型框架平台"，走开源开放API，透过API掌控App，力量足以与底层OS抗衡，进而掩护自己的OS。

 

[#1025]"行业型框架平台"与中间件(middle-ware)两者都建立于OS之上，到底它们又有何区别呢? 其微妙差异就在于"行业型"，也就是前者主要关注于纳入完整的上层领域知识(Domain Knowledge)，而后者关注于下层平台知识，包容其差异、抽象其共同性。两者互补，只是许多人没去厘清而已。

 

[#1026]为什么"行业型框架平台"，走开源开放API，透过API掌控App，就能够强力掩护自己的OS呢? 兹比喻：Android如同15年前的Windows；而"行业型框架平台"就好比当年的MS Office。试想，如果微软好好做Windows，而国人好好做 CN Office；结果会如何呢?

 

[#1027]Android本来就是技术海中的一股洋流，聪明人会借力使力，让它来推动大轮船、发电、洗刷海岸、借机捕鱼；不得已才需走对抗的下下策。

 

[#1028]到底"行业型框架平台"与中间件有何区别呢? 可以从智能城镇的视角来看，一个智慧城市包含数十个不同的行业区块(Business Area)，每个行业区块至今已经各自发展多年了，行业概念各自发展。于是，每一个区块都会有各自的"行业型框架平台"。至于中间件则是底层OS而定，数个区块的中间件最好是一样的。

 

[#1029]@让您成为杰出架构师 #敏捷顶层设计方法# "中层设计"是软件层，用意在于使用软件开发的TDD(Test-Driven Development)分法来检验顶层设计里的"接口"部分，为互联互通做优先的测试；提升顶层设计的可"落地"性。更多新思维：http://t.cn/8Fo3z3r

 

[#1030]为什么，架构师必须建立中层的行业型软件开放(或标准)接口呢? 因为软件必须包容互联网&通信的标准与不标准接口。试想在{Client端软件，通信网路，Server端软件} 的系统结构中，许多人会先订定通信网路协议，然后才分别开发两端的软件，这很可能是灾难的开始。两项软件变成通信网路两端的插件(配件)了。

 

[#1031]为什么，架构师必须建立中层的行业型软件开放(或标准)接口呢? 因为让业务层的接口直接依赖于互联网&通信的接口是非常危险的；就如同火车与轮子之间没有弹簧一样；这种不合理性，使得国人尽管互联网服务业发达，还是受制于洋人的软件平台；但是许多人至今还视而不见。

 

[#1032]为什么我把智能电视、数字家庭和智慧城市三位一体去构思整体设计呢? 其实，从"智能"(即软件运算)的视角看，智能都是位于我所提出TSMC模式的元素里。其中的T是智能电视(TV)元素，S是Sensor(如RFID末梢端)，M是移动端(Mobile，包括手机和车载)，而C是Cloud端。家庭只是一个套件内含TV，城市是更大套件。

 

[#1033]智慧城市顶层设计是一个复杂系统的设计，分层(layer)是人们面对复杂的＂分而治之＂的模式之一。例如，物联网研究专家王建平在《八论物联网》中阐述的物联网“感知层-传输层-处理层”三层架构。我也分为三层：1)行业区块的服务接口规范层；2)行业型软件开放接口定义层；3)系统实践&开发层。

 

[#1036]我个人认为：IME属于开发方法，其目标偏于建造一个大型而复杂的系统；而EA属于架构框架，其目标偏于众多复杂系统之间的互联互通(对接)。换句话说，IME目标是开发一个大型的系统；而EA目标在于组合出一个SoS(System of systems)。

 

[#1037]基于SoS概念和业务合作观点；可规划出这业务区块里的组织单位之间的业务合作(Collaboration)关系，就成为顶层设计里的业务观点(Operational View)。同理基于SoS概念和系统互动观点；可规划出这业务区块里的许多系统单元之间的信息互动(Interaction)关系，就成为顶层设计里的系统观点(System View)了。

 

[#1038]于二十世纪初， 爱因斯坦发表了简单公式：E=MC平方；让人们能理解复杂的质量、能量与光速之间的复杂关系。同理，我也尝提出一个简单顶层设计框架：{一个造形、一个模式、加一层设计} 来协助大家理解复杂的智慧城市规划和建置。

 

[#1039]一般人看到专利，第一个反应是想避开它。专利发明人都是聪明人，却不善长说服别人避开不如合作，因为不善长于以战术引导战略(专利创意)。一项战略性的专利，如果搭配其战术的发明，就非常有说服力了，专利就价值连城了，如LED灯的发明专利。

 

[#1040]专利是战略资源，一方面用来阻碍对手的战略资源的调度，来阻止对手战术的获利性。专利可以汇集己方的资源，让己方会赢的战术获利极大化。但是，有聪明人发明战略资源，却没发明配套的战术；没有可获利战术搭配，战略可能只是挂在墙壁上的口号而已。

 

[#1041]在传统的敏捷开发里，架构设计似乎都被视为手段，产出代码是目地。TDD则检验这个目地产出物，如果不合格就重新调整手段，也重新产出代码。其实，将上述目的和手段颠倒过来，也是可以的。透过检验不同角度的代码，来检验架构；逐渐从各种角度来优化(琢磨)架构，也是一件非常有意义的事。

 

[#1042]@让您成为杰出架构师 #敏捷顶层设计方法# 敏捷开发为何那么依赖架构师呢? 我认为敏捷迭代的背后有个架构设计迭代来支撑。例如，敏捷迭代的起点：simple solution就来自架构设计迭代的产出物(如附图)。了解这之后，你就不会觉得simple solution很神秘了。更多新思维：http://t.cn/8Fo3z3r

 

[#1043]<<敏捷初期>>敏捷专家Fred George继续说道："Then I feel comfortable letting the rest of the programming team follow that pattern. That is the "architecture". 敏捷迭代的Simple solution来自架构师的精心构思与减法设计，并产出一种模式(又称造形)，称为架构。

 

[#1044]<<敏捷初期 >>敏捷专家Fred George说道：As an architect, I will implement the most difficult parts of a system. I call it "pioneering", the process where I see if an idea in my head actually is a good idea. I will always refine the idea in that first implementation.更多新思维：http://t.cn/8Fo3z3r

 

[#1045]著名敏捷专家Fred George说道：The architect that doesn't carry his vision into code will never gain the insights that our changing industry exhibits. 架构师关注于Vision的落实为代码。敏捷产出代码(C)需要架构(A)、架构设计需要Vision(V)；那么，需求(R)的角色是什么? 是目的，还是手段呢?

 

[#1046]其实，架构师在减法设计出simple solution时，已经进行了无数次不明显的心智内的迭代了，这种迭代，就是"Mapping from vision to reality"，这个reality包括一般的外在需求、内心的审美、失败经验的限制、自我假设等等。

 

[#1047]什么是造形呢? 例如软件人员都熟知的类别(Class)，如图。其中的class 是造形，含有两种元素：属性(attribute) 和 函数(function)。而Car是拿此造形来产出的实体物-- 一个有利(可换薪水)的类别。而class造形是有用的。您喜欢做有利，还是有用的呢?

 

[#1048]智能电视、数字家庭、智慧城市的三位一体化<中层设计>。智慧城市的愿景、战略规划：顶层设计、灵活战术：中层设计、基于EIT造形的整体开发<流程>、三位一体的中层设计五大块。阐述了智能电视、数字家庭和智慧城市，三位一体化中层设计的流程。

 

[#1049]顶层设计应该是指：Top-level Design或High-level Design；而不是Top-Layer 或Top-Tier Design。意味着不同的决策(Decision-Making)阶段的区别。其中，Top-level Design偏于投资决策前的(高阶)设计阶段；而Bottom-level Design则偏于决策后(已经立项了)的实践考虑的细节设计阶段。更多新思维：http://t.cn/8Fo3z3r

 

[#1050]由于是决策依据，悠关于城市的永续发展，不能一次性的完美的、僵化的大型设计。所以顶层设计必须时时做出能承先启后的最佳设计。因此，顶层设计的过程本身就必须迭代的(Iterative)，依据大环境变化的反馈(Feedback)来触发迭代，带动设计的重构，调整出最适时的新设计来捕捉未来的机运。 

 

欢迎访问 =>高老师的ADT技术论坛 

高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练 

ee                                                                                 ee

<<看上一集-------看下一集>>

 

转载于:https://www.cnblogs.com/misoo/p/3572758.html