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

前言：许多架构师追求稳定、可靠、不变的系统结构；这常常导致敏捷开发的困难；所以我主张：架构师要以接口(Interface)为焦点，以组合创新为依归，就能与敏捷完美组合了。在移动应用和软硬结合应用上，我希望软件变化集中于框架接口的实作基类内；因为这些变化与通信协议或硬件设备有关，为了包容通信&硬件的变动、标准与不标准，软件框架基类内部代码随之而变，代价不高。敏捷非常依赖重构(重整架构)，能"分合自如"就易于重构，欲分合自如，接口是第一等公民(The first-class citizen)，让接口订益和设计能迅速落实为代码，是"架构+敏捷"完美组合的基石。 

 

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。A段与B段的区别是：A段获利思维，B段成本思维。两种思维之间的差异是：1)获利思维：用户＜占便宜＞；2)成本思维：让用户＜捡便宜＞货。 

目录：請看目錄  

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

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

ee                                                                                 ee

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

 

 

[#801]依据传统抽象视角，分析与设计Domain Classes的继承结构是项目的起步工作之一，但是建立出可靠的继承结构，本身就是跌代的结果，那么跌代的起点(Simple Solution)应该不是继承视角，而是其它视角；例如，组合视角。

 

[#802]将 {基类 / 子类} 结构视为一种 "代码"造形。然后从不同视角，将分析与设计的内涵赋予到此结构上，则这象造形就能有形形色色的内涵了。这摆脱掉传统 {基类 / 子类} 结构只有一种内涵(抽象&继承)的苍白思维世界；更能灵活地配合敏捷的跌代、并顺畅重构与成长了。

 

[#803]回复TriChaos: 我反而是在调整概念层次的分析和设计视角，能直觉地落实为代码。并不是去改进实现细节，而是调整架构师的思维视角。架构师可以调整自己，而不是仅仅去调整别人。

 

[#804]子类开发者，将子类名称写在配置文文件里，让基类来读取即可。Android & iOS都如此，设计模式已经是1990年代的思维了，应该翻新了。

 

[#805]由于我们的<软硬结合平台>上的应用软件，其形式包含传统的Android App形式，以及HTML5-based的Web App形式。所以我们必须重构PhoneGap框架，让信息流向也能承接来自传统(一般)Android App里的View事件。

 

[#806] @让您成为杰出架构师#IT+Design Thinking# 浏览器轻量化(做减法设计)让HTML5 UI飞快执行；透过架构设计让UI和插件分离，产生执行效率极大化，又能同步跨平台。可避免当今HTML5-based浏览器不断做加法设计，变成<母鸡翼大而不能飞>的窘境。更多新思维：http://t.cn/8FbhmdD

 

[#807] 许多插件(Plug-in)是跟业务知识(如Business Rules)有关的；它本来就是HTML5-based App的一部份。当HTML5与高老师所提出的EIT造形携手合作，可让Web App和插件都能同步跨平台。

 

[#808] 就拿业务规则引擎(如Business Rules)来说；这引擎软件模块，到底该写在JS里，还是写在PhoneGap插件里呢? 如果，必需写在PhoneGap插件里(例如需要OS层的快速图像解析)，如何完整App的跨平台，就变成重要议题了。

 

[#809] HTML5文檔是Webkit(Browser)的 UI layout插件；JS也是Webkit的script插件；而PhoneGap里的Java模块也是Webkit的业务型插件。为何大家只追求HTML5+JS插件的跨平台，而抛弃了业务型插件呢? 没有业务规则支撑的UI又有何意义呢? 或是期待所有的业务规则都丢上云端后台呢?

 

[#810] 浏览器轻量化(做减法设计)让HTML5 UI飞快执行；透过架构设计让UI和插件分离，产生执行效率极大化，又能同步跨平台。可避免当今HTML5-based浏览器不断做加法设计，变成<母鸡翼大而不能飞>的窘境。

 

[#811]由于硬件、软件、内容服务(运营)各产业都必须不断创新，藉由独特性、差异化来取的市场的竞争优势。所以，软硬结合工程师必须运用精致的框架(Framework)、接口(Interface)、插件(Plug-in)技术来包容硬件(含驱动软件)的改版和差异化，并且在硬件产业的不断创新之下，仍维持整体产品的完整性和稳定性。

 

[#812] @让您成为杰出架构师#IT+Design Thinking#IT架构师如果具备"设计思考"，他就很容易领会，谷歌副总Marissa Mayer所提倡的：“创意爱上限制”(Creativity loves Constraint)。她说：”创新来自愿景与限制的互动”(Innovation is born from the interaction between constraint and vision)。更多新思维：http://t.cn/8FbhmdD

 

[#813]在互联网、物联网等通信网络普及的今天，日新月异、日益增多的智能型设备，需要透过通信网络来对接相联。在设计思维上，这称为<加法设计>，让整体系统愈加复杂化。面对<加法>的复杂性，人们因为恐惧而寻求<减法设计>来简化复杂性。例如，期待通信协议的统一化、标准化等。但是，这只能望梅止渴。

 

[#814]我深深觉得过去30年，"实践"是华人的主轴，而思考、设计、方法和造形大多是舶来品。我深深觉得国人头脑好又多，应该多思考、多创造才是对的。

 

[#815]许多人误认为，过多的设计和创意会带来风险；其实设计与创意也能用来避风险，探索一条更稳当的途径。韩国非常重视设计，三星许多创新，也善于避风险，业务蒸蒸日上。所希望大家喜欢我提出的EIT造形、TSMC设计模式和我设计的"敏捷顶层设计方法论"。更希望大家一起来设计与创造。

 

[#816]在手机产业里，大小配件的结合销售情形，已经愈来愈多样化了。试想，Apple公司的配件总类多达600种以上。以此观之，以智能TV/STB为中心的客厅小配件市场机会是很抢眼的。试想，国内3亿个客厅，需要大量相关配件。所以我们需要建立两个平台：<软件框架平台>和<商务交易平台>。

 

[#817] @让您成为杰出架构师#IT+Design Thinking# 硬件、软件与内容，三者之间；软件最虚、内容次之、硬件最实；而服务则是三者的融合功能。软硬结合最符合太极的阴阳相抱。更多新思维：http://t.cn/8FbhmdD

 

[#818]在当今的Android产业里，无论是软件、或硬件，生产并非问题所在；销售渠道是一大挑战。因此，透过数字家庭产业联盟的行业型<软件框架平台>和<商业交易平台>能强力解决困境。例如，许多款的Android投影仪，并没有与家庭其它智能设备做好整合&应用，未能有效进入广大的家庭。

 

[#819]智能家庭的行业型<软件框架平台>与传统大家熟悉的智能电视<中间件>是不一样的。行业型<软件框架平台>位于中间件之上。中间件内含的是平台插件，其整合底层操作系统平台的功能。行业型<软件框架平台>则内含许多商业层面的插件，例如股票分析的软件模块等。

 

[#820]智能电视<中间件>主要是去屏蔽底层硬件或平台的差异化，来支持App的跨平台。行业型<软件框架平台>则是用来 "框住" App，来强力支持<软硬结合开发、硬硬结合销售>的高获利商业模式和策略。

 

[#821]为什么要迈向<智能家庭OTT平台>呢? 因为从 "智慧城市顶层设计" 来看，城市的商业模式将会在OTT层级对接，然后才指引底层物联网如何对接；而不是先在底层感知对象的对接之后，才来寻找商业模式。这也可能化解当今物联网难寻有效商业模式的窘境。

 

[#822]在<软硬结合开发、硬硬结合销售>新型商业模式的支撑下，除了大家熟悉的家庭医疗智能设备、音视频拨放的相关设备(如投影仪)、智能地毯等硬件销售之外；更多的幼儿学习内容等文化产业的商品，也能透过此交易平台的巨大销售渠道。这我们称为："内容创意在云端，整合销售在终端"商业模式。

 

[#823]许多人都相信，互联网和云计算技术会让整个产业走向<卖内容送硬件>之路。事实上，内容与硬件是虚实相依，透过<软件平台>来挟<内容>以卖<硬件>，却是永远不会消失的市场模式，更重要的是：用户很愿意付钱买硬件，是永远不变的真理。所以，我大力推动深圳的<软硬结合开发、硬硬结合销售>模式。

 

[#824] <通过软件提升硬件的价值> 就是俗称的"软硬结合"，它是手段，是发钱又是国人看不见的，不愿意投资的。所以要倒过来，同步推动<硬硬结合销售>，强调获利模式，是必要的途径。

 

[#825] @让您成为杰出架构师#IT+Design Thinking# 硬件、软件与内容，三者之间；软件最虚、内容次之、硬件最实；而服务则是三者的融合功能。软硬结合最符合太极的阴阳相抱。更多新思维：http://t.cn/8FbhmdD

 

[#826]我致力于推动深圳的<软硬结合开发，硬硬结合销售，挟内容以卖服务>商业模式；其中，软硬结合开发是手段，硬硬结合销售是 "短期获利" 策略，而挟内容以卖服务则是 "长期获利" 策略。

 

[#827]所以，软硬结合、挟内容(把内容夹在软硬中间，成为三明治)以卖硬件(软件开源免费)。就是我推动深圳的<软硬结合开发，硬硬结合销售>商业模式的幕后设计思考。

 

[#828]国人鼓吹务实，所以重硬件、网络、通信，也重 "内容" 却轻忽 "软件"；因此未能有效虚实相依、阴阳相抱。国人的软件业者也很务实，重表面UI、重数据，却轻忽 "设计"；因此也未能有效虚实相依、阴阳相抱。剩女剩男太多，何不结为好缘，从此公主、王子过着幸福快乐的日子。

 

[#829]@让您成为杰出架构师#IT+Design Thinking# <<跨平台架构设计是基础>> 大家都知道，无法跨平台，就永无宁日，测试方案就没有自主性、也不能复用。反之，基于跨平台的架构设计，不受别人平台(如Android平台)的牵绊，可以大幅减少测试工作量，并提升质量；全力创新出自己产品的独一无二风格。更多新思维：http://t.cn/8FbhmdD

 

[#831]国人ICT领域喜欢谈<互联网>、<移动(终端硬件)>、<内容>和<(大)数据>；可是很不喜欢谈<软件>和<设计>；只喜欢看得见摸得着的务实东西，这违背虚实相依设计原则，这常常陷入困境：1) 产业走不出国门，只能赚外国的蝇头小利。 2) 只能拼命赚国内的钱。

 

[#832] <<热情投入的重要>> 李安导演的专注投入是他的电影奇迹的基础。4年来，他拍 "少年PI"期间，开始学潜水，且拿到潜水牌照。我也学习李安，过去4个月来，苦思谜题，我开始学习划 "蛇板" 领悟身体像10岁小孩的敏捷。5月中我到成都，将拍一支我的"蛇板MV"与大家分享"英姿"。

 

[#833]欲掌握Android的知识体系，从框架角度切入，可以找到它的甜心点(Sweet Spot)。由于它是一个开源开放的架构，我们可以直接切入核心，看到树干结构，一目了然；而不必像iOS、Win8等封闭平台，只能从外部功能(树叶)去猜测底层架构。

 

[#834] <<跨平台架构设计是基础>> 面对强势的Android开源平台，我们不得不使用Android x.x 版本。那么，我们有何高明的跨平台策略和技术，让我们(大鸿鸟)能振翅高飞、遨游天际呢? 跨别人的平台，整合自己产品，进而推展自己的平台，是当今处于Android多元发展情势下的赢家之路。

 

[#835] <<跨平台架构设计是基础>> 跨别人平台的问题有两个来源： 1) 来自终端产品总是面对外来芯片(及其API)的善变； 2)平台软件(如Android, iOS等)升级和版本变更频繁，终端必须随之而更新。

 

[#836]为什么我提出的EIT造形，能化解敏捷开发里，架构师与开发者之间的衔接问题呢? 答案是：因为EIT代码造形，既是代码，又是设计模式。它是架构设计师(建筑师)心中的"砖块"；也是开发者(营建商)心中的砖块。前者是设计单元；后者是施工单元。两者同出而异名，是敏捷和谐的基础。玄之又玄、众妙之门。

 

[#837] @让您成为杰出架构师#IT+Design Thinking# 在Android芯片厂商发挥的<一站式>(Turnkey)策略下，其话语权愈来愈大；相对地，Android终端厂商的自主性空间就日益缩小，这就是俗称<山寨化>现象。所以我提出了<挟天子以令诸侯>策略，追求水涨船高，反过来擅用枷锁的束缚，来激发自己的创意。更多新思维：http://t.cn/8FbhmdD

 

[#838]由于EIT代码造形，既是代码，又是设计模式。它是架构设计师(建筑师)心中的"砖块"；也是开发者(营建商)心中的砖块。所以就成为开发者从代码开发而迈向架构设的快捷之门。

 

[#839]架构师与开发者之间如何紧密衔接，是敏捷(agile)顺畅性的关键所在。架构师需要看开发者的代码吗? 架构师设计在先，又如何看到开发者的代码呢? 如果不想看、不会看、或看不到时，架构师如何表述其构想给开发者呢? 这如同蛋生鸡、鸡生蛋的古老问题。为了解开这个谜题，我提出了 "EIT代码造形" 。

 

[#840]欲掌握Android的知识体系，从框架角度切入，可以找到它的甜心点(Sweet Spot)。由于它是一个开源开放的架构，我们可以直接切入核心，看树干结构，一目了然；而不必像iOS、Win8等封闭平台，只能从外部功能(树叶)去猜测底层架构。所以，欲掌握Android架构体系，从它的多层框架体系视角切入，是最有效的。

 

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

 

[#842] @让您成为杰出架构师#IT+Design Thinking# 改变我们对架构的视角。例如，不合理的假设(assumption)是：先厘清用户需求(Requirements)，然后针对需求，区分善变与不变，得出稳定的架构。这就是古典的Requirement-based架构设计。这是让Android大型项目与敏捷无法携手同行的致命伤。 更多新思维：http://t.cn/8Fo3z3r

 

[#843] 许多人尝试了，许多人遇到复杂的难题。高老师闭关苦思，解开了这个谜题，从复杂中得到了简单的答案：改变我们对架构的视角、认知和心中的假设(Assumption)，就迎刃而解了。

 

[#844]改变我们对架构的视角。例如，不合理的假设(assumption)是：架构是下层，应该像地基或平台；应用(App)像地面上的房屋。下层架构要稳定，才能支撑上层应用的百花齐放。这项古老的假设与Android现代软件结构是格格不入的。

 

[#845]最有创意的达芬奇(Leonardo da Vinci)认为：“能不能看出事物的关系和模式，并做出不寻常的组合和关连，乃是创造力的核心要素。”所以，当你也可以观察乍看之下毫不相干的事物，找出不同的关联方式，发展出和达文西一样的能力。

 

[#846] @让您成为杰出架构师#IT+Design Thinking# 改变我们对架构的视角。例如，不合理的假设(assumption)是：建立分层架构(Layered Architecture)，然后期待越底层必须越稳定。这是莫大的错误认知阿!! 更多新思维：http://t.cn/8Fo3z3r

 

[#847]达芬奇经常写下『务必彻彻底底想清楚』和『先考虑终点』。从最终目标(Goal)去思考及领悟事物的本源，是欣赏关连的一个好方法。以某种架构来表达其关连及组合，就表现出创意了。

 

[#848]从目标(Goal)领悟其本质并构思其形(Form)，这过程产生创意及其呈现。有了创意之后，以现实条件来检验创意的可实现性、以及创意与现实的调和，这过程产出创意的实现计划。有了实现计划之后，就依据实现计划而贯彻执行。

 

[#849]然而麦肯锡(全球最出名的顾问公司)思维强调分析事实并加以验证，不但让看似天马行空的构思也能逐步修正到可实现的境界，而且把创意视为假设基调，不会让我们等待有好的创意之后才开始思考其实现计划。

 

[#850]架构的新学习法，不是学习更多运用设计模式的技巧。而是学习反思自己心中对于架构本身的诸多假设(Assumption)。

 

[#851]改变我们对架构的假设(assumption)是：在<<呆伯特法则>>一书的作者写道：有些单位透过调整其业务内容，盼望追求美好的未来。这往往是虚掷时间的，其实藉由调整商业计划幕后的<假设>部分，就能有效获得一样的结果。请记得，未来建立在假设上，而假设就是你自己所编撰出来的，没有必要让它绑住你自己。

 

[#852]改变我们对架构的视角。例如，不合理的假设(assumption)是：用户使用App，用户下命令给App，然后App调用平台软件。这是古老的认知，已经不何时宜了。事实上，用户所碰触的是硬件面板或键盘，没摸过App软件。不然，有谁能说说软件摸起来的感觉如何? 像摸猫咪? 像熳鱼?

 

[#853]当用户将小配件连接到TV/STB时，此平台就会启动相对映的(软件)插件(Plug-in)来掌控大、小硬件的通信；而且衔接到上层的应用软件(App)。随着小配件的创新和数量增多，插件也会更新、数量也会增多。

[#854] @让您成为杰出架构师在PhoneGap 框架里有个<插件管理(Plug-in Manager)>模块，由于PhoneGap是一个开源软件，可以对它加以重构而移植过来，做为我们开源开放的<软硬结合平台>里的<插件管理模块>。

 

[#855]此<软硬结合平台>里，需要开发一个软件模块来管理上述的众多插件。这个软件模块，通称为：<插件管理模块>(Plug-in Manager)。它负责管理众多的插件，这插件就是EIT造形里的。

 

[#856]在PhoneGap 框架里有个<插件管理(Plug-in Manager)>模块，由于PhoneGap是一个开源软件，可以对它加以重构而移植过来，做为我们开源开放的<软硬结合平台>里的<插件管理模块>。

 

[#857] #软硬结合架构设计# 软硬结合案例分享：这是支持智能家庭的<软硬结合开发、硬硬结合销售>商业模式的应用软件平台架构设计。在此商业模式里，TV/STB是扮演主角(主硬件角色)，所以这个开源(Open Source)的软件平台会执行于TV/STB里。我们称此平台为：<软硬结合平台>。更多新思维：http://t.cn/8Fo3z3r

 

[#858] #顶层设计# 过去，架构师的设计注重于表达(业务)领域知识的结构，其设计出来的架构，需要再进行细部设计，才能对映到代码结构。这项细部设计，由谁来做呢? 试想，如果架构师直接以代码造型来思考其设计，让架构师与开发者具有一致的心灵、共同的感觉，您觉得会有建设性吗? http://t.cn/8FbhmdD

 

[#859] #顶层设计# 由于"以TV/STB为中心的家庭配件商业模式"里，各主件厂每年的产销量都在千万台等级，采取标准通信配件与非标准通信配件齐头并进，用户自由选择，更加尊重市场与用户。而<平台/插件>架构能够以软件标准接口来封装各种通信协议。做法请参阅高老师的讲座。 http://t.cn/8FbhmdD

 

[#860] #顶层设计# 由数字家庭推进中心主办，高焕堂主持的"以TV/STB为中心的家庭Android配件商业模式的论坛和产品展示"；并不是推行传统的通信标准老路子，而是标准通信配件，与非标准通信配件都是鼓励的。因为<平台/插件>架构能够以软件接口来封装标准与不标准通信协议。 http://t.cn/8FbhmdD

 

[#861] #顶层设计# 我认为，让微博或微信直接连结到家庭里的物(如马桶)，并非最好的。而是为智能家庭建立"Family微博"和"Family微信"平台；然后"Family微X"一般的"微X"对接。"Family微X"平台与<平台/插件>架构，能让家庭平台活跃起来。这种"Family微X"平台，我们通称为"Family OTT平台"。 http://t.cn/8FbhmdD

 

[#862] #顶层设计# 我认为，让微博或微信直接连结到家庭里的物(如马桶)，并非最好的。而是为智能家庭建立"Family微博"和"Family微信"平台；然后"Family微X"一般的"微X"对接。"Family微X"平台与<平台/插件>架构，能让家庭平台活跃起来。这种"Family微X"平台，我们通称为"Family OTT平台"。

 

[#863] #顶层设计#在数字家庭推进中心的策略下，我用心推动"Family OTT平台"，俗称"Family微X"平台。"Family OTT平台"是一个类别(Type)；每一个家庭都是此类的一个个体(Instance)，都有一个2维码ID。家庭里的任何智能设备都是此平台个体的一个插件。对于一般的微信平台而言，上述个体又是它的一个插件。

 

[#864] #顶层设计#这是实体架构设计的新格局，可化解物联网的N:N网状结构的困境，和难以找到商业模式的问题。因为，家庭插件Instance与家庭平台Instance是N:1结构；而家庭OTT平台Instance与Social OTT平台之间也是N:1结构。因此将N:N网状结构，转变成为N:1 & N:1的树状结构。这才是合理的、有效的。

 

[#865]物联网将所有物品都加入到互联网，产生了N:N的网状结构，这种简单架构概念真的无法让智慧城市落地。只需要改为新思维、新概念，改为N:1 & N:1的树状结构，才能大幅降低物联网和智慧城市的复杂度，就更容易务实落地了。 http://t.cn/8FbhmdD

 

[#866]<为什么说炒作概念呢？Family-OTT与其它的OTT有何区别？> 高老师回答："Family微X"平台是一般"微X"平台的一部分，这种"Family微X"平台也是一种OTT平台；OTT确是一个概念，但确让外行人能慨括知道其涵意。

 

[#867] #顶层设计# 这是一般的 {微信平台(移动互联网) + 智能家庭(物联网)}，这种架构属于纯加法的设计，少了有效的减法设计，是个非常容易失控的架构，所以应该重构才能成为有效的架构设计。http://t.cn/8FbhmdD

 

[#868] #顶层设计# 落实"Family微X"平台，此平台能与一般微信、微博、LINE等俗称OTT平台来对接，传统侠义的OTT平台是指从云端将内容(含音视频)送进家庭播放。这里的"Family微X"平台则能双向互联的，例如可以将家庭信息推送到一般微信的手机上。

  

[#869]那么，什么才是有效的架构设计呢? 将属于纯加法的N:N网状结构，配上有效的减法设计，如图所示重构为N:1 & N:1的树状结构。就能让"微X"平台形有机(Organic)成长了。http://t.cn/8Fo3z3r

 

[#870] #顶层设计# 微信是一个理想的顶层系统平台，只是它还是属于N:N的网状系统架构，而不是多层级的N:1树状结构。另一方面，家庭物联网或医疗物联网等，则还偏于通信传输层的N:N网状架构。于是，减化设计为：将物联网提升到如微信的顶层系统架构，然后两者对接成多层级的N:1树状结构。http://t.cn/8Fo3z3r

 

[#871]#顶层设计# 智慧城市的顶层设计本身的神圣职责就是：创造全国性的 "规划文件上要书同文"、"网络通信上要车同轨"、"系统架构上要诗同形"。高老师是基于他提出的EIT软件造形，延伸到EIT-based的智慧城市顶层平台造形，也就是一个多层级的N:1树状平台造形。http://t.cn/8Fo3z3r

 

[#872]#顶层设计# 建议： 1) 秦皇岛数字家庭联盟的"家庭物联网平台" 与 腾讯微信(移动互联网)平台对接；2) 各家庭里的TV(或网关等)是"家庭物联网平台"的主角；3) 各家庭里的主角成为微信平台的插件；4) 家庭里的智能设备成为家庭里主角的插件；构成双层树状架构。5)将家庭平台模是复制到其它领域(如学校)。

 

[#873]"统一系统架构" 目的是要创造 "诗同形" 的整体造形；让各城市、各业务区块、各厂商都能将其各自的内涵以相同的形式来城现出来。就如同，李白、杜甫、白居易等诗人都能将其意境内涵以相同的七言绝句造形成现出来。高老师的EIT软件造形就是这项"统一系统架构" 造形的基础。

 

[#874]物联网各自N:N网状结构的信息孤岛，可以藉由移动互联网来连结起来。例如，城市静态和动态交通系统信息孤岛，该如何与城市行政与规划拓展孤岛，是可行之路。

 

[#875]<<智慧城市顶层设计的统一系统架构刍议>> 在"移动互联网"与"物联网"对接的实践层面，分为绑定(Binding)与数据传输(Transmit)两个步骤。这个统一架构偏于前者，以一个稳定、能有机成长的树状体系来组织众多终端或中间结点；迅速绑定目标对象，并决定最佳的数据传输途径。

 

[#876]#顶层设计# "移动互联网" 与 "物联网" 的对接，主要是绑定(Binding)过程，而不是指连结后的大量数据传输。例如，主人如何用他的手机连结到人形态检测仪，或检测仪如何推送简信通知手机：有大数据已经送到他的邮箱。

 

[#877]#顶层设计# 建议：智能城市顶层设计的统一系统架构>>1) "家庭物联网平台" 与 移动互联网(如微信)平台对接；2) 家庭里的TV(或网关等)是家庭平台的主角；3) 各家庭主角成为微信平台的插件；4) 家庭智能设备成为家庭主角的插件；构成树状架构。5)将家庭平台模式复制到智能城市的其它各领域(如医疗)。

 

[#878]架构师对整个产业的影像愈来愈大。只依赖传统的"抽象思考"，其实并不足够。因为抽象是根据特定视角(View)而抽的，常常会将一些不可或缺的(从别的视角而言)内涵；因而失去内涵的整体性，虽然这样也能从复杂中(抽象而)得到简单，但很可能已经伤害了复杂本身的完整性了。http://t.cn/8Fo3z3r

 

[#879]<<智慧城市的焦点在于智慧，还是城市呢???} 是一个热门议题，您觉得呢? 例如，好睡觉的床，焦点在睡觉，还是床呢? 有内容的电视剧，其焦点在于内容，还是电视剧呢? 还有，嫁一个有钱的老公，其焦点在于钱，还是老公呢? 更多新思维：http://t.cn/8Fo3z3r

 

[#880]#顶层设计# 最近，{ 智慧城市的焦点在于智慧，还是城市呢? } 是一个热门议题。一个城市有许多个面向和面貌，智能只是其中之一。尊重城市的永续发展、全方位的发展；智慧城市并不是"只有智慧的城市"或是"只有物联网的城市"。就像一个人不应该"穷得只剩下钱"一样的处境。更多新思维：http://t.cn/8Fo3z3r

 

[#881]#顶层设计# 为什么智慧城市顶层设计适合采取SoS(System of Systems)思维呢? 因为城市本来就含有无数种、无数个形形色色的小系统(小S)。包括建筑物、自然景物、人、IT系统等，各有各的智能。顶层设计是一群设计师在构思如何"有智能地"将这些小系统(的智能)组合起来，让城市(大S)像飞机一样飞上天。

 

[#882]智慧城市的顶层设计，很像飞机的上层设计。它是基于SoS(System of Systems)的思维，焦点在于左边的"大S"，而不在又边的那一群"小S"。有效顶层设计：将城市里的一群不会飞的小系统，让它们互联互通，组合起来，竟然能飞上天空!! 我认为，没有产生"会飞"的效果的设计，可能就不是顶层设计。

 

[#884]瑞典数学家安德烈斯：用数字说谎非常容易，用数据说出真相則非常困难。在大数据时代，面对与人们工作、生活息息相关的经济数据、市场信息、消费行为等，宜反思这句话，有助于提升敏銳的判断力和洞察力！

 

[#885]有创意的个人才有活泼创新的社会。创意的活动是必须全心全力投入的构思工作，深入掌握设计思考(Design Thinking)技巧，还要加上你的热情才行。高老师每年闭关时间长达3~4个月透入创意构思。欢迎您多观照高老师的<>的创意行列...。

 

[#886]@让您成为杰出架构师#溯因推理# 想成为”创新型架构师”吗? 必备的设计思考方法：溯因(Abductive)推理，请看高老师的介绍。http://t.cn/8Fo3z3r

 

[#887]Android-based项目开发需要敏捷，敏捷需要搭配<创新组合型>架构设计师，架构师需要设计思考技巧，设计思考仰赖溯因逻辑推理能力。

 

[#888]演绎逻辑是从一般性到特定性的推理；例如，一般法则是：会抓耗子的猫，就是好猫。当我们看到一只懒猫(不是好猫)，就可以依演易推理而得知：牠不不会抓耗子。

 

[#889]美国史坦福大学教授 马丁说：朔因逻辑是设计思考者的命脉，设计思考者很习惯探索难题，从不同观点切入，寻找新事物；非常具有创新性。

 

[#890]大多数人看 Android时，是从它的功能、服务、API等上层角度来看的；然而Android是开源平台，可以直接切入底层核心，因此可以摆脱掉功能观点，而从框架视角切入，如附图。接者再从框架基本造形(Form)来看到每一层框架，就能掌握Android的整体架构了。

 

[#891]@让您成为杰出架构师#软硬结合# 鱼头头clover: <<高老师来说说微信怎么软硬结合吧>> 软硬结合应该是"不得不"走的路，也是各企业的商业策略部分，应该自己寻觅，才能变成核心竞争力。更多新思维：http://t.cn/8Fo3z3r

 

[#892]无论是移动应用、物联网等都涉及愈来愈多的系统组合或整合。而软件开发(如敏捷方法)，愈来愈仰赖架构设计，所以架构师们亟需要去更深刻领悟和学习创意型的架构设计模式。

 

[#893]许多架构师追求稳定、可靠、不变的系统结构；这常常导致敏捷开发的困难；所以我主张：架构师要以接口(Interface)为焦点，以组合创新为依归，就能与敏捷完美组合了。更多新思维：http://t.cn/8Fo3z3r

 

[#894]回复TriChaos: 在移动应用和软硬结合应用上，我希望软件变化集中于框架接口的实作基类内；因为这些变化与通信协议或硬件设备有关，为了包容通信&硬件的变动、标准与不标准，软件框架基类内部代码随之而变，代价不高。

 

[#895]回复寒武纪的三叶虫-Q: 敏捷非常依赖重构(重整架构)，能"分合自如"就易于重构，欲分合自如，接口是第一等公民(The first-class citizen)，让接口订益和设计能迅速落实为代码，是"架构+敏捷"完美组合的基石。更多新思维：http://t.cn/8Fo3z3r

 

[#896]balto ：<追求稳定不变的架构往往带来的是僵化和各种千奇百怪的work around.> 是的，架构要持续地改变，支持更多创新、更高度灵活&敏捷。

 

[#897]上善若水_利万物 ：<<重构是不得已而为之！也和别人聊起过敏捷，貌似重构是必然的。>> 如果系统重新组合有大利益可图时，重构就不是成本问题，就希望能"上善若水"，如水之无形地分合自如，重构如流水。

 

[#898]这个世界总是在"虚实相依"状态下才能展示出力与美的组合。我经常谈到微信、Facebook、Line、Skype等，相对于网络运营商而言，属于虚的一层。其可获利的商业模式不可能来自全虚的OTT环境，它必须在智能终端去"落实接地"才能虚实相依，OTT才不会是朵无根的兰花而已。

 

[#899]微信一直没走好软硬结合、端云整合之路，未能达到虚实相依之境；一旦被迫收费了，就会正视"软硬结合"才是移动互联网时代欲拥有话语权、可高度自主性的获利商业模式的本质性(不可或缺性)要素。更多新思维：http://t.cn/8Fo3z3r

 

[#900]在未能将"软硬结合"做到位之前，"微信 = 微利"很可能是事实。因而，一旦走好软硬结合、端云整合之路，达到虚实相依之境，就会摇身移变成为"微信 = 大利"了。

 

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

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

ee                                                                                 ee

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