IT架构设计_隽语集(Design Thinking _0901)

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

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

  

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。A段与B段的区别是：A段获利思维，B段成本思维。两种思维是两个不同视角(View)；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:加法和集装箱的说法很有意思，其原因在于个性的演化和不确定，而减法的原因通常缘于各类产品间的功能重叠或绑定关联，这需要有一套开放的架构来保证松耦合基础上的随需而变。

 

 

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

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

ee                                                                                 ee

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