高老師的架構設計_雋語集(BB_0751)

前言：基於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

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