A段架构师_隽语集(IT+設計思考_2101)

前言：使用"框架的插件管理器" 管理好业务逻辑插件，包括：插件定义、插件创建、插件配对、插件Callback(含同步与异步)等等。然后，让 HTML5幕后的WebView事件能传递给管理器，同时也能让Android一般的View的事件也能传递给管理器，就行了。

    有些业务逻辑需要在终端上执行。例如，有些游戏的运算、影像处理逻辑、还有，如股票分析师在自己家庭里的TV/STB上执行。在Android平台上的同一份业务逻辑插件(Plug-in)设计，可以提供给HTML5-based App使用；也能给传统Native Android App使用。你知道如何达成这目标? 你知道这对大型移动终端应用开发有多大的好处吗? 攸关客户业务逻辑的分析、设计、维护和复用等等。 

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。在进行战术引导战略过程中，A段架构师脑中清晰可见未来成功景象(愿景)，反向推理回到现在(Mapping from vision to reality)，找出会赢的战术，汇集有利的战略资源让战术效益极大化。由于战略资源的取得和应用有其时效性和稀有性，不一定能重复取得，所以优势战略非常难以复制，其会赢战术也难以复制。

目录：請看目錄

欢迎访问 =>A段架构师技术论坛(ADT)

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

ee                                                                                 ee

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

  

[#2101]今年来，我积极推动行业别应用框架(AF)平台开发技术和实务交流，包括框架API规划&设计，企业的业务逻辑插件(Plug-in)、平台插件的开发、复用、改版、测试和管理等。也含敏捷开发&测试框架等。

 

[#2102]即使是身为 "码农" 的App开发者，也不应该继续坚持从 App看软件世界视角，因为这样就无法知彼知己，扩展视野了。更多新思维：http://t.cn/8Fo3z3r

 

[#2103]只要使用"框架的插件管理器" 管理好业务逻辑插件，包括：插件定义、插件创建、插件配对、插件Callback(含同步与异步)等等。然后，让 HTML5幕后的WebView事件能传递给管理器，同时也能让Android一般的View的事件也能传递给管理器，就行了

 

[#2104]有些业务逻辑需要在终端上执行。例如，有些游戏的运算、影像处理逻辑、还有，如股票分析师在自己家庭里的TV/STB上执行。 //@Angry_Jimmy:业务逻辑，是不是做成web service比较好？

 

[#2105]在Android平台上的同一份业务逻辑插件(Plug-in)设计，可以提供给HTML5-based App使用；也能给传统Native Android App使用。你知道如何达成这目标? 你知道这对大型移动终端应用开发有多大的好处吗? 攸关客户业务逻辑的分析、设计、维护和复用等等。

 

[#2106]我百思不解，为什么系统架构都是<移动端/建康云>两层架构呢? 如果设计为<终端/家庭云/建康云>三层架构又如何呢?

 

[#2107] 客厅配件市场是<藉助TV/STB的既有销售渠道>帮配件厂商创造量产机会。在将TV/STB与微信平台对接的，微信也将是<3亿个移动用户 + 3亿个家庭>的中心平台。 更多思维： http://t.cn/8FGlU1n

 

[#2108]许多架构师偏向于将所有 "业务逻辑" 摆在后台Web Service里。这可能带来分工开发上的极大困境。例如，移动端与后台的分工中，业务逻辑的变动部分该分给谁来做呢? Web Service接口属于被动型API，将让后台开发者成为前端开发者的小弟，还可能沦为救火队!!

 

[#2109]#行业应用API设计# 行业应用API设计，依赖丰富而扎实的行业领域知识，包括从客户进行Use Case分析，从企业经理分析Business Rules，从产业资深专家分析领域概念及其信息结构等(如图)。之后，对映到EIT代码造形，将其<E&I>部分美妙组合成为框架和API了。

 

[#2110]家庭的主人应该有全利决定其家庭建康检测数据如何授权给医疗机构，而不是使用不同检测仪器而分散于自己都不知道的"云平台"!! 唯有尊重家庭人员的权利和隐私，家庭健康产业才能健康成长与茁壮!!

 

[#2111]@让您成为杰出架构师#家庭物联网 + 微信移动互联网# 智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

 

[#2112]行业型应用框架，可以扩大成为应用平台(即俗称的中间件)，提供API来支持特定行业的App开发，并将客户插件交给App开发者，外包出去。这些客户插件包括因客户不同而有差异的各种逻辑(含UI、业务性、平台性)，都能外包出去，大幅降低公司的系统开发、管理和维护成本。

 

[#2113] 在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。更多思维：http://t.cn/8Fo3HIo

 

[#2114]行业型应用框架开发的主要效益，必须从"分工"的角度去衡量，不是仅仅从Client/Server 或<移动端/后台云端>的实体硬件或网络架构去看。这也是为什么当今业界那么重视以框架来提供API的原因。掌握API的制定权，就拥有产业的话语权!

 

[#2115]我百思不解，为什么Android开发者都只会用代码表示想法，而不重视图形思考；那么，请问接口(Interface)如IBinder, BnInterface<T>又如何从代码里看出来呢? 我从2007年陪着Android产业发展，但是显而易见的是Android开发者心灵并没有同步成长，颇令人忧心的。

 

[#2116] 敏捷的精神，偏向于UML是代码的图形表示。或是坚持1990年代的UML图形表示呢? 我是偏于前者，代码就是 {基类 / 子类}的结构，例如Android、iOS的代码都是如此。这是视角问题，不是真理问题。取决于 代码的 {基类/子类}结构是否需要与UML一致的问题。http://t.cn/8Fo3z3r

 

[#2117]人人都在谈"从开发到设计"，却没留意到"从(架构)设计到(代码)开发"的反向观点。例如，类(Class)观念是来自于OOP，是代码层级的结构改进，却因而改变了系统分析从结构化(Structured)设计改变为OOAD设计，也改变了测试单元和方法。因此，让架构师回归到代码造形也是很关键的。

 

[#2118]特定行业的软件框架，易于跨OS(和硬件)平台；反之，特定平台的框架，则易于跨行业。因之，特定行业的软件框架，能有效地跨Android、iOS和Win-8平台，不依赖HTML5也能轻易跨平台。

 

[#2119]#行业别框架&API# 基于行业别框架&API，独立出业务插件，并由框架管理之，基于这些共享插件，和一致性API，而发展的跨平台App，可称为<行业级别app>。 

 

[#2120]在古典的架构思维里，”平台 = (服务)引擎”，App直接使用平台(引擎)的API，由于引擎API是被动地被调用(左图)，往往绑死引擎，业务规则代码动弹不得，带给企业恶梦。为了维护底层<引擎>的变动自由度，就采用新思维和新架构实践(右图)。

 

[#2121]掌握行业应用API，才有软件平台上的话语权，才能具有商业策略的主导权。行业API来自软件框架设计与特定行业的领域知识(Domain knowledge)的完美结合。唯有兼具<架构+代码>的优质架构师，才能设计出优越框架和API，强力支撑商业策略。

 

[#2122]如今，数字家庭产业的客厅配件市场的全新商业模式里，平台软件几乎完全是Android天下了。数字家庭OFA联盟大力整合产学研之力量，推动<以TV/STB为中心的数字家庭产业的客厅配件市场>新兴产业策略，并有投资基金支撑。

 

[#2123]<<Why? Android学生的投资效益日益低落?>>Android产业的发展活力，一直以来都在于它的开源开放，扎根于软硬结合，向多机整合、多屏互动，物联网+移动互联网发展出枝叶茂盛的大树。产业路线与iOS, Win-8封闭平台不同，所以教育途径也应该不同，否则不适当的初学途径，只会让学生投资效益更低落!!

 

[#2124]随着Android平台的飞跃成长，各行各业的<行业别应用框架平台>日益受到关注，<行业别应用框架平台>意味着：专门的行业知识+软件框架技术。尤其是该行业的领头羊企业，掌握了最完整、最先进的专业领域知识；一旦这些知是纳入软件框架平台，并掌握API，则能大幅提升它在整个行业的主导性。

 

[#2125]在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。

 

[#2126]行业别应用框架(AF)平台开发的关键部分：业务逻辑插件的接口(API)设计。只需要替客户(如广电CRM)一份API，以不同平台的语言(如Android的Java，iOS的Objective-C)实现之。针对一个客户，只需要一套需求分析、一套架构设计、一套测试方案，大幅节省开发费用和时程。这是大型行业移动应用项目的必然之路。

 

[#2127]家庭配件市场策略与商机# 客厅配件市场是<藉助TV/STB的既有销售渠道>帮配件厂商创造量产机会。在将TV/STB与微信平台对接的，微信也将是<3亿个移动用户 + 3亿个家庭>的中心平台。 更多思维： http://t.cn/8FGlU1n

 

[#2128]<从客厅看Android TV/STB可看到"客厅配件市场"巨大商机；也可看到TV/STB与微信平台对接的庞大商业机会。> 这项超级的架构设计，将影响数亿人的移动和居家生活，并带来庞大商机。同时，腾讯微信将成为全球最大的<移动互联网+物联网>的整合中心平台。

 

[#2129]当敏捷(项目)团队不顺畅时，如果从团队管理视角去求解，而无效时；很可能是架构设计是问题所在，可尝试从架构设计视角去求解。来自架构师的视角和习惯的蜕变；就能 让架构设计和项目开发都敏捷起来。信不信由你!!更多思维： http://t.cn/8FGlU1n

 

[#2130]#敏捷开发# 如何解答<Android项目 + 敏捷开发>的谜题呢? 

 

[#2131]YES；但是，如果架构师和架构设计本身并不敏捷的话，可能无法支撑整体项目的敏捷开发呢!! 更多思维： http://t.cn/8FGlU1n

 

[#2132]<Android项目 + 敏捷开发>谜题的焦点：传统架构设计视角偏于抽象思维，致力于抽象出稳定、可靠、不变的共同性架构；做为应用发展的基础。然而，这项稳定架构无法迅速得到，不是“足够好”而已，这违背敏捷的Simple Solution的要求，不易迅速推动敏捷迭代。

 

[#2133]组合的核心工作就是“接口”设计。因而，架构与敏捷完美结合之秘诀就是：每回敏捷的迭代，都让其接口落实为代码，交给TDD来触发反馈 。

 

[#2134]其实，<Android项目+敏捷>是完美结合。Android完善的测试框架，有利于TDD机制来推动迭代。此外，Android是一个多层框架(Framework)体系，框架内涵是代码，能密切配合TDD和迭代过程。那么，<Android项目+敏捷>不顺畅的谜底又是什么呢?

 

[#2135]当敏捷项目推动不顺畅时，大多将焦点放在"组织架构"的改进上，因此把偏重于项目经理(PM)和团队领导(如Scrum Master)的视角和技能的改变上。但是，我则另寻他途，将焦点放在"架构设计"的改进上，因此专注于架构师的视角和技能的<蜕变>上。

 

[#2136]无论是基于Android或iOS等OS平台，建构自己行业的软件框架都是非常重要的，为什么呢? 理由只有一个：掌控API接口，制约别人的软件模块，而且保护自己的业务逻辑模块。例如，图中的中间件框架掌握了三项接口，安内攘外作用兼备矣。

 

[#2137]#行业应用API设计# 行业应用API设计，依赖丰富而扎实的行业领域知识，包括从客户进行Use Case分析，从企业经理分析Business Rules，从产业资深专家分析领域概念及其信息结构等(如图)。之后，对映到EIT代码造形，将其<E&I>部分美妙组合成为框架和API了。

 

[#2138]物联网业者给家庭带来许多的"加法"思维，也带来复杂思维，例如买来三星的烤箱，如何与TCL电视机对接呢? 谁来对接呢? 物联网厂商? TCL? 三星? 都不是!! 而是第三方App开发者来替用户做"减法"设计。请问：这些App跑在那里? 在网关??

 

[#2139]软件框架的存在，犹如万里长城的作用，API的功用也犹如山海关的作用。唯有主动型API才能像山海关一样制约关外势力(App)，才能保护关内居民(即底层模块的变动自由度)。只要了解这个道理，你就能理解Android关于DB的架构设计了。

 

[#2140]传统上，将框架视为平台，会产生严重误区；因为许多人因而会求平台稳定、可靠和不变；这是不对的。框架像集装箱，可容纳形形色色的业务逻辑模块(即软件的插件)，也备有优良的插件管理器(如图)来管理插件。其实，人人只能追求稳定的API。

 

[#2141]行业框架能跨越移动终端与后台云端(如附图)，能有效化解过去Client-Server架构的分工困境。古典分工模式让Server团队成为忙于应付终端需求的"救火队"；主要原因是Server提供给Client的API属于被动型API，被Client调用，没有主导权所致。

 

[#2142]框架不仅仅是软件系统平台而已，其API是该行业里<强龙/地头蛇>分工与合作的分界线。在更高级的架构设计里，框架与行业领域的业务逻辑引擎是分离的，自家的逻辑引擎(如图右下)模块必须被框架完美而有效的保护，确保其变动的自由度。

 

[#2143]#家庭物联网 + 微信移动互联网# 智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

 

[#2144]掌握在"智能家庭软硬结合平台者手中"；例如，1980年代企业办公室的争霸战，掌握Office平台软件的MS得天下，而不是思科、或宏碁。综观当今物联网业者，都是以数据流动、网络流量思维为主，可能比彩电厂商更没机会，更是当局者迷；您觉得如呵呢?

 

[#2145]<<微信 + 智慧家居>> 对于微信而言，最好的切入点是智慧家居。智慧家居是物联网9大试点领域最接近终端用户的行业，智慧家居是最需要人与物互动的物联网行业之一。

 

[#2146]有人问我：为什么需要去推动这项对接工作呢? 不是让家庭的电视机或网关成为微信平台里的一个客户终端就行了吗? 替电视机赋予一个2D码即可了。这是单向沟通功能而已，并没有考虑到家庭信息(如Shopping List)推送给家人的微信手机客户端的双向流畅联系。

 

[#2147]智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

 

[#2148]着眼于家人(family)的心灵联系的无限关怀：在外用微信手机终端，回家在客厅使用TV等的双向沟通&家人心灵联系。这个视角可让人们重新看待智慧TV，例如传统上认为TV就是娱乐、就是一块屏、就是音视频播放而已；并没有真正发挥"智慧"的时代意义。

 

[#2149]这项超级架构设计的主要功能并不在于传统的"智能TV"或"智慧家居"的视角，例如从手机端操控家里设备等等。而是着眼于家人(family)在外用微信手机终端，回家在客厅使用TV等的双向沟通&家人之间心灵联系的无限关怀。

 

[#2150]这项超级架构设计的神奇效果是：物联网和移动互联网两者都是N:N大型网状结构(Network)；在相对接之后，却神奇地变成更大的树状结构。虽然变大了，确因树状结构(Hierarchy)而能稳定、有机成长。这种神奇效果来自高老师的EIT造形的架构设计新思维。

 

[#2151]许多人将TV/STB定位成为音视频播放的娱乐终端，然后就没继续探究TV/STB的"非音视频"角色。因此，比较不容易领会TV/STB成为微信平台的"不移动终端"的重要涵意了。

 

[#2152]客厅里的TV/STB将扮演重要角色，可与微信对接，成为微信的"不移动客户端"。微信既有的3亿移动客户端，服务在外的家人； 国内3亿个家庭里的"微信不移动客户端"则服务在家中的人。创造极为温馨的"Family"生活。

 

[#2153]微信平台就像一个轿子，它的必备条件是有人抬轿。就微信而言，目前的商业应用都属于依附轿子的人，而非抬轿人。一旦，微信能回首关照一下抬轿人，也让抬轿人受惠，则微信平台就会涌现无限多的新潮商业模式了。

 

[#2154]数字家庭# <<OFA不是制定TV业界标准>> 高老师正担任<工信部数字家庭促进中心>的OFA联盟主席，致力于<数字家庭物联网与移动互联网(如WeChat、Weibo)>对接API规范。但是许多人误解这是制定官方标准的老路；其实是基于数字家庭产业的客厅配件市场的全新商业模式而规划。更多思维：http://t.cn/8Fo3HIo

 

[#2155]Android是开源开放的平台和系统，就像一棵大树；当您想要了解它、爬它、养它、喂它、安慰它、疼它、在它树下乘凉抓萤火虫；您完全可以就树干(架构)、树根(底层驱动)、树梢(App)兼顾；而不是当瓢虫在外围看树叶(App)。这是许多Android初学者的陷阱，高老师给您一条轻松之路。

 

[#2156]我除了盼望将Android最新潮的知识和软件技术普及到乡村各地，也盼望这些广大地区的人才，能透过互联网而帮全球各地的业主，开发杰出软件，包括新潮的智慧电视、车机软硬结合系统，工业物联网与WeChat的信息推送业务等。深山幽谷里的人才是被正确呵护、关怀、培养，就绽放无限芬芳。

 

[#2157]Android产业需要培养更多的软硬结合、多机整合多屏互动、端&云结合的人才。这种人才的培养需要整体观，需要善用Android开放开源平台的特质，唯有紧扣这项特质，从第一秒钟得初学就培养全局观才是正确的教育。就如同，要培养好的网球人才，第一秒钟就要进场，而不对着墙壁打球!!

 

[#2158]App代码开发者要清晰业务流程(Logic Flow)；平台(系统)代码开发者要清晰内存进程(process)和线程(Thread)。两者兼顾，整体系统才能稳定发展。由于Android是开源开放平台，初学者必须一开始就非常重视线程，才能放眼全局，有正确的视角和视野。学习Android本来就不应该跟iOS、Win-8一样的学法!!

 

[#2159]在学习Android时，从第一秒钟就持着优雅的素养：对于每一行代码，都必须能准确而正确地说出来，目前该行代码正由那一个线程(Thread)所执行的。

 

[#2160]#码农的图形思考# 为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 更多思维：http://t.cn/8Fo3HIo

 

[#2161]我在课程里，全程使用世界标准的UML Class Diagram来绘制架构图，以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。兼具<代码+架构>就能陪养正确的素养，正确的学习出发点，是成功的保证。例如，学习打网球时，先面向墙壁练球，球感素样就永远错了。

 

[#2162]<<Why? Android学生的投资效益日益低落?>>Android产业的发展活力，一直以来都在于它的开源开放，扎根于软硬结合，向多机整合、多屏互动，物联网+移动互联网发展出枝叶茂盛的大树。产业路线与iOS, Win-8封闭平台不同，所以教育途径也应该不同，否则不适当的初学途径，只会让学生投资效益更低落!!

 

[#2163]当今Android初学者的<码农式>(又谑称"码奴式")教育方式，让人人的学习的"本益比"日益低落。因为忽略了Android式开源开放的平台，其产业发展的活力来自软硬结合，多机多屏互动，以及"物联网+移动互联网"系统开发。<码奴式")初学教育阻碍产业发展!!

 

[#2164]<<为一个新兴市场而整合>> 将移动互联网平台(如Weibo,Skype)的软件接口，做进去数以亿计的Android TV里，这不是去订定业界标准，而是为了一新兴的巨大市场而整合。这就是：以Android TV为中心的智能家庭的客厅配件市场，并提供Android新一代整合开发者创业的空间。

 

[#2165]#行业别应用框架开发# 在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。更多思维：http://t.cn/8Fo3HIo

 

[#2166]<<为一个新兴市场而整合>> 我主持的<工信部数字家庭促进中心OFA(Open Family Alliance)联盟，不是要去订定业界标准，而是为了一新兴的巨大市场而整合。跳脱古典的音视频视角来看Android TV和智慧家庭，从具有高度产值的客厅配件市场出发，衔接移动互联网，延伸到广大的移动终端。

 

[#2167]<<为一个新兴市场而整合>> 如果你从主件的战场下来，可以转移到配件市场，例如来自美国的柯博文老师将与IC Coffee合办的<iPhone & iPAD 与接口设备连结之软/硬/韧体应用整合开发>技术讲座。此外，高焕堂老师也担任北京数字家庭OFA联盟主席，致力推动<以TV/STB为中心的家庭客厅配件市场>。

 

[#2168]随着Android平台的飞跃成长，各行各业的<行业别应用框架平台>日益受到关注，<行业别应用框架平台>意味着：专门的行业知识+软件框架技术。尤其是该行业的领头羊企业，掌握了最完整、最先进的专业领域知识；一旦这些知是纳入软件框架平台，并掌握API，则能大幅提升它在整个行业的主导性。

 

[#2169]使用世界标准的UML Class Diagram来绘制架构图，不仅内容以作品来期许，还以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。

 

[#2170]#码农的图形思考#为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 更多思维：http://t.cn/8Fo3HIo

 

[#2171]善用UML类图(Class Diagram)来表达代码结构，是迈向有效架构设计的起点。我在课程里，全程使用世界标准的UML Class Diagram来绘制架构图，以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。

 

[#2172]<<图形思考>>。有效的架构师都具备出色的图形思考能力。目前Android课程和教案，唯有高老师坚持特别重视培养开发者的图形思考能力，其它大多数书籍都只有代码，非常不利于开发者迈向架构师之路。

 

[#2173]从代码解析软件，和从结构理解软件；它们本来就是两个必备的学习途径。从代码解析软件，仰赖流程逻辑；从结构理解软件，仰赖架构接口。在传统封闭平台上(如 Windows, iOS)只能依循<从代码解析软件>学习途径；在Android开源开放平台上的正确学习途径则是<代码+架构>兼具。

 

[#2174]从代码解析软件，和从结构理解软件；它们本来就是两个必备的学习途径。在Android开源开放平台上的正确学习途径则是<代码+架构>兼具。<从结构理解软件>需要以图形来表达软件里的类(class)和接口(interface)，以及其间的关系(relationship)，此时像UML class diagram就很有用处了。

 

[#2175]<<如何让码农也使用UML?>> UML用在系统建模是OK的，但是Android开发者和书籍作者都不用它；因为UML都被用来表达业务逻辑、企业对象和用例分析，而不是给<码农>来表述其代码架构，这是UML的瓶颈也是Android开发者的损失。我希望UML不仅能表达大象的知识，也能完美表述小虾米(码农)思路。

 

[#2176]为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 其用意是：以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。在Android开源开放平台上的正确学习途径则<代码+架构>兼具。<从结构理解软件>需要以UML来表达软件里的类(class)和接口(interface)。

 

[#2177]由于云计算、大数据中心的潮流，使得人们都是围绕着数据去思考系统架构，却忘了：一个云一张网、一个中心一张网，产生的信息孤岛大问题。因此，我们必须从"网"的角度去建构一个超级架构，来整合各云计算、大数据中心所衍生的网，而间接、实质地整合了大数据本身。

 

[#2178]@让您成为杰出架构师#顶层设计# <<家庭物联网 + 微信移动互联网>> 这项架构设计的神奇效果是：物联网和移动互联网两者都是N:N大型网状结构(Network)；在相对接之后，却神奇地变成更大的树状结构。虽然变大了，确因树状结构(Hierarchy)而能稳定、有机成长。这种神奇效果来自高老师的EIT造形的架构设计新思维。

 

[#2179]双向联系的典型范例：TV里有个家庭Shopping List，早上安排好家人预定购买的东西，并储存于Shopping List上。下班时，家庭妈妈临时逛了超市，决定将东西都买了。于是透过手机浏览器上网，访问TV里的网页去更新Shopping List。TV立即透过微信平台将更新信息推送到各家人的手机终端。

 

[#2180]家庭物联网的专注焦点，逐渐从原来的House转移到Home，如今更迈向Family。因为House因Home而存在；至于Home则因Family而存在。更何况，一个Home有多个house；一个Family可能分散于各Home。此时，TV/STB将扮演联系Family的"不移动终端"。

 

[#2181]TV/STB的主板大厂沟通，都非常期待早日与微信对接，将微信推送的接口安全机制，部分直接写入主板里。如此让微信直接深入TV/STB的硬件核心，实现与3亿个不移动终端之间的虚实相依，将能有效弭补微信在移动终端一直无法虚实相依，缩小商业模式空间的短板问题

 

[#2182]在这超级架构设计里，"虚实相依原则"与"EIT设计造形"，一直扮演着设计的核心思维。其中的虚实相依原则是：虚在上，实在下；务虚者必须主动接触务实者，否则虚脱离了实，就像失根的兰花，难以取得养分或水分(在商业上，就是难以找到创新的有效商业模式）。同时，务实者也会生存得很辛苦。

 

[#2183]一旦微信切入了TV/STB的主板(Motheboard)，就能依循EIT树状体系架构，而迅速、顺势网下层延伸，掌握了整个家庭物联网众多Sensor端。以此类推，一旦掌握了家庭，此模式就能进而复制到学校、医院等来服务教师、医生等。于是，微信-based的智慧城市就自然形成了。

 

[#2184]高老师提出这项<<智慧城市顶层设计的统一系统架构刍议>> ，仅仅是"造形"的建议而已，并没有任何实践"标准化"的意图。例如，唐诗七言绝句的形式，并没有强迫或规范李白、杜甫等诗人的意图。

 

[#2185]Herbert Simon(经济学诺贝尔奖得主)写的一本书：The Architecture of Complexity，谈到N:N网状架构可以转变成为多层级N:1树状体系，得到稳定、有机成长的活力。所以发现，这正是全国智慧城市顶层设计的有效思维借镜。更多思维：http://t.cn/8Fo3HIo

 

[#2186]回复青润: 1. 基于我提出的多层树状体系，以手机进形摄像机和后台的动态绑定(Binding); 2)摄像机和后台进行视频实时分析处理； 3) 信息推送到手机。

 

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

 

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

 

[#2189] 有人问到：为什么要由"移动互联网"来衔接智慧城市里各个区块的"物联网"呢? 其实，我是倒过来从物联网出发的，想藉由"移动互联网"来将各"物联网"的信息，推送到移动终端里，因为这些物联网悠关的主人们(Stakeholder)大多随身携带移动终端。更多思维：http://t.cn/8Fo3HIo

 

[#2190]可先从目的想起。Herbert Simon(经济学诺贝尔奖得主)写的一本书：The Architecture of Complexity，谈到N:N网状架构可以转变成为多层级N:1树状体系，得到稳定、有机成长的活力。所以发现，这正是全国智慧城市顶层设计的有效思维借镜，改善目前物联网网状架构的瓶颈。

 

[#2191]<城市远比家庭更为复杂> 所以大家想想如何在架构设计上，从众多N:N结构的信息孤岛群中，建立一个比较稳定、能有机成长的多层级树状体系。由于只是结构之形，与各业务(如家庭、医疗、公交等)的内涵是无关的。

 

[#2192]就微信而言，透过各业务区块(如家庭、医疗、公交车等领域)里的小平台(如家庭平台)的主角(如TV)，来间接(却众星拱月)地连结到物联网的感知终端，因而以API衔接到无限数量硬设备，可以弥补微信在移动终端OS和通信平台上没有掌握对硬设备API的主导权的困境。

 

[#2193]@让您成为杰出架构师#顶层设计# 智慧城市源于物联网的基础，实体层是网状结构，但是逻辑层必须转换成一个较为减化的结构，才能支撑上层商业的复杂关联性。例如，Database的结构设计，实体层的数据结构识网状的，必须经由Normalization的减化才能稳定、有机成长。更多思维：http://t.cn/8Fo3z3r

 

[#2194]就微信而言，透过各业务区块(如家庭、医疗、公交车等领域)里的小平台(如家庭平台)的主角(如TV)，来间接(却众星拱月)地连结到物联网的感知终端，藉由微信强大的互联能力来帮各物联网推送信息(不一定是实际数据)，借机成为智能城市的Command Flow整合中心，也帮了物联网和城市。

 

[#2195]武汉是全球幅员最大的城市，但目前许多信息孤岛，就像古代的中国。欲社会和谐、生态均衡，顶层设计需要"减法设计"，如秦国 " 书同文、车同轨"，和唐朝"诗同形"。亦即，专家Brooks提出的Conceptual Integrity。

 

[#2196]我建议武汉在规划层面要留意：规划概念的一致性(即书同文、车同轨、诗同形)。另外我还建议在系统架构上，可藉由移动互联网(如微信、微博等)来联接众多物联网，将众多的网状信息孤岛，转变成为多层树状体系。

 

[#2197]智慧城市的焦点在"智慧"而不在"城市"，城市本质不能因智慧而变，它是永续经营的；智能本身则是善变的，就像衣服(智慧)加诸于人(城市)。衣服要随着人的成长而换新，不能将人"衣服化"，也不能将城市本质智慧化了。

 

[#2198]高老师提出这项<<智慧城市顶层设计的统一系统架构的刍议>> ，仅仅是"造形"的建议而已，并没有任何实践"标准化"的意图。例如，唐诗七言绝句的形式，并没有强迫或规范李白、杜甫等诗人的意图。

 

[#2199]将Android与iOS采相同的初学教育方式，很可能是错误的。因为iOS封闭，学员看不到树干，只好看树叶，各自想象树干长相。Android可以直接看树干，对树叶的来龙去脉轻易撩若指掌，何苦只知其然(树叶)不知所以然(树干)呢? 换个有效的新观点!!

 

[#2200]@让您成为杰出架构师#敏捷开发与Android# 为什么敏捷开发与Android是个很好的搭配呢? 更多思维：http://t.cn/8Fo3z3r

 

 

欢迎访问 ==>A段架构师技术论坛(ADT)

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

我們都很欣賞孔明的空城計和千古文章"隆中對"，可是孔明沒有寫出他"如何思考"空城計，也沒有寫下他"如何構思"隆中對裡的三分天下大策略，只留下大策略，卻沒有留下"策略思考技術"。今天高老師以傳承"策略思考技術"為職志，盼望大家的支持&鼓勵。

ee                                                                                 ee

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