前言：从"Essence"(本质)这个字看物联网的思维局限。天下物本质上就是多样化的，IOT想把天下物组合于网络上，是加法设计，物物通信的多样化也是本质性的，也只能加法、不能减法。英文的Essence是不可或缺之意；过度要求通信统一(减法)会伤害物物通信的本质(不可或缺的多样化)；所以另寻他途做减法设计。
我认为，数字家庭里的设备"模块化"本来就是正确的方向。模块化是做"分"的动作，是一种厂商的减法设计。问题是：对于家庭主人而言，如合将多个简化的东东组"合"起来呢? 这是加法问题了。于是家庭主人需要有效的减法设计来支撑这个烦人的加法问题。于是，许多人又回到"订定通信标准"的乌托邦减法思路了。
本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。A段获利思维，B段成本思维；两种思维是两个不同视角(View)。然而，商业模式是复杂的，商业策略是多变的，A段架构师宜随时兼顾获利思维和成本思维两种视角，才能灵活调整策略，来支撑商业模式，将获利极大化。
目录：請看目錄
欢迎访问 =>高老师的ADT技术论坛
高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练
ee ee
[#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)来触发迭代，带动设计的重构，调整出最适时的新设计来捕捉未来的机运。
[#1051]许多人认为架构设计要基于用户的需求(Requirements)，然而当用户需求不稳定而多变时，又该如何下手做设计呢? 答案是：以问题(Problem)和愿景(Vision)为出发点，"设计"出初期架构(Simple Solution)，展开敏捷迭代过程。在愿景指引下，探索复杂谜题(问题)，而减法设计出"简单"的Solution。
[#1052]一般人看到专利，第一个反应是想避开它。专利发明人都是聪明人，却不善长说服别人避开不如合作，因为不善长于以战术引导战略(专利创意)。一项战略性的专利，如果搭配其战术的发明，就非常有说服力了，专利就价值连城了，如LED灯的发明专利。
[#1053]@让您成为杰出架构师#敏捷顶层设计方法# 为什么敏捷开发团队会很依赖架构设计呢? 因为敏捷认为需求是善变的，不宜走过去Waterfall方法的Requirement-based途径。需求是测试的基础，不是代码开发的基础。http://t.cn/8Fo3z3r
[#1054]专利是战略资源，一方面用来阻碍对手的战略资源的调度，来阻止对手战术的获利性。专利可以汇集己方的资源，让己方会赢的战术获利极大化。但是，有聪明人发明战略资源，却没发明配套的战术；没有可获利战术搭配，战略可能只是挂在墙壁上的口号而已。
[#1055]<过程(Process)：基于敏捷开发(Agile Development)原则>此方法的顶层设计过程是基于当今最流行的敏捷(Agile)开发原则。以敏捷的测试来带动设计团队进行迭代(Iterative)过程。以测试结果的反馈(Feedback)激发各参与人员(Stakeholder)的反思、讨论与重构设计，让顶层设计止于至善。
[#1056]<决策分析(Decision Analysis)：基于AHP方法>采用常常与EA框架配的AHP决策分析方法，来评估顶层设计里的重要决策。以确设计决策的<最佳性>。
[#1057]<需求检验(Requirement Test)：基于TDD方法> 以敏捷的<测试驱动开发>(TDD, Test-Driven Development)来带动整个设计团队进行迭代过程。这迭代过程，会不断重构顶层设计，来满足用户的功能性需求。
[#1058]于是，架构(&Vision)成为代码开发的起点(Simple solution)。这个起点就是一个起始架构，来自架构师的设计。
[#1061]《设计大变革》有两个甚至在规划专业界也默认接受但是极其错误的观念：一是规划要具备前瞻性甚至有的提出要预判超前十年二十年，那都是胡扯的意淫。连当下的完整信息数据都没有，还想去判断若干年后各种情况，连今天城市人口信息情况都不了解还要去判断未来变化多端的城市人口生活生存状态，实是空想。
[#1062]@让您成为杰出架构师#架构师的反思练习# A段架构师思考技术的形成途径有二：1)自己实践时的思维、视角与反思；2)学习别人的设计思维。杰出与平凡之间的差别就在于是否培养自己的思考逻辑和知识体系。更多新思维：http://t.cn/8FbhmdD
[#1063]平台(操作系统)是轿子，无限(线)感知、云计算、大数据都是轿子的配件，甚至互联网、通信机制都是(轿子的)配件；可是有许多人认为"互联网"或"云平台"是轿子! 观点不一样呀!!
[#1064]@让您成为杰出架构师#架构师的反思练习# <<互联网是中心吗?>> 自从2009年4月，我在北京举办第一届"亚太Android技术大会"，就鼓吹国人要推行Android，但要采取"挟天子以令诸侯"策略，陪育各行业的强龙，我称之小强龙；深耕软硬结合，软件人员不宜只做App。更多新思维：http://t.cn/8FbhmdD
[#1065]自从我在北京举办第一届"亚太Android技术大会"(2009)，当时就已经发现几乎所有国人都把互联网视为平台(Platform)，全力开发互联网插件(如物联网、云计算、海量数据等)。而没有换个视角：其实互联网也是一个插件而已。例如从新娘花轿来看，道路(互联网)只是花轿的配件而已。似乎没人想过要上去坐轿子。
[#1066]我认为是大家把通信层级的互联网视为平台(Platform)的缘故；而忽略了软件层级的真正平台。君不见，当今的物联网产业仍然是典型的互联网是核心、是平台、是轿子的观点，其实互联网只是真实轿子的一项配件而已。观点决定策略、策略决定行为、行为决定结果。
[#1067]@让您成为杰出架构师#架构师的反思练习# <<互联网是中心吗?>> 我们只想做云和端，洋人做平台。云端和终端都是插件(Plugin)，Android是平台(Platform)。插件只是配角，平台是主角。做云和端只是<利用>互联网；做平台是<控制>互联网。利用互联网省钱；控制互联网花钱。更多新思维：http://t.cn/8FbhmdD
[#1068]#互联网只是配件，不是平台# 我认为是大家把通信层级的互联网视为平台(Platform)的缘故；而忽略了软件层级的真正平台。君不见，当今的物联网产业仍然是典型的互联网是核心、是平台、是轿子的观点，其实互联网只是真实轿子的一项配件而已。观点决定策略、策略决定行为、行为决定结果。
[#1069]把通信层级的互联网视为平台(Platform)，<利用>互联网来卖配件(如RFID)，当小弟。重视软件层级的真正平台，则<控制>互联网，当家作主。
[#1070]工信部电信研究院称：Android占国内86.4%市场份额，我国移动操作系统研发对 Android 存在严重路径依赖。1）核心技术和路线受到谷歌严格的控制，并时刻面临谷歌的商业歧视，2）我国移动操作系统起点低、起步晚、3）谷歌已经形成庞大的生态系统了，4）知识产权受制于外人。
[#1071]回复电视空移: 中国字：<容易>就是要包容改变，事情才会容易。易就改变，通信层是底层，最为善变，必须用软件来包容它，才会容易。但是，太多人都想把万事万物挂到互联网(如物联网)。甚至把软件挂在善变的互联网上，就危如累卵、永无宁日了；产业也无法成长茁壮了。电视空移:这个分析精典。
[#1072]我一直都百思不解：为什么大家都看到道路(通信层的互联网)，而没看到上层轿子(软件层平台)；更没看到轿里的新娘子；这样怎能娶到老婆呢?
[#1073]@让您成为杰出架构师#架构师的反思练习# <<互联网是中心吗?>> 应该要反思自己为什么被 "互联网思维" 绑架了10多年，还在为绑架者说情，反过来责怪Android。反思自己为什么一直注视道路地面(底层的网络平台)，不离开地面，又如何上轿(上层软件平台)当新娘子呢? 更多新思维：http://t.cn/8FbhmdD
[#1074]懂得注视道路(通信层的互联网)的人是轿夫；懂得注视上层轿子(软件层平台)和轿内新娘子的人，是新郎倌。
[#1075]<<不满国内移动操作系统现状:严重依赖安卓>> 国人务实，喜欢<看得见模得着>的底层通信平台架构(互联网)，洋人务虚，喜欢<看不见模不着>的上层软件平台架构(Android)。是喜欢不喜欢的问题，不是能不能的问题；也不是时机的问题，有为者亦若是。
[#1076]只有底层网络平台，是不够的；还要软件平台，而且软件平台控制网络平台，而不是将软件切分为两块，分别挂在网络平台的两端：终端与云端。善于处理云端大数据，也是善于推磨的朴人；而不是享福的员外。
[#1077]@让您成为杰出架构师#架构师的反思练习# <<互联网是中心吗?>>大家都知道：想找出迷宫游戏的路径，从出口反向寻找是最有效的，<逆向思维>是支撑有效<减法设计>的必备心理条件。正推思维无法简化迷雾，加法设计又迷上迷，可能掉入深渊而不自知。更多新思维：http://t.cn/8FbhmdD
[#1078]国人思维的严重误区：互联网是平台，软件是平台的插件。于是，软件被切分为终端软件与云端软件；分别插挂在互联网的两端。而Google公司的软件平台(含Android)正好横跨&控制整个互联网；国人的软件变成Google软件平台的两端插件；沦为洋人的附庸!!
[#1079]我一直百思不解：我们学打算盘，利用了算盘，终究会想抛弃算盘；武林大侠楚留香练剑，终究也把剑抛掉了，练成弹指神功。反观，国人利用互联网10多年，早就该抛调"互联网是中心"的古老思维，才能理解Android控制全局的来龙去脉。至今，绝大多数人对互联网的信仰和膜拜，已经失去反思一下的动力了。
[#1080]要说服国人去抛弃<互联网是中心>的信仰；可能比数百年前，哥白尼说服人们放弃<地球是宇宙中心>，还要困难多了。因为心中的宇宙就是互联网，心想Android只是一颗彗星而已，不值得重视。回忆2007年我在西班牙巴赛罗讷市上班，一见到Android即将上市，不久就辞掉工作回来海峡两岸大力鼓吹Android。
[#1081]回复傻瓜阿狸: 懂得离开轿夫的角色，变成乘轿者，才真正懂轿子(互联网)。 //傻瓜阿狸:用户比程序员更懂互联网? //高焕堂:懂得注视道路(通信层的互联网)的人是轿夫；懂得注视上层轿子(软件层平台)和轿内新娘子的人，是新郎倌。
[#1082]懂得抛弃算盘的人才真正懂珠算；懂的抛弃剑，如楚留香者，才真正懂剑。懂得非战者，才是善战者。还持有"互联网是中心"思维者，可能都还不是真的懂互联网!!
[#1083]从底层通信网路而观之，互联网是中心。国人基于这样的思维，5年后会又一次受制于洋人，因为国人擅长<正推思维>和<加法设计>；洋人则擅长<逆推思维>和<减法设计>。例如，高速云计算、海量数据、无限(线)感知等。国人应该静下心来反思自己的<固>有思维，免得5年后长叹技不如人。
[#1084]#好文章推荐# <三星已经意识到，下一个重要领域在于软件。> <未来硬件和软件将进一步整合> 软件是上层平台，互联网是下层平台。http://t.cn/zYnTTdJ
[#1085]@让您成为杰出架构师#顶层设计&减法设计# 软件平台就像集装箱(Container)，将复杂的通信网络、硬件接口、内容格式等包装起来，呈现出简单外形，让人们感到这些事物的可爱、好玩好摸好抱。并没有删除外在事物(如冰箱等)的复杂。而只消除人们心中的复杂感觉，达到简化目的。更多新思维：http://t.cn/8FbhmdD
[#1086]在智慧化潮流中，软件会陆续进入家庭中，那么我们如何看待这个Smart潮流呢? 软件会让家庭复杂化? 还是简化呢? 类似的问题也曾出现于手机智能化的初期阶段，结果人们选择了"以软件简化了的复杂手机"，而不是"简陋的手机"。这项历史，提示了什么?
[#1087]排斥家庭设备的太多智能化，是想维持身外物(如TV)的简陋易用；欢迎家庭设备的智能化，是想透过软件创造身内(心中)的简单感觉，但维护身外物(如TV)的多样化和生命活力。
[#1088]软件平台与网络平台是两的层级，网络平台是以互联网为中心，云端和终端各挂在互联网的两端；两者都是互联网平台的插件。软件平台则想办法让互联网被包容起来，成为软件平台的插件；这是为什么三网融合可能帮三个软件平台抬轿的原故。
[#1089]今天的 <软件+家庭> 类似于 20年前的 <软件+企业>；遥想当年的企业(尤其是办公室)多少IT豪杰逐鹿中原(企业办公室)，但终究归于MS-Office的一统天下。以古鉴今，以互联网为平台的网络层级思维，可能也将臣服于Family的"MS-Office"的软件平台思维之下。
[#1090]在穿戴式移动设备上为成为IT产业的主战场之前，<家庭>这个熟悉的主战场(IT业的坟场)仍是兵家必争之地。如何建立<软件平台+互联网平台>的双层平台，将是赢家必备的系统架构设计。其中成败的关键思维是：不能将软件切分为端与云两块，且当成网络平台的插件；这样家庭就成为插件了。
[#1091]@让您成为杰出架构师#顶层设计&减法设计# 开放智能家庭的标准软件接口，与当今的新兴移动互联网应用业务(如微信、Line等)紧密衔接，让数字家庭摆脱过去的被动接收信息，改变为主动推送信息到家人、小区等。以移动互联网对接的需求带动本产业的整体发展。更多新思维：http://t.cn/8FbhmdD
[#1092]数字家庭(Digital Family)与智能家庭(Smart Family)有何区别呢? 前者偏于物，后者偏于人。家庭里的人是什么角色? 是数字内容的消费者(被喂以内容和信息的对象)，或者在既定范围内有一点点选择内容的权力，或者能与这个互动、创意和做梦呢?
[#1093]以行业型软件平台，弭补现有中间件的不足。在与智能城市的其它行业(如医疗保健、公共交通等)对接过程中，将各行业的专业知识纳入行业型软件平台。基于行业型软件平台来提供整体性的服务跟踪。
[#1094]以行业型软件平台，往下整合大小硬件及通信设备，促进主硬件搭配小硬件的营销模式；往上大力支撑第三方应用开发厂商；往水平方向，与智能城市的其它行业(如医疗保健、公共交通等)紧密对接、互联互通。
[#1095]建立<云端、家庭、移动(手机、车载)>三层组合的新型产品及服务模式。例如，让股票分析师、外语老师能在家里的智能电视里，执行他自己的应用软件，从家外的股票云平台取得股票数据，在家里分析之后，从智能电视将分析建议信息推送到手机的微信画面上。
[#1096]<云端、家庭、移动(手机、车载)>三层组合的新型产品及服务模式。强力支持股票分析师、中医师等师字辈的智能型人物，在最温暖、最熟悉的客厅里跑自己的Android App，产生自己的智能数据，推送到自己的学生，获取收入。这是智能电视(家庭)的美好服务和商机。
[#1097]<云端、家庭、移动(手机、车载)>三层组合的新型产品及服务模式。在自己的家里，跑自己的App，处理自己的数据，做自己的饭，泡自己的茶，服务自己的online客户。乃人生一大乐事也。
[#1098]【智能城市的<顶层设计>并不是<上层设计>】顶层设计应该是指：Top-level Design 。其偏于投资决策前的A段架构设计阶段，做为城市政府立项投资决策的评估依据；而Bottom-level Design则偏于决策后的B段架构设计阶段。<顶层设计>并不是<上层设计>(Top-layer design)。请参阅文章：http://t.cn/8FQwifc
[#1099]面对全世界最巨大&复杂、又必须持续未来发展的中国智慧城镇规划，唯有力求减法设计才能有效包容复杂多变。"敏捷"做过程的减法；而"诗同形"是做架构的减法。大家都知道，唯有简单，才能消除害怕，才能有勇气理解复杂、迎接未来。
[#1100]@让您成为杰出架构师#加法设计：无限创新# 有了愿景和架构的指引，让人们的思考连结到更多的未知(Unknown)新事物。基于减法设计，让人们更有勇气面对复杂。透过迭代和反馈的去芜存菁，让人们更具有信心去经营未来、捕捉新机会。因此，激发出更多的新型商业模式和策略。更多新思维：http://t.cn/8FbhmdD
欢迎访问 =>高老师的ADT技术论坛
高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练
ee ee
1317
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
