前言：基于parts(行人与汽车)和whole(社会)的需要的平衡之目标，架构师就设计出<红绿灯和班马线>，其规范parts之间的接口(interface)，进而细腻订定两者的互动规则(rule) ，如车站、月台、先上后下、排队上车等。上述的接口和互动规范就是架构师的核心职责，在交通系统如此，在软件、硬件系统也是如此。

架构师思维演练的第一要素是时间：从未来回顾现在。第二要素是空间：专注于领悟The needs of the whole 与 The needs of the parts。例如，街道上十字路口，其攸关的whole 和parts各为何? 其needs又为何呢? whole(如社会)和各parts(如汽车和行人)都是<实>个体，各有需求，常常互相冲突和摩擦。如何让化解冲突和摩擦，架构师要设计<虚的虚>结构(Structure)来规范协调。然而虚结构没有行动能力，架构师就创造(无中生有)一些<虚的实>个体来执行协调任务。

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

目录：請看目錄

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

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

ee                                                                                 ee

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

[#751]@让您成为杰出架构师<<架构师思维练习>> 悟道。自然界生物之设计，其主要限制是<信息的有限性>。因而自然界之道是：单纯造形、内涵不同、无限重复。例如，人的手掌，其造形简单、细节纹路不同，无限重复；树叶也如此。如果软件架构也如此，必然具有旺盛生命力，例如OO技术里的Class, 造形简单、个个内涵不同、无限重复。

[#752]唐诗的7言绝句中的<句>就是一件很好、美丽创意的文词<造形>，它具有：简单造形、每句内涵不同、无限重复。愈能将这种创造新的造形的思维习惯发扬光大的朝代，社会生命力就愈旺盛、社会愈和谐。更多新思维：http://t.cn/8FbhmdD

[#753]小米把终端(硬件)产品当作战略物资，网络(软件)服务作为战术武器。唯有战术能在战场上获利，战略支持会赢的战术，让战术效益极大化。如果网络(软件)服务是小米的<会赢的战术>，则小米的愿景是合理的。

[#754]过去大家开发平台或应用框架(Framework)时，都采取"分析、抽象"的途径，一心一意追求通用性、稳定性；EIT门派抛弃这项思维，采取<师法自然>途径，追求<造型简单、内涵不同、无限重复>的上帝造物法则。这项方法来自台湾框架设计联盟的研发项目，目的为了促进IT业迈向软硬结合之路。

[#755]我一直关注<整合>；身为华人思维习惯：<分析>辨认事物而生知识，<抽象>而归纳出较共通性(华人信以为就是道)。华人擅长<分>与<抽>之外，还欠缺<合>。基于我在美、欧、日将近十年生活中，体会到华人需要把<合>的短板补起来。例如，肯德基的半鸡是组<合>出来的；而全聚德的半鸭是<分>解出来的。

[#756]从应用而观之，面向对象(Object-Oriented)的主角是Object；从软件架构而观之，OO的主角是Class。这Class具备<造型简单、内涵不同、无限重复>特质，这依循上帝造物法则：信息局限性(Information limitations)。它具有无现活力和巨大商业潜能。多年来，让我百思不解的是：为何华人对此物的发现不感兴趣?

[#757]名人Will Rogers说：不是那些我们所不知道的事情带给我们麻烦；而是那些我们信以为真，但却实际上并非如此的事情(假设及其推论)。

[#758]蒋友柏谈品牌：品牌可以分成品味、品性、品格三个面向，缺一不可。成功的品牌是一种病毒，就如同"爱"一样，当市场知道它后，愿意靠近它、了解它、进而爱上它。 ~~ 摘自 <<蒋道设计>>一书，蒋友柏(蒋家第四代) 着。

[#759]Whole-part与有机次序(Organic order)。软件设计模式(design patterns)的概念是源自著名的建筑学家Christopher Alexander。他说："We define organic order as the kind of order that is achieved when there is a perfect balance between the needs of the parts, and the needs of the whole."

[#760]Italk新经济沙龙 ： 回顾【一孔之见：员外和长工】与高焕堂老师谈话，我常常是这样：高老师，您刚才说的是不是这个意思？然后我把我的理解，用我的语境再说一遍。因为高老师确实是很上心，很会思考，常常出乎意料，常常让你醍醐灌顶

[#761]在架构师心中，攸关街道十字路口，有两种parts：行人与汽车；并且有一种whole：城市社会。试想，各part的needs是甚么? 该whole的needs又是甚么? 如何才能让它们达到Christopher Alexander所说的 "perfect balance between the needs of the parts, and the needs of the whole" 呢?

[#762]设计API就是设计别人；相对上，开发AP就是被设计而不自知。API是不平等的协议或条约，如同马关条约、南京条约。掌握API制定权是非常重要的。最近两个月，我在台北闭关写书，书名：<<如何开发Android框架和API。>> 其中API就是接口，框架支撑API。更多新思维：http://t.cn/8FbhmdD

[#763]whole(社会) 的need是：<和谐>。part(行人)的need是：安全过马路。part(汽车)的need是：顺畅行驶。如何实现Christopher Alexander所说的 "perfect balance between the needs of the parts, and the needs of the whole" 呢?

[#764]<英国前首相撒切尔夫人曾说：今天中国出口的是电视机，而不是思想观念。> 近代中国人喜欢贬视<拥抱愚蠢梦想>的思考者，而尊崇追求<看得到摸得着>的实践者。因此，只能出口电视机。http://t.cn/zOPVBEA

[#765]在iPhone、iPad产品生产上，美国(苹果公司)和中国(富士康)是两个parts，那么你知道此情境下的whole为何呢? 三者的needs又是甚么? 如何达到完美平衡呢? <谁>掌控这项平衡? 利润有如何共享与分成呢?

[#766]#架构师思维练习# 需求(Requirements)与设计(Design)有甚么关系呢? 目的关系(1)：设计支撑需求；设计是手段，需求是目的。目的关系(2)： 需求检验设计；需求是手段，设计是目的。两者都对，但是要留意来源关系，如果设计是<基于需求(requirement-based)>应是错的；亦即，设计不应从需求衍生出来。

[#767]如果D从R衍生出来；则拿R来检验D的有效性就大大降低了。所以，美国大学通常都会要求自己培养出来的博士学生，必须先到别的学校去教学，才受欢迎回母校当教授。因之，如果D来自R，则R就无法有效检验D；因此D不应从R衍生出来。

[#769]#先进架构设计思维# 还是有人再问到可能性与机率性的区别。<可能性(possibility)>是指一个事件无论其发生机会有多渺茫，它仍然可能实际发生；领导者常关注它万一发生了，可能导致的灾难性后果 。<机率性(probability)>是指一个事件在未来被人预期会发生的或然率；管理者常视同一件事情的成功机会。

[#771]#先进架构设计思维# 创意者。环球影城副总裁Hettema说：<创意者有三种。第一种是能想出好点子的人，解析问题并提出解决方案。第二种人能举一反三，看出其中关联，然后将解决方案应用到另一个问题情境上。第三种人能在脑海里将整套系统方案与世界概念化。想做出优质电影，三者缺一不可。>

[#772]#架构师思维练习# 删除法。开发者和管理者，常凭<过去>经验而挑选一条看来成功机率性较高的路径X。架构师常从未来回顾现在，很容易看出路径Y才是抵达未来目标最佳路径。此刻架构师不能专注于正面说明路径Y优于X，而是要专注于: 1)清晰叙述未来目标；2)找出事实删除路径X。如此才可能说服他们放弃X。

[#773]#架构师思维练习# Bono思考法：县太爷想娶姑娘为妾，故意逮捕她父亲。村长约定公开抽石子决定。隔天众人围观，村长拿一个袋子将放入两个黑白石子让姑娘抽取其一，若抽到黑色就必须嫁给他，反之不必。此时大爷从地上捡取两颗黑色石子放入袋，只有姑娘看见，却不敢吭声以免激怒大爷。请问姑娘如何应对?

[#774]如果姑娘被困住了，表示姑娘心中有一个假设(assumption)：众人要看我抽出来那颗石头的颜色。因此姑娘逃脱不了自己的思维束缚。

[#775]假设(assumption)。这个思考法练习，目的在于探讨，大部分人面临突发状况，会一时被困住，不知所措，任人摆布。重点在于：为何会被困住呢? 原因是甚么? 可能与自己的思维习惯息息相关而不自知。意谓着人们思维习惯里蕴藏了许多隐晦的假设，常常让自己寸步难行。更多新思维：http://t.cn/8FqOSGr

[#776]有一家百货公司贴出公告：<本周末下午2:00准时举办上空泳装选美大会。> 周末到了，吸引了众多男士前来观赏，选美尚未结束，男士们都失望地走光光了。Why? 这些笨男士们当时心中有个Assumption：选美大会参加者必然是女性。这并非真理，但是自己当时信以为真，而未曾反思，才变笨男士。

[#777]新年初一阅读<<呆伯特法则>>一书，其写到：有些公司藉由调整经营计划来追求所期望的未来，这常常是徒劳无功的。因为调整计划背后的假设(Assumption)部分，便能获得同样的效果。别忘了，未来是建立在假设之上(the future depends on assumptions)，而假设都是你自己编出来的。没有必要自己绑住自己。

[#778] #EIT架构设计思考# 我认为，改变架构师对 {基类 / 子类} 造形的视角，让架构师更有效支持敏捷，可大幅提升敏捷流畅性，是有价值的。同样的{基类 / 子类} 造形，却是extends关系，这是1996年诞生Java时就有的。架构师本来就会注意：形(Form)与视角(View)的关系。

[#779] @让您成为杰出架构师#IT+Design Thinking# 现在主要的议题是：如何培养架构师的思维去设计这种组合架构，来配合敏捷跌代，提升敏捷的流畅性。更多新思维：http://t.cn/8Fo3z3r更多新思维：http://t.cn/8Fo3z3r

[#780] <继承和接口，反应了框架的构建思想，简单但有代表性> 很好的注释。 我还想提出，架构师除了关注架构的涵意之外，还要注重设计思考，例如：当基类不再是"抽象类"的系统情境下，这样的基类是如何设计出来的呢? 我们惯用的 "抽象思考" 是不是反而成为一种偏执呢? 也可能是阻碍敏捷的因子呢? 值得反思。

[#781] #EIT架构设计思考# {基类 / 子类} 是软件开发者人人知晓的最基本软件架构造形(Form)，但是人人都能以不同的视角(View)去看它。其中，更多的是，大部分人一辈子都偏执于单一的视角去看它。各项观点都不是本质或真理，而只是视角或观点而已。各项观点都没有对与错；唯一错误的可能是：偏执于单一观点。

[#782] #EIT架构设计思考# <加个部件的基类>，也是 {基类/子类} 的造形，还是一样的设计思考问题：这个部件的基类，与部件子类之间是 "抽象关系" 吗? 谁调用谁? 抽象些什么? 是不是又要找到几乎完整的子类之后，脑海里才能进行抽象思考，是不是又违背敏捷的 simple solution原则呢?

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

[#784]过去一年来，我在面对 {Android + 敏捷} 的谜题上，我逐渐发现这个 {基类 / 子类} 基础造形的特别视角，正是这项谜题的答案。于是我称之为 EIT造形，在外观上是传统的{基类 / 子类} 基础结构；但是其幕后设计思维是完全不同维度的；而且对敏捷的顺畅性具有决定性的影响。于是我就提出来与大家共享。

[#785]回复KorukH: 我年轻的时候，处处想把IT智能应用到别的行业，后来觉得是"吃里扒外"；决定改邪归正，从各行业里扒来他们的智慧，充实软件产业的内涵。这句话就是我扒来的。 经典的一句话：Don't call me,I'll call you back. 这是好莱乌大明星的名言，是我把它拿来软件业而已。

[#786]我也发现： "Call back" 这个名词阻碍了架构师的思维视角。例如，谁才是老大呢? 谁启动这一串的相互之间的 "call" 呢? 如果Call back 隐含了：子类(App)里有个main()函数，它是主动发出第一个call的一方。我认为就误导了架构师的思维视角，是不好的。

[#787] #EIT架构设计思考# 许多人放不开App为主的心理，承受不了身为App开发者沦为 "配角" 的心理失落感。就不容易 "知彼知己" 看到整体和全貌；也就不容易找到架构设计的新视角，调整产业或企业的脚步和方向，和新落脚处。例如，下图的<E>和<T>谁是老大呢? 谁call 谁? 那个方向才是call back呢?

[#788] IT专家网:哪个方向才是call back呢?回复IT专家网: A先call B, 而B才call back to A。这是一般的合理说法。所以应先厘清谁先call。通常，大家认为App是先call平台，平台才call back to App。这是古典平台的情形，在今天的framework-based平台，是由平台先call App的。

[#789] #EIT架构设计思考# 在软件的世界里，App早已经沦为 "配角"。例如，Android的App里没有main()函数，没有主控权；再如，App里的Activity、Service的子类的对象都不是App自己创建的。失去了主控权，连自身的生杀大权都 "身不由己" 了。所以软件架构师应该放弃从App看世界的古典视角。

[#790] #EIT架构设计思考# 基于传统的面向对象思维，会认为基类(Thread)里的函数是从多个子类之中所抽象出来的；尤其是抽象的run()函数。如此，就很难理解图里的runnable接口是如何设计出来的。这种抽象思维比较难以搭配敏捷开发的跌代过程。

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

[#792] #EIT架构设计思考# 一旦软件架构师采取了新潮的 "创新组合" 视角，除了能有效支持敏捷跌代过程；还能够有效促进软硬结合设计。例如，下图左边是：主硬件 + Dongle插件 + 血压计配件。右边则是以 {基类 / 子类 } 基本软件结构来整合上述的硬件模块。这就是典型的软硬结合产品；其中，软件是整合的主角。

[#793] {基类 / 子类} 结构，是传统面向对象的抽象视角，从已知的子类里抽象出基类。附图右边的 {基类 / 子类} 结构则是已知的基类，来包容未知的插件和配件(医疗仪)。同一种结构表达两种涵意。

[#794] #EIT架构设计思考# {基类 / 子类} 结构的用途之一。目的是：A(手机) 将来需要与B(医疗仪器)沟通；然而，在开发A时，B是未知的，而且B的接口也未知；如附图的左边。于是，采用 "子类插件" 结构来担任未来的绑定(Binding)任务。

[#795]设计模式是1995年写的，当时还是以inheritance来看{基类/子类} ；1996年Java出来，已经加上 extends 视角了。GoF设计模式是基于古典视角的。

[#796] <前期架构建模和敏捷迭代并不抵触> 这是目的，希望架构设计能配合敏捷跌代，而不是敏捷跌代反过来配合古典抽象思维下的架构设计。前天撰写基类，昨天撰写子类，今天早上compiling，下午运行(runtime)时才去执行基类代码(子类名称昨天已经定案)，去创建子类对象，是可行的呀。

[#797]例如， Android里的 class HelloService extends Service { ... }; 到底谁来创建HelloService子类的对象呢? 如何创建呢? 古典抽象思维才偏执于：{ 基类 / 子类 } 一定是继承。新潮视角下，{ 基类 / 子类 } 结构也能是组合呀 !!

[#798]架构师是否需要考虑代码结构呢? 代码结构就只有一种：{基类/子类} 结构。我主张任何架构设计必须能直觉地落实为代码，对敏捷开发比较有帮助。

[#799] @让您成为杰出架构师#EIT架构设计思考# 在 {基类 / 子类} 基本结构里，到底是有谁来 "创建" ( new ) 子类的对象呢? 这是许多App开发者所忽略的视角，却是非常重要的。http://t.cn/8FbhmdD

[#800]从古典的抽象视角来看，基类是稳定的。从新潮的 "组合创新" 视角来看，基类可以是善变的，基类可以包容多变的通信协议。所以，基类不一定是抽象类，这才能有效支持敏捷开发。

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

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

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

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

[#810] <HTML5 + EIT造形> 浏览器轻量化(做减法设计)让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个月来，苦思<Android+敏捷>谜题，我开始学习划 "蛇板" 领悟身体像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] <Android + 敏捷> 许多人尝试了，许多人遇到复杂的难题。高老师闭关苦思，解开了这个谜题，从复杂中得到了简单的答案：改变我们对架构的视角、认知和心中的假设(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造形里的<T>。

[#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个月透入创意构思。欢迎您多观照高老师的<<IT+设计>>的创意行列...。

[#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

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