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

前言：架構設計的主要流派有二：1) 抽象思惟派：致力於抽象出穩定、可靠、不變的共同性架構；亦即，追求<萬變不離其宗>的宗。2)組合創新派：致力於組合出具體獨特性的創新架構；亦即，追求<不同凡響>的特質。你屬於哪一派呢? html

許多人認爲架構設計要基於用戶的需求(Requirements)，然而當用戶需求不穩定而多變時，又該如何下手作設計呢? 答案是：以問題(Problem)和願景(Vision)爲出發點，"設計"出初期架構(Simple Solution)，展開敏捷迭代過程。在願景指引下，探索複雜謎題(問題)，而減法設計出"簡單"的Solution。 android

本書原因：高煥堂於2013年在日本退休以前，基於日本師徒制的要求而傳承給下一代架構師的架構思考技術(俗稱設計心法)。25年來他專精於A段(投資決策前)架構設計，退休閒暇將之寫成中文，歡迎你們指教。程序員

歡迎訪問 =>高老師的ADT技術論壇數據庫

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練設計模式

[#901]深圳原本就是全球最佳的 {軟硬結合、端雲整合、IT+設計} 肥沃之地，若是能藉由Android潮流而抓住機運，就能從微利而轉變成大利了。微信

[#902]從"虛實相依"的原則來看微信；OTT影響了運營商原來所處的虛實相依狀態，可是微信目前偏於虛，影響力道還不足。然而，從產業發展趨勢來看，Android的開源開放，給與各行業從新調整虛實相依的腳步；我認爲：包括物聯網、智慧城市在內，都不宜只停留在"物和網"的實體層思惟上。網絡

[#903]更多議題；硬硬結合銷售(大小配件整合銷售)是商機，SZ是全球最大的配件研發&生產城市。硬硬結合銷售須要有大市場的主件；最近<數字家庭產業聯盟>與我，正想在SZ創建這樣的舞臺。以智能TV爲主配件，主配件具有了，家庭內能與TV搭配的小配件，就有大商機。

[#904]@讓您成爲傑出架構師 架構設計的主要流派有二：1) 抽象思惟派：致力於抽象出穩定、可靠、不變的共同性架構；亦即，追求<萬變不離其宗>的宗。2)組合創新派：致力於組合出具體獨特性的創新架構；亦即，追求<不同凡響>的特質。你屬於哪一派呢? 更多新思惟：http://t.cn/8Fo3z3r

[#905]許多人認爲架構設計要基於用戶的需求(Requirements)，然而當用戶需求不穩定而多變時，又該如何下手作設計呢? 答案是：以問題(Problem)和願景(Vision)爲出發點，"設計"出初期架構(Simple Solution)，展開敏捷迭代過程。在願景指引下，探索複雜謎題(問題)，而減法設計出"簡單"的Solution。

[#906]敏捷開發爲什麼那麼依賴架構師呢? 我認爲敏捷迭代的背後有個架構設計迭代來支撐。例如，敏捷迭代的起點：simple solution就來自架構設計迭代的產出物(如附圖)。瞭解這以後，你就不會以爲simple solution很神祕了。

[#907]架構師的創意是上帝給人的基因 //朵兒叢子:感受像女人一輩子的演變 //高煥堂:茲用個比喻，架構的主人是願景(Vision)，架構的生母是問題(Problem)，架構的養母是現實(Reality or Constraint)，架構的養份是設計師的創意(Creativity)，架構的外貌是代碼(Code)，架構的情人是需求(Requirement)。

[#908]爲何，抽象思惟派架構設計與敏捷開發比較難以搭配呢? 理由是：抽象思惟派架構設計，致力於抽象出穩定、可靠、不變的共同性架構；作爲應用發展的基礎。可是，這樣的穩定架構不是迅速可得，不是"足夠好"而已，已經違背敏捷的Simple Solution的要求了，不易迅速推進敏捷迭代。

[#909]在敏捷開發裏，穩定、可靠、不變的共同性架構是持續減驗與調教(重構)的結果；並且隨着外在需求的變化，而從新調教出新的穩定結構和狀態；其穩定是動態平衡中的穩定，而不是真的萬變不離其宗的"宗"。動態平衡的穩定，並非不變的穩定。

[#910]組合創新派以"組合"爲目標，先定接口(Interface)來支持組合，並以接口包裝內部的結構，讓內部結構也是能夠變更的，以便支持彈性地敏捷重構，迅速取得動態的穩定。因爲接口只有定義沒有代碼，即便是Facade模式或EIT造形來表達接口，也是很簡單、容易得到，因此比較符合敏捷所要的Simple Solution。

[#911]隨着Android版圖，於2011年從手機開始擴大到電視、車載系統以後，現在成爲數字家庭的主流平臺；隨之將繼續邁入物聯網、智能城市領域。Android已經不只僅是用來寫寫單機的應用了。Android-based的大型系統整合，如同 OTT通常，即將成爲主流。Android須要新的架構設計思惟，以及PM、測試都須要擴大格局。

[#913]近年來，美國著名的史坦福大學大力推行"設計思考"(Design Thinking)，例如<<The Design of Business>>一書就應用於商業上。

[#914]"Innovation is born from the interaction between constraint and vision." (創新來自願景與限制的互動)。這可對映到另外一個說法："Architecture comes from the mapping from the vision to the reality"。架構就是創意的表示。

[#915]移動雲_曹文斌:我的認爲在Android上作TDD受限於單次部署時間的延長可能會帶來開發效率的下降。

[#916]@讓您成爲傑出架構師#架構與敏捷的完美組合# 其組合的關鍵在於對架構的核心的掌握。架構設計的核心任務就是"整合"，整合的目的就是要實現總體的"和諧"及其"獨特功能"。因而，架構設計的核心工做就是"接口"設計。而架構與敏捷完美結合之祕訣就是：每回敏捷的迭代，都讓其接口落實爲代碼，交給TDD來觸發反饋。

[#917]#頂層設計# 以智能家庭爲例，Android已經成爲平臺的主控者，這種Android-based系統涵蓋物聯網(如NFC)、雲計算和移動手機(及不移動TV)各層面。因而對開發者而言，面臨的挑戰是：系統整合、軟硬結合、跨芯片(和通訊)平臺、內容(信息)共享的需求。咱們真的須要<Android + 軟件工程>。

[#918]#頂層設計# 許多人把頂層設計翻譯爲Top-layer Design，而後把系統架構、網絡通訊架構歸於底層設計。其實這是很大的誤解!! 頂層設計應翻譯爲Hi-level Design纔對。是指投資決策前的規劃，相對的Low-level Design是指項目發包後，實際建置時的細節設計。二者是先後關係，不是上下關係。

[#919]#頂層設計# 頂層設計翻譯爲Top-layer Design，其實這是很大的誤解!! 正卻應該是：Hi-level Design，它是指投資決策前的規劃，它涵蓋了上層業務架構、中層系統架構和底層通訊架構，但僅僅是架構性的設計；而不是細節設計。更多新思惟：http://t.cn/8Fo3HIo

[#920]我曾經作了一個比喻：架構的主人是願景(Vision)，架構的生母是問題(Problem)，架構的養母是現實(Reality or Constraint)，架構的養份是設計師的創意(Creativity)，架構的外貌是代碼(Code)，架構的情人是需求(Requirement)，架構的歲月是迭代(Iteration)。更多新思惟：http://t.cn/8Fo3z3r

[#921]傳統Waterfall開發，屬於演繹邏輯(左圖)：從需求可演繹出來代碼和架構。如今的敏捷開發，屬於朔因邏輯：架構和代碼都不是純然從需求演繹出來，而是假定-否證的邏輯。這是<從程序員到架構師之路>幕後的哲學。

[#923]在軟件開發上，關於"架構設計"每每比較重視"架構"而不是"設計"，所以對於設計思考、設計技術並不過重視；這樣會影響到智能終端設計的優劣，由於具備設計思考的人員只能當"美工"化妝UI而已。因而致使，沒有設計的架構，化妝效果有限。

[#924]個別孤島的用戶體驗，即便都不斷提高，客廳的總體用戶體驗卻往下滑；由於個別部分(Part)的總合經常不會等於總體(Whole)；反而像一架飛機，個別都不會飛，總體卻能飛上天空。

[#925]@讓您成爲傑出架構師開源頂層框架可支持數字家庭總體產業的創新型商業模式。例如，由秦皇島數字加停產業聯盟所提倡的新型商業模式："硬硬結合銷售、軟硬結合開發"。就是基於"開源頂層框架"來支撐總體產業的"智能電視(主件) + 家用醫療健康小配件 + 醫療雲服務" 的整合營銷策略。更多新思惟：http://t.cn/8Fo3z3r

[#926]其中，值得特別留意的是：什麼是"本質"呢? 華人很喜歡談本質，其意義偏於"恆久不變的"核心部分，也就是萬變不離其宗的"宗"。這與洋人所談的"Essential"略有不一樣，洋人長談的"Essential"偏向於"不可或缺"的部分。其微妙差別在於：有些易變部分多是不可或缺的。

[#927]華人的"本質"偏於抽象思惟，把萬變的部分去掉，抽(像)出其萬變不離其宗的"宗"。洋人的"Essential"偏於減法思惟，把多餘的部分去掉，留下"不可或缺"的部分。例如，你們都知道j軟件是複雜(善變)的，因此複雜是軟件所"不可或缺"的一環。因此洋人Brook才說："The complexity of software is essential."

[#928]<<爲何一個家庭會有那麼多的機頂盒、電視棒、Dongle呢? >> 家庭裏的客廳原本是高雅設計的。隨着智能化、數字化，硬件廠商一直到處作加法，把客廳變成了設備的集裝箱。爲何沒有人來作減法設計呢? 若是您能讓客廳恢復簡單、可愛的靜地，極可能有機會成爲數字家庭產業的贏家呢!

[#929]<師字輩>(如股票分析師、拳師)能夠在家裏的 Android TV上執行本身的App，向雲端取得信息，而後由App處理，運行本身專業首創的分析算法，並定時推送給本身的客戶。在家工做，可避免堵車、節省能源、又提高家庭溫暖和親子互動，百利而無一害，必然受歡迎。

[#930]"秦皇島數字家庭產業聯盟"正開發家庭"師字輩"(如股票分析師、拳師)的行業型API，師字輩專家在家裏的TV上執行本身的App，向雲端取得信息，而後由App處理，運行本身專業首創的分析算法，並定時推送給本身的客戶。API幕後就是數字家庭的"開源頂層框架"。

[#931]"硬硬結合銷售、軟硬結合開發" 商業模式。蘋果iPhone手機有數百種硬件配件，單單外套(Cover)收入都高於App。TV身爲家庭信息中心，只要基於頂層框架API和軟硬結合軟件，就能基於通用USB+Dongle模式來困綁衆多家用小配件，一塊兒銷售。這就是"秦皇島數字家庭產業聯盟"提出的產業新銷售模式。

[#932]@讓您成爲傑出架構師#架構與敏捷的完美組合# 其組合的關鍵在於對架構的核心的掌握。架構設計的核心任務就是"整合"，整合的目的就是要實現總體的"和諧"及其"獨特功能"。因而，架構設計的核心工做就是"接口"設計。而架構與敏捷完美結合之祕訣就是：每回敏捷的迭代，都讓其接口落實爲代碼，交給TDD來觸發反饋。

[#933]數字家庭的"開源頂層框架"，能夠支持Native App，也能支持HTML5 App。在位階上接近PhoneGap。可是PhoneGap內涵的大可能是平臺性插件；而"開源頂層框架"則內涵衆多行業型的插件，擁有豐富的專業領域知識，支撐行業型的API，來與智能城市的其它行業區塊對接。

[#934]開源平臺和開放服務api，橫向和縱向延伸，企業服務營銷平臺搭建一樣適合這模式，平臺解決的企業和外部的溝通渠道，服務api承載的是行業管理，諮詢服務。

[#935]數字家庭的"開源頂層框架"，能夠支持Native App，也能支持HTML5 App。在位階上接近PhoneGap。可是PhoneGap內涵的大可能是平臺性插件；而"開源頂層框架"則內涵衆多行業型的插件，擁有豐富的專業領域知識，支撐行業型的API，來與智能城市的其它行業區塊對接。

[#936]"開源頂層框架"的接口(Interface)分爲三類型：1) API，支持行業型App開發；2) SI，便是SoS(System of Systems)的接口，支持與智能城市其它行業區塊的橫向互聯互通；3)PI，便是插件接口，提供與底層平臺插件，以及行業知識插件的對接，進行縱向的系統整合。

[#937]"開源頂層框架" 以軟件模塊來支持和整合底層的各類硬件和(無線)通訊途徑；例如，支持NFC+WiFi、NFC+Bluetooth等的多樣化組合。以支持TV/STB與手機的互動和有關<雲+TV+Mobile+Sensor>整合的商業模式。數字家庭除了以往音視頻內容的消費終端以外，在智慧城市裏，家庭是很是重要的信息化活動場所。

[#938]將"架構設計"與"敏捷"二者作完美的組合，這自己就是一項完美的架構設計；而我這項組合工做也是經歷屢次敏捷迭代的，才得以成功的歷程。

[#939]@讓您成爲傑出架構師#設計思考與造形# "抽象型"架構師，喜歡單純作減法設計，獲得簡單的事物。"組合型"架構師，是爲了創新功能(加法設計)，而採起減法設計來實現之；獲得整合(可能簡單、也可能複雜)的事物。更多新思惟：http://t.cn/8Fo3z3r

[#940]許多架構師喜歡"抽象型"的架構設計；而我喜歡"組合型"的架構設計。前者目標是：抽象出穩定、可靠、不變的共同性結構。後者目標是：組合出新結構、支持獨特性功能；例如，將一羣不會飛的零件，組合成爲會飛的飛機。

[#941]"組合型"架構設計，其過程比較像設計師，比較不像科學家。由於經常發現組合不起來的困境，就必須去創造一些新東西來介接搭橋。例如，我就創造了EIT造形和中層設計，才能實現完美的組合。因而，EIT造形和中層設計成爲個人創新做品，也讓我這項完美組合具備"獨特性"。

[#942]@讓您成爲傑出架構師#設計思考與造形# 爲何我喜歡談造形(Form)呢? 回想我第一回到韓國時，有感於韓國建築物(實體)都是當地材料所造的；其造形是唐宋中國來的，而顯現出中華風格、文化的輸出。更多新思惟：http://t.cn/8Fo3z3r

[#943]許多人經常問我：作造形又不能賣錢，如何賺錢? 其實這不是問題，君不見，唐代盛世王朝，其輸出造形特別多。愈多造形國力愈強，國力愈強造形愈多。再看，歐美髮明瞭一個軟件產業人人知曉的軟件造形：類別(class)，其軟件實力和經濟收益很是高。因此，我一直不主張國人只寫App，而應重視造形的創新。

[#944]許多人經常問我：作造形又不能賣錢，如何賺錢? 這不是問題，茲舉個例子，IBM發明了Database的E-R model數據庫造形，不斷成爲IBM和Oracle公司擴充市場版圖的利器。

[#945]Class是一個很是簡單的造形，在1980年代橫掃整個軟件產業，改變了主要語言，這就是面向對象(Object-Oriented Programming)的潮流，至今的主流的Java語言也是OO的。洋人熱衷於開發造形，國人則熱中於(造形的)應用。造形帶動潮流，稱爲時尚、風格。

[#946]爲何在IT產業裏，軟件開發者被稱爲"碼農"；而UI設計者被稱爲"美工"呢? 其實也不是沒道理的，道理是：都是拿別人創做的造形來套用，作出能賣錢的App。別人創做(造形)，咱們使用；別人造車，咱們開車；被稱司機(而不是稱師傅)也算合理。

[#947]"減法設計"思惟，古代的"容易"是包容改變的意思，並不是捨棄改變之意。如此，化繁爲簡，提高人們掌握複雜的能力。逐漸地，國人喜歡抽象(Abstraction)，抽出萬變不離其宗的"不變"，來掌握簡單。這就違背了"容易"的標的了。

[#948]數字家庭或智能城市幕後的系統架構到底分爲幾層(Layer)呢? 人人想法都不一樣。最多見的想法是兩層：網絡通訊層和業務應用層；這認爲互聯互通是網絡通訊層的事，應力求[#949]訂定通訊標準。另外一種想法是三層：通訊層、軟件框架層和應用層；這認爲互聯互通是框架層的事，應力求包容通訊協議的多樣化。您的想法呢?

[#950]強大的文化中國應該輸出造形，而不是輸出實體物(如冰箱)。最近，個人EIT造形最近也輸出到日本和印度尼西亞。

[#951]插上200多元RMB的電視棒就能跑Android股票分析的App，透過家中的WiFi能取得窗外雲端的股市最新情報；處理運算以後，透過家中的WiFi 推送到本身的客戶手機中。比買一臺PC或平板便宜多了，何樂不爲呢? 買一個大屏只用來當影視播放器，太奢侈了。

[#952]@讓您成爲傑出架構師 #架構與敏捷的完美組合# Android進入家庭，掌控家庭智能設備的軟件OS層，早已成爲定局了。最佳對策是：水漲船高，在Android之上，創建一個"開源頂層框架"，並訂定"開放行業型API"，並有效實踐跨(Android)平臺(例如善用高老師的EIT造形)，強力掌握行業型App。更多新思惟：

[#953]智能TV與智能手機之間還有許多想象空間，TV不只僅是影視播放器，手機不只僅是TV的遙控器。爲何手機要"控制"TV呢? 當TV貼上一張NFC Tag時，手機和TV能夠"親親"(嘴)相親相愛，而不是誰控制誰了。今後公主王子過着幸福快樂的家庭生活，永浴愛河。

[#954]若是Fred George架構師所設計出來的Simple solution(architecture)是一顆鑽石的話，那麼實踐的代碼，就是這顆鑽石(內在)的外貌。迭代過程如同女大十八變，內在夢想(Vision)依舊，外貌動人(改變了Stakeholders的需求)。

[#955]<秦皇島數字家庭產業聯盟>正積極開發家庭<師字輩>(如股票分析師、拳師)的行業型軟件框架API，支持以智能TV爲中心的家庭專業服務應用(如附圖)，並透過OTT型式將專業信息推送到移動終端的畫面(如微信、Line)上。將來將進一步將該軟件框架平臺開放給產業，成爲行業型開源開放平臺。

[#956]<<大約15年前，RFID技術先驅凱文•阿什頓(Kevin Ashton)創造了「物聯網」(IoT)一詞，他相信物聯網能改變咱們所處的這個世界，由於「若是咱們擁有可以感知一切的電腦存在，那麼咱們就可以感知一切事物」。>>

[#958]回覆宇宙教父: 因此，不要用"古典的抽象" 角度去看"容易"，它只是很簡單地把複雜包裝起來而已。就像集裝箱把雜物包裝起來，容易運輸和管理而已。

[#959]@讓您成爲傑出架構師 組合創新派以"組合"爲目標，先定接口(Interface)來支持組合，並以接口包裝內部的結構，讓內部結構也是能夠變更的，以便支持彈性地敏捷重構。例如，軟件層的Socket接口能夠是較穩定的，此接口的實現類內涵可變更，包括Socket接口在通訊層的實踐通訊協議(如Zigbee、藍芽等)都是可重構、可變更的。

[#960]數字家庭設備的"模塊化"一直都是物聯網領域的理想境界，但是模塊化很是依賴無線通訊的統一與標準化。理論上，通訊的統一是有利於模塊化的大量製造和下降成本。然而，理想歸理想，標準化等於給了小公司進入市場削價競爭的機會，市場老大誰願意呢?

[#961]回覆小笨熊ZJ: 把通訊協議包容於兩端的軟件基類裏，提供軟件接口(如Socket)，而兩端邏輯模塊則寫在兩端的子類裏，調用基類的Socket接口就好了。將來通訊協議改變了，兩端的基類內容更改便可，Socket接口不變。

[#962]爲何，我積極把敏捷開發(Agile)帶進Android世界呢? 由於Android已經跨越單機開發，邁入多機整合、多屏互動的領域了。尤爲是當今兵家必爭的智能家庭，以及新興的智能城市領域。Android的項目日益擴大、複雜化。咱們須要加入新潮的軟件工程、新一代的架構設計思惟和模式。

[#964]爲何敏捷開發與Android是個好的搭配呢? 理由之一是：Android有完善的測試框架，有利於創建TDD測試機制來推進迭代過程。理由之二是：Android平臺架構是一個[#965]多層框架體系，框架內涵是代碼，知足敏捷原則：」各項架構設計決策都必須迅速落實爲代碼」；有利於讓敏捷方法漂亮地」落地」在Android平臺上。

[#966]{ Android + 敏捷 = ???? } 當Android開發團隊趕上敏捷方法，會如何呢? 這是我最近4個月來，主要的思考議題之一，我發現必須調整幕後的架構設計方法，從原來的你們熟悉的"抽象思惟派"設計，改以"組合創新派"設計；今後王子、公主過着幸福快樂的日子，你相信嗎?

[#968]若是你想知道我是如何將<開發、架構與敏捷>三者組合起來的，就必須理解這圖理的兩種不一樣的推理邏輯。

[#969]請留意，朔因邏輯(右圖)是<假定-否證>的邏輯，而不是"實證"邏輯，這是初入們架構師最常誤解的地方。因此，敏捷的TDD主要任務不是來證明你的架構和代碼，而是來否證，並將被否認的部分反饋回去給架構師和開發者，而帶動一次新的迭代。

[#970]剛纔有粉絲提到：＂android+敏捷不太好，在移動項目中會碰到太多問題＂。這能夠另外一種說法更合理：由於Android與敏捷融合得不完美(不太好），因此在移動項目中會碰到太多問題。你以爲呢？

[#971]史坦福大學馬丁教授在其著名的("The Design of Business")一書裏寫到："限制(constraint)迫使你運用創意，它讓你聚精會神、釐清思路。" 這(限制)和敏捷的TDD角色是同樣的。

[#972]在一個企業(或公司)裏，程序員、架構師和高層經裏三者之間有着"戰術引導戰略"的重要關係。經理與架構師之間是：戰略-戰術關係；而架構師與程序員之間也是：戰略-戰術關係。敏捷方法，讓"戰術引導戰略"的機制實際運行起來，例如TDD對代碼(戰術效果)檢驗的反饋，帶動了架構的重構(戰略調整)。

[#973]也許您會問道，爲何咱們積極把敏捷開發(Agile)帶進Android世界呢? 由於Android已經跨越單機開發，邁入多機整合、多屏互動的領域了。尤爲是當今兵家必爭的智能家庭，以及新興的智慧城市領域。Android的項目日益擴大、複雜化。咱們須要加入新潮的軟件工程、新一代的架構設計思惟和模式。

[#974]在我最近三個多月來，思考如何實現<Android + 敏捷>的最佳組合，其中還有一項"敏捷"的收穫：高老師學會了劃 "蛇板"，在Android還沒有敏捷起來以前，高老師本身先敏捷起來。找個時間拍個視頻來與粉絲們分享"蛇板"之樂。

[#975]洋人的肯德基炸雞餐廳，廚師作"分"，就是庖丁解雞(切分紅雞腿、雞翅等)；而櫃檯的工讀生作"合"，就是組合成半雞、全雞、套餐等。華人的全聚德烤鴨餐廳，你知道誰作"分"嗎? 誰作"合"嗎? 兩種餐廳的架構設計與分工模式有何關係呢? 他們屬於哪一派呢?

[#977]比爾蓋茲(Bill Gates)曾說："願景是免費的東西。所以，不管是以什麼方式、什麼形式提出來，都不算是一項競爭優點。"(Vision is free. And it's therefore not a competitive advantage in any way, shape or form.)。然而，當它搭配上策略和戰術以後，卻成爲競爭優點的核心。

[#978]關於頂層設計的涵義一直見仁見智，然而基於我曾經從事DoDAF架構設計實務經驗來看，我認爲在智慧城市領域的頂層設計，應該是指：Top-level Design 或 High-level Design。然而許多人誤解爲：Top-layer Design，或Top-tier Design。

[#979]Top-level Design與Low-level Design之間的差別；意味着不一樣的決策(Decision-Making)階段的區別。其中，Top-level Design偏於投資決策前的(高階)設計階段，作爲政府立項投資決策的評估依據；而Bottom-level Design則偏於決策後(已經立項了)的實踐考慮的細節設計階段。這兩階段是有時間上的落差的。

[#980]抽象派：抽象出穩定、可靠、不變的共同性架構。 組合派：增添一個"合"元素，組合出具體獨特性的創新架構。 "合"元素的影響：以"組合"爲目標，先定接口(Interface)來支持組合，並以接口包裝內部的結構，讓內部結構也是能夠變更的，以便支持彈性地敏捷重構。

[#981]把敏捷開發(Agile)帶進Android世界!! Android已經跨越單機開發，邁入多機整合、多屏互動的領域了。尤爲是當今兵家必爭的智能家庭，以及新興的智慧城市領域。Android的項目日益擴大、複雜化。咱們須要加入新潮的軟件工程、新一代的架構設計思惟和模式。

[#982]創新組合派的創意主要來自設計思考(Design Thinking)模式，就是：溯因(Abductive)邏輯思考。不管是移動應用、物聯網等都涉及越來越多的系統組合或整合。而軟件開發(如敏捷方法)，越來越仰賴架構設計，因此架構師們亟須要去學習和領悟創意型的架構設計模式。

[#983]創新組合派：願景是起點，創新組合是目標，需求用來檢驗；因此又稱爲Test-Driven架構設計方法。

[#984]國脈微物聯：<<智慧城市是21世紀城市發展的最終目標>> 這句話有凍結城市將來(Frozen the future of city)之嫌，創造永續發展，給與城市更多"不設計"的空間，是更好的頂層設計。

[#987]像Skype、微信、Line等是(移動)互聯網的OTT產品，是在"網絡通訊層"之上，再創建一個"軟件整合層"(簡稱OTT層)。相對上，"網絡層"就像陸地上的火車、汽車道路；而"OTT層"就像天空上的飛機航線。

[#988]我主張推展物聯網OTT，由於把物"聯"起來以外，還要把"人"聯起來。例如，數字家庭(物聯網)的OTT 聯結到社交OTT(如微信、Line等)，從物聯網原來的"監控"視角，轉移到"舒適關懷"的視角。

[#990]相對上，Skype、Line、微信等OTT是屬於"移動型"的OTT；而家庭物聯網上的OTT，則是"不移動型"OTT。兩種OTT互相銜接，讓物聯網+人聯網，創造更多的商業模式。

[#991]因爲架構設計有兩個基本技藝：抽象與組合。所以衍生兩個不一樣的架構設計流派。1)抽象思惟派：致力於抽象出穩定、可靠、不變的共同性架構；亦即，追求<萬變不離其宗>的宗。2)創新組合派：致力於組合出具體獨特性的創新架構；亦即，追求<不同凡響>的特質。

[#992]從{分vs.合} 看架構設計。洋人的肯德基炸雞餐廳，廚師作"分"，就是庖丁解雞(切分紅雞腿、雞翅等)；而櫃檯的工讀生作"合"，就是組合成半雞、全雞、套餐等。華人的全聚德烤鴨餐廳，你知道誰作"分"嗎? 誰作"合"嗎? 兩種餐廳的設計與分工模式有何關係呢?

[#993]<創新組合派>最傳神的隱喻是，谷歌公司副總Marissa Mayer所提倡的：「創意愛上限制」(Creativity loves Constraint)。

[#994]<<架構師如何更具創造力呢? >> 完成性假設是樂觀的，意在激發人們腦海裏的觀想(Visualization)能力，像愛迪生髮明燈泡、萊特兄弟發明飛機等，都是先把所要發明的事物化爲有形，激發樂觀的信心和想象，成爲人類進化動力。

[#995]回覆張湯_: <簡單化的形式是否可理解爲抽象後的模型>，簡單化是設計出來的，抽象只是諸多設計思考之一，這是國人經常混淆的地方，要明辨之；國人善於抽象，但卻不擅長設計!!

[#996]減法設計有兩個主要途徑：抽象與組合(封裝)。所以衍生兩個不一樣的架構設計流派：1) 抽象思惟派：致力於抽象出穩定、可靠、不變的共同性架構；亦即，追求<萬變不離其宗>的宗。2)組合創新派：致力於組合出具體獨特性的創新架構；亦即，追求<不同凡響>的特質。

[#997]@讓您成爲傑出架構師 #設計思考：有效減法設計# 什麼是減法設計呢? 減法設計的最基本手藝是：刪除與包裝(隱藏)。刪除就是偉大的雕刻師羅丹所說的：把不要的部分去掉。對於沒被刪除的，人們又沒必要直接關注(pay attention)的部分，使用障眼法將它移開視線。更多新思惟：http://t.cn/8Fo3z3r

[#998]洋人常說：The complexity of software is essential. 而華人則說：軟件的大道至簡。有人認爲軟件的本質(道)是至簡的；有人認爲軟件的本質(Essence)是複雜的。您比較認同何者呢?

[#999]硬件廠商一直到處作加法，把客廳變成了設備的集裝箱。一個小小的數字家庭，將會有越來越多的信息孤島。愈大的廠商擁有愈大的島，但仍是孤島。欲實現互聯互通、信息共享，只好開始作減法：繼續硬件做加法(不要求硬件&通訊標準化)，力求以開源開放軟件平臺上做減法設計。

[#1000]roadonroad:加法和集裝箱的說法頗有意思，其緣由在於個性的演化和不肯定，而減法的緣由一般緣於各種產品間的功能重疊或綁定關聯，這須要有一套開放的架構來保證鬆耦合基礎上的隨需而變。

[#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]目前對於互聯互通的標準思惟，偏於網絡標準，還停留在基礎的減法設計層面，就像秦國"書同文、車同軌"階段。在面對更復雜的智慧城市時，咱們須要更高境界的減法設計，就像唐代的"詩同形"。詩同形既不侷限李白、杜甫的創意情境，又能互聯互通，不亦美哉!!

[#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)來觸發迭代，帶動設計的重構，調整出最適時的新設計來捕捉將來的機運。

高煥堂：MISOO(大數據.大思考)聯盟.臺北中心和東京(日本)分社.總教練